From noreply at sourceforge.net  Sat Jul  1 00:03:59 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 30 Jun 2006 15:03:59 -0700
Subject: [ python-Bugs-1501934 ] incorrect LOAD/STORE_GLOBAL generation
Message-ID: <E1FwR5j-0005Eo-D4@sc8-sf-web5.sourceforge.net>

Bugs item #1501934, was opened at 2006-06-06 23:57
Message generated for change (Comment added) made by nascheme
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501934&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.5
Status: Open
Resolution: None
Priority: 8
Submitted By: Thomas Wouters (twouters)
Assigned to: Jeremy Hylton (jhylton)
Summary: incorrect LOAD/STORE_GLOBAL generation

Initial Comment:
Python 2.5 compiles the following piece of code
differently than Python 2.4:

g = 1
def f():
    g += 1

In Python 2.4, this raises an UnboundLocalError. In
current svn trunk, it will increment the global g by 1.
(dis.dis shows that it actually compiles into
LOAD/STORE_GLOBAL opcodes.) It seems the compiler
doesn't treat augmented assignment as assignment for
the purpose of determining locals, as this still fails
correctly:

g = 1
def f():
    g += 1
    g = 5

I can't find where this optimization happens nowadays,
but it feels like a short fix.


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

>Comment By: Neil Schemenauer (nascheme)
Date: 2006-06-30 22:03

Message:
Logged In: YES 
user_id=35752

Adding a patch to "fix" test_ast.py.  I have no idea what
the test is trying to verify.  It looks like it was written
by martin.v.loewis so maybe he can comment.

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

Comment By: Neil Schemenauer (nascheme)
Date: 2006-06-30 17:51

Message:
Logged In: YES 
user_id=35752

I've got a simple fix that seems to work.  I feel this part
of the compiler could use some more serious cleanups but
probably not for 2.5.  Note that test_ast fails after
applying my patch.  I haven't had time to look into that yet
but I think it's shallow.

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

Comment By: Neil Schemenauer (nascheme)
Date: 2006-06-30 16:22

Message:
Logged In: YES 
user_id=35752

Here are some notes in case I wear out before finding a fix.
 analyze_name() gets to the SET_SCOPE(dict, name,
GLOBAL_IMPLICIT) line because the name does not have the
DEF_LOCAL flag set as it should.  It does not have DEF_LOCAL
because Name.ctx for 'g' is Load.  I believe there should be
a set_context() call in ast_for_expr_stmt, as flagged as
TODO by  Jeremy.  Maybe set_context(..., Store, ...) would
work or maybe things need to be changed to allow ctx to have
AugAssign as a value.

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

Comment By: Thomas Wouters (twouters)
Date: 2006-06-19 17:44

Message:
Logged In: YES 
user_id=34209

Possibly related is the discovery of free variables (used
when forming closures) and optimized-out codeblocks:

>>> def foo(x):
...     def bar():
...         if 0:
...             print x
...     return bar

In 2.4, there is no closure:
>>> foo.func_code.co_cellvars
()
>>> foo(5).func_closure
>>>

In 2.5, there is:
>>> foo.func_code.co_cellvars
('x',)
>>> foo(5).func_closure
(<cell at 0x2b9abf6d7e30: int object at 0x6b6580>,)

(I don't think it's unreasonable to declare the old
behaviour bugged, though :-)


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

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

From noreply at sourceforge.net  Sat Jul  1 01:12:51 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 30 Jun 2006 16:12:51 -0700
Subject: [ python-Bugs-1513646 ] os.access reports incorrect write permissions
	in Windows
Message-ID: <E1FwSAN-0007Ov-FU@sc8-sf-web5.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.5
Status: Open
Resolution: None
Priority: 7
Submitted By: Yi S. Ding (yi_ding)
Assigned to: Martin v. L??wis (loewis)
Summary: os.access reports incorrect write permissions in Windows

Initial Comment:
Platform: Python 2.5b1 Windows XP

Bug:
os.access will report that a user doesn't have write
permissions to a file or directory when the user
actually does.

Reproducibility: always

This is being run on an administrator account.
>>> import os
>>> os.access("C:\\", os.W_OK)
False
>>> os.access("C:\\test.txt", os.W_OK)
False

I have also checked that Python can indeed write to the
file.

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

>Comment By: Yi S. Ding (yi_ding)
Date: 2006-06-30 16:12

Message:
Logged In: YES 
user_id=1081617

Cool.  I added the new patch with the test case.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-06-30 00:12

Message:
Logged In: YES 
user_id=33168

Your change looks correct, but I would really like a test
case to fix this problem.  I don't have access to a Windows
box, so I can't verify the test fails before this patch and
succeeds with it.  Can you create a test case too?  The best
place to add the test would be Lib/test/test_posix.py.  Thanks!

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

Comment By: Yi S. Ding (yi_ding)
Date: 2006-06-29 12:56

Message:
Logged In: YES 
user_id=1081617

Yeah, it's only 2.5, and only 2.5b1.  Basically, there's a
double ampersand used instead of a single ampersand in
posixmodule.c.  I've attached the patch.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-06-27 22:28

Message:
Logged In: YES 
user_id=33168

Does this problem only occur with 2.5 or is it also present
in 2.4?

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

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

From noreply at sourceforge.net  Sat Jul  1 02:46:52 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 30 Jun 2006 17:46:52 -0700
Subject: [ python-Bugs-1202533 ] a bunch of infinite C recursions
Message-ID: <E1FwTdM-0007e2-I0@sc8-sf-web5.sourceforge.net>

Bugs item #1202533, was opened at 2005-05-15 16:43
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
>Assigned to: Armin Rigo (arigo)
Summary: a bunch of infinite C recursions

Initial Comment:
There is a general way to cause unchecked infinite recursion at the C level, and I have no clue at the moment how it could be reasonably fixed.  The idea is to define special __xxx__ methods in such a way that no Python code is actually called before they invoke more special methods (e.g. themselves).

>>> class A: pass
>>> A.__mul__=new.instancemethod(operator.mul,None,A)
>>> A()*2
Segmentation fault

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

>Comment By: Brett Cannon (bcannon)
Date: 2006-06-30 17:46

Message:
Logged In: YES 
user_id=357491

OK, new patch, with the check in PyObject_Call() (and thus
slot_tp_call() recursion check removed), the addition of
PyExc_RecursionErrorInst which is an instance of
RuntimeError and a reasonable message set, and
PyErr_NormalizeException() checking the recursion depth
directly and using PyExc_RecursionErrorInst when the limit
is hit.

Hopefully this does it.  =)

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

Comment By: Brett Cannon (bcannon)
Date: 2006-06-30 10:06

Message:
Logged In: YES 
user_id=357491

Seems reasonable to me.  I will try to cook up a patch after
I am done trying to fix the xml_parsers.py crasher.

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

Comment By: Armin Rigo (arigo)
Date: 2006-06-30 00:14

Message:
Logged In: YES 
user_id=4771

Looks quite obscure, a hack to avoid the bad effects of the
previous hack of temporarily decreasing the recursion depth
(which no other piece of code does).  I'd be much more
confident that I'm looking at correct code if we used a more
explicit approach.  What about a prebuilt RuntimeError
instance with the message "maximum recursion depth
exceeded", similar to the prebuilt MemoryError instance?

Then at least PyObject_Call() could raise this instance
directly, with PyErr_SetObject().  We'd get an
already-normalized exception in this way, and remove any
need for tstate recursion_depth mangling.

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

Comment By: Brett Cannon (bcannon)
Date: 2006-06-26 12:31

Message:
Logged In: YES 
user_id=357491

Yes, Armin, that is a rather evil piece of code.  =)  But I
have a possible simple solution.  =)

If you add a check after the PyExceptionClass_Check() in the
'if' statement that tstate->recursion_depth is greater than
0, you short-circuit the infinite recursion and still get a
sensible output.

I have attached a patch with my proposed changes for
PyObject_Call() and PyErr_NormalizeException() and the
remove of the recursion check for slot_tp_call().  The only
issue I can see with this is if the recursion_depth check
turns out to be too small of a number.  But I really doubt
that will be an issue since one shouldn't be having a depth
of tracebacks greater than the current recursion depth.

Let me know what you think of the patch.

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

Comment By: Armin Rigo (arigo)
Date: 2006-06-25 02:33

Message:
Logged In: YES 
user_id=4771

Yes, it seems reasonable.  You should probably manipulate
tstate->recursion_depth directly instead of via the
macros, as e.g. ceval.c does.

This would fix most crashes here.  It would make the attached
test17.py segfault, though.  This test17 already segfaults a
debug build of Python, but not a release build because the
recursive PyErr_NormalizeException() is turned into a tail
call by gcc.  (What, a convoluted mind, mine?)

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

Comment By: Brett Cannon (bcannon)
Date: 2006-06-23 14:54

Message:
Logged In: YES 
user_id=357491

I just had an idea, Armin.  What if, at the recursive call
site in PyErr_NormalizeException(), we called
Py_LeaveRecursiveCall() before and Py_EnterRecursiveCall()
after?  That would keep the recursion limit the same when
the normalization was done, but still allow the check in
PyObject_Call()::

Py_LeaveRecursiveCall();
PyErr_NormalizeException(exc, val, tb);
Py_EnterRecursiveCall("");

Since it is an internal call I think it would be safe to
"play" with the recursion depth value like this.  What do
you think?

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

Comment By: Brett Cannon (bcannon)
Date: 2006-06-23 13:57

Message:
Logged In: YES 
user_id=357491

The rev. that Armin checked in was actually r47061.

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

Comment By: Brett Cannon (bcannon)
Date: 2006-06-23 13:53

Message:
Logged In: YES 
user_id=357491

I thought the check was in slot_tp_call and not
PyObject_Call.  So yeah, I basically forgot.  =)

The problem with allowing the segfault to stay is that it
destroys security in terms of protecting the interpreter,
which I am trying to deal with.  So leaving random ways to
crash the interpreter is currently a no-no for me.  I will
see if I can come up with another way to fix this issue.

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

Comment By: Armin Rigo (arigo)
Date: 2006-06-23 13:05

Message:
Logged In: YES 
user_id=4771

I'd have answer "good idea, go ahead", if it were not for
what I found out a few days ago, which is that:

* you already checked yourself a Py_EnterRecursiveCall() into
PyObject_Call() -- that was in r46806 (I guess you forgot)

* I got a case of Python hanging on me in an infinite busy
loop, which turned out to be caused by this (!)

So I reverted r46806 in r47601, added a test (see log for an
explanation), and moved the PyEnter_RecursiveCall()
elsewhere, where it still catches the originally intended
case, but where it will probably not catch the cases of the
present tracker any more.  Not sure what to do about it.  I'd
suggest to be extra careful here; better some extremely
obscure and ad-hoc ways to provoke a segfault, rather than
busy-loop hangs in previously working programs...

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

Comment By: Brett Cannon (bcannon)
Date: 2006-06-23 12:44

Message:
Logged In: YES 
user_id=357491

Do you have any objection to using the
Py_EnterRecursiveCall() in PyObject_Call(), Armin, to at
least deal with the crashers it fixes?

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

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-09-01 13:39

Message:
Logged In: YES 
user_id=593130

Bug submission [ 1267884 ] crash recursive __getattr__
appears to be another example of this problem, so I closed it as 
a duplicate.  If that turns out to be wrong, it should be reopened.


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

Comment By: Armin Rigo (arigo)
Date: 2005-05-29 05:23

Message:
Logged In: YES 
user_id=4771

Adding a Py_EnterRecursiveCall() in PyObject_Call() seems to fix all the examples so far, with the exception of the "__get__=getattr" one, where we get a strange result instead of a RuntimeError (I suspect careless exception eating is taking place).

The main loop in ceval.c doesn't call PyObject_Call() very often: it usually dispatches directly itself for performance, which is exactly what we want here, as recursion from ceval.c is already protected by a Py_EnterRecursiveCall().  So this change has a minor impact on performance.  Pystone for example issues only three PyObject_Call() per loop, to call classes.  This has an almost-unmeasurable impact ( < 0.4%).

Of course I'll think a bit more and search for examples that don't go through PyObject_Call()  :-)

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

Comment By: Armin Rigo (arigo)
Date: 2005-05-23 06:52

Message:
Logged In: YES 
user_id=4771

When I thought about the same problem for PyPy, I imagined
that it would be easy to use the call graph computed by
the type inferencer ("annotator").  We would find an
algorithm that figures out the minimal number of places
that need a Py_EnterRecursiveCall so that every cycle goes
through at least one of them.  For CPython it might be
possible to go down the same path if someone can find a C
code analyzer smart enough to provide the required
information -- a call graph including indirect calls through
function pointers.  Not sure it's sane, though.

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

Comment By: Michael Hudson (mwh)
Date: 2005-05-23 06:16

Message:
Logged In: YES 
user_id=6656

I agree with Armin that this could easily be a never ending story.  Perhaps 
it would suffice to sprinkle Py_EnterRecursiveCall around as we find holes.

It might have to, because I can't really think of a better way of doing this.  
The only other approach I know is that of SBCL (a Common Lisp 
implementation): it mprotects a page at the end of the stack and installs a 
SIGSEGV handler (and uses sigaltstack) that knows how to abort the 
current lisp operation.  Somehow, I don't think we want to go down this 
line.

Anybody have any other ideas?

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

Comment By: Martin v. L??wis (loewis)
Date: 2005-05-23 06:06

Message:
Logged In: YES 
user_id=21627

It has been a long-time policy that you should not be able
to crash the Python interpreter even with malicious code. I
think this is a good policy, because it provides people
always with a back-trace, which is much easier to analyse
than a core dump.

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

Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-05-23 00:41

Message:
Logged In: YES 
user_id=341410

I personally think that the CPython runtime should make a
best-effort to not crash when running code that makes sense.
 But when CPython is running on input that is nonsensical
(in each of the examples that Armin provides, no return
value could make sense), I think that as long as the
behavior is stated clearly, it is sufficient.

Certainly it would be nice if CPython did not crash in such
cases, but I don't know if the performance penalty and code
maintenance outweigh the cases where users write bad code. 
Perhaps a compile-time option, enabled by default based on
whether or not we want a safer or faster CPython.  Of course
maintenance is still a chore, and it is one additional set
of calls that C extension writers may need to be aware of
(if their code can be recursively called, and they want to
participate in the infinite recursion detection).

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

Comment By: Armin Rigo (arigo)
Date: 2005-05-20 14:46

Message:
Logged In: YES 
user_id=4771

Yes, but I'm concerned that we would need to add it really really many places, and probably forget some even then.  E.g. I just thought about:

    lst = [apply]
    lst.append(lst)
    apply(*lst)

It seems a bit hopeless, honestly...

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

Comment By: Martin v. L??wis (loewis)
Date: 2005-05-20 14:22

Message:
Logged In: YES 
user_id=21627

Wouldn't adding Py_EnterRecursiveCall into many places solve
the problem?

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

Comment By: Armin Rigo (arigo)
Date: 2005-05-19 08:05

Message:
Logged In: YES 
user_id=4771

This is not about the new module.  The same example can be written as:

  import types
  class A: pass
  A.__mul__ = types.MethodType(operator.mul, None, A)

If this still looks essentially like an indirect way of using the new module, here is another example:

  class A(str): __get__ = getattr
  a = A('a')
  A.a = a
  a.a

Or, as I just found out, new-style classes are again vulnerable to the older example based __call__, which was fixed for old-style classes:

  class A(object): pass
  A.__call__ = A()
  A()()

I'm not denying that these examples look convoluted :-)
My point here is that we can basically build a lot of examples based only on core (if not necessarily widely understood) language features.  It appears to go against the basic hope that CPython cannot be crashed as long as you don't use features explicitely marked as dangerous.

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

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-05-18 19:02

Message:
Logged In: YES 
user_id=593130

On Windows, this caused the interactive window to just 
disappear.so I suspect something similar occurred.

New is a known dangerous, use at your own risk, implementation 
specific module whose use, like byte code hacking, is outside 
the language proper.  Both bypass normal object creation syntax 
and its checks and both can create invalid objects.  A hold-your-
hand inplementation would not give such access to internals.

Lib Ref 3.28 says "This module provides a low-level interface to 
the interpreter, so care must be exercised when using this 
module. It is possible to supply non-sensical arguments which 
crash the interpreter when the object is used."  Should more or 
different be said?  

If not, I suspect this should be closed as 'won't fix', as in 'won't 
remove the inherently dangerous new module'.




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

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

From noreply at sourceforge.net  Sat Jul  1 10:22:18 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 01 Jul 2006 01:22:18 -0700
Subject: [ python-Bugs-1513223 ] socket close() hangs client if used without
	prior shutdown()
Message-ID: <E1Fwak6-00006g-9g@sc8-sf-web2.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.5
Status: Open
Resolution: None
Priority: 7
Submitted By: Irmen de Jong (irmen)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket close() hangs client if used without prior shutdown()

Initial Comment:
In Python 2.5b1, when closing a client socket using
socket.close(), the connecting client hangs. I.e. the
socket is not properly taken down. If you add an
explicit call to socket.shutdown(), prior to the
close(), it works again.

But I think this shutdown() should not be mandatory? At
least, it wasn't in older Python versions.

Sample code attached. Run the script and connect to
socket 9000. If you remove the call to shutdown, your
client connection will hang (use telnet or netcat).


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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-01 01:22

Message:
Logged In: YES 
user_id=33168

The attached patch fixes the problem for me.  It includes a
test.  If no one gets to it in the next few days, I'll apply it.

It could be augmented with Martin's suggestion to check the
refcount.

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-06-30 09:34

Message:
Logged In: YES 
user_id=21627

The problem is that _socketobject.close fails to set
recv_into and recvfrom_into to _dummy.

The real problem seems to me that close relies on 
refcounting to close the underlying socket object. I think 
it should first call self._sock.close() before releasing
it.

Also, a test case should be added that the socket object
really does go away after close, e.g. in the form

 native_socket = s._sock
 s.close()
 assert sys.getrefcount(native_socket) == 2


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-06-29 23:07

Message:
Logged In: YES 
user_id=33168

Shutdown should not be mandatory.

I can reproduce the same behaviour under linux.  This is new
breakage in 2.5 and needs to be fixed.

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

Comment By: Irmen de Jong (irmen)
Date: 2006-06-27 02:55

Message:
Logged In: YES 
user_id=129426

Oops forgot to mention: Tested with Python2.5b1 (official
binary releases) on Windows XP and on Mac OS tiger.

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

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

From noreply at sourceforge.net  Sat Jul  1 11:41:30 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 01 Jul 2006 02:41:30 -0700
Subject: [ python-Bugs-1515471 ] wrong handling of character buffers in
	stringobject
Message-ID: <E1Fwbyk-00048G-4Z@sc8-sf-web3.sourceforge.net>

Bugs item #1515471, was opened at 2006-07-01 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=1515471&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 7
Submitted By: Georg Brandl (gbrandl)
Assigned to: Fredrik Lundh (effbot)
Summary: wrong handling of character buffers in stringobject

Initial Comment:
stringobject.c:

In string_replace, there is

	if (PyString_Check(from)) {
	  /* Can this be made a '!check' after the Unicode
check? */
	}
#ifdef Py_USING_UNICODE
	if (PyUnicode_Check(from))
		return PyUnicode_Replace((PyObject *)self,
					 from, to, count);
#endif
	else if (PyObject_AsCharBuffer(from, &tmp_s, &tmp_len))
		return NULL;

[the same check with "to"]

	return (PyObject *)replace((PyStringObject *) self,
				   (PyStringObject *) from,
				   (PyStringObject *) to, count);

This is not correct if from or to isn't a string
object, but a char buffer compatible object.


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

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

From noreply at sourceforge.net  Sat Jul  1 16:47:52 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 01 Jul 2006 07:47:52 -0700
Subject: [ python-Bugs-1513223 ] socket close() hangs client if used without
	prior shutdown()
Message-ID: <E1FwglE-0006GA-7a@sc8-sf-web6.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.5
Status: Open
Resolution: None
Priority: 7
Submitted By: Irmen de Jong (irmen)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket close() hangs client if used without prior shutdown()

Initial Comment:
In Python 2.5b1, when closing a client socket using
socket.close(), the connecting client hangs. I.e. the
socket is not properly taken down. If you add an
explicit call to socket.shutdown(), prior to the
close(), it works again.

But I think this shutdown() should not be mandatory? At
least, it wasn't in older Python versions.

Sample code attached. Run the script and connect to
socket 9000. If you remove the call to shutdown, your
client connection will hang (use telnet or netcat).


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

Comment By: Matt Fleming (splitscreen)
Date: 2006-07-01 14:47

Message:
Logged In: YES 
user_id=1126061

The patch fixes the problem for me too, on NetBSD 3.0, 

revision 47189.

Thanks, Matt

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-01 08:22

Message:
Logged In: YES 
user_id=33168

The attached patch fixes the problem for me.  It includes a
test.  If no one gets to it in the next few days, I'll apply it.

It could be augmented with Martin's suggestion to check the
refcount.

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-06-30 16:34

Message:
Logged In: YES 
user_id=21627

The problem is that _socketobject.close fails to set
recv_into and recvfrom_into to _dummy.

The real problem seems to me that close relies on 
refcounting to close the underlying socket object. I think 
it should first call self._sock.close() before releasing
it.

Also, a test case should be added that the socket object
really does go away after close, e.g. in the form

 native_socket = s._sock
 s.close()
 assert sys.getrefcount(native_socket) == 2


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-06-30 06:07

Message:
Logged In: YES 
user_id=33168

Shutdown should not be mandatory.

I can reproduce the same behaviour under linux.  This is new
breakage in 2.5 and needs to be fixed.

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

Comment By: Irmen de Jong (irmen)
Date: 2006-06-27 09:55

Message:
Logged In: YES 
user_id=129426

Oops forgot to mention: Tested with Python2.5b1 (official
binary releases) on Windows XP and on Mac OS tiger.

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

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

From noreply at sourceforge.net  Sat Jul  1 17:37:01 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 01 Jul 2006 08:37:01 -0700
Subject: [ python-Bugs-1513223 ] socket close() hangs client if used without
	prior shutdown()
Message-ID: <E1FwhWn-0000PW-MW@sc8-sf-web3.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Irmen de Jong (irmen)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket close() hangs client if used without prior shutdown()

Initial Comment:
In Python 2.5b1, when closing a client socket using
socket.close(), the connecting client hangs. I.e. the
socket is not properly taken down. If you add an
explicit call to socket.shutdown(), prior to the
close(), it works again.

But I think this shutdown() should not be mandatory? At
least, it wasn't in older Python versions.

Sample code attached. Run the script and connect to
socket 9000. If you remove the call to shutdown, your
client connection will hang (use telnet or netcat).


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

>Comment By: Martin v. L??wis (loewis)
Date: 2006-07-01 17:37

Message:
Logged In: YES 
user_id=21627

I committed this as r47190. Adding my test is pointless in
the current state: the test already passes only if the
socket gets released by .close.

The refcount test would have been useful if there was an
explicit self._sock.close() call in close. I tried adding
one, but that would not work because you then can't call
close multiple times anymore.

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

Comment By: Matt Fleming (splitscreen)
Date: 2006-07-01 16:47

Message:
Logged In: YES 
user_id=1126061

The patch fixes the problem for me too, on NetBSD 3.0, 

revision 47189.

Thanks, Matt

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-01 10:22

Message:
Logged In: YES 
user_id=33168

The attached patch fixes the problem for me.  It includes a
test.  If no one gets to it in the next few days, I'll apply it.

It could be augmented with Martin's suggestion to check the
refcount.

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-06-30 18:34

Message:
Logged In: YES 
user_id=21627

The problem is that _socketobject.close fails to set
recv_into and recvfrom_into to _dummy.

The real problem seems to me that close relies on 
refcounting to close the underlying socket object. I think 
it should first call self._sock.close() before releasing
it.

Also, a test case should be added that the socket object
really does go away after close, e.g. in the form

 native_socket = s._sock
 s.close()
 assert sys.getrefcount(native_socket) == 2


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-06-30 08:07

Message:
Logged In: YES 
user_id=33168

Shutdown should not be mandatory.

I can reproduce the same behaviour under linux.  This is new
breakage in 2.5 and needs to be fixed.

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

Comment By: Irmen de Jong (irmen)
Date: 2006-06-27 11:55

Message:
Logged In: YES 
user_id=129426

Oops forgot to mention: Tested with Python2.5b1 (official
binary releases) on Windows XP and on Mac OS tiger.

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

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

From noreply at sourceforge.net  Sat Jul  1 18:33:00 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 01 Jul 2006 09:33:00 -0700
Subject: [ python-Bugs-1296433 ] expat crash python
Message-ID: <E1FwiOy-0003e1-QK@sc8-sf-web3.sourceforge.net>

Bugs item #1296433, was opened at 2005-09-20 10:10
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1296433&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: XML
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Mike Rozhnov (rozhnov)
Assigned to: Brett Cannon (bcannon)
Summary: expat crash python

Initial Comment:
This simple script crash python.
Parsing of commented xml string work good.
(i.e. raised exception not crash python)
Buffer overflow during convertion to unicode?

Tested on Win XP and linux with kernel 2.4 with same
results.

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-01 12:33

Message:
Logged In: YES 
user_id=3066

This is now fixed in the Expat CVS with lib/xmlparse.c
revisions 1.154 and 1.155.  I've merged these into the Expat
bundled with Python in revision 47191 (on the trunk), and
moved the crasher test into the tests for xml.parsers.expat.

I don't know when the next Expat release will go out yet,
but this will keep us from being dependent on that schedule.

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

Comment By: Brett Cannon (bcannon)
Date: 2006-06-30 14:06

Message:
Logged In: YES 
user_id=357491

The fault is with Expat and not us.  I have submitted a bug
report with a possible patch at
http://sourceforge.net/tracker/index.php?func=detail&aid=1515266&group_id=10127&atid=110127
 .  I don't know what their turn-around time will be with
this so I will email python-dev to see how long people want
to wait on the Expat developers before we just push our own
patch for this.

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

Comment By: Brett Cannon (bcannon)
Date: 2006-06-29 21:33

Message:
Logged In: YES 
user_id=357491

Still seems to be failing even with the Expat 2.0 upgrade in
HEAD.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-11-12 15:53

Message:
Logged In: YES 
user_id=33168

I had recently upgraded to expat 1.95.8, so I was hopeful. 
But it still crashed for me on linux.  

I did get a better stack trace which allowed me to come up
with a patch that solves the problem and passes all the
tests.  The patch seems a bit odd and I think there might be
another problem going on here.  It would be great if someone
more familiar with xmlparse could take a look at the patch
and figure out if it's right or not.

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

Comment By: Fredrik Lundh (effbot)
Date: 2005-11-12 06:05

Message:
Logged In: YES 
user_id=38376

Works for me under 2.3.2 (with expat 1.95.6) and 2.4.1 (with
expat 1.95.8).

Try upgrading your expat and see if the problem goes away.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-22 17:54

Message:
Logged In: YES 
user_id=33168

I can reproduce on Linux with current CVS and expat
1.95.5-2.  Note the size of the data only needs to be
greater than 1024.

xml = "<?xml version='1.0' encoding='iso8859'?><s>%s</s>" %
('a' * 1025)

I am not certain this problem is specific to Python.  It
might be down in expat only.  Need to investigate further.

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

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

From noreply at sourceforge.net  Sun Jul  2 13:29:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 02 Jul 2006 04:29:46 -0700
Subject: [ python-Bugs-1333982 ] Bugs of the new AST compiler
Message-ID: <E1Fx094-0000ds-8Q@sc8-sf-web1.sourceforge.net>

Bugs item #1333982, was opened at 2005-10-21 10:08
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1333982&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: AST
Status: Open
Resolution: None
Priority: 7
Submitted By: Armin Rigo (arigo)
Assigned to: Jeremy Hylton (jhylton)
Summary: Bugs of the new AST compiler

Initial Comment:
The newly merged AST branch is likely to expose
a number of small problems before it stabilizes,
so here is a tentative bug tracker entry to
collect such small problems.


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

>Comment By: Armin Rigo (arigo)
Date: 2006-07-02 11:29

Message:
Logged In: YES 
user_id=4771

Attached a patch for the LOAD_CONST POP_TOP optimization
(modified from Georg Brandl on python-dev).

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

Comment By: Michael Hudson (mwh)
Date: 2006-04-11 09:41

Message:
Logged In: YES 
user_id=6656

Good morning Armin!

I've reported that bug already: http://python.org/sf/1441486
There's a patch which purports to fix it: http://python.org/sf/1446922
but I haven't gotten around to testing it.

(this is running the pypy/module/array tests or something, isn't it?)

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

Comment By: Armin Rigo (arigo)
Date: 2006-04-11 08:45

Message:
Logged In: YES 
user_id=4771

Another one: the literal -2147483648 (i.e. the value of
-sys.maxint-1) gives a long in 2.5, but an int in <= 2.4.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-03 07:30

Message:
Logged In: YES 
user_id=33168

The tuple store problem is fixed.  The only outstanding item
is the LOAD_CONST/POP_TOP.  I will fix that soon.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-18 06:56

Message:
Logged In: YES 
user_id=33168

Jeremy, there's no need to read anything before my last
comment at 2005-12-17 23:10.  The last two by Armin,
Michael, then my last comment are the only important ones. 
Everything that occurred before my 2005-12-17 comment was
taken care of AFAIK.

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

Comment By: Armin Rigo (arigo)
Date: 2006-02-12 21:54

Message:
Logged In: YES 
user_id=4771

Subscripting is generally a bit sloppy: e.g. the AST model has
no way to distinguish between a single value and a one-element
tuple value!  See:

>>> d = {}
>>> d[1,] = 6
>>> d
{1: 6}        # !

I suggest we fix the model to turn the 'subs' of the 'Subscript' node
from a list of nodes to a single, mandatory 'sub' node.  If tupling is
necessary, it can be explicitly represented with a 'sub' containing a
'Tuple' node.

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

Comment By: Michael Hudson (mwh)
Date: 2006-02-09 15:02

Message:
Logged In: YES 
user_id=6656

We found another one.  Something is wrong in the compilation of augmented 
assignment to subscriptions containing tuples; running this code:

class C:
    def __setitem__(self, i, v):
        print i, v
    def __getitem__(self, i):
        print i
        return 0

c = C()
c[4,5] += 1

gives a spurious exception:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: object does not support item assignment

By contrast, "c[(4,5)] += 1" works fine.



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

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-12-18 07:10

Message:
Logged In: YES 
user_id=33168

EXTENDED_ARG problem was fixed a while ago.
The assert/pass problem was fixed with: 41756.

That leaves the LOAD_CONST/POP_TOP optimization that was
lost and one compiler warning: marshal_write_mod() not being
used.

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

Comment By: Michael Hudson (mwh)
Date: 2005-12-11 00:41

Message:
Logged In: YES 
user_id=6656

You have to include those lines in a source file.  It still crashes for me.

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

Comment By: Brett Cannon (bcannon)
Date: 2005-12-10 23:44

Message:
Logged In: YES 
user_id=357491

I just checked Armin's problem code on rev. 41638 and it
worked for me in the interpreter.  You still having
problems, Armin?

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

Comment By: Armin Rigo (arigo)
Date: 2005-12-04 10:30

Message:
Logged In: YES 
user_id=4771

At rev 41584, the following code snippet triggers an assert
if --with-pydebug is enabled:
Python/compile.c:3843: assemble_lnotab: Assertion 'd_lineno >= 0' failed

-----------------------
assert 1, ([s for s in x] +
           [s for s in x])
pass
-----------------------

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-23 19:14

Message:
Logged In: YES 
user_id=33168

Checkpoint of outstanding issues.  I think all the others
mentioned so far have been fixed:

 * Raymond's warnings in compile.c (unused locals are fixed)
 * EXTENDED_ARG problem
 * LOAD_CONST/POP_TOP (note we can fix this in the optimizer
generally which would get rid of other useless code too)


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

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-10-23 04:53

Message:
Logged In: YES 
user_id=80475

FWIW, here are the warnings issued by my compiler:

Python-ast.c
C:\py25\Python\Python-ast.c(1995) : warning C4101: 'i' : 
unreferenced local variable
C:\py25\Python\Python-ast.c(2070) : warning C4101: 'i' : 
unreferenced local variable
C:\py25\Python\Python-ast.c(2085) : warning C4101: 'i' : 
unreferenced local variable
C:\py25\Python\Python-ast.c(2130) : warning C4101: 'i' : 
unreferenced local variable
C:\py25\Python\Python-ast.c(2151) : warning C4101: 'i' : 
unreferenced local variable
C:\py25\Python\Python-ast.c(2261) : warning C4101: 'i' : 
unreferenced local variable
C:\py25\Python\Python-ast.c(2270) : warning C4101: 'i' : 
unreferenced local variable


compile.c
C:\py25\Python\compile.c(3782) : warning C4305: '=' : truncation 
from 'const int ' to 'char '
C:\py25\Python\compile.c(3802) : warning C4305: '=' : truncation 
from 'const int ' to 'char '
C:\py25\Python\compile.c(3806) : warning C4305: '=' : truncation 
from 'const int ' to 'char '


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-22 07:28

Message:
Logged In: YES 
user_id=33168

I assigned to Jeremy and Neil in the hopes they will see
this message and know about these problems.

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

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 12:45

Message:
Logged In: YES 
user_id=4771

The following (similarly strange-looking) code snippets
compiled successfully before, now they give SyntaxErrors:

--------------------
def f():
    class g:
        exec "hi"
        x
--------------------
def f(x):
    class g:
        exec "hi"
        x
--------------------
def f():
    class g:
        from a import *
        x
--------------------
def f(x):
    class g:
        from a import *
        x


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

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 12:33

Message:
Logged In: YES 
user_id=4771

I would suspect the following one to be due to incorrect
handling of EXTENDED_ARG -- it's from a PyPy test about that:

longexpr = 'x = x or ' + '-x' * 2500
code = '''
def f(x):
    %s
    %s
    %s
    %s
    %s
    %s
    %s
    %s
    %s
    %s
    while x:
        x -= 1
        # EXTENDED_ARG/JUMP_ABSOLUTE here
    return x
''' % ((longexpr,)*10)

exec code
f(5)
SystemError: unknown opcode

dis.dis() shows that the target of both the SETUP_LOOP and
the JUMP_IF_FALSE at the start of the loop are wrong.

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

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 12:15

Message:
Logged In: YES 
user_id=4771

The Python rules about which names get mangled are a bit
insane.  I share mwh's view that mangling should never have
been invented in the first place, but well:

>>> def f():
...   __x = 5
...   class X:
...     def g(self):
...       return __x
...   return X
... 
Fatal Python error: unknown scope for _X__x in X(135832776)
in <stdin>


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

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 12:01

Message:
Logged In: YES 
user_id=4771

For reference, an optimization that got lost:

    def f():
        'a'
        'b'

'a' is the docstring, but the 'b' previously did not show
up anywhere in the code object.  Now there is the
LOAD_CONST/POP_TOP pair.

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

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 11:54

Message:
Logged In: YES 
user_id=4771

any reason why lambda functions have a __name__ of
'lambda' now instead of '<lambda>' ?

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

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 10:22

Message:
Logged In: YES 
user_id=4771

import a as b, c

the 'c' part gets completely forgotten and there is
no 'IMPORT_NAME c' in the bytecode.

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

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 10:13

Message:
Logged In: YES 
user_id=4771

A scoping problem (comparing with the old compiler):

class X:
    print hello

The variable 'hello' is incorrectly looked up with
LOAD_GLOBAL instead of LOAD_NAME.  It causes a crash
in PyPy in a case where the name 'hello' is stored
into the class implicitely (via locals()).  It can
probably be discussed if the bug is in PyPy, but it
is a difference in behavior.

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

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

From noreply at sourceforge.net  Sun Jul  2 14:26:59 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 02 Jul 2006 05:26:59 -0700
Subject: [ python-Bugs-1515829 ] Exponential behavior in regular expression
Message-ID: <E1Fx12R-00065G-3O@sc8-sf-web1.sourceforge.net>

Bugs item #1515829, was opened at 2006-07-02 08:26
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=1515829&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Regular Expressions
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Erik Demaine (edemaine)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: Exponential behavior in regular expression

Initial Comment:
're' seems to have serious performance trouble with
nested Kleene stars in the regular expression, if the
matched text is fairly long.  Attached is an example,
naturally arising in some LaTeX parsing [admittedly not
the only way to do it], along with a text generator
parameterized by a repetition count n.  Here is simple
timing data on a Pentium 4 1.5GHz with 1.5GB RAM as a
function of n:

[...]
n=4: 0:00:00.015000
n=5: 0:00:00.032000
n=6: 0:00:00.140000
n=7: 0:00:00.594000
n=8: 0:00:02.203000
n=9: 0:00:08.859000
n=10: 0:00:39.641000
n=11: 0:02:44.172000
n=12: 0:10:23.500000

This seems far slower than it should be, but I don't
know the algorithm used by 're'.  Is this behavior
expected?  If so, should it be optimized away by
changing the algorithm?

The generated text consists of a few lines of preamble,
then a variable number n of copies of a partiuclar
line, followed by a few lines of postscript.  The first
line of the postscript causes the regular expression
*not* to match, and 're' spends a long time to find
that out.  Removing that line from the postscript, and
causing the regular expression to match, makes the
program run instantly.

I get the same behavior on Python 2.4 and 2.5b1, on
Windows and Linux, and with re.sub and re.search.

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

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

From noreply at sourceforge.net  Sun Jul  2 14:35:29 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 02 Jul 2006 05:35:29 -0700
Subject: [ python-Bugs-1488934 ] file.write + closed pipe = no error
Message-ID: <E1Fx1Af-00054g-Kt@sc8-sf-web5.sourceforge.net>

Bugs item #1488934, was opened at 2006-05-15 12:10
Message generated for change (Comment added) made by edemaine
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488934&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Erik Demaine (edemaine)
Assigned to: Nobody/Anonymous (nobody)
Summary: file.write + closed pipe = no error

Initial Comment:
I am writing a Python script on Linux that gets called
via ssh (ssh hostname script.py) and I would like it to
know when its stdout gets closed because the ssh
connection gets killed.  I assumed that it would
suffice to write to stdout, and that I would get an
error if stdout was no longer connected to anything. 
This is not the case, however.  I believe it is because
of incorrect error checking in Objects/fileobject.c's
file_write.

Consider this example:

while True:
__print 'Hello'
__time.sleep (1)

If this program is run via ssh and then the ssh
connection dies, the program continues running forever
(or at least, over 10 hours).  No exceptions are thrown.

In contrast, this example does die as soon as the ssh
connection dies (within one second):

while True:
__os.write (1, 'Hello')
__time.sleep (1)

I claim that this is because os.write does proper error
checking, but file.write seems not to.  I was surprised
to find this intricacy in fwrite().  Consider the
attached C program, test.c.  (Warning: If you run it,
it will create a file /tmp/hello, and it will keep
running until you kill it.)  While the ssh connection
remains open, fwrite() reports a length of 6 bytes
written, ferror() reports no error, and errno remains
0.  Once the ssh connection dies, fwrite() still
reports a length of 6 bytes written (surprise!), but
ferror(stdout) reports an error, and errno changes to 5
(EIO).  So apparently one cannot tell from the return
value of fwrite() alone whether the write actually
succeeded; it seems necessary to call ferror() to
determine whether the write caused an error.

I think the only change necessary is on line 2443 of
file_write() in Objects/fileobject.c (in svn version
46003):

2441        n2 = fwrite(s, 1, n, f->f_fp);
2442        Py_END_ALLOW_THREADS
2443        if (n2 != n) {
2444                PyErr_SetFromErrno(PyExc_IOError);
2445                clearerr(f->f_fp);

I am not totally sure whether the "n2 != n" condition
should be changed to "n2 != n || ferror (f->f_fp)" or
simply "ferror (f->f_fp)", but I believe that the
condition should be changed to one of these
possibilities.  The current behavior is wrong.

Incidentally, you'll notice that the C code has to turn
off signal SIGPIPE (like Python does) in order to not
die right away.  However, I could not get Python to die
by re-enabling SIGPIPE.  I tried "signal.signal
(signal.SIGPIPE, signal.SIG_DFL)" and "signal.signal
(signal.SIGPIPE, lambda x, y: sys.exit ())" and neither
one caused death of the script when the ssh connection
died.  Perhaps I'm not using the signal module correctly?

I am on Linux 2.6.11 on a two-CPU Intel Pentium 4, and
I am running the latest Subversion version of Python,
but my guess is that this error transcends most if not
all versions of Python.

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

>Comment By: Erik Demaine (edemaine)
Date: 2006-07-02 08:35

Message:
Logged In: YES 
user_id=265183

A simple test case is this Python script (fleshed out from
previous example), also attached:

import sys, time
while True:
__print 'Hello'
__sys.stdout.flush ()
__time.sleep (1)

Save as blah.py on machine foo, run 'ssh foo python blah.py'
on machine bar--you will see 'Hello' every second--then, in
another shell on bar, kill the ssh process on bar.  blah.py
should still be running on foo.  ('foo' and 'bar' can
actually be the same machine.)

The example from the original bug report that uses
os.write() instead of print was an example that *does* work.


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

Comment By: A.M. Kuchling (akuchling)
Date: 2006-06-03 16:16

Message:
Logged In: YES 
user_id=11375

I agree with your analysis, and think your suggested fixes are correct.

However, I'm unable to construct a small test case that exercises this bug.  I 
can't even replicate the problem with SSH; when I run a remote script with 
SSH and then kill SSH with Ctrl-C, the write() gets a -1.  Are you terminating 
SSH in some other way?  (I'd really like to have a test case for this problem 
before committing the fix.)


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

Comment By: Erik Demaine (edemaine)
Date: 2006-05-15 12:26

Message:
Logged In: YES 
user_id=265183

One more thing: fwrite() is used in a couple of other
places, and I think the same comment applies to them.  They are:

- file_writelines() in Objects/fileobject.c
- w_string() in Python/marshal.c doesn't seem to have any
error checking?  (At least no ferror() call in marhsal.c...)
- string_print() in Objects/stringobject.c doesn't seem to
have any error checking (but I'm not quite sure what this
means in Python land).
- flush_data() in Modules/_hotshot.c
- array_tofile() in Modules/arraymodule.c
- write_file() in Modules/cPickle.c
- putshort(), putlong(), writeheader(), writetab() [and the
functions that call them] in Modules/rgbimgmodule.c
- svc_writefile() in Modules/svmodule.c

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

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

From noreply at sourceforge.net  Sun Jul  2 15:05:04 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 02 Jul 2006 06:05:04 -0700
Subject: [ python-Bugs-1515839 ] socket timeout inheritance on accept
Message-ID: <E1Fx1dI-0003iF-TY@sc8-sf-web6.sourceforge.net>

Bugs item #1515839, was opened at 2006-07-02 16: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=1515839&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Jari Kirma (kirma)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket timeout inheritance on accept

Initial Comment:
Socket objects returned by socket.accept() get their
blocking and timeout setting(s) from
socket.defaulttimeout. This can be in conflict with
reality of the (non-)blocking mode of actual OS-level
socket they use. For instance, FreeBSD sockets inherit
their socket options from the parent socket on
accept(2) system call, and thus a socket object with
defined socket timeout and default defaulttimeout
returns a socket object that seems to be blocking,
non-timeout socket, but the underlying OS socket is
actually in nonblocking mode, which can cause read/recv
and write/send operations to behave unexpectedly. Even
worse, POSIX/SUSv3 doesn't explicitly require socket
option inheritance
(http://www.opengroup.org/onlinepubs/009695399/functions/accept.html).
  

The socket library should explicitly set the socket
timeout mode (either to defaulttimeout, or with
accompanying documentation, inherit the value from
socket object passed to accept()) and modify the OS
socket options accordingly.

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

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

From noreply at sourceforge.net  Sun Jul  2 15:23:37 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 02 Jul 2006 06:23:37 -0700
Subject: [ python-Bugs-1515839 ] socket timeout inheritance on accept
Message-ID: <E1Fx1vF-0000ka-0I@sc8-sf-web6.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Jari Kirma (kirma)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket timeout inheritance on accept

Initial Comment:
Socket objects returned by socket.accept() get their
blocking and timeout setting(s) from
socket.defaulttimeout. This can be in conflict with
reality of the (non-)blocking mode of actual OS-level
socket they use. For instance, FreeBSD sockets inherit
their socket options from the parent socket on
accept(2) system call, and thus a socket object with
defined socket timeout and default defaulttimeout
returns a socket object that seems to be blocking,
non-timeout socket, but the underlying OS socket is
actually in nonblocking mode, which can cause read/recv
and write/send operations to behave unexpectedly. Even
worse, POSIX/SUSv3 doesn't explicitly require socket
option inheritance
(http://www.opengroup.org/onlinepubs/009695399/functions/accept.html).
  

The socket library should explicitly set the socket
timeout mode (either to defaulttimeout, or with
accompanying documentation, inherit the value from
socket object passed to accept()) and modify the OS
socket options accordingly.

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

>Comment By: Jari Kirma (kirma)
Date: 2006-07-02 16:23

Message:
Logged In: YES 
user_id=1548868

Making socket objects behave reliably can be achieved simply
by always calling internal_setblocking in init_sockobject of
socketmodule.c, but this causes overhead of one system call
on all socket creations. Alternatively one could call
internal_setblocking from sock_accept if parent socket has
timeouts/nonblocking mode enabled. This should work in under
all reasonable scenanarios and avoid system call overhead on
majority of cases.

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

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

From noreply at sourceforge.net  Sun Jul  2 19:53:20 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 02 Jul 2006 10:53:20 -0700
Subject: [ python-Bugs-1515932 ] 2.3.6.4 Mutable Sequence Types clarification
Message-ID: <E1Fx68G-0003h1-2W@sc8-sf-web1.sourceforge.net>

Bugs item #1515932, was opened at 2006-07-02 12: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=1515932&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Alan (aisaac0)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.3.6.4 Mutable Sequence Types clarification

Initial Comment:
Documentation of Mutable Sequence Types
at http://docs.python.org/lib/typesseq-mutable.html
has the following language:

s[i:j] = t  slice of s from i to j is replaced by t  	
...
s[i:j:k] = t the elements of s[i:j:k] are replaced by
those of t 	(1)

The asymmetry is misleading (e.g., one might think that
in the first case t could be a single number that would
be assigned to all the elements, particularly since the
footnote is omitted).

Therefore I propose the first case become:

s[i:j] = t   the elements of the slice of s from i to j
are replaced by those of t 	(1)

The following alternative would be even more parallel
and also acceptable:

s[i:j] = t  the elements of s[i:j] are replaced by
those of t 	(1)

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

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

From noreply at sourceforge.net  Sun Jul  2 20:45:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 02 Jul 2006 11:45:05 -0700
Subject: [ python-Bugs-1513646 ] os.access reports incorrect write permissions
	in Windows
Message-ID: <E1Fx6wL-0003EG-OI@sc8-sf-web3.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Yi S. Ding (yi_ding)
Assigned to: Martin v. L??wis (loewis)
Summary: os.access reports incorrect write permissions in Windows

Initial Comment:
Platform: Python 2.5b1 Windows XP

Bug:
os.access will report that a user doesn't have write
permissions to a file or directory when the user
actually does.

Reproducibility: always

This is being run on an administrator account.
>>> import os
>>> os.access("C:\\", os.W_OK)
False
>>> os.access("C:\\test.txt", os.W_OK)
False

I have also checked that Python can indeed write to the
file.

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

>Comment By: Martin v. L??wis (loewis)
Date: 2006-07-02 20:45

Message:
Logged In: YES 
user_id=21627

Thanks for the report and the patch, committed as r47198 (I
moved the test in a separate class, though).

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

Comment By: Yi S. Ding (yi_ding)
Date: 2006-07-01 01:12

Message:
Logged In: YES 
user_id=1081617

Cool.  I added the new patch with the test case.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-06-30 09:12

Message:
Logged In: YES 
user_id=33168

Your change looks correct, but I would really like a test
case to fix this problem.  I don't have access to a Windows
box, so I can't verify the test fails before this patch and
succeeds with it.  Can you create a test case too?  The best
place to add the test would be Lib/test/test_posix.py.  Thanks!

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

Comment By: Yi S. Ding (yi_ding)
Date: 2006-06-29 21:56

Message:
Logged In: YES 
user_id=1081617

Yeah, it's only 2.5, and only 2.5b1.  Basically, there's a
double ampersand used instead of a single ampersand in
posixmodule.c.  I've attached the patch.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-06-28 07:28

Message:
Logged In: YES 
user_id=33168

Does this problem only occur with 2.5 or is it also present
in 2.4?

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

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

From noreply at sourceforge.net  Sun Jul  2 22:18:00 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 02 Jul 2006 13:18:00 -0700
Subject: [ python-Bugs-1514617 ] evaluated code filename changed to <module>
	instead of ?
Message-ID: <E1Fx8OG-0007Xa-TJ@sc8-sf-web3.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: James Y Knight (foom)
Assigned to: Nobody/Anonymous (nobody)
Summary: evaluated code filename changed to <module> instead of ?

Initial Comment:
It seems as though the default filename for evaluated changed from "?" to 
"<module>". Was this intentional? (it's causing some test failures for me. 
The tests are correctable of course, but it doesn't seem to be an obvious 
improvement in behavior, so if it wasn't intentional, perhaps it should be 
changed back.)

Python 2.3.5 (#1, Mar 20 2005, 20:38:20) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin

>>> eval("0/0")    
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<string>", line 0, in ?


Python 2.5b1 (trunk:47096, Jun 25 2006, 23:18:21) 
[GCC 4.0.0 20041026 (Apple Computer, Inc. build 4061)] on darwin

>>> eval("0/0")    
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 1, in <module>
ZeroDivisionError: integer division or modulo by zero


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

Comment By: Jp Calderone (kuran)
Date: 2006-07-02 16:18

Message:
Logged In: YES 
user_id=366566

Note that in the example James included, the code is /not/
in a module.

A clear improvement to me would be to say something like
<repl> or <interactive prompt> in the case James pasted and
<the name of a module> for the case of top-level code.

"<module>" is about as information-free as "?".


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

Comment By: Collin Winter (collinwinter)
Date: 2006-07-01 14:26

Message:
Logged In: YES 
user_id=1344176

For me, this is indeed an obvious improvement in behaviour.
"<module>" is a much clearer indicator of where the code in
question is located; using "?" could mean that it's anywhere.

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

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

From noreply at sourceforge.net  Sun Jul  2 22:20:35 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 02 Jul 2006 13:20:35 -0700
Subject: [ python-Bugs-1514617 ] evaluated code filename changed to <module>
	instead of ?
Message-ID: <E1Fx8Ql-0000QF-Vz@sc8-sf-web3.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: James Y Knight (foom)
Assigned to: Nobody/Anonymous (nobody)
Summary: evaluated code filename changed to <module> instead of ?

Initial Comment:
It seems as though the default filename for evaluated changed from "?" to 
"<module>". Was this intentional? (it's causing some test failures for me. 
The tests are correctable of course, but it doesn't seem to be an obvious 
improvement in behavior, so if it wasn't intentional, perhaps it should be 
changed back.)

Python 2.3.5 (#1, Mar 20 2005, 20:38:20) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin

>>> eval("0/0")    
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<string>", line 0, in ?


Python 2.5b1 (trunk:47096, Jun 25 2006, 23:18:21) 
[GCC 4.0.0 20041026 (Apple Computer, Inc. build 4061)] on darwin

>>> eval("0/0")    
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 1, in <module>
ZeroDivisionError: integer division or modulo by zero


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

Comment By: Jp Calderone (kuran)
Date: 2006-07-02 16:20

Message:
Logged In: YES 
user_id=366566

Also see
https://sourceforge.net/tracker/?func=detail&aid=1512007&group_id=5470&atid=305470
for a patch to revert to the old behavior.


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

Comment By: Jp Calderone (kuran)
Date: 2006-07-02 16:18

Message:
Logged In: YES 
user_id=366566

Note that in the example James included, the code is /not/
in a module.

A clear improvement to me would be to say something like
<repl> or <interactive prompt> in the case James pasted and
<the name of a module> for the case of top-level code.

"<module>" is about as information-free as "?".


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

Comment By: Collin Winter (collinwinter)
Date: 2006-07-01 14:26

Message:
Logged In: YES 
user_id=1344176

For me, this is indeed an obvious improvement in behaviour.
"<module>" is a much clearer indicator of where the code in
question is located; using "?" could mean that it's anywhere.

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

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

From noreply at sourceforge.net  Sun Jul  2 22:44:51 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 02 Jul 2006 13:44:51 -0700
Subject: [ python-Bugs-1515998 ] bdist_msi fails (egg-info)
Message-ID: <E1Fx8oF-0003HH-UB@sc8-sf-web1.sourceforge.net>

Bugs item #1515998, was opened at 2006-07-02 21: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=1515998&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Paul Moore (pmoore)
Assigned to: Nobody/Anonymous (nobody)
Summary: bdist_msi fails (egg-info)

Initial Comment:
If I try to build a bdist_msi installer for a trivial
module, using Python 2.5b1, I get an error.

It looks like a problem with the interaction of the new
(in 2.5) egg-info stuff and the bdist_msi code - but I
have no further ideas.
Here is the setup.py

from distutils.core import setup
setup(
   name='test',
   version='1.0',
   py_modules=['test'],
)

And here is the build output:

>python setup.py bdist_msi
running bdist_msi
running build
running build_py
creating build
creating build\lib
copying test.py -> build\lib
installing to build\bdist.win32\msi
running install_lib
creating build\bdist.win32
creating build\bdist.win32\msi
creating build\bdist.win32\msi\Lib
creating build\bdist.win32\msi\Lib\site-packages
copying build\lib\test.py ->
build\bdist.win32\msi\Lib\site-packages
running install_egg_info
Writing
build\bdist.win32\msi\Lib\site-packages\test-1.0-py2.5.egg-info
creating dist
Traceback (most recent call last):
 File "setup.py", line 5, in <module>
   py_modules=['test'],
 File "D:\Apps\Python25\Lib\distutils\core.py", line
151, in setup
   dist.run_commands()
 File "D:\Apps\Python25\Lib\distutils\dist.py", line
974, in run_commands
   self.run_command(cmd)
 File "D:\Apps\Python25\Lib\distutils\dist.py", line
994, in run_command
   cmd_obj.run()
 File
"D:\Apps\Python25\Lib\distutils\command\bdist_msi.py",
line 235, in run
   self.add_files()
 File
"D:\Apps\Python25\Lib\distutils\command\bdist_msi.py", line
263, in add_files
   key = dir.add_file(file)
 File "D:\Apps\Python25\Lib\msilib\__init__.py", line
343, in add_file
   language, attributes, sequence)])
 File "D:\Apps\Python25\Lib\msilib\__init__.py", line
115, in add_data
   raise MSIError("Could not insert "+repr(values)+"
into "+table)
_msi.MSIError: Could not insert [(None, 'site_packages',
'TEST-1~1.EGG|test-1.0-py2.5.egg-info', 186L, None,
None, 512, 1)]
into File


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

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

From noreply at sourceforge.net  Sun Jul  2 23:40:55 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 02 Jul 2006 14:40:55 -0700
Subject: [ python-Bugs-1515829 ] Exponential behavior in regular expression
Message-ID: <E1Fx9gV-0000VE-6p@sc8-sf-web5.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Regular Expressions
>Group: Feature Request
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Erik Demaine (edemaine)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Exponential behavior in regular expression

Initial Comment:
're' seems to have serious performance trouble with
nested Kleene stars in the regular expression, if the
matched text is fairly long.  Attached is an example,
naturally arising in some LaTeX parsing [admittedly not
the only way to do it], along with a text generator
parameterized by a repetition count n.  Here is simple
timing data on a Pentium 4 1.5GHz with 1.5GB RAM as a
function of n:

[...]
n=4: 0:00:00.015000
n=5: 0:00:00.032000
n=6: 0:00:00.140000
n=7: 0:00:00.594000
n=8: 0:00:02.203000
n=9: 0:00:08.859000
n=10: 0:00:39.641000
n=11: 0:02:44.172000
n=12: 0:10:23.500000

This seems far slower than it should be, but I don't
know the algorithm used by 're'.  Is this behavior
expected?  If so, should it be optimized away by
changing the algorithm?

The generated text consists of a few lines of preamble,
then a variable number n of copies of a partiuclar
line, followed by a few lines of postscript.  The first
line of the postscript causes the regular expression
*not* to match, and 're' spends a long time to find
that out.  Removing that line from the postscript, and
causing the regular expression to match, makes the
program run instantly.

I get the same behavior on Python 2.4 and 2.5b1, on
Windows and Linux, and with re.sub and re.search.

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

>Comment By: Tim Peters (tim_one)
Date: 2006-07-02 17:40

Message:
Logged In: YES 
user_id=31435

Since this isn't going to change, I'm closing this.

I don't know exactly what your regexp is intended to match,
but I expect this will help speed it enormously:  inside a
group, one of the alternatives is the negated character
class (NCC):

[^{}%]

One of the other alternatives starts with "{" and another
with "%".  That's very good, because those three
alternatives are mutually exclusive based on just the
current character in the target string.

However, yet another alternative starts with a backslash,
and it's thus ambiguous whether the backslash should be
matched by that alternative or by the NCC.  Because this is
a backtracking engine, and the NCC is the first alternative,
it tries the NCC first and won't try the backslash
alternative unless it's impossible to find a match having
tried the NCC.  That can cause exponential-time
failing-match behavior all by itself.

If it's the case that a backslash in this context is
_always_ supposed to match the

\\.

alternative, then adding a backslash to the NCC removes the
ambiguity and greatly speeds (at least) failing matches:

[^{}%\\]

Then which alternative is supposed to match is entirely
determined by the current character in the target string, so
when backtracking on failure all other alternatives fail at
once, and backtracking continues with at worst insignificant
delay.

Adding a backslash to the "inner" NCC helps a little, but
adding one to the "outer" NCC too is very effective:

n=0: 0:00:00
n=1: 0:00:00
n=2: 0:00:00
...
n=97: 0:00:00
n=98: 0:00:00
n=99: 0:00:00

See Friedl's book for much more along these lines.

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

Comment By: Tim Peters (tim_one)
Date: 2006-07-02 09:13

Message:
Logged In: YES 
user_id=31435

Yes, it's easy to provoke exponential-time behavior.  For a
simple example, the regexp

^((a+)*)*$

takes O(3**n) time to fail to match strings of the form

"a"*n + "b"

Python's matcher is a backtracking engine, much like Perl's,
and most other languages' non-POSIX re facilities.  There's
nary a DFA in sight ;-)  Jeffrey Friedl's thick O'Reilly
book "Mastering Regular Expressions" is mostly about the
pragmatics of using such engines efficiently:

http://regex.info/

Note that there's no current hope that this will change: 
because of gimmicks like backreferences, these aren't
CompSci's idea of regular expressions, and no "thoroughly
efficient" implementation technique is known.  For example,
this teensy regexp:

^(aa+)\\1+$

matches strings of a's whose length isn't prime, and finds a
non-trivial factor when the length is composite.  For
harder-to-solve but messier examples:

http://perl.plover.com/NPC/

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

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

From noreply at sourceforge.net  Mon Jul  3 02:42:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 02 Jul 2006 17:42:23 -0700
Subject: [ python-Bugs-1516068 ] Under OS X,
	compiling against local readline fails
Message-ID: <E1FxCW7-0000v9-Pg@sc8-sf-web6.sourceforge.net>

Bugs item #1516068, was opened at 2006-07-02 17: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=1516068&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Nelson Arzola (narzola72)
Assigned to: Nobody/Anonymous (nobody)
Summary: Under OS X, compiling against local readline fails

Initial Comment:
I've installed a version of the GNU Readline (5.1) in a
local directory (/Volumes/DATA/dev/toolset/{include,lib}.

I'm compiling Python with:

CFLAGS=-I/Volumes/DATA/dev/toolset/include \
LDFLAGS=-L/Volumes/DATA/dev/toolset/lib \
./configure \
     --prefix=/Volues/DATA/dev/toolset/inst/python \
     --with-libs="-lexpat -lncurses -lreadline"
make

I get the following error:

./Modules/readline.c:885: error: 'HISTORY_STATE'
undeclared (first use in this function)
./Modules/readline.c:885: error: 'state' undeclared
(first use in this function)
./Modules/readline.c:887: warning: assignment discards
qualifiers from pointer target type

When I look at the gcc command that was used to compile
Modules/readline.c, I see that my CFLAGS is not passed
to gcc and so the (broken) system readline is being used.

I can temporarily solve this problem with:

echo "readline readline.c ${CFLAGS} ${LDFLAGS}
-lreadline -l termcap" >> Modules/Setup.local

before I call make.

What I can't understand is why the build process
correctly uses the local version of expat (2.0.0) that
is installed in the directories with readline, but not
readline?

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

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

From noreply at sourceforge.net  Mon Jul  3 02:44:35 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 02 Jul 2006 17:44:35 -0700
Subject: [ python-Bugs-1516068 ] Under OS X,
	compiling against local readline fails
Message-ID: <E1FxCYF-0000mf-St@sc8-sf-web1.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Nelson Arzola (narzola72)
Assigned to: Nobody/Anonymous (nobody)
Summary: Under OS X, compiling against local readline fails

Initial Comment:
I've installed a version of the GNU Readline (5.1) in a
local directory (/Volumes/DATA/dev/toolset/{include,lib}.

I'm compiling Python with:

CFLAGS=-I/Volumes/DATA/dev/toolset/include \
LDFLAGS=-L/Volumes/DATA/dev/toolset/lib \
./configure \
     --prefix=/Volues/DATA/dev/toolset/inst/python \
     --with-libs="-lexpat -lncurses -lreadline"
make

I get the following error:

./Modules/readline.c:885: error: 'HISTORY_STATE'
undeclared (first use in this function)
./Modules/readline.c:885: error: 'state' undeclared
(first use in this function)
./Modules/readline.c:887: warning: assignment discards
qualifiers from pointer target type

When I look at the gcc command that was used to compile
Modules/readline.c, I see that my CFLAGS is not passed
to gcc and so the (broken) system readline is being used.

I can temporarily solve this problem with:

echo "readline readline.c ${CFLAGS} ${LDFLAGS}
-lreadline -l termcap" >> Modules/Setup.local

before I call make.

What I can't understand is why the build process
correctly uses the local version of expat (2.0.0) that
is installed in the directories with readline, but not
readline?

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

>Comment By: Nelson Arzola (narzola72)
Date: 2006-07-02 17:44

Message:
Logged In: YES 
user_id=1478788

Sorry, I forgot to mention that I'm using the latest verion
of Python 2.4.3 from python.org.

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

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

From noreply at sourceforge.net  Mon Jul  3 10:39:49 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 03 Jul 2006 01:39:49 -0700
Subject: [ python-Bugs-1516184 ] inspect.py: still infinite recursion
	inspecting frames
Message-ID: <E1FxJy9-0003tO-Vw@sc8-sf-web3.sourceforge.net>

Bugs item #1516184, was opened at 2006-07-03 10: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=1516184&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Don Quijote (dq_searchlores)
Assigned to: Nobody/Anonymous (nobody)
Summary: inspect.py: still infinite recursion inspecting frames

Initial Comment:
Using python 2.5 beta 1 on Windows XP, and py2exe 0.6.5.

After packing and compressing a project via py2exe,
there's still an infinite recursion involving functions
getsourcefile, getmodule and getabsfile in module
inspect.py.

I was able to fix this infinite recursion by

1) changing the declaration of getabsfile & getmodule to:
def getabsfile(object, filename=None):
def getmodule(object, filename=None):

2) including the "filename" parameter in all calls to
getabsfile inside of function getmodule.

3) having getabsfile return the absolute and normalized
filename if not null.

Perhaps this change helps to clean up the 'ugliness'
introduced in version 45822.

Kind regards,
Don Quijote 

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

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

From noreply at sourceforge.net  Mon Jul  3 11:44:44 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 03 Jul 2006 02:44:44 -0700
Subject: [ python-Bugs-1514703 ] setup in Pen.__init__()
Message-ID: <E1FxKyy-0006s8-BE@sc8-sf-web3.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 8
Submitted By: Lingl (gregorlingl)
Assigned to: Martin v. L??wis (loewis)
Summary: setup in Pen.__init__()

Initial Comment:
Each time a Pen is constructed, the graphics
window is resized and recenter (if position or
size was changed before by the user).

I think a call of a window-oriented function
doesn't belong in the Pen-cunstructor.

Must somehow be called separately.

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

>Comment By: Martin v. L??wis (loewis)
Date: 2006-07-03 11:44

Message:
Logged In: YES 
user_id=21627

Thanks for the report. I fixed in r47208 by only calling
setup when _canvas gets initialized.

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

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

From noreply at sourceforge.net  Mon Jul  3 11:46:07 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 03 Jul 2006 02:46:07 -0700
Subject: [ python-Bugs-1515998 ] bdist_msi fails (egg-info)
Message-ID: <E1FxL0J-0001rR-3c@sc8-sf-web1.sourceforge.net>

Bugs item #1515998, was opened at 2006-07-02 22:44
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1515998&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils
Group: Python 2.5
Status: Open
Resolution: None
>Priority: 8
Submitted By: Paul Moore (pmoore)
>Assigned to: Martin v. L??wis (loewis)
Summary: bdist_msi fails (egg-info)

Initial Comment:
If I try to build a bdist_msi installer for a trivial
module, using Python 2.5b1, I get an error.

It looks like a problem with the interaction of the new
(in 2.5) egg-info stuff and the bdist_msi code - but I
have no further ideas.
Here is the setup.py

from distutils.core import setup
setup(
   name='test',
   version='1.0',
   py_modules=['test'],
)

And here is the build output:

>python setup.py bdist_msi
running bdist_msi
running build
running build_py
creating build
creating build\lib
copying test.py -> build\lib
installing to build\bdist.win32\msi
running install_lib
creating build\bdist.win32
creating build\bdist.win32\msi
creating build\bdist.win32\msi\Lib
creating build\bdist.win32\msi\Lib\site-packages
copying build\lib\test.py ->
build\bdist.win32\msi\Lib\site-packages
running install_egg_info
Writing
build\bdist.win32\msi\Lib\site-packages\test-1.0-py2.5.egg-info
creating dist
Traceback (most recent call last):
 File "setup.py", line 5, in <module>
   py_modules=['test'],
 File "D:\Apps\Python25\Lib\distutils\core.py", line
151, in setup
   dist.run_commands()
 File "D:\Apps\Python25\Lib\distutils\dist.py", line
974, in run_commands
   self.run_command(cmd)
 File "D:\Apps\Python25\Lib\distutils\dist.py", line
994, in run_command
   cmd_obj.run()
 File
"D:\Apps\Python25\Lib\distutils\command\bdist_msi.py",
line 235, in run
   self.add_files()
 File
"D:\Apps\Python25\Lib\distutils\command\bdist_msi.py", line
263, in add_files
   key = dir.add_file(file)
 File "D:\Apps\Python25\Lib\msilib\__init__.py", line
343, in add_file
   language, attributes, sequence)])
 File "D:\Apps\Python25\Lib\msilib\__init__.py", line
115, in add_data
   raise MSIError("Could not insert "+repr(values)+"
into "+table)
_msi.MSIError: Could not insert [(None, 'site_packages',
'TEST-1~1.EGG|test-1.0-py2.5.egg-info', 186L, None,
None, 512, 1)]
into File


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

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

From noreply at sourceforge.net  Mon Jul  3 12:29:07 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 03 Jul 2006 03:29:07 -0700
Subject: [ python-Bugs-1514685 ] radians() doesn't work correctly
Message-ID: <E1FxLfv-00017P-Ue@sc8-sf-web5.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
>Status: Closed
>Resolution: Duplicate
Priority: 7
Submitted By: Lingl (gregorlingl)
Assigned to: Martin v. L??wis (loewis)
Summary: radians() doesn't work correctly

Initial Comment:
>>> from turtle import *
>>> left(90)
>>> heading()
90.0
>>> radians()
>>> heading()
90.0    # should give pi/2, i.e. 1.5707... 
>>> forward(50) # turtle goes in direction 90 rad
                # i.e. approx. 116.62 degrees
  

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

>Comment By: Martin v. L??wis (loewis)
Date: 2006-07-03 12:29

Message:
Logged In: YES 
user_id=21627

This is essentially a duplicate of #1514693, which was fixed
with r47210.

Please provide patches as unified diffs in the future; they
would be much easier to process that way. See

http://www.python.org/dev/patches/

I don't think the top-level degrees functions should grow a
fullcircle argument: this is only to simplify the
implementation (i.e. having the state-changing code in a
single function). The end user is not expected to pass an
argument to degrees() or radians().

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

Comment By: Lingl (gregorlingl)
Date: 2006-06-30 21:04

Message:
Logged In: YES 
user_id=1547199

Making two changes will correct the bug:

(a) In RawPen.__init__(): 

    def __init__(self, canvas):
        self._canvas = canvas
        self._items = []
        self._tracing = 1
        self._arrow = 0
        self._delay = 10     # default delay for drawing
        # patch for degrees()
##      self.degrees() # replace by the following two lines
        self._fullcircle = 360.0
        self._invradian = pi/180.0
        self.reset()

(b) in RawPen.degrees() : 

    def degrees(self, fullcircle=360.0):
        """ Set angle measurement units to degrees.

        Example:
        >>> turtle.degrees()
        """
        # patch for degrees(): add next line
        self._angle=self._angle*fullcircle/self._fullcircle
        self._fullcircle = fullcircle
        self._invradian = pi / (fullcircle * 0.5)


Additional Remark: In order that the function degrees()
works identically to the method of same name it should be
written:

def degrees(fullcircle=360.0): _getpen().degrees(fullcircle)


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

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

From noreply at sourceforge.net  Mon Jul  3 12:36:06 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 03 Jul 2006 03:36:06 -0700
Subject: [ python-Bugs-1514725 ] turtle.py: setup() call in Pen.__init__()
Message-ID: <E1FxLmg-0004Af-Fr@sc8-sf-web5.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
>Status: Closed
Resolution: Duplicate
Priority: 1
Submitted By: Lingl (gregorlingl)
Assigned to: Nobody/Anonymous (nobody)
Summary: turtle.py: setup() call in Pen.__init__()

Initial Comment:
Each time a Pen is constructed, the graphcis window
gets resized and recenter (restored to ist's initial state)
if the user had changed that state.

I think a window-oriented function call doesn't
belong into the Pen-constructor

Must be called somewhere else


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

>Comment By: Martin v. L??wis (loewis)
Date: 2006-07-03 12:36

Message:
Logged In: YES 
user_id=21627

Closing as a duplicate of #1514703.

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

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

From noreply at sourceforge.net  Mon Jul  3 13:13:09 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 03 Jul 2006 04:13:09 -0700
Subject: [ python-Bugs-1514730 ] turtle.py docs out of date
Message-ID: <E1FxMMX-0003Ed-Cm@sc8-sf-web2.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Lingl (gregorlingl)
Assigned to: Martin v. L??wis (loewis)
Summary: turtle.py docs out of date

Initial Comment:
Python Docs / Global Module Index / turtle(Tk)
has simply not been updated to Vern Ceders
revision and is way out of date

many functions like position(), heading(),
setheading(), begin_fill(), end_fill()
and more are not mentioned.

Also class Turte is not mentioned



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

>Comment By: Martin v. L??wis (loewis)
Date: 2006-07-03 13:13

Message:
Logged In: YES 
user_id=21627

Thanks for the report; this was fixed in r47211. Please
review whether anything is still missing, and submit a new
report if you find further problems.

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

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

From noreply at sourceforge.net  Mon Jul  3 14:03:09 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 03 Jul 2006 05:03:09 -0700
Subject: [ python-Bugs-978833 ] SSL-ed sockets don't close correct?
Message-ID: <E1FxN8v-0001Jh-Hm@sc8-sf-web6.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 8
Submitted By: kxroberto (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: Martin v. L??wis (loewis)
Date: 2006-07-03 14:03

Message:
Logged In: YES 
user_id=21627

Can you please try the attached patch? It makes sure
_socketobject.close really closes the socket, rather than
relying on reference counting to close it.

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

Comment By: kxroberto (kxroberto)
Date: 2006-05-11 14:05

Message:
Logged In: YES 
user_id=972995

Testing it with Python2.5a2, the problem is still there.

Without the .shutdown(2) (or .shutdown(1)) patch to the
httplib.SharedSocket (base for FakeSocket), the ftps example
freezes on the cmd channel, because the SSL'ed data channel
doesn't close/terminate --> FTPS server doesn't respond on
the cmd channel. The ftps example is most specific to show
the bug. 

Yet you can also easily blow up a HTTPS-server with this
decent test code who only opens (bigger!) files and closes
without reading everything:

Python 2.5a2 (r25a2:45740, May 11 2006, 11:25:30)
[GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
Robert's Interactive Python - TAB=complete
import sys,os,re,string,time,glob,thread,pdb
>>> import urllib
>>> l=[]
>>> for i in range(10):
...    f=urllib.urlopen('https://srv/big-Python-2.5a2.tgz')
...    f.close()
...    l.append(f)
...
>>>


=> in the (apache) servers ssl_engine_log you can see that
connections remain open (until apache times out after 2
minutes) and lots of extra apache daemons are started!

=> f.close() doesn't really close the connection (until it
is __del__'ed )


Trying around I found that the original undeleted f.fp._ssl
is most probably the cause and holds the real socket open. 
a f.fp._sock.close() doesn't close also  - but only when del
f.fp._ssl is done. (only a f.fp._sock._sock.close() would
force the close). The original fp is held in closures of
.readline(s)/__iter__/next... 

--

I now tried an alternative patch (instead of the
shutdown(2)-patch), which also so far seems to cure
everything . Maybe thats the right solution for the bug:

--- httplib.py.orig     2006-05-11 11:25:32.000000000 +0200
+++ httplib.py  2006-05-11 13:45:07.000000000 +0200
@@ -970,6 +970,7 @@
             self._shared.decref()
             self._closed = 1
             self._shared = None
+            self._ssl = None

 class SSLFile(SharedSocketClient):
     """File-like object wrapping an SSL socket."""
@@ -1085,6 +1086,7 @@
     def close(self):
         SharedSocketClient.close(self)
         self._sock = self.__class__._closedsocket()
+        self._ssl = None

     def makefile(self, mode, bufsize=None):
         if mode != 'r' and mode != 'rb':


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



In another application with SSL'ed SMTP connections there
arose similar problems.

I also worked around the problem in smtplib.py so far in a
similar style:

    def close(self):
        self.realsock.shutdown(2)
        self.realsock.close()


---

Yet, the right patch maybe (not tested extensively so far):


--- Lib-orig/smtplib.py 2006-05-03 13:10:40.000000000 +0200
+++ Lib/smtplib.py      2006-05-11 13:50:12.000000000 +0200
@@ -142,6 +142,7 @@
     sendall = send

     def close(self):
+        self.sslobj = None
         self.realsock.close()

 class SSLFakeFile:
@@ -161,7 +162,7 @@
         return str

     def close(self):
-        pass
+        self.sslobj = None

 def quoteaddr(addr):
     """Quote a subset of the email addresses defined by RFC
821.


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

-robert

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

Comment By: kxroberto (kxroberto)
Date: 2005-09-24 21:45

Message:
Logged In: YES 
user_id=972995

Now I managed to solve the problem for me with attached
patch of httplib.py: a explicit shutdown ( 2 or 1 ) of the
(faked) ssl'ed socket solves it. 
I still guess the ssl'ed socket (ssl dll) should do that
auto on sock.close() 
Thus I  leave it as a bug HERE. Right?

[ I also have the hope, that this also solves the
ssl-eof-errors with https (of some of my users; will see
this in future)


*** \usr\src\py24old/httplib.py Sat Sep 24 21:35:28 2005
--- httplib.py  Sat Sep 24 21:37:48 2005
*************** class SharedSocket:
*** 899,904 ****
--- 899,905 ----
          self._refcnt -= 1
          assert self._refcnt >= 0
          if self._refcnt == 0:
+             self.sock.shutdown(2)
              self.sock.close()

      def __del__(self):

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

Comment By: kxroberto (kxroberto)
Date: 2005-09-24 21:06

Message:
Logged In: YES 
user_id=972995

I retried that again with py2.4.1. The problem/bug is still
there.

In attachment I supplied a full FTPS client test_ftpslib.py
with simple test function - ready to run into the problem:
At the end of ftp.retrlines 'return self.voidresp()' 
freezes : waiting eternally for response bytes at the
command port. the same at the end of .storelines after the
data is transfered on the data port.

My preliminary guess is still, that python's ssl has a
severe (EOF?) problem closing a socket/connection correctly.
 obviously this problem doesn't show up with https because
everything is done on one connection - no dependency on a
correct socket/connect close signal.

(from other https communication with some proxies in between
my users get ssl-eof-error errors also. I still can't solve
that bug too. this shows python's ssl has a severe EOF bug
with complex https also - or cannot handle certain
situations correct.)

I learned the FTPS/TLS client from M2crypto's ftpslib. the
only difference in (transposed) logic, that I can see is,
that M2crpyto uses an additional line
"conn.set_session(self.sock.get_session())" during setup of
the data port ssl connection. I don't know what it is,
pythons ssl doesn't have sucht "session"-functions, but I
think it has no severe meaning.?

Robert

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

Comment By: Brett Cannon (bcannon)
Date: 2004-12-22 06:14

Message:
Logged In: YES 
user_id=357491

Since I believe this was fixed with the patch Tino mentions and Roberto 
has not replied, I am closing as fixed.

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

Comment By: Brett Cannon (bcannon)
Date: 2004-08-17 01:18

Message:
Logged In: YES 
user_id=357491

Is this still a problem for you, Roberto, with Python 2.4a2?

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

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  Mon Jul  3 14:21:07 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 03 Jul 2006 05:21:07 -0700
Subject: [ python-Bugs-1417699 ] float/atof have become locale aware
Message-ID: <E1FxNQJ-0007JZ-Nv@sc8-sf-web5.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Bernhard Herzog (bernhard)
Assigned to: Nobody/Anonymous (nobody)
Summary: float/atof have become locale aware

Initial Comment:
The builtin float and the function string.atof have
become locale aware in Python 2.4:

Python 2.4.2 (#1, Nov 29 2005, 16:07:55) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import locale
>>> import string
>>> locale.setlocale(locale.LC_ALL, "de_DE")
'de_DE'
>>> float("1,5")
1.5
>>> string.atof("1,5")
1.5


This doesn't match what's specified in pep 331:

        - float() and str() stay locale-unaware.

It also doesn't match the documentation for atof:

  Convert a string to a floating point number.
  The string must have the standard syntax for a
  floating point literal in Python, optionally
  preceded by a sign ("+" or "-"). Note that this
  behaves identical to the built-in function float()
  when passed a string.

The documentation for float() doesn't state which
format is accepted by float(), though.

The reason for this behavior is ultimately, that
PyOS_ascii_strtod accepts the locale specific
convention in addition to the "C"-locale/python
convention, even though the comment in the code
preceding its definition states:

  This function behaves like the standard strtod() 
  function does in the C locale.




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

>Comment By: Martin v. L??wis (loewis)
Date: 2006-07-03 14:21

Message:
Logged In: YES 
user_id=21627

Thanks for the report and the patch. Committed as r47212.

I don't think it should get backported to 2.4, as it may
break existing code.

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

Comment By: Bernhard Herzog (bernhard)
Date: 2006-06-10 21:18

Message:
Logged In: YES 
user_id=2369

gustavo, your patch seems to work fine.  However, it leads
to some test failures because the testsuite already tests
for the wrong behaviour.  I've uploaded a version of your
patch that in addtion to your changes contains modifications
to the test suite so that it tests for the new behavior and
also tests some more variations of floating point literals
accepted by float().

It would be nice if this patch could go into 2.5 before beta1

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

Comment By: Gustavo J. A. M. Carneiro (gustavo)
Date: 2006-05-16 18:35

Message:
Logged In: YES 
user_id=908

It seems I can't upload files?!
I have put the patch to fix this problem, including unit
test, here: http://www.gnome.org/~gjc/python-1417699.diff

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

Comment By: Gustavo J. A. M. Carneiro (gustavo)
Date: 2006-05-13 13:59

Message:
Logged In: YES 
user_id=908

I'm quite busy at this moment, but I'll send a patch soon,
promise.

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-05-12 16:14

Message:
Logged In: YES 
user_id=21627

Unassigning myself - I don't plan to work on this anytime soon.

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

Comment By: Georg Brandl (gbrandl)
Date: 2006-05-08 20:00

Message:
Logged In: YES 
user_id=849994

I grepped around and found PyOS_ascii_strtod in the
following places:

* stropmodule::atof
* cPickle::load_float (the writing of locale dependent
floats was fixed recently)
* floatobject::PyFloat_FromString
* complexobject::complex_subtype_from_string

In my opinion, all these should not tolerate localized
floats, so Gustavo, please ask the original author how to
achieve this.

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

Comment By: Gustavo J. A. M. Carneiro (gustavo)
Date: 2006-05-04 11:47

Message:
Logged In: YES 
user_id=908

My comment is, is "PyOS_ascii_strtod accepting both forms"
something that is harmful and should be fixed?

I didn't exactly write the PyOS_ascii_strtod code; I only
integrated it with Python.  But if we really need to fix
this, I'll try to figure out how to make it not accept
floating points in locale aware format; if necessary I'll
ask help from  the original author of the code, Alexander
Larsson.

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-05-04 06:42

Message:
Logged In: YES 
user_id=21627

It's a bug. As bernhard says, it originates from
PyOS_ascii_strtod accepting both forms, which in turn
happens because it just leaves the locale-specific decimal
point in the string, only replacing the . with the
locale-specific point. Then, the platform's strtod will
happily accept the locale-specific version. 

I'd like Gustavo Carneiro to comment.

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

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-17 13:19

Message:
Logged In: YES 
user_id=1188172

Martin, you checked in the patch which is mentioned in PEP
331. Is this correct behavior?

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

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

From noreply at sourceforge.net  Mon Jul  3 14:31:58 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 03 Jul 2006 05:31:58 -0700
Subject: [ python-Bugs-1362587 ] Problem with tapedevices and the tarfile
	module
Message-ID: <E1FxNao-0003cf-6U@sc8-sf-web3.sourceforge.net>

Bugs item #1362587, was opened at 2005-11-21 08:44
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1362587&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
>Priority: 5
Submitted By: Henrik (esshenrik)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem with tapedevices and the tarfile module

Initial Comment:
Problem to read a archive from tape that was created 
with the tarfile module in python.

Error:
>>> tar = tarfile.open("/dev/st0", "r")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.4/tarfile.py", line 
916, in open
    return func(name, "r", fileobj)
  File "/usr/local/lib/python2.4/tarfile.py", line 
933, in taropen
    return cls(name, mode, fileobj)
  File "/usr/local/lib/python2.4/tarfile.py", line 
811, in __init__
    fileobj = file(self.name, self.mode)
IOError: [Errno 16] Device or resource 
busy: '/dev/st0'


I was creating the archive with succes:
>>> tar.close()
>>> tar = tarfile.open("/dev/st0", "w")
>>> tar.add("/tmp/bin1.tar")
>>> tar.add("/tmp/bin2.tar")
>>> tar.close()
>>>

When I try to read the tape without pyton the 
folowing error:
[root at localhost tmp]# tar tvbf 20 /dev/st0
tar: Record size = 8 blocks
-rw-r--r-- root/root 128614400 2005-11-20 19:53:11 
tmp/bin1.tar
tar: /dev/st0: Cannot read: Cannot allocate memory
tar: /dev/st0: Cannot read: Cannot allocate memory
tar: /dev/st0: Cannot read: Cannot allocate memory
tar: /dev/st0: Cannot read: Cannot allocate memory
tar: /dev/st0: Cannot read: Cannot allocate memory
tar: /dev/st0: Cannot read: Cannot allocate memory
tar: /dev/st0: Cannot read: Cannot allocate memory
......

Can anyone help me with this problem or have another 
module for tarfile that works with tapedevices?

/Henrik 


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

>Comment By: Martin v. L??wis (loewis)
Date: 2006-07-03 14:31

Message:
Logged In: YES 
user_id=21627

Lowering priority, as the issue doesn't appear that urgent.

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

Comment By: Lars Gust?bel (gustaebel)
Date: 2005-11-21 09:40

Message:
Logged In: YES 
user_id=642936

Could try and use tarfile's stream interface for writing and
reading and see if that works? Just append a pipe symbol to
the mode, e.g.:

tar = tarfile.open("/dev/st0", "w|")

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

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

From noreply at sourceforge.net  Mon Jul  3 14:36:14 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 03 Jul 2006 05:36:14 -0700
Subject: [ python-Bugs-1237697 ] link path probs on OSX re: Tcl,
	Tk & fink's /sw
Message-ID: <E1FxNew-0001N8-Ex@sc8-sf-web1.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.4
Status: Open
Resolution: None
>Priority: 5
Submitted By: OpenMacNews (blakers)
Assigned to: Nobody/Anonymous (nobody)
Summary: link path probs on OSX re: Tcl, Tk & fink's /sw

Initial Comment:
hi all,

i'm bldg Python 2.4.1 on OSX 10.4.1 ...

i've installed a late version of Tcl/Tk framework in:

   /Library/Frameworks/Tcl.framework
   /Library/Frameworks/Tk.framework

iiuc, these frameworks/libs are SUPPOSED to be searched PRIOR to /
System/Library/Frameworks ...

i've installed the Fink dev env in "/sw"

the Fink ev is 'disabled' o my box ... i.e., "/sw" is NOT in my path ...



that said, the Python build 'insists' on building against:

(1) the /System/... Tcl & Tk frameworks
(2) libs/includes in /sw/... (e.g., ndbm.h ...)

correcting the problem is INSENSITIVE to discreet inclusion of /Library/
Frameworks in LD_LIBRARY_PATH/DYLD_LIBRARY_PATH

only the build time spec'n of:

   setenv LDFLAGS "-L/Library/Frameworks -framework Tcl -framework 
Tk"

seems to do the trick ...

as for /sw, only a:

mv /sw /swTMP
( ... build ...)
mv /swTMP /sw

seems to work.

cheers,

richard


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

>Comment By: Martin v. L??wis (loewis)
Date: 2006-07-03 14:36

Message:
Logged In: YES 
user_id=21627

It's not clear to me what the problem is that is being
reported here; it looks like a messed-up setup on the build
machine to me. Lowering the priority to "normal".

blakers, if the problem persists, it would be good if you
could start all over:
1) close this report
2) create a new report, indicating
   a) what you did
   b) what happened (stop your report at the first error,
      later errors might be follow-up)
   c) what you expected to happen instead.

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

Comment By: OpenMacNews (blakers)
Date: 2005-07-13 20:32

Message:
Logged In: YES 
user_id=564069

1st, i "lied" earlier ... i'm building on OSX 10.4.2, not 10.4.1.

AND, apparently, i still have a problem ... the WRONG HEADERS.

even with:

	setenv CPPFLAGS "-I/Library/Frameworks/Tcl.framework/Headers -I/
Library/Frameworks/Tcl.framework/Versions/Current/PrivateHeaders -I/
Library/Frameworks/Tk.framework/Headers -I/Library/Frameworks/
Tk.framework/Versions/Current/PrivateHeaders"

set prior to configure, the build 'make' STILL complains abt:

building '_tkinter' extension
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fno-strict-aliasing -Wno-
long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -
DWITH_APPINIT=1 -I/System/Library/Frameworks/Tcl.framework/Headers -I/
System/Library/Frameworks/Tcl.framework/Versions/Current/PrivateHeaders -
I/System/Library/Frameworks/Tk.framework/Headers -I/System/Library/
Frameworks/Tk.framework/Versions/Current/PrivateHeaders -I/usr/X11R6/
include -I. -I/usr/ports/Python-2.4.1/./Include -I/usr/ports/Python-2.4.1/./Mac/
Include -I/usr/local/include -I/usr/ports/Python-2.4.1/Include -I/usr/ports/
Python-2.4.1 -c /usr/ports/Python-2.4.1/Modules/_tkinter.c -o build/
temp.darwin-8.2.0-Power_Macintosh-2.4/_tkinter.o -framework Tcl -
framework Tk
In file included from /System/Library/Frameworks/Tk.framework/Headers/tk.h:
96,
                 from /usr/ports/Python-2.4.1/Modules/_tkinter.c:67:
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:140: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:343: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:462: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:480: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:505: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:506: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:518: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:531: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:1065: 
warning: function declaration isn't a prototype
powerpc-apple-darwin8-gcc-4.0.0: -framework: linker input file unused 
because linking not done
powerpc-apple-darwin8-gcc-4.0.0: Tcl: linker input file unused because 
linking not done
powerpc-apple-darwin8-gcc-4.0.0: -framework: linker input file unused 
because linking not done
powerpc-apple-darwin8-gcc-4.0.0: Tk: linker input file unused because 
linking not done
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fno-strict-aliasing -Wno-
long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -
DWITH_APPINIT=1 -I/System/Library/Frameworks/Tcl.framework/Headers -I/
System/Library/Frameworks/Tcl.framework/Versions/Current/PrivateHeaders -
I/System/Library/Frameworks/Tk.framework/Headers -I/System/Library/
Frameworks/Tk.framework/Versions/Current/PrivateHeaders -I/usr/X11R6/
include -I. -I/usr/ports/Python-2.4.1/./Include -I/usr/ports/Python-2.4.1/./Mac/
Include -I/usr/local/include -I/usr/ports/Python-2.4.1/Include -I/usr/ports/
Python-2.4.1 -c /usr/ports/Python-2.4.1/Modules/tkappinit.c -o build/
temp.darwin-8.2.0-Power_Macintosh-2.4/tkappinit.o -framework Tcl -
framework Tk
In file included from /System/Library/Frameworks/Tk.framework/Headers/tk.h:
96,
                 from /usr/ports/Python-2.4.1/Modules/tkappinit.c:17:
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:140: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:343: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:462: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:480: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:505: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:506: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:518: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:531: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:1065: 
warning: function declaration isn't a prototype
powerpc-apple-darwin8-gcc-4.0.0: -framework: linker input file unused 
because linking not done
powerpc-apple-darwin8-gcc-4.0.0: Tcl: linker input file unused because 
linking not done
powerpc-apple-darwin8-gcc-4.0.0: -framework: linker input file unused 
because linking not done
powerpc-apple-darwin8-gcc-4.0.0: Tk: linker input file unused because 
linking not done
gcc -L/Library/Frameworks -framework Tcl -framework Tk -bundle -undefined 
dynamic_lookup -L/Library/Frameworks -framework Tcl -framework Tk -I. -I./
Include build/temp.darwin-8.2.0-Power_Macintosh-2.4/_tkinter.o build/
temp.darwin-8.2.0-Power_Macintosh-2.4/tkappinit.o -L/usr/local/lib -o build/
lib.darwin-8.2.0-Power_Macintosh-2.4/_tkinter.so -framework Tcl -framework 
Tk
running build_scripts
creating build/scripts-2.4
copying and adjusting /usr/ports/Python-2.4.1/Tools/scripts/pydoc -> build/
scripts-2.4
copying and adjusting /usr/ports/Python-2.4.1/Tools/scripts/idle -> build/
scripts-2.4
copying and adjusting /usr/ports/Python-2.4.1/Lib/smtpd.py -> build/scripts-2.4
changing mode of build/scripts-2.4/pydoc from 644 to 755
changing mode of build/scripts-2.4/idle from 644 to 755
changing mode of build/scripts-2.4/smtpd.py from 644 to 755

cheers,

richard



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

Comment By: OpenMacNews (blakers)
Date: 2005-07-13 19:56

Message:
Logged In: YES 
user_id=564069

1st, i "lied" earlier ... i'm building on OSX 10.4.2, not 10.4.1.

AND, apparently, i still have a problem ... the WRONG HEADERS.

even with:

	setenv CPPFLAGS "-I/Library/Frameworks/Tcl.framework/Headers -I/
Library/Frameworks/Tcl.framework/Versions/Current/PrivateHeaders -I/
Library/Frameworks/Tk.framework/Headers -I/Library/Frameworks/
Tk.framework/Versions/Current/PrivateHeaders"

set prior to configure, the build 'make' STILL complains abt:

building '_tkinter' extension
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fno-strict-aliasing -Wno-
long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -
DWITH_APPINIT=1 -I/System/Library/Frameworks/Tcl.framework/Headers -I/
System/Library/Frameworks/Tcl.framework/Versions/Current/PrivateHeaders -
I/System/Library/Frameworks/Tk.framework/Headers -I/System/Library/
Frameworks/Tk.framework/Versions/Current/PrivateHeaders -I/usr/X11R6/
include -I. -I/usr/ports/Python-2.4.1/./Include -I/usr/ports/Python-2.4.1/./Mac/
Include -I/usr/local/include -I/usr/ports/Python-2.4.1/Include -I/usr/ports/
Python-2.4.1 -c /usr/ports/Python-2.4.1/Modules/_tkinter.c -o build/
temp.darwin-8.2.0-Power_Macintosh-2.4/_tkinter.o -framework Tcl -
framework Tk
In file included from /System/Library/Frameworks/Tk.framework/Headers/tk.h:
96,
                 from /usr/ports/Python-2.4.1/Modules/_tkinter.c:67:
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:140: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:343: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:462: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:480: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:505: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:506: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:518: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:531: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:1065: 
warning: function declaration isn't a prototype
powerpc-apple-darwin8-gcc-4.0.0: -framework: linker input file unused 
because linking not done
powerpc-apple-darwin8-gcc-4.0.0: Tcl: linker input file unused because 
linking not done
powerpc-apple-darwin8-gcc-4.0.0: -framework: linker input file unused 
because linking not done
powerpc-apple-darwin8-gcc-4.0.0: Tk: linker input file unused because 
linking not done
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fno-strict-aliasing -Wno-
long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -
DWITH_APPINIT=1 -I/System/Library/Frameworks/Tcl.framework/Headers -I/
System/Library/Frameworks/Tcl.framework/Versions/Current/PrivateHeaders -
I/System/Library/Frameworks/Tk.framework/Headers -I/System/Library/
Frameworks/Tk.framework/Versions/Current/PrivateHeaders -I/usr/X11R6/
include -I. -I/usr/ports/Python-2.4.1/./Include -I/usr/ports/Python-2.4.1/./Mac/
Include -I/usr/local/include -I/usr/ports/Python-2.4.1/Include -I/usr/ports/
Python-2.4.1 -c /usr/ports/Python-2.4.1/Modules/tkappinit.c -o build/
temp.darwin-8.2.0-Power_Macintosh-2.4/tkappinit.o -framework Tcl -
framework Tk
In file included from /System/Library/Frameworks/Tk.framework/Headers/tk.h:
96,
                 from /usr/ports/Python-2.4.1/Modules/tkappinit.c:17:
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:140: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:343: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:462: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:480: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:505: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:506: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:518: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:531: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:1065: 
warning: function declaration isn't a prototype
powerpc-apple-darwin8-gcc-4.0.0: -framework: linker input file unused 
because linking not done
powerpc-apple-darwin8-gcc-4.0.0: Tcl: linker input file unused because 
linking not done
powerpc-apple-darwin8-gcc-4.0.0: -framework: linker input file unused 
because linking not done
powerpc-apple-darwin8-gcc-4.0.0: Tk: linker input file unused because 
linking not done
gcc -L/Library/Frameworks -framework Tcl -framework Tk -bundle -undefined 
dynamic_lookup -L/Library/Frameworks -framework Tcl -framework Tk -I. -I./
Include build/temp.darwin-8.2.0-Power_Macintosh-2.4/_tkinter.o build/
temp.darwin-8.2.0-Power_Macintosh-2.4/tkappinit.o -L/usr/local/lib -o build/
lib.darwin-8.2.0-Power_Macintosh-2.4/_tkinter.so -framework Tcl -framework 
Tk
running build_scripts
creating build/scripts-2.4
copying and adjusting /usr/ports/Python-2.4.1/Tools/scripts/pydoc -> build/
scripts-2.4
copying and adjusting /usr/ports/Python-2.4.1/Tools/scripts/idle -> build/
scripts-2.4
copying and adjusting /usr/ports/Python-2.4.1/Lib/smtpd.py -> build/scripts-2.4
changing mode of build/scripts-2.4/pydoc from 644 to 755
changing mode of build/scripts-2.4/idle from 644 to 755
changing mode of build/scripts-2.4/smtpd.py from 644 to 755

cheers,

richard



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

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

From noreply at sourceforge.net  Mon Jul  3 14:38:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 03 Jul 2006 05:38:42 -0700
Subject: [ python-Bugs-992389 ] attribute error after non-from import
Message-ID: <E1FxNhK-0006SK-Ox@sc8-sf-web3.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
>Priority: 5
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.


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

>Comment By: Martin v. L??wis (loewis)
Date: 2006-07-03 14:38

Message:
Logged In: YES 
user_id=21627

Lowering the priority, as this apparently is not a
high-priority issue.

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

Comment By: Tim Peters (tim_one)
Date: 2004-11-16 03:03

Message:
Logged In: YES 
user_id=31435

Nick, the semantics of circular imports aren't clear even if no 
packages are involved.  Note that the Reference manual is 
silent about such cases.  In effect, it's defined by the 
implementation, and some people think they know how that 
works -- although nobody has credibly claimed to fully 
understand the implementation consequences since Gordon 
McMillan vanished <0.5 wink>.

While I expect this bug report to sit here for years (it's hard 
to imagine anyone caring enough to devote the time needed 
to untangle this subsystem), I'll note in passing that this 
case "works" if bar.py uses relative import instead; i.e., if it 
begins with

import baz
y = baz.y

instead of with

import eek.foo.baz
y = eek.foo.baz.y

Then it stops referencing attributes that don't exist before 
the whole chain of imports completes.

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

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-11-15 12:08

Message:
Logged In: YES 
user_id=1038590

If the semantics aren't clear, then isn't that a bug in
itself? If the behaviour of Jim's code is officially
undefined, then the docs need to say so.

A simple rule would seem to be "a package should not try to
import itself or any subpackages with an absolute import in
its __init__.py file".

Given the nature of __all__ and __path__ for packages, I
can't see a way to safely set eek's foo attribute before
foo's __init__.py has been processed.


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

Comment By: Jeremy Hylton (jhylton)
Date: 2004-11-07 16:30

Message:
Logged In: YES 
user_id=31392

Are the semantics of import clear enough to confirm that
this is a bug?  Specifically, this seems to revolve around
circular imports and code in __init__.  I agree that this
behavior is confusing, but I don't know if that has more to
do with the nature of circular imports than any bug.



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

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

From noreply at sourceforge.net  Mon Jul  3 14:41:48 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 03 Jul 2006 05:41:48 -0700
Subject: [ python-Bugs-956303 ] Potential data corruption bug in save_pers in
	pickle module.
Message-ID: <E1FxNkK-0001rF-4s@sc8-sf-web1.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
>Priority: 5
Submitted By: Allan Crooks (amc1)
Assigned to: Nobody/Anonymous (nobody)
Summary: Potential data corruption bug in save_pers in pickle module.

Initial Comment:
There is a bug in save_pers in both the pickle and
cPickle modules in Python.

It occurs when someone uses a Pickler instance which is
using an ASCII protocol and also has persistent_id
defined which can return a persistent reference that
can contain newline characters in.

The current implementation of save_pers in the pickle
module is as follows:

----

   def save_pers(self, pid):
        # Save a persistent id reference
        if self.bin:
            self.save(pid)
            self.write(BINPERSID)
        else:
            self.write(PERSID + str(pid) + '\n')

----

The else clause assumes that the 'pid' will not be a
string which one or more newline characters.

If the pickler pickles a persistent ID which has a
newline in it, then an unpickler with a corresponding
persistent_load method will incorrectly unpickle the
data - usually interpreting the character after the
newline as a marker indicating what type of data should
be expected (usually resulting in an exception being
raised when the remaining data is not in the format
expected).

I have attached an example file which illustrates in
what circumstances the error occurs.

Workarounds for this bug are:
  1) Use binary mode for picklers.
  2) Modify subclass implementations of save_pers to
ensure that newlines are not returned for persistent ID's.

Although you may assume in general that this bug would
only occur on rare occasions (due to the unlikely
situation where someone would implement persistent_id
so that it would return a string with a newline
character embedded), it may occur more frequently if
the subclass implementation of persistent_id uses a
string which has been constructed using the marshal module.

This bug was discovered when our code implemented the
persistent_id method, which was returning the
marshalled format of a tuple which contained strings.
It occurred when one or more of the strings had a
length of ten characters - the marshalled format of
that string contains the string's length, where the
byte used to represent the number 10 is the same as the
one which represents the newline character:

>>> marshal.dumps('a' * 10)
's\n\x00\x00\x00aaaaaaaaaa'
>>> chr(10)
'\n'

I have replicated this bug on Python 1.5.2 and Python
2.3b1, and I believe it is present on all 2.x versions
of Python.

Many thanks to SourceForge user (and fellow colleague)
SMST who diagnosed the bug and provided the test cases
attached.

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

>Comment By: Martin v. L??wis (loewis)
Date: 2006-07-03 14:41

Message:
Logged In: YES 
user_id=21627

Also lowering the priority. amc1, if you are still
interested, are you willing to provide a documentation patch?

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

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

Message:
Logged In: YES 
user_id=31435

Unassigned myself (I don't have time for it), but changed the 
Category to Documentation.  (Changing what a persistent ID 
can be would need to be a new feature request.)

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

Comment By: Allan Crooks (amc1)
Date: 2004-05-19 17:30

Message:
Logged In: YES 
user_id=39733

I would at least like the documentation modified to make it
clearer that certain characters are not permitted for
persistent ID's. I think the text which indicates the
requirement of printable ASCII characters is too subtle -
there should be something which makes the requirement more
obvious, the use of a "must" or "should" would help get the
point across (as would some text after the statement
indicating that characters such as '\b', '\n', '\r' are not
permitted).

Perhaps it would be an idea for save_pers to do some
argument checking before storing the persistent ID, perhaps
using an assertion statement to verify that the ID doesn't
contain non-permitted characters (or at least, checking for
the presence of a '\n' character embedded in the string).

I think it is preferable to have safeguards implemented in
Pickler to prevent potentially dodgy data being stored - I
would rather have an error raised when I'm trying to pickle
something than have the data stored and corrupted, only to
notice it when it is unpickled (when it is too late).

Confusingly, the code in save_pers in the pickle module
seems to indicate that it would happily accept non-String
based persistent ID's:

----
else:
 self.write(PERSID + str(pid) + '\n')
----

I don't understand why we are using the str function if we
are expecting pid to be a string in the first place. I would
rather that this method would raise an error if it tried to
perform string concatenation on something which isn't a string.

I agree with SMST, I would like the restriction removed over
what persistent ID's we can use, it seems somewhat arbitary
- there's no reason, for example, why we can't use any
simple data type which can be marshalled as an ID.

Apart from the reason that it wouldn't be backwardly
compatible, which is probably a good enough reason. :)

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

Comment By: Steve Tregidgo (smst)
Date: 2004-05-19 12:31

Message:
Logged In: YES 
user_id=42335

I'd overlooked that note in the documentation before, and in
fact developed the opposite view on what was allowed by
seeing that the binary pickle format happens to allow
persistent IDs containing non-printable ASCII characters.

Given that the non-binary format can represent strings
(containing any character, printable or not) by escaping
them, it seems unfortunate that the same escaping was not
applied to the saving of persistent IDs.

It might be helpful if the documentation indicated that the
acceptance by the binary pickle format of strings without
restriction is not to be relied upon, underlining the fact
that printable ASCII is all that's allowed by the format.

Personally I'd like to see the restriction on persistent IDs
lifted in a future version of the pickle module, but I don't
have a compelling reason for it (other than it seeming to be
unnecessary). On the other hand, it seems to be a limitation
which hasn't caused much grief (if any) over the years...
perhaps such a change (albeit a minor one) in the
specifications should be left until another protocol is
introduced.


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

Comment By: Tim Peters (tim_one)
Date: 2004-05-19 05:02

Message:
Logged In: YES 
user_id=31435

The only documentation is the "Pickling and unpickling 
external objects" section of the Library Reference Manual, 
which says:

"""
Such objects are referenced by a ``persistent id'', which is 
just an arbitrary string of printable ASCII characters.
"""

A newline is universally considered to be a control character, 
not a printable character (e.g., try isprint('\n') under your 
local C compiler).  So this is functioning as designed and as 
documented.  If you don't find the docs clear, we should call 
this a documentation bug.  If you think the semantics should 
change to allow more than printable characters, then this 
should become a feature request, and more is needed to 
define exactly which characters should be allowed.  The 
current implementation is correct for persistent ids that meet 
the documented requirement.

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

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

From noreply at sourceforge.net  Mon Jul  3 14:48:16 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 03 Jul 2006 05:48:16 -0700
Subject: [ python-Bugs-827760 ] Bug in dbm - long strings in keys and values
Message-ID: <E1FxNqa-0002WD-9g@sc8-sf-web1.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
>Group: 3rd Party
>Status: Closed
>Resolution: Wont Fix
Priority: 7
Submitted By: John Draper (jdcrunchman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bug in dbm - long strings in keys and values

Initial Comment:
#!/usr/local/bin/python
#2003-10-19. Feedback to crunch at shopip.com
import dbm

print &quot;&quot;&quot;
Python dbm bugs summary:
  1. Long strings cause weirdness.
  2. Long keys fail without returning error.

This demonstrates serious bugs in the Python dbm 
module.
Present in OpenBSD versions 2.2, 2.3, and 2.3.2c1.

len(key+string)&gt;61231 results in the item being 'lost', 
without warning.
If the key or string is one character shorter, it is fine.
Writing multiple long strings causes unpredictable results
(none, some, or all of the items are lost without warning).

Curiously, keys of length 57148 return an error, but
longer keys fail without warning
(sounds like an = instead of a &gt; somewhere).
&quot;&quot;&quot;

mdb=dbm.open(&quot;mdb&quot;,&quot;n&quot;)
print &quot;Writing 1 item to database, but upon reading,&quot;
k='k'
v='X'*61230 #Long string
mdb[k]=v
mdb.close()

md=dbm.open(&quot;mdb&quot;,&quot;r&quot;)
print &quot;database contains %i items&quot;%len(md.keys())
md.close()

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

>Comment By: Martin v. L??wis (loewis)
Date: 2006-07-03 14:48

Message:
Logged In: YES 
user_id=21627

I'm closing this as a third-party bug. If there is any
evidence that there is something that Python could do to
reduce the impact of this problem, please submit this as a
new bug report.

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

Comment By: Tino Lange (tinolange)
Date: 2003-10-26 16:06

Message:
Logged In: YES 
user_id=212920

Hi!

This is no bug - at least no python bug.
It seems to be a limitation in the underlying dbm engine.

I tested it with different dbm implementations under Linux
today. You are right - when using dbm as ndbm.h (which
belongs to libc6, i.e. db1/ndbm.h) this error/limitation occurs.
Please test: At least for me the dbm engine still finds the
data if you specify it, a print md[k] shows the long v
string. Only the keys() and len() methods which iterate over
the database fail.

I also tested without Python, i. e. just using the C-API and
it's just the same (linking against libdb1.so). It is the
underlying dbm_firstkey() which fails when using that HUGE
keys. It just returns NULL.

Context:
--------

drec=dbm_firstkey(dbm);
while(drec.dptr) {
  size++;
  drec = dbm_nextkey(dbm);
}


If you happen to have a system that uses gdbm/ndbm.h as
dbm.h (for example SuSE) or if you change the links in your
include and lib directories accordingly and recompile Python
then this bug disappears and your program is working as
expected. The GNU gdbm engine (I tested 1.73 and 1.8.3)
seems to be much better in handling huge keys as the old
libc dbm.

If possible change to gdbm or assure that dbm is linked
against gdbm (-compat). setup.py tries to be smart about
that but sometimes chooses the old dbm even if it could use
gdbm instead.

ldd /usr/local/lib/python2.3/lib-dynload/dbm.so

shows you what lib you're using.

On my Debian system an
ln -sf /usr/include/gdbm/ndbm.h /usr/include/ndbm.h
ln -sf /usr/lib/libgdbm.so /usr/lib/libndbm.so
fixed it.

Ciao

Tino

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

Comment By: John Draper (jdcrunchman)
Date: 2003-10-25 00:47

Message:
Logged In: YES 
user_id=891874

I upped the priority since this bug causes dbm database 
corruption, which could be disastrous for users of dbm or 
shelve.


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

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

From noreply at sourceforge.net  Mon Jul  3 15:03:26 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 03 Jul 2006 06:03:26 -0700
Subject: [ python-Bugs-822974 ] Telnet.read_until() timeout parameter
	misleading 
Message-ID: <E1FxO5G-0003xc-PN@sc8-sf-web1.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Mitchel Quinn (mnquinn)
Assigned to: Nobody/Anonymous (nobody)
Summary: Telnet.read_until() timeout parameter misleading 

Initial Comment:
Telnet.read_until(str,timeout) documentation reads as
follows:
Read until a given string, expected, is encountered or
until timeout seconds have passed.

When no match is found, return whatever is available
instead, possibly the empty string. Raise EOFError if
the connection is closed and no cooked data is available. 

However, the method does not behave in this manner. The
method will only return if the call to select() on the
socket is blocked for longer than the specified
timeout. If there is a steady stream of data available,
and it does not contain the specified string, this
method will _NEVER_ return.

A possible solution would be to subtract the elapsed
time from the given timeout each time through the while
loop.

Here's a snippet of the code from telnetlib.py
read_until():

        if timeout is not None:
            s_args = s_args + (timeout,)
        while not self.eof and apply(select.select,
s_args) == s_reply:
            i = max(0, len(self.cookedq)-n)
            self.fill_rawq()
            self.process_rawq()
            i = self.cookedq.find(match, i)
            if i &gt;= 0:
                i = i+n
                buf = self.cookedq[:i]
                self.cookedq = self.cookedq[i:]
                return buf
        return self.read_very_lazy()






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

>Comment By: Martin v. L??wis (loewis)
Date: 2006-07-03 15:03

Message:
Logged In: YES 
user_id=21627

This is fixed with said patch.

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

Comment By: Johan M. Hahn (johahn)
Date: 2003-10-17 12:31

Message:
Logged In: YES 
user_id=887415

I confirm everything Mitchel wrote + I have submitted a patch 
for this:


http://sourceforge.net/tracker/index.php?
func=detail&amp;aid=825417&amp;group_id=5470&amp;atid=305470




...johahn


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

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

From noreply at sourceforge.net  Mon Jul  3 15:05:09 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 03 Jul 2006 06:05:09 -0700
Subject: [ python-Bugs-785031 ] MacPython installer fails on UFS filesystem
Message-ID: <E1FxO6v-00013o-98@sc8-sf-web6.sourceforge.net>

Bugs item #785031, was opened at 2003-08-07 23:30
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=785031&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
>Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Nobody/Anonymous (nobody)
Summary: MacPython installer fails on UFS filesystem

Initial Comment:
If you use the binary installer to install to a UFS filesystem 
in stead of an HFS+ filesystem the applets will not work.
The reason is that the #! lines refer to &quot;python&quot; in stead of 
&quot;Python&quot;.

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

>Comment By: Martin v. L??wis (loewis)
Date: 2006-07-03 15:05

Message:
Logged In: YES 
user_id=21627

Does this problem still exist?

In any case, it doesn't appear that urgent, so lowering its
priority.

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

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

From noreply at sourceforge.net  Mon Jul  3 15:15:11 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 03 Jul 2006 06:15:11 -0700
Subject: [ python-Bugs-1424148 ] urllib.FancyURLopener.redirect_internal
	looses data on POST!
Message-ID: <E1FxOGd-0008OD-Df@sc8-sf-web6.sourceforge.net>

Bugs item #1424148, was opened at 2006-02-04 18:35
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1424148&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
>Priority: 5
Submitted By: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib.FancyURLopener.redirect_internal looses data on POST!

Initial Comment:
    def redirect_internal(self, url, fp, errcode,
errmsg, headers, data):
        if 'location' in headers:
            newurl = headers['location']
        elif 'uri' in headers:
            newurl = headers['uri']
        else:
            return
        void = fp.read()
        fp.close()
        # In case the server sent a relative URL, join
with original:
        newurl = basejoin(self.type + ":" + url, newurl)
        return self.open(newurl)


... has to become ...


    def redirect_internal(self, url, fp, errcode,
errmsg, headers, data):
        if 'location' in headers:
            newurl = headers['location']
        elif 'uri' in headers:
            newurl = headers['uri']
        else:
            return
        void = fp.read()
        fp.close()
        # In case the server sent a relative URL, join
with original:
        newurl = basejoin(self.type + ":" + url, newurl)
        return self.open(newurl,data)



... i guess?   (  ",data"  added )

Robert

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

Comment By: John J Lee (jjlee)
Date: 2006-02-06 22:19

Message:
Logged In: YES 
user_id=261020

Conservative or not, I see no utility in changing the
default, and several major harmful effects: old code breaks,
and people have to pore over the specs to figure out why
"urlopen() doesn't work".


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

Comment By: Jim Jewett (jimjjewett)
Date: 2006-02-06 21:52

Message:
Logged In: YES 
user_id=764593

Sorry, I was trying to provide a quick explanation of why we 
couldn't just "do the obvious thing" and repost with data.

Yes, I realize that in practice, GET is used for non-
idempotent actions, and POST is (though less often) done 
automatically.

But since that is the official policy, I wouldn't want to 
bet too heavily against it in a courtroom -- so python 
defaults should be at least as conservative as both the spec 
and the common practice.  

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

Comment By: John J Lee (jjlee)
Date: 2006-02-06 21:24

Message:
Logged In: YES 
user_id=261020

First, anyone replying to this, *please* read this page (and
the whole of this tracker note!) first:

http://ppewww.ph.gla.ac.uk/~flavell/www/post-redirect.html


kxroberto: you say that with standard urllibX error handling
you cannot get an exception on redirected 301/302/307 POST.
 That's not true of urllib2, since you may override
HTTPRedirectHandler.redirect_request(), which method was
designed and documented for precisely that purpose.  It
seems sensible to have a default that does what virtually
all browsers do (speaking as a long-time lynx user!).  I
don't know about the urllib case.

It's perfectly reasonable to extend urllib (if necessary) to
allow the option of raising an exception.  Note that (IIRC!)
 urllib's exceptions do not contain the response body data,
however (urllib2's HTTPErrors do contain the response body
data).

It would of course break backwards compatibility to start
raising exceptions by default here.  I don't think it's
reasonable to break old code on the basis of a notional
security issue when the de-facto standard web client
behaviour is to do the redirect.  In reality, the the only
"security" value of the original prescriptive rule was as a
convention to be followed by white-hat web programmers and
web client implementors to help users avoid unintentionally
re-submitting non-idempotent requests.  Since that
convention is NOT followed in the real world (lynx doesn't
count as the real world ;-), I see no value in sticking
rigidly to the original RFC spec -- especially when 2616
even provides 307 precisely in response to this problem. 
Other web client libraries, for example libwww-perl and Java
HTTPClient, do the same as Python here IIRC.  RFC 2616
section 10.3.4 even suggests web programmers use 302 to get
the behaviour you complain about!

The only doubtful case here is 301.  A decision was made on
the default behaviour in that case back when the tracker
item I pointed you to was resolved.  I think it's a mistake
to change our minds again on that default behaviour.


kxroberto.seek(nrBytes)
assert kxroberto.readline() == """\
To redirect POST as GET _while_ simply loosing (!) the data
(and not appending it to the GET-URL) is most bad for a lib."""

No.  There is no value in supporting behaviour which is
simply contrary to both de-facto and prescriptive standards
(see final paragraph of RFC 2616 section 10.3.3: if we
accept the "GET on POST redirect" rule, we must accept that
the Location header is exactly the URL that should be
followed).  FYI, many servers return a redirect URL
containing the urlencoded POST data from the original request.


kxroberto: """Don't know if the MS & netscape's also
transpose to GET with long data? ..."""

urllib2's behaviour (and urllib's, I believe) on these
issues is identical to that of IE and Firefox.


jimjewett: """In theory, a GET may be automatic, but a POST
requires user interaction, so the user can be held
accountable for the results of a POST, but not of a GET."""

That theory has been experimentally falsified ;-)


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

Comment By: Jim Jewett (jimjjewett)
Date: 2006-02-06 18:57

Message:
Logged In: YES 
user_id=764593

In theory, a GET may be automatic, but a POST requires user 
interaction, so the user can be held accountable for the 
results of a POST, but not of a GET.

Often, the page will respond to either; not sending the 
queries protects privacy in case of problems, and works more 
often than not.  (That said, I too would prefer a raised 
error or a transparent repost, at least as options.)

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

Comment By: kxroberto (kxroberto)
Date: 2006-02-06 11:29

Message:
Logged In: YES 
user_id=972995

> http://python.org/sf/549151

the analyzation of the browsers is right. lynx is best ok to
ask.
But urllibX is not a browser (application) but a lib: As of
now with standard urllibX error handling you cannot code a lynx.

gvr's initial suggestion to raise a clear error (with
redirection-link as attribute of the exception value) is
best ok. Another option would be to simly yield the
undirected stub HTML and leave the 30X-code (and redirection
LOCATION in header).

To redirect POST as GET _while_ simply loosing (!) the data
(and not appending it to the GET-URL) is most bad for a lib.
Transcribing smart a short formlike POST to a GET w QUERY
would be so la la.
Don't know if the MS & netscape's also transpose to GET with
long data? ...

The current behaviour is most worst of all 4. All other
methods whould at least have raisen an early hint/error in
my case.

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

Comment By: John J Lee (jjlee)
Date: 2006-02-06 01:54

Message:
Logged In: YES 
user_id=261020

This is not a bug.
See the long discussion here:
http://python.org/sf/549151

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

Comment By: kxroberto (kxroberto)
Date: 2006-02-04 21:10

Message:
Logged In: YES 
user_id=972995

Found http://www.faqs.org/rfcs/rfc2616.html (below).
But the behaviour is still strange, and the bug even more
serious: a silent redirection of a POST as GET without data
is obscure for a Python language. Leads to unpredictable
results. The cut half execution is not stopable and all is
left to a good reaction of the server, and complex
reinterpreation of the client. Python urllibX should by
default yield the 30X code for a POST redirection and
provide the first HTML: usually a redirection HTML stub with
< a href=...
That would be consistent with the RFC: the User
(=Application! not Python!) can redirect under full control
without generating a wrong call! In my application, a bug
was long unseen because of this wrong behaviour. with
30X-stub it would have been easy to discover and understand ...

urllib2 has the same bug with POST redirection.

=======
10.3.2 301 Moved Permanently

   The requested resource has been assigned a new permanent
URI and any
   future references to this resource SHOULD use one of the
returned
   URIs.  Clients with link editing capabilities ought to
automatically
   re-link references to the Request-URI to one or more of
the new
   references returned by the server, where possible. This
response is
   cacheable unless indicated otherwise.

   The new permanent URI SHOULD be given by the Location
field in the
   response. Unless the request method was HEAD, the entity
of the
   response SHOULD contain a short hypertext note with a
hyperlink to
   the new URI(s).

   If the 301 status code is received in response to a
request other
   than GET or HEAD, the user agent MUST NOT automatically
redirect the
   request unless it can be confirmed by the user, since
this might
   change the conditions under which the request was issued.

      Note: When automatically redirecting a POST request after
      receiving a 301 status code, some existing HTTP/1.0
user agents
      will erroneously change it into a GET request.

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

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

From noreply at sourceforge.net  Mon Jul  3 15:39:17 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 03 Jul 2006 06:39:17 -0700
Subject: [ python-Bugs-1237697 ] link path probs on OSX re: Tcl,
	Tk & fink's /sw
Message-ID: <E1FxOdx-0005X3-NW@sc8-sf-web5.sourceforge.net>

Bugs item #1237697, was opened at 2005-07-13 17:06
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1237697&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.4
>Status: Pending
Resolution: None
Priority: 5
Submitted By: OpenMacNews (blakers)
Assigned to: Nobody/Anonymous (nobody)
Summary: link path probs on OSX re: Tcl, Tk & fink's /sw

Initial Comment:
hi all,

i'm bldg Python 2.4.1 on OSX 10.4.1 ...

i've installed a late version of Tcl/Tk framework in:

   /Library/Frameworks/Tcl.framework
   /Library/Frameworks/Tk.framework

iiuc, these frameworks/libs are SUPPOSED to be searched PRIOR to /
System/Library/Frameworks ...

i've installed the Fink dev env in "/sw"

the Fink ev is 'disabled' o my box ... i.e., "/sw" is NOT in my path ...



that said, the Python build 'insists' on building against:

(1) the /System/... Tcl & Tk frameworks
(2) libs/includes in /sw/... (e.g., ndbm.h ...)

correcting the problem is INSENSITIVE to discreet inclusion of /Library/
Frameworks in LD_LIBRARY_PATH/DYLD_LIBRARY_PATH

only the build time spec'n of:

   setenv LDFLAGS "-L/Library/Frameworks -framework Tcl -framework 
Tk"

seems to do the trick ...

as for /sw, only a:

mv /sw /swTMP
( ... build ...)
mv /swTMP /sw

seems to work.

cheers,

richard


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

Comment By: Martin v. L??wis (loewis)
Date: 2006-07-03 12:36

Message:
Logged In: YES 
user_id=21627

It's not clear to me what the problem is that is being
reported here; it looks like a messed-up setup on the build
machine to me. Lowering the priority to "normal".

blakers, if the problem persists, it would be good if you
could start all over:
1) close this report
2) create a new report, indicating
   a) what you did
   b) what happened (stop your report at the first error,
      later errors might be follow-up)
   c) what you expected to happen instead.

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

Comment By: OpenMacNews (blakers)
Date: 2005-07-13 18:32

Message:
Logged In: YES 
user_id=564069

1st, i "lied" earlier ... i'm building on OSX 10.4.2, not 10.4.1.

AND, apparently, i still have a problem ... the WRONG HEADERS.

even with:

	setenv CPPFLAGS "-I/Library/Frameworks/Tcl.framework/Headers -I/
Library/Frameworks/Tcl.framework/Versions/Current/PrivateHeaders -I/
Library/Frameworks/Tk.framework/Headers -I/Library/Frameworks/
Tk.framework/Versions/Current/PrivateHeaders"

set prior to configure, the build 'make' STILL complains abt:

building '_tkinter' extension
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fno-strict-aliasing -Wno-
long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -
DWITH_APPINIT=1 -I/System/Library/Frameworks/Tcl.framework/Headers -I/
System/Library/Frameworks/Tcl.framework/Versions/Current/PrivateHeaders -
I/System/Library/Frameworks/Tk.framework/Headers -I/System/Library/
Frameworks/Tk.framework/Versions/Current/PrivateHeaders -I/usr/X11R6/
include -I. -I/usr/ports/Python-2.4.1/./Include -I/usr/ports/Python-2.4.1/./Mac/
Include -I/usr/local/include -I/usr/ports/Python-2.4.1/Include -I/usr/ports/
Python-2.4.1 -c /usr/ports/Python-2.4.1/Modules/_tkinter.c -o build/
temp.darwin-8.2.0-Power_Macintosh-2.4/_tkinter.o -framework Tcl -
framework Tk
In file included from /System/Library/Frameworks/Tk.framework/Headers/tk.h:
96,
                 from /usr/ports/Python-2.4.1/Modules/_tkinter.c:67:
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:140: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:343: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:462: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:480: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:505: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:506: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:518: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:531: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:1065: 
warning: function declaration isn't a prototype
powerpc-apple-darwin8-gcc-4.0.0: -framework: linker input file unused 
because linking not done
powerpc-apple-darwin8-gcc-4.0.0: Tcl: linker input file unused because 
linking not done
powerpc-apple-darwin8-gcc-4.0.0: -framework: linker input file unused 
because linking not done
powerpc-apple-darwin8-gcc-4.0.0: Tk: linker input file unused because 
linking not done
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fno-strict-aliasing -Wno-
long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -
DWITH_APPINIT=1 -I/System/Library/Frameworks/Tcl.framework/Headers -I/
System/Library/Frameworks/Tcl.framework/Versions/Current/PrivateHeaders -
I/System/Library/Frameworks/Tk.framework/Headers -I/System/Library/
Frameworks/Tk.framework/Versions/Current/PrivateHeaders -I/usr/X11R6/
include -I. -I/usr/ports/Python-2.4.1/./Include -I/usr/ports/Python-2.4.1/./Mac/
Include -I/usr/local/include -I/usr/ports/Python-2.4.1/Include -I/usr/ports/
Python-2.4.1 -c /usr/ports/Python-2.4.1/Modules/tkappinit.c -o build/
temp.darwin-8.2.0-Power_Macintosh-2.4/tkappinit.o -framework Tcl -
framework Tk
In file included from /System/Library/Frameworks/Tk.framework/Headers/tk.h:
96,
                 from /usr/ports/Python-2.4.1/Modules/tkappinit.c:17:
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:140: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:343: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:462: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:480: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:505: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:506: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:518: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:531: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:1065: 
warning: function declaration isn't a prototype
powerpc-apple-darwin8-gcc-4.0.0: -framework: linker input file unused 
because linking not done
powerpc-apple-darwin8-gcc-4.0.0: Tcl: linker input file unused because 
linking not done
powerpc-apple-darwin8-gcc-4.0.0: -framework: linker input file unused 
because linking not done
powerpc-apple-darwin8-gcc-4.0.0: Tk: linker input file unused because 
linking not done
gcc -L/Library/Frameworks -framework Tcl -framework Tk -bundle -undefined 
dynamic_lookup -L/Library/Frameworks -framework Tcl -framework Tk -I. -I./
Include build/temp.darwin-8.2.0-Power_Macintosh-2.4/_tkinter.o build/
temp.darwin-8.2.0-Power_Macintosh-2.4/tkappinit.o -L/usr/local/lib -o build/
lib.darwin-8.2.0-Power_Macintosh-2.4/_tkinter.so -framework Tcl -framework 
Tk
running build_scripts
creating build/scripts-2.4
copying and adjusting /usr/ports/Python-2.4.1/Tools/scripts/pydoc -> build/
scripts-2.4
copying and adjusting /usr/ports/Python-2.4.1/Tools/scripts/idle -> build/
scripts-2.4
copying and adjusting /usr/ports/Python-2.4.1/Lib/smtpd.py -> build/scripts-2.4
changing mode of build/scripts-2.4/pydoc from 644 to 755
changing mode of build/scripts-2.4/idle from 644 to 755
changing mode of build/scripts-2.4/smtpd.py from 644 to 755

cheers,

richard



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

Comment By: OpenMacNews (blakers)
Date: 2005-07-13 17:56

Message:
Logged In: YES 
user_id=564069

1st, i "lied" earlier ... i'm building on OSX 10.4.2, not 10.4.1.

AND, apparently, i still have a problem ... the WRONG HEADERS.

even with:

	setenv CPPFLAGS "-I/Library/Frameworks/Tcl.framework/Headers -I/
Library/Frameworks/Tcl.framework/Versions/Current/PrivateHeaders -I/
Library/Frameworks/Tk.framework/Headers -I/Library/Frameworks/
Tk.framework/Versions/Current/PrivateHeaders"

set prior to configure, the build 'make' STILL complains abt:

building '_tkinter' extension
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fno-strict-aliasing -Wno-
long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -
DWITH_APPINIT=1 -I/System/Library/Frameworks/Tcl.framework/Headers -I/
System/Library/Frameworks/Tcl.framework/Versions/Current/PrivateHeaders -
I/System/Library/Frameworks/Tk.framework/Headers -I/System/Library/
Frameworks/Tk.framework/Versions/Current/PrivateHeaders -I/usr/X11R6/
include -I. -I/usr/ports/Python-2.4.1/./Include -I/usr/ports/Python-2.4.1/./Mac/
Include -I/usr/local/include -I/usr/ports/Python-2.4.1/Include -I/usr/ports/
Python-2.4.1 -c /usr/ports/Python-2.4.1/Modules/_tkinter.c -o build/
temp.darwin-8.2.0-Power_Macintosh-2.4/_tkinter.o -framework Tcl -
framework Tk
In file included from /System/Library/Frameworks/Tk.framework/Headers/tk.h:
96,
                 from /usr/ports/Python-2.4.1/Modules/_tkinter.c:67:
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:140: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:343: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:462: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:480: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:505: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:506: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:518: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:531: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:1065: 
warning: function declaration isn't a prototype
powerpc-apple-darwin8-gcc-4.0.0: -framework: linker input file unused 
because linking not done
powerpc-apple-darwin8-gcc-4.0.0: Tcl: linker input file unused because 
linking not done
powerpc-apple-darwin8-gcc-4.0.0: -framework: linker input file unused 
because linking not done
powerpc-apple-darwin8-gcc-4.0.0: Tk: linker input file unused because 
linking not done
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fno-strict-aliasing -Wno-
long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -
DWITH_APPINIT=1 -I/System/Library/Frameworks/Tcl.framework/Headers -I/
System/Library/Frameworks/Tcl.framework/Versions/Current/PrivateHeaders -
I/System/Library/Frameworks/Tk.framework/Headers -I/System/Library/
Frameworks/Tk.framework/Versions/Current/PrivateHeaders -I/usr/X11R6/
include -I. -I/usr/ports/Python-2.4.1/./Include -I/usr/ports/Python-2.4.1/./Mac/
Include -I/usr/local/include -I/usr/ports/Python-2.4.1/Include -I/usr/ports/
Python-2.4.1 -c /usr/ports/Python-2.4.1/Modules/tkappinit.c -o build/
temp.darwin-8.2.0-Power_Macintosh-2.4/tkappinit.o -framework Tcl -
framework Tk
In file included from /System/Library/Frameworks/Tk.framework/Headers/tk.h:
96,
                 from /usr/ports/Python-2.4.1/Modules/tkappinit.c:17:
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:140: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:343: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:462: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:480: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:505: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:506: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:518: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:531: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:1065: 
warning: function declaration isn't a prototype
powerpc-apple-darwin8-gcc-4.0.0: -framework: linker input file unused 
because linking not done
powerpc-apple-darwin8-gcc-4.0.0: Tcl: linker input file unused because 
linking not done
powerpc-apple-darwin8-gcc-4.0.0: -framework: linker input file unused 
because linking not done
powerpc-apple-darwin8-gcc-4.0.0: Tk: linker input file unused because 
linking not done
gcc -L/Library/Frameworks -framework Tcl -framework Tk -bundle -undefined 
dynamic_lookup -L/Library/Frameworks -framework Tcl -framework Tk -I. -I./
Include build/temp.darwin-8.2.0-Power_Macintosh-2.4/_tkinter.o build/
temp.darwin-8.2.0-Power_Macintosh-2.4/tkappinit.o -L/usr/local/lib -o build/
lib.darwin-8.2.0-Power_Macintosh-2.4/_tkinter.so -framework Tcl -framework 
Tk
running build_scripts
creating build/scripts-2.4
copying and adjusting /usr/ports/Python-2.4.1/Tools/scripts/pydoc -> build/
scripts-2.4
copying and adjusting /usr/ports/Python-2.4.1/Tools/scripts/idle -> build/
scripts-2.4
copying and adjusting /usr/ports/Python-2.4.1/Lib/smtpd.py -> build/scripts-2.4
changing mode of build/scripts-2.4/pydoc from 644 to 755
changing mode of build/scripts-2.4/idle from 644 to 755
changing mode of build/scripts-2.4/smtpd.py from 644 to 755

cheers,

richard



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

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

From noreply at sourceforge.net  Mon Jul  3 15:40:22 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 03 Jul 2006 06:40:22 -0700
Subject: [ python-Bugs-1295179 ] termios.c in qnx4.25
Message-ID: <E1FxOf0-0005xy-PV@sc8-sf-web5.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Platform-specific
>Status: Pending
Resolution: None
Priority: 5
Submitted By: kbob_ru (kbob_ru)
Assigned to: Nobody/Anonymous (nobody)
Summary: termios.c in qnx4.25

Initial Comment:
I compile python version 2.3.5 in QNX4.25.
But I found that #include <termios.h> don't work 
because in qnx4 we need to include <sys/termio.c> first 
in which #include <termios.h> already present.
Second, Module/termios.c needs flag IXANY, that not 
defined in qnx4 headers.

Include right header and write #ifdef IXANY \ #endif 
around helps to compile Module/termios.c.

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

>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-03 13:40

Message:
Logged In: YES 
user_id=849994

Can you test this with Python 2.5b1?

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

Comment By: kbob_ru (kbob_ru)
Date: 2006-06-03 05:03

Message:
Logged In: YES 
user_id=1347065

I used next patch for Python versions 2.3.5 and 2.4.3.
It helps work properly termios module in QNX4.25 and
termios test pass.


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

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

From noreply at sourceforge.net  Mon Jul  3 15:48:56 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 03 Jul 2006 06:48:56 -0700
Subject: [ python-Bugs-927248 ] Python segfaults when freeing &quot; deep&quot;
	objects
Message-ID: <E1FxOnI-0000sw-Gn@sc8-sf-web5.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 6
Submitted By: Jp Calderone (kuran)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python segfaults when freeing &quot;deep&quot; objects

Initial Comment:
An example to produce this behavior:

>>> f = lambda: None
>>> for i in range(1000000):
...     f = f.__call__
... 
>>> f = None
Segmentation fault


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

>Comment By: Martin v. L??wis (loewis)
Date: 2006-07-03 15:48

Message:
Logged In: YES 
user_id=21627

This is now fixed in r47217 and r47218, by putting the
method-wrapper objects into the trashcan.

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

Comment By: Jp Calderone (kuran)
Date: 2006-01-10 23:05

Message:
Logged In: YES 
user_id=366566

Note that in doerwalter transcript, _ is still bound to the
method wrapper, preventing Python from attempting to free it.


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

Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-10 22:54

Message:
Logged In: YES 
user_id=1188172

CVS HEAD of 2006/01/10 still segfaults (here GCC 3.4.5).

Segfault occurs at wrapper_dealloc in descrobject.c.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2004-06-02 21:25

Message:
Logged In: YES 
user_id=89016

Python CVS from 2004-06-02 seems to work:
Python 2.4a0 (#5, Jun  2 2004, 20:23:30) 
[GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-113)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
>>> f = lambda: None
>>> for x in xrange(1000000):
...  f = f.__call__
... 
>>> f
<method-wrapper object at 0x4259478c>
>>> f = None
>>> f
>>>

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

Comment By: Jacob Smullyan (smulloni)
Date: 2004-04-08 05:20

Message:
Logged In: YES 
user_id=108556

Python CVS as of April 7th consistently segfaults with the
above example for me:

smulloni at bracknell src $ ~/apps/python-cvs/bin/python
Python 2.4a0 (#1, Apr  7 2004, 23:10:34) 
[GCC 3.3.2 20031218 (Gentoo Linux 3.3.2-r5,
propolice-3.3-7)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> f=lambda: None
>>> for x in xrange(1000000):
...     f=f.__call__
... 
>>> f=None
Segmentation fault

Of course, maybe that's a good thing :).

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

Comment By: Jim Jewett (jimjjewett)
Date: 2004-04-05 02:32

Message:
Logged In: YES 
user_id=764593

CVS for 2.4 has comments for (and a fix for) problems similar 
to this.  Does the bug still exist with that source code?

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

Comment By: Hye-Shik Chang (perky)
Date: 2004-04-01 07:21

Message:
Logged In: YES 
user_id=55188

Oh. my patch doesn't fix another scenario that using
recursive by two or more types of slots. So I remove.

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

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

From noreply at sourceforge.net  Mon Jul  3 16:08:15 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 03 Jul 2006 07:08:15 -0700
Subject: [ python-Bugs-1515932 ] 2.3.6.4 Mutable Sequence Types clarification
Message-ID: <E1FxP5z-0008TK-Ee@sc8-sf-web3.sourceforge.net>

Bugs item #1515932, was opened at 2006-07-02 13:53
Message generated for change (Settings changed) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1515932&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Alan (aisaac0)
>Assigned to: A.M. Kuchling (akuchling)
Summary: 2.3.6.4 Mutable Sequence Types clarification

Initial Comment:
Documentation of Mutable Sequence Types
at http://docs.python.org/lib/typesseq-mutable.html
has the following language:

s[i:j] = t  slice of s from i to j is replaced by t  	
...
s[i:j:k] = t the elements of s[i:j:k] are replaced by
those of t 	(1)

The asymmetry is misleading (e.g., one might think that
in the first case t could be a single number that would
be assigned to all the elements, particularly since the
footnote is omitted).

Therefore I propose the first case become:

s[i:j] = t   the elements of the slice of s from i to j
are replaced by those of t 	(1)

The following alternative would be even more parallel
and also acceptable:

s[i:j] = t  the elements of s[i:j] are replaced by
those of t 	(1)

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

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-03 10:08

Message:
Logged In: YES 
user_id=11375

In rev.47219, I've replaced the first case with "slice of
\var{s} from \var{i} to \var{j} is replaced by the contents
of the iterable \var{t}".  

Thanks for your comment.


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

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

From noreply at sourceforge.net  Mon Jul  3 16:09:19 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 03 Jul 2006 07:09:19 -0700
Subject: [ python-Bugs-1513913 ] mimetools message's To field can't be changed
Message-ID: <E1FxP71-00009p-78@sc8-sf-web6.sourceforge.net>

Bugs item #1513913, was opened at 2006-06-28 06:51
Message generated for change (Settings changed) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513913&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Albert Strasheim (fullung2)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: mimetools message's To field can't be changed

Initial Comment:
Steps to reproduce:

>>> from email.MIMEText import MIMEText
>>> msg = MIMEText('')
>>> msg['To'] = 'foo at bar.com'
>>> msg['To']
'foo at bar.com'
>>> msg['To'] = 'foo at baz.com'
>>> msg['To']
'foo at bar.com' (should be @baz.com?)

Same problem exists in Python 2.4.3 and Python 2.5b1.

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

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

From noreply at sourceforge.net  Mon Jul  3 16:19:57 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 03 Jul 2006 07:19:57 -0700
Subject: [ python-Bugs-1511911 ] vague xref in description of sorted() builtin
Message-ID: <E1FxPHJ-0004mL-M9@sc8-sf-web3.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: rurpy (rurpy)
>Assigned to: A.M. Kuchling (akuchling)
Summary: vague xref in description of sorted() builtin

Initial Comment:
In section 2.1, "Builtin Functions", in the 
description of function sorted(), it says:

The optional arguments cmp, key, and reverse have the 
same meaning as those for the list.sort() method. 

For someone not already very familiar with the 
organiztion of the Library Reference, a reference to 
list.sort() is not very useful.  If one looks in the 
index one sees "List Object" and "List, operations 
on".  Although the latter link does bring one to the 
right page (2.3.6.4 "Mutable Sequence Types") it is 
not obvious to those not yet used to the loose use of 
terms in the Puython docs, that "operation" 
and "method" are synonymous.  And God help the poor 
newbie who forgets the index and tries to find the 
relevent page using the ToC.

I suggest:
1) In sec. 2.1, explicity describe sorted()'s 
arguments rather than referencing list.sort().  Cut 
and paste from list.sort.  Mention (as a helpful "see 
also") the existence of the list.sort() method with a 
link.

If that is not acceptable than, 

2a) In sec 2.1, change word "method" to "operation", or
2b) In the index under "List", add a link "methods" 
pointing to section 2.1, (i.e. same target as the 
currently existing "operations" entry under List.
And, 
3) In sec 2.1 make the text "List.sorted()" a link to
to the List.sorted() page (2.3.6.4 "Mutable Sequence 
Types")

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

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-03 10:19

Message:
Logged In: YES 
user_id=11375

Thanks for your comment!

In rev. 47220, I've copied the description of cmp, reverse,
and key, and also improved the xref to give the actual
section number.  Rev. 47222 applies the change to the 2.4
maintenance branch.


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

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

From noreply at sourceforge.net  Mon Jul  3 22:27:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 03 Jul 2006 13:27:42 -0700
Subject: [ python-Bugs-1516613 ] Decimal should allow leading or trailing
	spaces.
Message-ID: <E1FxV1C-0002YY-5x@sc8-sf-web5.sourceforge.net>

Bugs item #1516613, was opened at 2006-07-03 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=1516613&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ronaldo Francisco Maia (romaia)
Assigned to: Nobody/Anonymous (nobody)
Summary: Decimal should allow leading or trailing spaces.

Initial Comment:
When creating a Decimal from a string, leading and
trailing spaces should be allowed, as it happens with
int and float:

>>> int(' 1 ')
1
>>> Decimal(' 1 ')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.4/decimal.py", line 571, in
__new__
    self._sign, self._int, self._exp =
context._raise_error(ConversionSyntax)
  File "/usr/lib/python2.4/decimal.py", line 2267, in
_raise_error
    raise error, explanation
decimal.InvalidOperation


If we look at decimal.py, the code (regex) is already
there, but commented.

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

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

From noreply at sourceforge.net  Tue Jul  4 00:12:16 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 03 Jul 2006 15:12:16 -0700
Subject: [ python-Bugs-1516078 ] dbhash __len__ not reliable
Message-ID: <E1FxWeO-0004dg-Ij@sc8-sf-web3.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: cmorvant (chrismorvant)
Assigned to: Nobody/Anonymous (nobody)
Summary: dbhash __len__ not reliable

Initial Comment:
Python Version 2.4.3
OS Windows XP

When I open a db file in read only mode('r') 
the 'len' method will only work once.  After this it 
will return only 0.  Using anydbm on my windows box 
defaults to dbhash(bsddb).  This only occurs with 
dbhash(dumbdbm and dbm on Unix work fine).  The 
output of the sample code is "2 0 dbhash".

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

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-03 18:12

Message:
Logged In: YES 
user_id=11375

Can you please provide a small test script that demonstrates
the problem?  When I try opening a dbhash database and
calling len(), it returns the correct results.



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

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

From noreply at sourceforge.net  Tue Jul  4 01:08:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 03 Jul 2006 16:08:23 -0700
Subject: [ python-Bugs-1512695 ] cPickle.loads() seg.faults when interrupted
	with keyboard
Message-ID: <E1FxXWg-0004GV-WE@sc8-sf-web2.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 2.5
Status: Closed
Resolution: Fixed
Priority: 7
Submitted By: Faik Uygur (faik)
Assigned to: Neal Norwitz (nnorwitz)
Summary: cPickle.loads() seg.faults when interrupted with keyboard

Initial Comment:
cPickle.loads() gives segmentation fault when 
interrupted with keyboard (CTRL+C). Attached python 
script tested with python version 2.4.3 and 2.5b1.


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

Comment By: Rene Dudfield (illume)
Date: 2006-07-03 23:08

Message:
Logged In: YES 
user_id=2042

Hello.

Relating to this bug, I think asserting not NULL in
Py_INCREF would have caught it.

Something like this?

// OLD.
#define Py_INCREF(op) (				\
	_Py_INC_REFTOTAL  _Py_REF_DEBUG_COMMA	\
	(op)->ob_refcnt++)

// NEW.
#define Py_INCREF(op) (				\
	assert((op) != NULL)	\
	_Py_INC_REFTOTAL  _Py_REF_DEBUG_COMMA	\
	(op)->ob_refcnt++)



Cheers.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-06-30 01:19

Message:
Logged In: YES 
user_id=33168

Rene can you produce a patch to address any places you
believe there are problems?  If you can't produce a patch,
at least a bug report with specific areas that are problems
would be helpful.  Thanks.

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

Comment By: Rene Dudfield (illume)
Date: 2006-06-30 00:59

Message:
Logged In: YES 
user_id=2042

Py_INCREF should check for NULL with an assert.

All uses of va_arg should be checked to see if they return
NULL... and handle error codes!

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-06-28 06:39

Message:
Logged In: YES 
user_id=33168

I'm impatient and think this fixes the problem.  So I'm
closing this report.  Please re-open if the patch didn't fix
your problem.  (I checked in something slightly different
that the patch attached.)

Committed revision 47139.
Committed revision 47140. (2.4)

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-06-28 06:09

Message:
Logged In: YES 
user_id=33168

Faik, can you see if the attached patch fixes this problem.
 I believe it should.  I can't reproduce the problem with
the patch.

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

Comment By: Faik Uygur (faik)
Date: 2006-06-27 08:12

Message:
Logged In: YES 
user_id=1541018

Back trace:

#0  PyTuple_Pack (n=0x3) at Objects/tupleobject.c:149
#1  0xa7b92024 in Instance_New (cls=0xa7bba064, 
args=0xa7c1a43c) 
at /var/tmp/pisi/python-2.4.3-14/work/Python-2.4.3/Modules/cPickle.c:3637
#2  0xa7b93798 in load (self=0xa7c0a80c) 
at /var/tmp/pisi/python-2.4.3-14/work/Python-2.4.3/Modules/cPickle.c:4389
#3  0xa7b953c8 in cpm_loads (self=0x0, args=0x0) 
at /var/tmp/pisi/python-2.4.3-14/work/Python-2.4.3/Modules/cPickle.c:5481
#4  0xa7ec4d97 in PyCFunction_Call (func=0xa7bc9b0c, 
arg=0xa7bc9cec, kw=0x0) at Objects/methodobject.c:108
#5  0xa7efe3d8 in PyEval_EvalFrame (f=0x807e4bc) at 
Python/ceval.c:3563
#6  0xa7f00bb3 in PyEval_EvalCodeEx (co=0xa7bbda60, 
globals=0x0, locals=0x0, args=0xa7bbda60, argcount=0x0, 
kws=0x0, kwcount=0x0, defs=0x0, defcount=0x0, 
closure=0x0) at Python/ceval.c:2736
#7  0xa7f00e35 in PyEval_EvalCode (co=0x0, globals=0x0, 
locals=0x0) at Python/ceval.c:484
#8  0xa7f1ba98 in run_node (n=0xa7bfbe18, filename=0x0, 
globals=0x0, locals=0x0, flags=0x0) at 
Python/pythonrun.c:1265
#9  0xa7f1ce28 in PyRun_SimpleFileExFlags (fp=0x804a008, 
filename=0xaf9ab3b9 "picklefault.py", closeit=0x1, 
flags=0xaf9aafe8) at Python/pythonrun.c:860
#10 0xa7f1d9aa in PyRun_AnyFileExFlags (fp=0x804a008, 
filename=0xaf9ab3b9 "picklefault.py", closeit=0x1, 
flags=0xaf9aafe8) at Python/pythonrun.c:664
#11 0xa7f238d0 in Py_Main (argc=0x1, argv=0xaf9aafe8) at 
Modules/main.c:493
#12 0x0804867a in main (argc=0x0, argv=0x0) at 
Modules/python.c:23


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

Comment By: Faik Uygur (faik)
Date: 2006-06-26 14:08

Message:
Logged In: YES 
user_id=1541018

I tracked the seg. fault. It seg. faults in method 
PyTuple_Pack(). When python receives the keyboard 
interrupt:
                o = va_arg(vargs, PyObject *);
                Py_INCREF(o);

va_arg returns NULL, and Py_INCREF causes the seg.fault.


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

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

From noreply at sourceforge.net  Tue Jul  4 01:46:47 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 03 Jul 2006 16:46:47 -0700
Subject: [ python-Bugs-1512695 ] cPickle.loads() seg.faults when interrupted
	with keyboard
Message-ID: <E1FxY7r-0002nv-VM@sc8-sf-web1.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 2.5
Status: Closed
Resolution: Fixed
Priority: 7
Submitted By: Faik Uygur (faik)
Assigned to: Neal Norwitz (nnorwitz)
Summary: cPickle.loads() seg.faults when interrupted with keyboard

Initial Comment:
cPickle.loads() gives segmentation fault when 
interrupted with keyboard (CTRL+C). Attached python 
script tested with python version 2.4.3 and 2.5b1.


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

Comment By: Rene Dudfield (illume)
Date: 2006-07-03 23:46

Message:
Logged In: YES 
user_id=2042

Sorry... the last post was wrong.

This is the working one:

#define Py_INCREF(op) (			        \
        (assert((op) != NULL)) ,  	        \
        _Py_INC_REFTOTAL  _Py_REF_DEBUG_COMMA	\
        (op)->ob_refcnt++)                      


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

Comment By: Rene Dudfield (illume)
Date: 2006-07-03 23:08

Message:
Logged In: YES 
user_id=2042

Hello.

Relating to this bug, I think asserting not NULL in
Py_INCREF would have caught it.

Something like this?

// OLD.
#define Py_INCREF(op) (				\
	_Py_INC_REFTOTAL  _Py_REF_DEBUG_COMMA	\
	(op)->ob_refcnt++)

// NEW.
#define Py_INCREF(op) (				\
	assert((op) != NULL)	\
	_Py_INC_REFTOTAL  _Py_REF_DEBUG_COMMA	\
	(op)->ob_refcnt++)



Cheers.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-06-30 01:19

Message:
Logged In: YES 
user_id=33168

Rene can you produce a patch to address any places you
believe there are problems?  If you can't produce a patch,
at least a bug report with specific areas that are problems
would be helpful.  Thanks.

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

Comment By: Rene Dudfield (illume)
Date: 2006-06-30 00:59

Message:
Logged In: YES 
user_id=2042

Py_INCREF should check for NULL with an assert.

All uses of va_arg should be checked to see if they return
NULL... and handle error codes!

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-06-28 06:39

Message:
Logged In: YES 
user_id=33168

I'm impatient and think this fixes the problem.  So I'm
closing this report.  Please re-open if the patch didn't fix
your problem.  (I checked in something slightly different
that the patch attached.)

Committed revision 47139.
Committed revision 47140. (2.4)

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-06-28 06:09

Message:
Logged In: YES 
user_id=33168

Faik, can you see if the attached patch fixes this problem.
 I believe it should.  I can't reproduce the problem with
the patch.

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

Comment By: Faik Uygur (faik)
Date: 2006-06-27 08:12

Message:
Logged In: YES 
user_id=1541018

Back trace:

#0  PyTuple_Pack (n=0x3) at Objects/tupleobject.c:149
#1  0xa7b92024 in Instance_New (cls=0xa7bba064, 
args=0xa7c1a43c) 
at /var/tmp/pisi/python-2.4.3-14/work/Python-2.4.3/Modules/cPickle.c:3637
#2  0xa7b93798 in load (self=0xa7c0a80c) 
at /var/tmp/pisi/python-2.4.3-14/work/Python-2.4.3/Modules/cPickle.c:4389
#3  0xa7b953c8 in cpm_loads (self=0x0, args=0x0) 
at /var/tmp/pisi/python-2.4.3-14/work/Python-2.4.3/Modules/cPickle.c:5481
#4  0xa7ec4d97 in PyCFunction_Call (func=0xa7bc9b0c, 
arg=0xa7bc9cec, kw=0x0) at Objects/methodobject.c:108
#5  0xa7efe3d8 in PyEval_EvalFrame (f=0x807e4bc) at 
Python/ceval.c:3563
#6  0xa7f00bb3 in PyEval_EvalCodeEx (co=0xa7bbda60, 
globals=0x0, locals=0x0, args=0xa7bbda60, argcount=0x0, 
kws=0x0, kwcount=0x0, defs=0x0, defcount=0x0, 
closure=0x0) at Python/ceval.c:2736
#7  0xa7f00e35 in PyEval_EvalCode (co=0x0, globals=0x0, 
locals=0x0) at Python/ceval.c:484
#8  0xa7f1ba98 in run_node (n=0xa7bfbe18, filename=0x0, 
globals=0x0, locals=0x0, flags=0x0) at 
Python/pythonrun.c:1265
#9  0xa7f1ce28 in PyRun_SimpleFileExFlags (fp=0x804a008, 
filename=0xaf9ab3b9 "picklefault.py", closeit=0x1, 
flags=0xaf9aafe8) at Python/pythonrun.c:860
#10 0xa7f1d9aa in PyRun_AnyFileExFlags (fp=0x804a008, 
filename=0xaf9ab3b9 "picklefault.py", closeit=0x1, 
flags=0xaf9aafe8) at Python/pythonrun.c:664
#11 0xa7f238d0 in Py_Main (argc=0x1, argv=0xaf9aafe8) at 
Modules/main.c:493
#12 0x0804867a in main (argc=0x0, argv=0x0) at 
Modules/python.c:23


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

Comment By: Faik Uygur (faik)
Date: 2006-06-26 14:08

Message:
Logged In: YES 
user_id=1541018

I tracked the seg. fault. It seg. faults in method 
PyTuple_Pack(). When python receives the keyboard 
interrupt:
                o = va_arg(vargs, PyObject *);
                Py_INCREF(o);

va_arg returns NULL, and Py_INCREF causes the seg.fault.


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

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

From noreply at sourceforge.net  Tue Jul  4 13:08:19 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 04 Jul 2006 04:08:19 -0700
Subject: [ python-Bugs-1516910 ] warnings.py still refers to OverflowWarning
Message-ID: <E1FxilP-0000GB-89@sc8-sf-web3.sourceforge.net>

Bugs item #1516910, was opened at 2006-07-04 21: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=1516910&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: John Machin (sjmachin)
Assigned to: Nobody/Anonymous (nobody)
Summary: warnings.py still refers to OverflowWarning

Initial Comment:
C:\devel\lfo_kit>c:\python25\python setup_mp.py install
Traceback (most recent call last):
  File "setup_mp.py", line 4, in <module>
    from distutils.core import setup, Extension
  File "c:\python25\lib\distutils\core.py", line 21, in
<module>
    from distutils.dist import Distribution
  File "c:\python25\lib\distutils\dist.py", line 16, in
<module>
    import warnings
  File "C:\python25\lib\warnings.py", line 265, in <module>
    simplefilter("ignore", category=OverflowWarning,
append=1)
NameError: name 'OverflowWarning' is not defined

C:\devel\lfo_kit>c:\python25\python
Python 2.5b1 (r25b1:47027, Jun 20 2006, 09:31:33) [MSC
v.1310 32 bit (Intel)] on win32

=====

I noted that on the line above, there's a comment
saying this should be removed for 2.5. I have commented
out the offending line in my local copy and now my
distutils stuff appears to be working.



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

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

From noreply at sourceforge.net  Tue Jul  4 16:34:45 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 04 Jul 2006 07:34:45 -0700
Subject: [ python-Bugs-1516995 ] test_logging fails with reference
	count-checking
Message-ID: <E1FxlzB-0008Je-C9@sc8-sf-web3.sourceforge.net>

Bugs item #1516995, was opened at 2006-07-04 10:34
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=1516995&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Collin Winter (collinwinter)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_logging fails with reference count-checking

Initial Comment:
When running from the following, test_logging fails:
./python Lib/test/regrtest.py -R :: test_logging.

Here's the traceback:

test test_logging crashed -- <type
'exceptions.KeyError'>: <logging.StreamHandler instance
at 0xb7aaebcc>
Traceback (most recent call last):
  File "Lib/test/regrtest.py", line 554, in runtest_inner
    dash_R(the_module, test, indirect_test, huntrleaks)
  File "Lib/test/regrtest.py", line 673, in dash_R
    run_the_test()
  File "Lib/test/regrtest.py", line 660, in run_the_test
    indirect_test()
  File
"/home/collin/src/python/Lib/test/test_support.py",
line 299, in inner
    return func(*args, **kwds)
  File
"/home/collin/src/python/Lib/test/test_logging.py",
line 677, in test_main
    test_main_inner()
  File
"/home/collin/src/python/Lib/test/test_logging.py",
line 640, in test_main_inner
    globals()['test%d' % t]()
  File
"/home/collin/src/python/Lib/test/test_logging.py",
line 347, in test2
    sh.close()
  File
"/home/collin/src/python/Lib/logging/__init__.py", line
687, in close
    del _handlers[self]
KeyError: <logging.StreamHandler instance at 0xb7aaebcc>




This problem does not occur when run without reference
count-checking.

System info:
Python SVN r47224
Linux 2.6.13
x86

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

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

From noreply at sourceforge.net  Tue Jul  4 16:35:03 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 04 Jul 2006 07:35:03 -0700
Subject: [ python-Bugs-1516995 ] test_logging fails with reference
	count-checking enabled
Message-ID: <E1FxlzT-0008R8-7f@sc8-sf-web3.sourceforge.net>

Bugs item #1516995, was opened at 2006-07-04 10:34
Message generated for change (Settings changed) made by collinwinter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1516995&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Collin Winter (collinwinter)
Assigned to: Nobody/Anonymous (nobody)
>Summary: test_logging fails with reference count-checking enabled

Initial Comment:
When running from the following, test_logging fails:
./python Lib/test/regrtest.py -R :: test_logging.

Here's the traceback:

test test_logging crashed -- <type
'exceptions.KeyError'>: <logging.StreamHandler instance
at 0xb7aaebcc>
Traceback (most recent call last):
  File "Lib/test/regrtest.py", line 554, in runtest_inner
    dash_R(the_module, test, indirect_test, huntrleaks)
  File "Lib/test/regrtest.py", line 673, in dash_R
    run_the_test()
  File "Lib/test/regrtest.py", line 660, in run_the_test
    indirect_test()
  File
"/home/collin/src/python/Lib/test/test_support.py",
line 299, in inner
    return func(*args, **kwds)
  File
"/home/collin/src/python/Lib/test/test_logging.py",
line 677, in test_main
    test_main_inner()
  File
"/home/collin/src/python/Lib/test/test_logging.py",
line 640, in test_main_inner
    globals()['test%d' % t]()
  File
"/home/collin/src/python/Lib/test/test_logging.py",
line 347, in test2
    sh.close()
  File
"/home/collin/src/python/Lib/logging/__init__.py", line
687, in close
    del _handlers[self]
KeyError: <logging.StreamHandler instance at 0xb7aaebcc>




This problem does not occur when run without reference
count-checking.

System info:
Python SVN r47224
Linux 2.6.13
x86

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

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

From noreply at sourceforge.net  Wed Jul  5 03:53:36 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 04 Jul 2006 18:53:36 -0700
Subject: [ python-Bugs-1516184 ] inspect.py: still infinite recursion
	inspecting frames
Message-ID: <E1Fxwa8-00062q-Le@sc8-sf-web1.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Don Quijote (dq_searchlores)
>Assigned to: Phillip J. Eby (pje)
Summary: inspect.py: still infinite recursion inspecting frames

Initial Comment:
Using python 2.5 beta 1 on Windows XP, and py2exe 0.6.5.

After packing and compressing a project via py2exe,
there's still an infinite recursion involving functions
getsourcefile, getmodule and getabsfile in module
inspect.py.

I was able to fix this infinite recursion by

1) changing the declaration of getabsfile & getmodule to:
def getabsfile(object, filename=None):
def getmodule(object, filename=None):

2) including the "filename" parameter in all calls to
getabsfile inside of function getmodule.

3) having getabsfile return the absolute and normalized
filename if not null.

Perhaps this change helps to clean up the 'ugliness'
introduced in version 45822.

Kind regards,
Don Quijote 

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-04 18:53

Message:
Logged In: YES 
user_id=33168

Phillip any comments?

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

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

From noreply at sourceforge.net  Wed Jul  5 06:02:45 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 04 Jul 2006 21:02:45 -0700
Subject: [ python-Bugs-1487105 ] 2.5 rev 45972 fails build on Mac-Intel
Message-ID: <E1Fxyb7-0000Nr-9G@sc8-sf-web6.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Alex Martelli (aleax)
Assigned to: Alex Martelli (aleax)
Summary: 2.5 rev 45972 fails build on Mac-Intel

Initial Comment:
brain:~/py25 alex$ make
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes   Parser/acceler.o 
Parser/grammar1.o Parser/listnode.o Parser/node.o Parser/parser.o 
Parser/parsetok.o Parser/bitset.o Parser/metagrammar.o Parser/
firstsets.o Parser/grammar.o Parser/pgen.o Objects/obmalloc.o Python/
mysnprintf.o Parser/tokenizer_pgen.o Parser/printgrammar.o Parser/
pgenmain.o -ldl  -o Parser/pgen
/usr/bin/ld: warning Parser/printgrammar.o cputype (18, architecture 
ppc) does not match cputype (7) for specified -arch flag: i386 (file not 
loaded)
/usr/bin/ld: Undefined symbols:
__Py_printgrammar
__Py_printnonterminals
collect2: ld returned 1 exit status
make: *** [Parser/pgen] Error 1
brain:~/py25 alex$ 

This is a MacBook Pro with gcc version 4.0.1 (Apple Computer, Inc. build 
5250) -- not sure why there's an "architecture ppc" found somewhere, 
haven't looked at it in detail yet, but at any rate this breaks the make.


Alex


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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-04 21:02

Message:
Logged In: YES 
user_id=33168

Alex reported in mail that everything works as of 2.5b1.

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-07-03 05:04

Message:
Logged In: YES 
user_id=21627

Lowering the priority - the problem apparently isn't all
that pressing anymore.

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

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-23 05:12

Message:
Logged In: YES 
user_id=580910

Never mind, wrong bug. I would like to hear if the trunk works for you though.

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

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-23 04:47

Message:
Logged In: YES 
user_id=580910

I've checked in a fix in revision 46103. Could you please test if this solves the 
problems for you?


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

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-19 03:38

Message:
Logged In: YES 
user_id=580910

It seems to work for me (current trunk). Feel free to assign this to me if it 
doesn't work for you.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-14 23:23

Message:
Logged In: YES 
user_id=33168

Alex, can you try with a current checkout?  It looks like
Ronald checked in fixes for x86 at 45997.

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

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

From noreply at sourceforge.net  Wed Jul  5 09:22:18 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 05 Jul 2006 00:22:18 -0700
Subject: [ python-Bugs-1517370 ] Getting an error message import site failed
	-v traceback.
Message-ID: <E1Fy1iE-0002CW-LE@sc8-sf-web5.sourceforge.net>

Bugs item #1517370, was opened at 2006-07-05 07: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=1517370&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: brijesh kumar (brijesh_04)
Assigned to: Nobody/Anonymous (nobody)
Summary: Getting an error message import site failed -v traceback.

Initial Comment:
we have not installed python on the machine and trying 
to use python24.dll in c++ code(by including header 
python.h).

At the time of py_initialize() we get an error import 
site failed -v traceback. But if python is installed 
on the machine no such error comes.

But we don't want to Install Python on my M/C.
Please tell us how to get rid of this error in our 
scenerio.



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

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

From noreply at sourceforge.net  Wed Jul  5 09:24:50 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 05 Jul 2006 00:24:50 -0700
Subject: [ python-Bugs-1517370 ] Getting an error message import site failed
	-v traceback.
Message-ID: <E1Fy1kg-0000wa-Hx@sc8-sf-web1.sourceforge.net>

Bugs item #1517370, was opened at 2006-07-05 07:22
Message generated for change (Settings changed) made by brijesh_04
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517370&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
>Priority: 9
Submitted By: brijesh kumar (brijesh_04)
Assigned to: Nobody/Anonymous (nobody)
Summary: Getting an error message import site failed -v traceback.

Initial Comment:
we have not installed python on the machine and trying 
to use python24.dll in c++ code(by including header 
python.h).

At the time of py_initialize() we get an error import 
site failed -v traceback. But if python is installed 
on the machine no such error comes.

But we don't want to Install Python on my M/C.
Please tell us how to get rid of this error in our 
scenerio.



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

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

From noreply at sourceforge.net  Wed Jul  5 10:05:54 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 05 Jul 2006 01:05:54 -0700
Subject: [ python-Bugs-1517370 ] Getting an error message import site failed
	-v traceback.
Message-ID: <E1Fy2OQ-0004Lu-Uf@sc8-sf-web5.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
>Priority: 5
Submitted By: brijesh kumar (brijesh_04)
Assigned to: Nobody/Anonymous (nobody)
Summary: Getting an error message import site failed -v traceback.

Initial Comment:
we have not installed python on the machine and trying 
to use python24.dll in c++ code(by including header 
python.h).

At the time of py_initialize() we get an error import 
site failed -v traceback. But if python is installed 
on the machine no such error comes.

But we don't want to Install Python on my M/C.
Please tell us how to get rid of this error in our 
scenerio.



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

>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-05 08:05

Message:
Logged In: YES 
user_id=849994

You'll have to set Py_NoSiteFlag prior to calling
Py_Initialize(). See Python/main.c which does this while
parsing command line args.

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

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

From noreply at sourceforge.net  Wed Jul  5 10:22:29 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 05 Jul 2006 01:22:29 -0700
Subject: [ python-Bugs-1516910 ] warnings.py still refers to OverflowWarning
Message-ID: <E1Fy2eT-00076i-Nk@sc8-sf-web2.sourceforge.net>

Bugs item #1516910, was opened at 2006-07-04 11:08
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1516910&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: John Machin (sjmachin)
Assigned to: Nobody/Anonymous (nobody)
Summary: warnings.py still refers to OverflowWarning

Initial Comment:
C:\devel\lfo_kit>c:\python25\python setup_mp.py install
Traceback (most recent call last):
  File "setup_mp.py", line 4, in <module>
    from distutils.core import setup, Extension
  File "c:\python25\lib\distutils\core.py", line 21, in
<module>
    from distutils.dist import Distribution
  File "c:\python25\lib\distutils\dist.py", line 16, in
<module>
    import warnings
  File "C:\python25\lib\warnings.py", line 265, in <module>
    simplefilter("ignore", category=OverflowWarning,
append=1)
NameError: name 'OverflowWarning' is not defined

C:\devel\lfo_kit>c:\python25\python
Python 2.5b1 (r25b1:47027, Jun 20 2006, 09:31:33) [MSC
v.1310 32 bit (Intel)] on win32

=====

I noted that on the line above, there's a comment
saying this should be removed for 2.5. I have commented
out the offending line in my local copy and now my
distutils stuff appears to be working.



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

>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-05 08:22

Message:
Logged In: YES 
user_id=849994

There must be a problem on your end. In the current
warnings.py there's no reference to OverflowWarning anymore.

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

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

From noreply at sourceforge.net  Wed Jul  5 10:30:33 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 05 Jul 2006 01:30:33 -0700
Subject: [ python-Bugs-1517370 ] Getting an error message import site failed
	-v traceback.
Message-ID: <E1Fy2mH-0004lW-Ef@sc8-sf-web1.sourceforge.net>

Bugs item #1517370, was opened at 2006-07-05 07:22
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517370&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
>Status: Pending
Resolution: None
Priority: 5
Submitted By: brijesh kumar (brijesh_04)
Assigned to: Nobody/Anonymous (nobody)
Summary: Getting an error message import site failed -v traceback.

Initial Comment:
we have not installed python on the machine and trying 
to use python24.dll in c++ code(by including header 
python.h).

At the time of py_initialize() we get an error import 
site failed -v traceback. But if python is installed 
on the machine no such error comes.

But we don't want to Install Python on my M/C.
Please tell us how to get rid of this error in our 
scenerio.



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

Comment By: Georg Brandl (gbrandl)
Date: 2006-07-05 08:05

Message:
Logged In: YES 
user_id=849994

You'll have to set Py_NoSiteFlag prior to calling
Py_Initialize(). See Python/main.c which does this while
parsing command line args.

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

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

From noreply at sourceforge.net  Wed Jul  5 12:09:07 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 05 Jul 2006 03:09:07 -0700
Subject: [ python-Bugs-1516910 ] warnings.py still refers to OverflowWarning
Message-ID: <E1Fy4Jf-0004Ue-Ot@sc8-sf-web1.sourceforge.net>

Bugs item #1516910, was opened at 2006-07-04 21:08
Message generated for change (Comment added) made by sjmachin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1516910&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Closed
Resolution: Works For Me
Priority: 5
Submitted By: John Machin (sjmachin)
Assigned to: Nobody/Anonymous (nobody)
Summary: warnings.py still refers to OverflowWarning

Initial Comment:
C:\devel\lfo_kit>c:\python25\python setup_mp.py install
Traceback (most recent call last):
  File "setup_mp.py", line 4, in <module>
    from distutils.core import setup, Extension
  File "c:\python25\lib\distutils\core.py", line 21, in
<module>
    from distutils.dist import Distribution
  File "c:\python25\lib\distutils\dist.py", line 16, in
<module>
    import warnings
  File "C:\python25\lib\warnings.py", line 265, in <module>
    simplefilter("ignore", category=OverflowWarning,
append=1)
NameError: name 'OverflowWarning' is not defined

C:\devel\lfo_kit>c:\python25\python
Python 2.5b1 (r25b1:47027, Jun 20 2006, 09:31:33) [MSC
v.1310 32 bit (Intel)] on win32

=====

I noted that on the line above, there's a comment
saying this should be removed for 2.5. I have commented
out the offending line in my local copy and now my
distutils stuff appears to be working.



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

>Comment By: John Machin (sjmachin)
Date: 2006-07-05 20:09

Message:
Logged In: YES 
user_id=480138

Yes, was local problem caused by jumbled install of 2.5b1
over the top of 2.5a2 -- am taking that issue up with MvL.
Sorry for the nuisance, Georg.

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

Comment By: Georg Brandl (gbrandl)
Date: 2006-07-05 18:22

Message:
Logged In: YES 
user_id=849994

There must be a problem on your end. In the current
warnings.py there's no reference to OverflowWarning anymore.

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

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

From noreply at sourceforge.net  Wed Jul  5 14:47:35 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 05 Jul 2006 05:47:35 -0700
Subject: [ python-Bugs-1517495 ] memory leak threading or socketserver module
Message-ID: <E1Fy6n1-00028q-86@sc8-sf-web3.sourceforge.net>

Bugs item #1517495, was opened at 2006-07-05 14: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=1517495&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ids van der Molen (idsvandermolen)
Assigned to: Nobody/Anonymous (nobody)
Summary: memory leak threading or socketserver module

Initial Comment:
a long running threaded server is not releasing memory,
but will keep lots of it for appearantly no reason,
causing memory exhaustion. This problem occurs with
python 2.4.2 (Suse 10.1 version) and 2.4.3 (customer
compiled on RedHat 8.0 and Suse 10.0). The problem does
_not_ occur with python 2.2.1 (RedHat 8.0 version).

The problem can be reproduced by running multiple
concurrent clients sending lots of data (25M)to a
threaded server. It looks like the garbage collector
does not always release memory used in threads, because
the ForkinMixIn and normal variants of the TCPServer do
not  show this problem (but it may be masked because of
seperate process memory space issues).
Testing:
To reproduce the probme run server code and create
multiple client connections by running multiple
instances of the client code, using the test run shell
script. The server will peak at about 550M, and remain
at lower but with every test run increasing amount of
memory (and therefore eventually using all available
memory).

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

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

From noreply at sourceforge.net  Wed Jul  5 15:09:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 05 Jul 2006 06:09:25 -0700
Subject: [ python-Bugs-1517509 ] filter() implementation does not match docs
Message-ID: <E1Fy789-0002SJ-QH@sc8-sf-web2.sourceforge.net>

Bugs item #1517509, was opened at 2006-07-05 09: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=1517509&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Collin Winter (collinwinter)
Assigned to: Nobody/Anonymous (nobody)
Summary: filter() implementation does not match docs

Initial Comment:
The docs for the built-in function filter() claim that
"filter(function, list) is equivalent to [item for item
in list if function(item)] if function is not None and
[item for item in list if item] if function is None".

>>> class infinite_str(str):
...     def __getitem__(self, index):
...         return "a"
...
>>> filter(None, infinite_str("1234"))
'aaaa'


Now, if we translate this to a listcomp according to
the docs:

>>> [x for x in infinite_str("1234") if x]

The listcomp version proceeds to chew up memory until
it exhausts the system resources or is killed by the user.

If the docs are to be believed, the filter() version
should do the same thing. 

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

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

From noreply at sourceforge.net  Wed Jul  5 16:58:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 05 Jul 2006 07:58:42 -0700
Subject: [ python-Bugs-1517509 ] filter() implementation does not match docs
Message-ID: <E1Fy8pu-0003d5-Je@sc8-sf-web6.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Collin Winter (collinwinter)
Assigned to: Nobody/Anonymous (nobody)
Summary: filter() implementation does not match docs

Initial Comment:
The docs for the built-in function filter() claim that
"filter(function, list) is equivalent to [item for item
in list if function(item)] if function is not None and
[item for item in list if item] if function is None".

>>> class infinite_str(str):
...     def __getitem__(self, index):
...         return "a"
...
>>> filter(None, infinite_str("1234"))
'aaaa'


Now, if we translate this to a listcomp according to
the docs:

>>> [x for x in infinite_str("1234") if x]

The listcomp version proceeds to chew up memory until
it exhausts the system resources or is killed by the user.

If the docs are to be believed, the filter() version
should do the same thing. 

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2006-07-05 09:58

Message:
Logged In: YES 
user_id=80475

Please take a larger view when reviewing the docs. 
The listcomp analogy is very helpful in explaining what 
filter() does and readers would not benefit by its removal.

Throughtout the docs, the phrase "is equivalent to" does 
not mean "is identical to" or "exactly the same as".   In 
this case, you have isolated a non-guaranteed 
implementation detail that is almost always irrelevant.  
When an object such as infinite_str lies about its length, 
the consequent behavior is undefined.  It is not hard to 
produce weird results when objects violate basic 
invariants such as len(istr)!=len(list(istr)) or the 
expected relation between __eq__ and __hash__.

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

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

From noreply at sourceforge.net  Wed Jul  5 19:33:58 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 05 Jul 2006 10:33:58 -0700
Subject: [ python-Bugs-1517663 ] Interpreter crash: filter() +
	gc.get_referrers()
Message-ID: <E1FyBGA-0007b9-B4@sc8-sf-web6.sourceforge.net>

Bugs item #1517663, was opened at 2006-07-05 13: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=1517663&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Collin Winter (collinwinter)
Assigned to: Nobody/Anonymous (nobody)
Summary: Interpreter crash: filter() + gc.get_referrers()

Initial Comment:
Similar to the bug in tuple() shown in the current
(r47245) version of Lib/test/crashers/gc_inspection.py,
filter() can be exploited in similar ways.

Rather than the tricky generator used to exploit
tuple(), the attached test case uses a subclass of
tuple with a malicious __getitem__ method. The pattern
being exploited is the same, however: a built-in
function pre-allocates a tuple, then fills it using
calls to user-defined code.

gc_inspection.py.diff also expands the infrastructure
in gc_inspection.py, allowing multiple test functions
to run that could crash the interpreter.

The second patch, fix_filter_crash.patch, is against
Python/bltinmodule.c and adds
_PyObject_GC_TRACK/UNTRACK macros around the call to
the type's sq_item slot in filtertuple().

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

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

From noreply at sourceforge.net  Wed Jul  5 19:34:40 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 05 Jul 2006 10:34:40 -0700
Subject: [ python-Bugs-1517663 ] Interpreter crash: filter() +
	gc.get_referrers()
Message-ID: <E1FyBGq-0000HE-Q5@sc8-sf-web6.sourceforge.net>

Bugs item #1517663, was opened at 2006-07-05 13:33
Message generated for change (Settings changed) made by collinwinter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517663&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
>Priority: 7
Submitted By: Collin Winter (collinwinter)
Assigned to: Nobody/Anonymous (nobody)
Summary: Interpreter crash: filter() + gc.get_referrers()

Initial Comment:
Similar to the bug in tuple() shown in the current
(r47245) version of Lib/test/crashers/gc_inspection.py,
filter() can be exploited in similar ways.

Rather than the tricky generator used to exploit
tuple(), the attached test case uses a subclass of
tuple with a malicious __getitem__ method. The pattern
being exploited is the same, however: a built-in
function pre-allocates a tuple, then fills it using
calls to user-defined code.

gc_inspection.py.diff also expands the infrastructure
in gc_inspection.py, allowing multiple test functions
to run that could crash the interpreter.

The second patch, fix_filter_crash.patch, is against
Python/bltinmodule.c and adds
_PyObject_GC_TRACK/UNTRACK macros around the call to
the type's sq_item slot in filtertuple().

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

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

From noreply at sourceforge.net  Wed Jul  5 19:54:26 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 05 Jul 2006 10:54:26 -0700
Subject: [ python-Bugs-1517663 ] Interpreter crash: filter() +
	gc.get_referrers()
Message-ID: <E1FyBZy-0007aT-8u@sc8-sf-web6.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 7
Submitted By: Collin Winter (collinwinter)
Assigned to: Nobody/Anonymous (nobody)
Summary: Interpreter crash: filter() + gc.get_referrers()

Initial Comment:
Similar to the bug in tuple() shown in the current
(r47245) version of Lib/test/crashers/gc_inspection.py,
filter() can be exploited in similar ways.

Rather than the tricky generator used to exploit
tuple(), the attached test case uses a subclass of
tuple with a malicious __getitem__ method. The pattern
being exploited is the same, however: a built-in
function pre-allocates a tuple, then fills it using
calls to user-defined code.

gc_inspection.py.diff also expands the infrastructure
in gc_inspection.py, allowing multiple test functions
to run that could crash the interpreter.

The second patch, fix_filter_crash.patch, is against
Python/bltinmodule.c and adds
_PyObject_GC_TRACK/UNTRACK macros around the call to
the type's sq_item slot in filtertuple().

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

>Comment By: Collin Winter (collinwinter)
Date: 2006-07-05 13:54

Message:
Logged In: YES 
user_id=1344176

An alternative fix for this would be not to invoke
filter{tuple,string,unicode} on instances of subclasses of
tuple, str and unicode.

This would fix this bug because you have to be using a
subclass of one of these types to exploit the preallocation.

As a side-effect, this would also resolve the issue I raised
in bug #1517509 concerning filter()'s treatment of these
subtypes re: the iterator protocol.

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

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

From noreply at sourceforge.net  Wed Jul  5 20:01:53 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 05 Jul 2006 11:01:53 -0700
Subject: [ python-Bugs-1517663 ] Interpreter crash: filter() +
	gc.get_referrers()
Message-ID: <E1FyBhB-0003BG-UI@sc8-sf-web5.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
>Priority: 3
Submitted By: Collin Winter (collinwinter)
Assigned to: Nobody/Anonymous (nobody)
Summary: Interpreter crash: filter() + gc.get_referrers()

Initial Comment:
Similar to the bug in tuple() shown in the current
(r47245) version of Lib/test/crashers/gc_inspection.py,
filter() can be exploited in similar ways.

Rather than the tricky generator used to exploit
tuple(), the attached test case uses a subclass of
tuple with a malicious __getitem__ method. The pattern
being exploited is the same, however: a built-in
function pre-allocates a tuple, then fills it using
calls to user-defined code.

gc_inspection.py.diff also expands the infrastructure
in gc_inspection.py, allowing multiple test functions
to run that could crash the interpreter.

The second patch, fix_filter_crash.patch, is against
Python/bltinmodule.c and adds
_PyObject_GC_TRACK/UNTRACK macros around the call to
the type's sq_item slot in filtertuple().

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2006-07-05 13:01

Message:
Logged In: YES 
user_id=80475

FWIW, I think these safe-cracking style efforts at 
creating crashers is a waste of time.  Please focus your 
efforts on fixing real bugs that matter, not in creating 
strange self-referential twists designed to poke holes in 
specific implementation details.  There is no end to the 
kind of things like this that can be found and "fixing" 
them involves either making the code more convoluted or 
making the code slower but it won't make life better for 
most users.  Also, I'm concerned that these "fixes" would 
need to be reviewed with extreme care, lest we introduce 
some new, real bug that DOES impact people's lives.  If 
there were a real problem with filter(), we would have 
known it long ago.

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

Comment By: Collin Winter (collinwinter)
Date: 2006-07-05 12:54

Message:
Logged In: YES 
user_id=1344176

An alternative fix for this would be not to invoke
filter{tuple,string,unicode} on instances of subclasses of
tuple, str and unicode.

This would fix this bug because you have to be using a
subclass of one of these types to exploit the preallocation.

As a side-effect, this would also resolve the issue I raised
in bug #1517509 concerning filter()'s treatment of these
subtypes re: the iterator protocol.

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

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

From noreply at sourceforge.net  Thu Jul  6 00:48:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 05 Jul 2006 15:48:05 -0700
Subject: [ python-Bugs-1514428 ] NaN comparison in Decimal broken
Message-ID: <E1FyGA9-0005Qo-6k@sc8-sf-web2.sourceforge.net>

Bugs item #1514428, was opened at 2006-06-29 11:19
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514428&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Nick Maclaren (nmm)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: NaN comparison in Decimal broken

Initial Comment:
Methinks this is a bit off :-)  True should be False.


Python 2.5b1 (trunk:47059, Jun 29 2006, 14:26:46)
[GCC 4.1.0 (SUSE Linux)] on linux2
>>> import decimal
>>> d = decimal.Decimal
>>> inf = d("inf")
>>> nan = d("nan")
>>> nan > inf
True
>>> nan < inf
False
>>> inf > nan
True
>>> inf < nan
False
b

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

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

From noreply at sourceforge.net  Thu Jul  6 04:10:22 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 05 Jul 2006 19:10:22 -0700
Subject: [ python-Bugs-1517887 ] zipfile appends broken in 2.5b1
Message-ID: <E1FyJJu-0003lU-5W@sc8-sf-web5.sourceforge.net>

Bugs item #1517887, was opened at 2006-07-06 12:03
Message generated for change (Comment added) made by krumms
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517887&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
>Status: Deleted
>Resolution: Invalid
Priority: 5
Submitted By: Thomas Lee (krumms)
Assigned to: Nobody/Anonymous (nobody)
Summary: zipfile appends broken in 2.5b1

Initial Comment:
Discovered this while implementing a patch for 1514451.
It doesn't matter if compression is used or not, the
bug occurs either way. Test case attached. Output as below:

tom at chip:~/python_bug$ ls
bug.py  file_a.txt  file_c.txt
tom at chip:~/python_bug$ python -V
Python 2.4.3
tom at chip:~/python_bug$ python bug.py
file a
file b
file c
file d
tom at chip:~/python_bug$ python2.5 -V
Python 2.5b1
tom at chip:~/python_bug$ python2.5 bug.py
file a
file b
Traceback (most recent call last):
  File "bug.py", line 16, in <module>
    print f.read('file_c.txt').strip()
  File "/usr/local/python2.5/lib/python2.5/zipfile.py",
line 482, in read
    raise BadZipfile, "Bad magic number for file header"
zipfile.BadZipfile: Bad magic number for file header
tom at chip:~/python_bug$


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

>Comment By: Thomas Lee (krumms)
Date: 2006-07-06 12:10

Message:
Logged In: YES 
user_id=315535

*sighs* I had local modifications that I forgot to remove
before testing this bug. Sorry.

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

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

From noreply at sourceforge.net  Thu Jul  6 04:31:06 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 05 Jul 2006 19:31:06 -0700
Subject: [ python-Bugs-1514451 ] zipfile "append" mode should create a file if
	not present
Message-ID: <E1FyJdy-0002bq-Vj@sc8-sf-web3.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ritesh Raj Sarraf (riteshsarraf)
Assigned to: Nobody/Anonymous (nobody)
Summary: zipfile "append" mode should create a file if not present

Initial Comment:
The line 

filename = zipfile.ZipFile(zip_file_name, "a") 

throws an exception if the given filename is not 
present already.

Shouldn't it create a file (in case one is not there) 
since it is "append" mode ??

It's throwing an OSError Exception stating "No such 
file/directory".

Normal convention has been that when opening a file 
in append mode, if the file is not present a new file 
is created.

Why is this non-standard?

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

Comment By: Thomas Lee (krumms)
Date: 2006-07-06 12:31

Message:
Logged In: YES 
user_id=315535

Patch #1517891 resolves this. See:

http://sourceforge.net/tracker/index.php?func=detail&aid=1517891&group_id=5470&atid=305470

Waiting for review.

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

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

From noreply at sourceforge.net  Thu Jul  6 08:56:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 05 Jul 2006 23:56:24 -0700
Subject: [ python-Bugs-1517388 ] sqlite3.dll only installed with Tcl/Tk
Message-ID: <E1FyNmi-0005EE-2v@sc8-sf-web1.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Installation
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Gerhard H??ring (ghaering)
Assigned to: Martin v. L??wis (loewis)
Summary: sqlite3.dll only installed with Tcl/Tk

Initial Comment:
The sqlite3.dll file is only installed if you activate
the "Tcl/Tk" checkbox in the Windows installer. I guess
many people (like me) don't do that because they have
no need for Tkinter stuff, and then wonder why the
sqlite3 module throws an ImportError. I guess it's a
minor fix in the MSI machinery, but I after a few
minutes of looking, I couldn't find where the problem
is there.

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

>Comment By: Martin v. L??wis (loewis)
Date: 2006-07-06 08:56

Message:
Logged In: YES 
user_id=21627

Thanks for the report. This is now fixed in r47258.

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

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

From noreply at sourceforge.net  Thu Jul  6 10:26:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 06 Jul 2006 01:26:05 -0700
Subject: [ python-Bugs-1517990 ] IDLE on macosx keybindings need work
Message-ID: <E1FyPBV-00007C-MJ@sc8-sf-web2.sourceforge.net>

Bugs item #1517990, was opened at 2006-07-06 10:26
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=1517990&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.5
Status: Open
Resolution: None
Priority: 7
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Nobody/Anonymous (nobody)
Summary: IDLE on macosx keybindings need work

Initial Comment:
There is a serious issue with the keybindings for IDLE on OSX: a lot of 
them don't work correctly. One example of a not-working key-binding is 
'CMD-W', this should close the current window but doesn't.  'CMD-N' does 
create a new window though, so at least some keybindings work.


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

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

From noreply at sourceforge.net  Thu Jul  6 10:29:09 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 06 Jul 2006 01:29:09 -0700
Subject: [ python-Bugs-1517993 ] IDLE: config-main.def contains
	windows-specific settings
Message-ID: <E1FyPET-0001Sm-3O@sc8-sf-web2.sourceforge.net>

Bugs item #1517993, was opened at 2006-07-06 10: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=1517993&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Nobody/Anonymous (nobody)
Summary: IDLE: config-main.def contains windows-specific settings

Initial Comment:
The default values in config-main.def contain values that are specific for 
Windows. This means that the key-bindings for other platforms, such as 
OSX will be wrong (because config-main selects the windows keybindings 
as the default keybindings).

I've worked around this by copying a mac version of config-main.def over 
the installed version of config-main.def from Mac/IDLE/Makefile.in. That 
is obviously a crude hack, but I know of no better solution.

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

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

From noreply at sourceforge.net  Thu Jul  6 10:34:00 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 06 Jul 2006 01:34:00 -0700
Subject: [ python-Bugs-1517996 ] IDLE (macosx): Class and Path browsers show
	Tk menu
Message-ID: <E1FyPJA-0005Ha-DY@sc8-sf-web6.sourceforge.net>

Bugs item #1517996, was opened at 2006-07-06 10:34
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=1517996&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Nobody/Anonymous (nobody)
Summary: IDLE (macosx): Class and Path browsers show Tk menu

Initial Comment:
I've done some work on fixing the menus for IDLE before 2.5b1, but 
recently found more toplevel windows that don't have their own menu.

Both the Path Browser and Class Browser don't have a menubar of their 
own. The Tk implementation on MacOSX won't accept an empty menubar, 
but will replace that by a generic Tk menubar.

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

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

From noreply at sourceforge.net  Thu Jul  6 16:46:33 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 06 Jul 2006 07:46:33 -0700
Subject: [ python-Bugs-1518190 ] c_void_pointer should accept a long pointer >
	0x7fffffff
Message-ID: <E1FyV7h-0000aS-FQ@sc8-sf-web3.sourceforge.net>

Bugs item #1518190, was opened at 2006-07-06 16:46
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=1518190&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
Summary: c_void_pointer should accept a long pointer > 0x7fffffff

Initial Comment:
Mike Fletcher reported this problem:

http://tinyurl.com/esneq

Currently, the c_void_p constructor calls
PyLong_AsVoidPtr(value), in Modules/_ctypes/cfield.c,
near line 1491.

This call should be changed to use either
PyLong_AsUnsignedLongMask() or
PyLong_AsUnsignedLongLongMask() depending on
sizeof(void *), and cast the result to (void *).

This change would also make the c_void_p behaviour more
consistent with the other c_int, c_long and so on
constructors since all of them mask the value to the
number of bits they can accept.

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

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

From noreply at sourceforge.net  Thu Jul  6 19:03:51 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 06 Jul 2006 10:03:51 -0700
Subject: [ python-Bugs-1518190 ] c_void_pointer should accept a long pointer >
	0x7fffffff
Message-ID: <E1FyXGZ-0003Gi-FL@sc8-sf-web2.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: c_void_pointer should accept a long pointer > 0x7fffffff

Initial Comment:
Mike Fletcher reported this problem:

http://tinyurl.com/esneq

Currently, the c_void_p constructor calls
PyLong_AsVoidPtr(value), in Modules/_ctypes/cfield.c,
near line 1491.

This call should be changed to use either
PyLong_AsUnsignedLongMask() or
PyLong_AsUnsignedLongLongMask() depending on
sizeof(void *), and cast the result to (void *).

This change would also make the c_void_p behaviour more
consistent with the other c_int, c_long and so on
constructors since all of them mask the value to the
number of bits they can accept.

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

>Comment By: Thomas Heller (theller)
Date: 2006-07-06 19:03

Message:
Logged In: YES 
user_id=11105

Assigning to Neal for review (please).  The #if block is not
really needed imo, but I used it for clarity - it is copied
verbatim from Objects/longobject.c, which would throw
compile errors if the conditions are not fulfilled.

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

Comment By: Thomas Heller (theller)
Date: 2006-07-06 18:56

Message:
Logged In: YES 
user_id=11105

Attached a patch, with tests, that fixes this bug.
PyInt_AsUnsignedLongMask() and
PyInt_AsUnsignedLongLongMask() is what we need to use.

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

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

From noreply at sourceforge.net  Thu Jul  6 21:28:53 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 06 Jul 2006 12:28:53 -0700
Subject: [ python-Bugs-1515998 ] bdist_msi fails (egg-info)
Message-ID: <E1FyZWv-0005B5-7o@sc8-sf-web4.sourceforge.net>

Bugs item #1515998, was opened at 2006-07-02 22:44
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1515998&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 8
Submitted By: Paul Moore (pmoore)
Assigned to: Martin v. L??wis (loewis)
Summary: bdist_msi fails (egg-info)

Initial Comment:
If I try to build a bdist_msi installer for a trivial
module, using Python 2.5b1, I get an error.

It looks like a problem with the interaction of the new
(in 2.5) egg-info stuff and the bdist_msi code - but I
have no further ideas.
Here is the setup.py

from distutils.core import setup
setup(
   name='test',
   version='1.0',
   py_modules=['test'],
)

And here is the build output:

>python setup.py bdist_msi
running bdist_msi
running build
running build_py
creating build
creating build\lib
copying test.py -> build\lib
installing to build\bdist.win32\msi
running install_lib
creating build\bdist.win32
creating build\bdist.win32\msi
creating build\bdist.win32\msi\Lib
creating build\bdist.win32\msi\Lib\site-packages
copying build\lib\test.py ->
build\bdist.win32\msi\Lib\site-packages
running install_egg_info
Writing
build\bdist.win32\msi\Lib\site-packages\test-1.0-py2.5.egg-info
creating dist
Traceback (most recent call last):
 File "setup.py", line 5, in <module>
   py_modules=['test'],
 File "D:\Apps\Python25\Lib\distutils\core.py", line
151, in setup
   dist.run_commands()
 File "D:\Apps\Python25\Lib\distutils\dist.py", line
974, in run_commands
   self.run_command(cmd)
 File "D:\Apps\Python25\Lib\distutils\dist.py", line
994, in run_command
   cmd_obj.run()
 File
"D:\Apps\Python25\Lib\distutils\command\bdist_msi.py",
line 235, in run
   self.add_files()
 File
"D:\Apps\Python25\Lib\distutils\command\bdist_msi.py", line
263, in add_files
   key = dir.add_file(file)
 File "D:\Apps\Python25\Lib\msilib\__init__.py", line
343, in add_file
   language, attributes, sequence)])
 File "D:\Apps\Python25\Lib\msilib\__init__.py", line
115, in add_data
   raise MSIError("Could not insert "+repr(values)+"
into "+table)
_msi.MSIError: Could not insert [(None, 'site_packages',
'TEST-1~1.EGG|test-1.0-py2.5.egg-info', 186L, None,
None, 512, 1)]
into File


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

>Comment By: Martin v. L??wis (loewis)
Date: 2006-07-06 21:28

Message:
Logged In: YES 
user_id=21627

Thanks for the report. This is now fixed in r47280.

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

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

From noreply at sourceforge.net  Thu Jul  6 21:31:39 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 06 Jul 2006 12:31:39 -0700
Subject: [ python-Bugs-1518346 ] cookielib doku
Message-ID: <E1FyZZb-0004a2-Qx@sc8-sf-web2.sourceforge.net>

Bugs item #1518346, was opened at 2006-07-06 21: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=1518346&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Christoph Zwerschke (cito)
Assigned to: Nobody/Anonymous (nobody)
Summary: cookielib doku

Initial Comment:
The cookielib doku says in 17.22
(http://docs.python.org/dev/lib/module-cookielib.html)
".. the max-age and port cookie-attributes introduced
with RFC 2109..."

The port cookie-attribute woth introduced with RFC
2965, not RFC 2109.

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

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

From noreply at sourceforge.net  Thu Jul  6 21:32:47 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 06 Jul 2006 12:32:47 -0700
Subject: [ python-Bugs-1518346 ] cookielib doku port cookie-attribute
Message-ID: <E1FyZah-0005Mb-CJ@sc8-sf-web6.sourceforge.net>

Bugs item #1518346, was opened at 2006-07-06 21:31
Message generated for change (Settings changed) made by cito
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1518346&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
>Priority: 1
Submitted By: Christoph Zwerschke (cito)
Assigned to: Nobody/Anonymous (nobody)
>Summary: cookielib doku port cookie-attribute

Initial Comment:
The cookielib doku says in 17.22
(http://docs.python.org/dev/lib/module-cookielib.html)
".. the max-age and port cookie-attributes introduced
with RFC 2109..."

The port cookie-attribute woth introduced with RFC
2965, not RFC 2109.

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

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

From noreply at sourceforge.net  Thu Jul  6 23:26:22 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 06 Jul 2006 14:26:22 -0700
Subject: [ python-Bugs-1518406 ] re '\' char interpretation problem
Message-ID: <E1FybMc-0001jl-Sr@sc8-sf-web3.sourceforge.net>

Bugs item #1518406, was opened at 2006-07-06 16:26
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=1518406&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Regular Expressions
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: ollie oldham (ooldham)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: re '\' char interpretation problem

Initial Comment:
I've run across 2 problems having to do with '\' 
character problems with the re module.

Problem 1 does not match the re when it should have.
Problem 2 matches, when it should not have.

There is a short snippet of code attached that shows 
the problems I'm having, and the output as it occurs 
on my machine.

I'm running on Windows 2000
Python versions: 2.4b1 and 2.4.3c1 both act the same 
way.

Problem (1) : why does * work and not + ?
import re
rex = re.compile(r'[a-z]:\.*', re.IGNORECASE)
rey = re.compile(r'[a-z]:\.+', re.IGNORECASE)
path1 = r'D:\Logs'
print rex.match(path1) # Matches - as it should have.
print rey.match(path1) # FAILES to match - should have.

Problem 2) : match occurs on nonUncPath when it should 
not
import re
uncPath = r'\\someUNC\path'
nonUncPath = r'\nonUnc\path'
rew = re.compile('\\\\.+', re.IGNORECASE)
print rew.match(uncPath) # works as it should.
print rew.match(nonUncPath) # matches and it should 
NOT.


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

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

From noreply at sourceforge.net  Thu Jul  6 23:36:11 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 06 Jul 2006 14:36:11 -0700
Subject: [ python-Bugs-1518406 ] re '\' char interpretation problem
Message-ID: <E1FybW7-0008Jx-IL@sc8-sf-web4.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Regular Expressions
Group: Python 2.4
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: ollie oldham (ooldham)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: re '\' char interpretation problem

Initial Comment:
I've run across 2 problems having to do with '\' 
character problems with the re module.

Problem 1 does not match the re when it should have.
Problem 2 matches, when it should not have.

There is a short snippet of code attached that shows 
the problems I'm having, and the output as it occurs 
on my machine.

I'm running on Windows 2000
Python versions: 2.4b1 and 2.4.3c1 both act the same 
way.

Problem (1) : why does * work and not + ?
import re
rex = re.compile(r'[a-z]:\.*', re.IGNORECASE)
rey = re.compile(r'[a-z]:\.+', re.IGNORECASE)
path1 = r'D:\Logs'
print rex.match(path1) # Matches - as it should have.
print rey.match(path1) # FAILES to match - should have.

Problem 2) : match occurs on nonUncPath when it should 
not
import re
uncPath = r'\\someUNC\path'
nonUncPath = r'\nonUnc\path'
rew = re.compile('\\\\.+', re.IGNORECASE)
print rew.match(uncPath) # works as it should.
print rew.match(nonUncPath) # matches and it should 
NOT.


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

>Comment By: Gustavo Niemeyer (niemeyer)
Date: 2006-07-06 21:36

Message:
Logged In: YES 
user_id=7887

1) r'[a-z]:\.+' should not match r'D:\Logs'. r'\.+' matches
one or more dots. There's no dot in this string.

2) '\\\\.+' is the equivalent of r'\\.+', and should match
anything that starts with a '\' and has at least one char
following it, which includes r'\nonUnc\path'.


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

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

From noreply at sourceforge.net  Fri Jul  7 00:46:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 06 Jul 2006 15:46:24 -0700
Subject: [ python-Bugs-1518406 ] re '\' char interpretation problem
Message-ID: <E1Fycc4-0005K3-Kh@sc8-sf-web1.sourceforge.net>

Bugs item #1518406, was opened at 2006-07-06 16:26
Message generated for change (Comment added) made by ooldham
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1518406&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Regular Expressions
Group: Python 2.4
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: ollie oldham (ooldham)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: re '\' char interpretation problem

Initial Comment:
I've run across 2 problems having to do with '\' 
character problems with the re module.

Problem 1 does not match the re when it should have.
Problem 2 matches, when it should not have.

There is a short snippet of code attached that shows 
the problems I'm having, and the output as it occurs 
on my machine.

I'm running on Windows 2000
Python versions: 2.4b1 and 2.4.3c1 both act the same 
way.

Problem (1) : why does * work and not + ?
import re
rex = re.compile(r'[a-z]:\.*', re.IGNORECASE)
rey = re.compile(r'[a-z]:\.+', re.IGNORECASE)
path1 = r'D:\Logs'
print rex.match(path1) # Matches - as it should have.
print rey.match(path1) # FAILES to match - should have.

Problem 2) : match occurs on nonUncPath when it should 
not
import re
uncPath = r'\\someUNC\path'
nonUncPath = r'\nonUnc\path'
rew = re.compile('\\\\.+', re.IGNORECASE)
print rew.match(uncPath) # works as it should.
print rew.match(nonUncPath) # matches and it should 
NOT.


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

>Comment By: ollie oldham (ooldham)
Date: 2006-07-06 17:46

Message:
Logged In: YES 
user_id=649833

I beg to differ on problem 1)

Since ???r??? was used in the definition of both the re and 
path, the ???.??? Char is not being escaped (not supposed to be 
anyway).
And even if it is, then rex=re.compile(???[a-z]:\\.+???, 
re.IGNORECASE) should get me what I want (in textual form:: 
char a-z colon backslash with 1 or more trailing chars).
But that does not work either.

I beg to differ on item 2) as well:
Yes - '\\\\.+' is the equivalent of r'\\.+'
BUT I then read this as: 2 backslashes with 1 or more 
chars ??? NOT backslash with escaped ???.???


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

Comment By: Gustavo Niemeyer (niemeyer)
Date: 2006-07-06 16:36

Message:
Logged In: YES 
user_id=7887

1) r'[a-z]:\.+' should not match r'D:\Logs'. r'\.+' matches
one or more dots. There's no dot in this string.

2) '\\\\.+' is the equivalent of r'\\.+', and should match
anything that starts with a '\' and has at least one char
following it, which includes r'\nonUnc\path'.


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

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

From noreply at sourceforge.net  Fri Jul  7 00:55:02 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 06 Jul 2006 15:55:02 -0700
Subject: [ python-Bugs-1518406 ] re '\' char interpretation problem
Message-ID: <E1FyckQ-0004Gv-6j@sc8-sf-web4.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Regular Expressions
Group: Python 2.4
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: ollie oldham (ooldham)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: re '\' char interpretation problem

Initial Comment:
I've run across 2 problems having to do with '\' 
character problems with the re module.

Problem 1 does not match the re when it should have.
Problem 2 matches, when it should not have.

There is a short snippet of code attached that shows 
the problems I'm having, and the output as it occurs 
on my machine.

I'm running on Windows 2000
Python versions: 2.4b1 and 2.4.3c1 both act the same 
way.

Problem (1) : why does * work and not + ?
import re
rex = re.compile(r'[a-z]:\.*', re.IGNORECASE)
rey = re.compile(r'[a-z]:\.+', re.IGNORECASE)
path1 = r'D:\Logs'
print rex.match(path1) # Matches - as it should have.
print rey.match(path1) # FAILES to match - should have.

Problem 2) : match occurs on nonUncPath when it should 
not
import re
uncPath = r'\\someUNC\path'
nonUncPath = r'\nonUnc\path'
rew = re.compile('\\\\.+', re.IGNORECASE)
print rew.match(uncPath) # works as it should.
print rew.match(nonUncPath) # matches and it should 
NOT.


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

>Comment By: Gustavo Niemeyer (niemeyer)
Date: 2006-07-06 22:55

Message:
Logged In: YES 
user_id=7887

Please, use a single way to report issues. Do not message
*and* add a comment to the bug.

I think you're missing the behavior of r'' in Python. It
changes the way the Python interpreter parses the string,
not the way the regular expression compiler/interpreter
works. r'\.' is precisely the same as '\\.', and both of
them really describe the string |\.|.

  >>> r'\.' == '\\.'
  True

  >>> print r'\.'
  \.

Escaping a dot means a real dot. Please have a look at the
re module documentation and perhaps some general regular
expression info for more details.


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

Comment By: ollie oldham (ooldham)
Date: 2006-07-06 22:46

Message:
Logged In: YES 
user_id=649833

I beg to differ on problem 1)

Since ???r??? was used in the definition of both the re and 
path, the ???.??? Char is not being escaped (not supposed to be 
anyway).
And even if it is, then rex=re.compile(???[a-z]:\\.+???, 
re.IGNORECASE) should get me what I want (in textual form:: 
char a-z colon backslash with 1 or more trailing chars).
But that does not work either.

I beg to differ on item 2) as well:
Yes - '\\\\.+' is the equivalent of r'\\.+'
BUT I then read this as: 2 backslashes with 1 or more 
chars ??? NOT backslash with escaped ???.???


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

Comment By: Gustavo Niemeyer (niemeyer)
Date: 2006-07-06 21:36

Message:
Logged In: YES 
user_id=7887

1) r'[a-z]:\.+' should not match r'D:\Logs'. r'\.+' matches
one or more dots. There's no dot in this string.

2) '\\\\.+' is the equivalent of r'\\.+', and should match
anything that starts with a '\' and has at least one char
following it, which includes r'\nonUnc\path'.


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

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

From noreply at sourceforge.net  Fri Jul  7 03:03:21 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 06 Jul 2006 18:03:21 -0700
Subject: [ python-Bugs-1518453 ] '\' problem in re.sub
Message-ID: <E1Fyekb-0000LM-7Y@sc8-sf-web2.sourceforge.net>

Bugs item #1518453, was opened at 2006-07-06 20: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=1518453&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: ilan29 (ilan29)
Assigned to: Nobody/Anonymous (nobody)
Summary: '\' problem in re.sub

Initial Comment:
#! /usr/bin/env python
import re

# Pattern only to match character 'b'
p = re.compile('b')

# Replace 'b' with SINGLE literal backslash
print p.sub( '\\', 'b', 1 )


I'm running:
   Python 2.4.3 (#1, Jun 11 2006, 12:01:42) 
   [GCC 3.3.4 (pre 3.3.5 20040809)] on linux2

When starting the progam it raises:
sre_constants.error: bogus escape (end of line)


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

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

From noreply at sourceforge.net  Fri Jul  7 03:51:43 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 06 Jul 2006 18:51:43 -0700
Subject: [ python-Bugs-1512604 ] Install on Windows Vista locks up
Message-ID: <E1FyfVP-00008B-Da@sc8-sf-web2.sourceforge.net>

Bugs item #1512604, was opened at 2006-06-26 11:15
Message generated for change (Comment added) made by plathem
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512604&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Installation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Lucas (michael_lucas)
Assigned to: Nobody/Anonymous (nobody)
Summary: Install on Windows Vista locks up

Initial Comment:
I have had problems trying to install this version on 
Vista. When the install gets to the verifying disk 
space requirements the system locks up. It does not go 
any further. I have to cancel the instalation of 
python. The only way I have got around this is to 
install an older version of python (version 2.3.5) 
this version does work, but there are newer versions 
that I want to work with on my system. If anyone has a 
work around for this please contact me at 
michael.lucas at us.army.mil

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

Comment By: Pat Lathem (plathem)
Date: 2006-07-07 01:51

Message:
Logged In: YES 
user_id=661716

FWIW, this can be worked around by using the command-line
MSI installer:

msiexec /i python-2.4.3.msi TARGETDIR="C:\Program
Files\Python24"
ALLUSERS=1 /qb

Found that here:
http://mail.python.org/pipermail/python-list/2006-June/347402.html

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-06-29 18:48

Message:
Logged In: YES 
user_id=21627

I can confirm the problem, but I doubt I can do much about it.

In fact, I believe this is a bug in Vista/Windows Installer
4.0.  The installer GUI waits for the CostingComplete
property to be set, but this never happens.

If you are a beta tester, please make a bug report to Microsoft.

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

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

From noreply at sourceforge.net  Fri Jul  7 07:08:50 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 06 Jul 2006 22:08:50 -0700
Subject: [ python-Bugs-1512604 ] Install on Windows Vista locks up
Message-ID: <E1FyiaA-0004OE-7M@sc8-sf-web4.sourceforge.net>

Bugs item #1512604, was opened at 2006-06-26 13:15
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512604&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Installation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Lucas (michael_lucas)
Assigned to: Nobody/Anonymous (nobody)
Summary: Install on Windows Vista locks up

Initial Comment:
I have had problems trying to install this version on 
Vista. When the install gets to the verifying disk 
space requirements the system locks up. It does not go 
any further. I have to cancel the instalation of 
python. The only way I have got around this is to 
install an older version of python (version 2.3.5) 
this version does work, but there are newer versions 
that I want to work with on my system. If anyone has a 
work around for this please contact me at 
michael.lucas at us.army.mil

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

>Comment By: Martin v. L??wis (loewis)
Date: 2006-07-07 07:08

Message:
Logged In: YES 
user_id=21627

That's actually no surprise: /qb disables the user
interface, so that the problematic interaction is skipped
entirely.

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

Comment By: Pat Lathem (plathem)
Date: 2006-07-07 03:51

Message:
Logged In: YES 
user_id=661716

FWIW, this can be worked around by using the command-line
MSI installer:

msiexec /i python-2.4.3.msi TARGETDIR="C:\Program
Files\Python24"
ALLUSERS=1 /qb

Found that here:
http://mail.python.org/pipermail/python-list/2006-June/347402.html

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-06-29 20:48

Message:
Logged In: YES 
user_id=21627

I can confirm the problem, but I doubt I can do much about it.

In fact, I believe this is a bug in Vista/Windows Installer
4.0.  The installer GUI waits for the CostingComplete
property to be set, but this never happens.

If you are a beta tester, please make a bug report to Microsoft.

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

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

From noreply at sourceforge.net  Fri Jul  7 08:10:06 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 06 Jul 2006 23:10:06 -0700
Subject: [ python-Bugs-1494314 ] Cannot use high-numbered sockets in 2.4.3
Message-ID: <E1FyjXS-00015z-Dn@sc8-sf-web4.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Smith (mlrsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cannot use high-numbered sockets in 2.4.3

Initial Comment:
Python 2.4.3 introduced (in Modules/socketmodule.c) the
IS_SELECTABLE() macro, to check whether calling
select() on a given file descriptor is permissible.

However, it executes this check even when it won't
actually call select(). Specifically, select() is
called ONLY when s->sock_timeout > 0 (in
internal_select mostly, but also internal_connect).

I have a twisted application which uses many FDs
(several thousand), and upgrading python to 2.4.3 makes
it hit this limit (at 1024 file descriptors),
regardless of ulimit settings. Twisted itself always
uses non-blocking I/O on sockets, so with older
versions of python this worked fine.

A simple solution relies on the fact that select is
only ever actually called, and changes the
IS_SELECTABLE macro as in the attached fairly trivial
patch. This is sufficient to restore my application to
its previous state (where it works fine).

This doesn't solve the more general problem in
socketmodule - that we simply can't do all operations
properly with the current reliance on select(), though,
and it seems like a bit of a hack...  If I wrote up a
patch to use poll() on systems where it's available,
throughout socketmodule.c, in preference to select(),
would this be accepted?

Mike



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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-06 23:10

Message:
Logged In: YES 
user_id=33168

I've added a more complete patch (against 2.5, hopefully
applies to 2.4 too).  It cleans up some things and adds
support for SSL sockets too.  Can people please review/test
this?  I manually tested this with regular sockets and it
seemed to work.  All the tests pass, but this is somewhat
tricky.  I hate the duplicated code between socket and ssl
modules, but added to it.  It would be great to clean this
up for 2.6.

If you are forced to use select with a high socket, the
exception on connect is operation in progress rather than
can't select on socket.  I guess that's ok, it doesn't
actually change the existing behaviour.  That would have
been more involved and I'm not sure it's worth it.

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

Comment By: Michael Smith (mlrsmith)
Date: 2006-06-09 03:31

Message:
Logged In: YES 
user_id=1488997

Ok, I'll attach a patch that uses poll when available
(HAVE_POLL is already being set by the configure stuff
appropriately).

It replaces one of the two uses of select() (specifically,
the internal_select() function) in socketmodule.c. The other
is win32-specific, so replacing it with poll() wouldn't make
sense.

greg: epoll/kevent don't make sense for replacing the use of
select/poll in this particular case - socketmodule.c always
selects/polls precisely one file descriptor.

I've tested this locally, and it fixes the problem
(linux/x86). I don't have a windows system to test it on,
but it shouldn't change behaviour in any way for windows.



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

Comment By: Gregory P. Smith (greg)
Date: 2006-06-07 22:51

Message:
Logged In: YES 
user_id=413

eew yuck.  yes use poll at the very least.

we should also consider using epoll (linux) and kevent (bsd)
in the future as both of those scale better than O(n) unlike
select and poll.

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-06-04 13:14

Message:
Logged In: YES 
user_id=21627

A patch to replace internal_select with poll(2) where
available is acceptable. The current version should be
conditionally kept. That Windows doesn't have poll(2) is no
problem: its select implementation supports arbitrarily
large FDs (just like poll).

Relaxing the IS_SELECTABLE usage to cases where select is
actually going to be called is optional: there shouldn't be
too many systems left without select where people still want
to open many file descriptors.

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

Comment By: Tim Peters (tim_one)
Date: 2006-05-31 15:27

Message:
Logged In: YES 
user_id=31435

akuchling:  No, poll() is not part of the Windows socket API.

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

Comment By: Michael Smith (mlrsmith)
Date: 2006-05-31 14:39

Message:
Logged In: YES 
user_id=1488997

That, of course, is the problem - select() is available more
or less universally, but poll() is not. However, it's not
terribly difficult to write a poll() wrapper using select(),
though doing so in general would have serious performance
issues (the specific uses in socketmodule.c do not hit this
problem), and retains the limitations of select. 

It's not clear that the complexity of doing this is
worthwhile compared to just implementing the simple API
needed internally to socketmodule.c using both APIs (i.e.
just adding a poll() option).

Regardless, it'd be nice if at least the basic fix I wrote
up went in - it solves the immediate problem, at least.

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

Comment By: A.M. Kuchling (akuchling)
Date: 2006-05-31 11:39

Message:
Logged In: YES 
user_id=11375

I expect such a patch would be acceptable.  The largest
issue is probably whether poll() is available everywhere, or
if we'd be stuck maintaining both select() and poll() based
versions of internal_select().  Does Windows support poll()
at all?

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

Comment By: Michael Smith (mlrsmith)
Date: 2006-05-29 07:13

Message:
Logged In: YES 
user_id=1488997

Yes, I had my ulimit set appropriately.

There's no problem with _opening_ many sockets (at least, I
don't think there is) - the problem is with trying to do
something (like call socket.recv()) with them.

The code in socketmodule.c is pretty clear - and having
upgraded to 2.4.3 with ubuntu dapper, I _am_ running into this.

For now, we're having to keep all our production machines on
2.4.2.


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

Comment By: Gabriel Wicke (gabrielwicke)
Date: 2006-05-29 07:11

Message:
Logged In: YES 
user_id=956757

Please disregard my comments completely- just opening more
than 1024 files does not trigger this bug, but doing a
socket.send() on the 1025th socket does.

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

Comment By: Gabriel Wicke (gabrielwicke)
Date: 2006-05-29 07:00

Message:
Logged In: YES 
user_id=956757

Never mind- you already tried ulimit. It still works for me
though, 2.4.3 from Ubuntu Dapper.

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

Comment By: Gabriel Wicke (gabrielwicke)
Date: 2006-05-29 06:57

Message:
Logged In: YES 
user_id=956757

Try "ulimit -n 8096" (only permitted in a root shell) to set
your max socket usage to something larger. Opening more than
1024 sockets works for me in python 2.4.3 after changing the
limit for the terminal in question and restarting the
interpreter. Just ulimit -n will show you your current
limit. Ulimits are enforced by the Linux kernel and can
likely be configured system-wide in /etc/sysctl.cfg.

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

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

From noreply at sourceforge.net  Fri Jul  7 08:18:29 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 06 Jul 2006 23:18:29 -0700
Subject: [ python-Bugs-1511964 ] Can't use sockets in 2.5b1
Message-ID: <E1FyjfZ-0006RL-OQ@sc8-sf-web5.sourceforge.net>

Bugs item #1511964, was opened at 2006-06-24 16:28
Message generated for change (Comment added) made by bos
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1511964&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Bryan O'Sullivan (bos)
Assigned to: Nobody/Anonymous (nobody)
Summary: Can't use sockets in 2.5b1

Initial Comment:
I'm testing Mercurial with Python 2.5b1, and I am getting severe badness in the socket module, complaining that _socket.socket doesn't have a recv_into method.

+  File "/tmp/hgtests.u_b_G-/install/lib/python/mercurial/httprangereader.py", line 24, in read
+    f = urllib2.urlopen(req)
+  File "/export/home/bos/src/py25/lib/python2.5/urllib2.py", line 121, in urlopen
+    return _opener.open(url, data)
+  File "/export/home/bos/src/py25/lib/python2.5/urllib2.py", line 374, in open
+    response = self._open(req, data)
+  File "/export/home/bos/src/py25/lib/python2.5/urllib2.py", line 392, in _open+    '_open', req)
+  File "/export/home/bos/src/py25/lib/python2.5/urllib2.py", line 353, in _call_chain
+    result = func(*args)
+  File "/export/home/bos/src/py25/lib/python2.5/urllib2.py", line 1099, in http_open
+    return self.do_open(httplib.HTTPConnection, req)
+  File "/export/home/bos/src/py25/lib/python2.5/urllib2.py", line 1071, in do_open
+    h.request(req.get_method(), req.get_selector(), req.data, headers)
+  File "/export/home/bos/src/py25/lib/python2.5/httplib.py", line 862, in request
+    self._send_request(method, url, body, headers)
+  File "/export/home/bos/src/py25/lib/python2.5/httplib.py", line 885, in _send_request
+    self.endheaders()
+  File "/export/home/bos/src/py25/lib/python2.5/httplib.py", line 856, in endheaders
+    self._send_output()
+  File "/export/home/bos/src/py25/lib/python2.5/httplib.py", line 728, in _send_output
+    self.send(msg)
+  File "/export/home/bos/src/py25/lib/python2.5/httplib.py", line 695, in send
+    self.connect()
+  File "/export/home/bos/src/py25/lib/python2.5/httplib.py", line 666, in connect
+    self.sock = socket.socket(af, socktype, proto)
+  File "/export/home/bos/src/py25/lib/python2.5/socket.py", line 154, in __init__
+    self.recv_into = self._sock.recv_into
+AttributeError: '_socket.socket' object has no attribute 'recv_into'


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

>Comment By: Bryan O'Sullivan (bos)
Date: 2006-07-06 23:18

Message:
Logged In: YES 
user_id=28380

I can't reproduce this with 2.5b1, so it was either some
strange pilot error, or it's been magically resolved.

By the way, this was on Linux, FC5.

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-06-29 11:46

Message:
Logged In: YES 
user_id=21627

Also, please report what operating system this is on.

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

Comment By: Armin Rigo (arigo)
Date: 2006-06-25 02:38

Message:
Logged In: YES 
user_id=4771

This looks like a broken install.  The socket objects
do have a recv_into() method in socketmodule.c.  Try "make
clean; make".  If it does not help, check where the _socket
module comes from with:

python2.5
>>> import _socket
>>> print _socket.__file__

and make sure that this file is among the ones you just
recompiled.

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

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

From noreply at sourceforge.net  Fri Jul  7 08:21:49 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 06 Jul 2006 23:21:49 -0700
Subject: [ python-Bugs-1518453 ] '\' problem in re.sub
Message-ID: <E1Fyjin-000884-MO@sc8-sf-web5.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: ilan29 (ilan29)
Assigned to: Nobody/Anonymous (nobody)
Summary: '\' problem in re.sub

Initial Comment:
#! /usr/bin/env python
import re

# Pattern only to match character 'b'
p = re.compile('b')

# Replace 'b' with SINGLE literal backslash
print p.sub( '\\', 'b', 1 )


I'm running:
   Python 2.4.3 (#1, Jun 11 2006, 12:01:42) 
   [GCC 3.3.4 (pre 3.3.5 20040809)] on linux2

When starting the progam it raises:
sre_constants.error: bogus escape (end of line)


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

Comment By: Bryan O'Sullivan (bos)
Date: 2006-07-06 23:21

Message:
Logged In: YES 
user_id=28380

Your code is wrong.  Both Python and re interpret
backslashes, and you're not passing enough backslashes in
for re to see two.

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

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

From noreply at sourceforge.net  Fri Jul  7 09:47:10 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 07 Jul 2006 00:47:10 -0700
Subject: [ python-Bugs-1518453 ] '\' problem in re.sub
Message-ID: <E1Fyl3O-0003ob-RT@sc8-sf-web6.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: ilan29 (ilan29)
Assigned to: Nobody/Anonymous (nobody)
Summary: '\' problem in re.sub

Initial Comment:
#! /usr/bin/env python
import re

# Pattern only to match character 'b'
p = re.compile('b')

# Replace 'b' with SINGLE literal backslash
print p.sub( '\\', 'b', 1 )


I'm running:
   Python 2.4.3 (#1, Jun 11 2006, 12:01:42) 
   [GCC 3.3.4 (pre 3.3.5 20040809)] on linux2

When starting the progam it raises:
sre_constants.error: bogus escape (end of line)


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

>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-07 07:47

Message:
Logged In: YES 
user_id=849994

bos is right.

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

Comment By: Bryan O'Sullivan (bos)
Date: 2006-07-07 06:21

Message:
Logged In: YES 
user_id=28380

Your code is wrong.  Both Python and re interpret
backslashes, and you're not passing enough backslashes in
for re to see two.

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

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

From noreply at sourceforge.net  Fri Jul  7 10:15:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 07 Jul 2006 01:15:25 -0700
Subject: [ python-Bugs-1518346 ] cookielib doku port cookie-attribute
Message-ID: <E1FylUj-0005Jv-GQ@sc8-sf-web1.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 1
Submitted By: Christoph Zwerschke (cito)
Assigned to: Nobody/Anonymous (nobody)
Summary: cookielib doku port cookie-attribute

Initial Comment:
The cookielib doku says in 17.22
(http://docs.python.org/dev/lib/module-cookielib.html)
".. the max-age and port cookie-attributes introduced
with RFC 2109..."

The port cookie-attribute woth introduced with RFC
2965, not RFC 2109.

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

>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-07 08:15

Message:
Logged In: YES 
user_id=849994

Fixed in rev. 47289.

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

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

From noreply at sourceforge.net  Fri Jul  7 10:15:37 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 07 Jul 2006 01:15:37 -0700
Subject: [ python-Bugs-1518569 ] 'import foo as bar' not checking for 'as'
Message-ID: <E1FylUv-0007Eb-Uo@sc8-sf-web4.sourceforge.net>

Bugs item #1518569, was opened at 2006-07-07 10: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=1518569&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.5
Status: Open
Resolution: None
Priority: 7
Submitted By: Thomas Wouters (twouters)
Assigned to: Thomas Wouters (twouters)
Summary: 'import foo as bar' not checking for 'as'

Initial Comment:
'import foo as bar' doesn't check if the 'as' is really
'as', allowing for 'import foo feeble bar' to mean the
same thing. I probably broke this somehow when making
'as' a future-keyword. Adding a bug to remind myself to
fix it (next week or so)



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

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

From noreply at sourceforge.net  Fri Jul  7 11:25:44 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 07 Jul 2006 02:25:44 -0700
Subject: [ python-Bugs-1518617 ] Website updating part of PEP101/102 out of
	date
Message-ID: <E1Fymam-0001n4-9f@sc8-sf-web1.sourceforge.net>

Bugs item #1518617, was opened at 2006-07-07 11: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=1518617&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Johannes Gijsbers (jlgijsbers)
Assigned to: Nobody/Anonymous (nobody)
Summary: Website updating part of PEP101/102 out of date

Initial Comment:
PEP 101 and 102 currently still describe the old way to
update the Python website. I noticed this, because I
wanted to add a note that wiki/BeginnersGuide/Download
needs to be updated as well.

Anthony, since you apparently know how to do the
updates right now, could you update PEP 101/102 with
the new procedure?

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

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

From noreply at sourceforge.net  Fri Jul  7 11:26:58 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 07 Jul 2006 02:26:58 -0700
Subject: [ python-Bugs-1518617 ] Website updating part of PEP101/102 out of
	date
Message-ID: <E1Fymby-0006Et-Ij@sc8-sf-web3.sourceforge.net>

Bugs item #1518617, was opened at 2006-07-07 11:25
Message generated for change (Settings changed) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1518617&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Johannes Gijsbers (jlgijsbers)
>Assigned to: Anthony Baxter (anthonybaxter)
Summary: Website updating part of PEP101/102 out of date

Initial Comment:
PEP 101 and 102 currently still describe the old way to
update the Python website. I noticed this, because I
wanted to add a note that wiki/BeginnersGuide/Download
needs to be updated as well.

Anthony, since you apparently know how to do the
updates right now, could you update PEP 101/102 with
the new procedure?

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

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

From noreply at sourceforge.net  Fri Jul  7 11:35:22 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 07 Jul 2006 02:35:22 -0700
Subject: [ python-Bugs-1518621 ] optparse.parse_args() ret value seems to be a
	dict but isn't
Message-ID: <E1Fymk6-0003wU-1t@sc8-sf-web6.sourceforge.net>

Bugs item #1518621, was opened at 2006-07-07 11:35
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=1518621&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: rhunger (rhunger)
Assigned to: Nobody/Anonymous (nobody)
Summary: optparse.parse_args() ret value seems to be a dict but isn't

Initial Comment:
...
from optparse import OptionParser
parser = OptionParser()
...
(options, args) = parser.parse_args()
print options
...

options seems to be a dict but isn't. So it's not possible to use e.g.

print "Option 1: %(firstOption)s" % options

Here it's easy to use "options.firstOption" but with a larger number of program options it would be nice to be able to use "options" as a dict directly.

(patch attached)

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

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

From noreply at sourceforge.net  Fri Jul  7 16:28:32 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 07 Jul 2006 07:28:32 -0700
Subject: [ python-Bugs-1518772 ] ext/win-cookbook.html has a broken link to
	distutils
Message-ID: <E1FyrJo-00013X-L2@sc8-sf-web1.sourceforge.net>

Bugs item #1518772, was opened at 2006-07-07 14:02
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1518772&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Documentation
>Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Johannes Gijsbers (jlgijsbers)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: ext/win-cookbook.html has a broken link to distutils

Initial Comment:
http://docs.python.org/ext/win-cookbook.html has a link
to distutils which points to
http://docs.python.org/ext/module-distutils.html. It
should point to
http://docs.python.org/lib/module-distutils.html.

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

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

From noreply at sourceforge.net  Fri Jul  7 17:50:13 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 07 Jul 2006 08:50:13 -0700
Subject: [ python-Bugs-1494314 ] Cannot use high-numbered sockets in 2.4.3
Message-ID: <E1Fysar-0001al-0z@sc8-sf-web6.sourceforge.net>

Bugs item #1494314, was opened at 2006-05-24 15:51
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494314&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Smith (mlrsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cannot use high-numbered sockets in 2.4.3

Initial Comment:
Python 2.4.3 introduced (in Modules/socketmodule.c) the
IS_SELECTABLE() macro, to check whether calling
select() on a given file descriptor is permissible.

However, it executes this check even when it won't
actually call select(). Specifically, select() is
called ONLY when s->sock_timeout > 0 (in
internal_select mostly, but also internal_connect).

I have a twisted application which uses many FDs
(several thousand), and upgrading python to 2.4.3 makes
it hit this limit (at 1024 file descriptors),
regardless of ulimit settings. Twisted itself always
uses non-blocking I/O on sockets, so with older
versions of python this worked fine.

A simple solution relies on the fact that select is
only ever actually called, and changes the
IS_SELECTABLE macro as in the attached fairly trivial
patch. This is sufficient to restore my application to
its previous state (where it works fine).

This doesn't solve the more general problem in
socketmodule - that we simply can't do all operations
properly with the current reliance on select(), though,
and it seems like a bit of a hack...  If I wrote up a
patch to use poll() on systems where it's available,
throughout socketmodule.c, in preference to select(),
would this be accepted?

Mike



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

>Comment By: Martin v. L??wis (loewis)
Date: 2006-07-07 17:50

Message:
Logged In: YES 
user_id=21627

The __APPLE__ stuff looks wrong in file 184131. You would
have to use selectmodule.c:select_have_broken_poll at
run-time to be sure you can use poll(2) on OS X (you can use
it on 10.4, but can't on 10.3, IIRC).

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-07 08:10

Message:
Logged In: YES 
user_id=33168

I've added a more complete patch (against 2.5, hopefully
applies to 2.4 too).  It cleans up some things and adds
support for SSL sockets too.  Can people please review/test
this?  I manually tested this with regular sockets and it
seemed to work.  All the tests pass, but this is somewhat
tricky.  I hate the duplicated code between socket and ssl
modules, but added to it.  It would be great to clean this
up for 2.6.

If you are forced to use select with a high socket, the
exception on connect is operation in progress rather than
can't select on socket.  I guess that's ok, it doesn't
actually change the existing behaviour.  That would have
been more involved and I'm not sure it's worth it.

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

Comment By: Michael Smith (mlrsmith)
Date: 2006-06-09 12:31

Message:
Logged In: YES 
user_id=1488997

Ok, I'll attach a patch that uses poll when available
(HAVE_POLL is already being set by the configure stuff
appropriately).

It replaces one of the two uses of select() (specifically,
the internal_select() function) in socketmodule.c. The other
is win32-specific, so replacing it with poll() wouldn't make
sense.

greg: epoll/kevent don't make sense for replacing the use of
select/poll in this particular case - socketmodule.c always
selects/polls precisely one file descriptor.

I've tested this locally, and it fixes the problem
(linux/x86). I don't have a windows system to test it on,
but it shouldn't change behaviour in any way for windows.



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

Comment By: Gregory P. Smith (greg)
Date: 2006-06-08 07:51

Message:
Logged In: YES 
user_id=413

eew yuck.  yes use poll at the very least.

we should also consider using epoll (linux) and kevent (bsd)
in the future as both of those scale better than O(n) unlike
select and poll.

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

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

Message:
Logged In: YES 
user_id=21627

A patch to replace internal_select with poll(2) where
available is acceptable. The current version should be
conditionally kept. That Windows doesn't have poll(2) is no
problem: its select implementation supports arbitrarily
large FDs (just like poll).

Relaxing the IS_SELECTABLE usage to cases where select is
actually going to be called is optional: there shouldn't be
too many systems left without select where people still want
to open many file descriptors.

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

Comment By: Tim Peters (tim_one)
Date: 2006-06-01 00:27

Message:
Logged In: YES 
user_id=31435

akuchling:  No, poll() is not part of the Windows socket API.

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

Comment By: Michael Smith (mlrsmith)
Date: 2006-05-31 23:39

Message:
Logged In: YES 
user_id=1488997

That, of course, is the problem - select() is available more
or less universally, but poll() is not. However, it's not
terribly difficult to write a poll() wrapper using select(),
though doing so in general would have serious performance
issues (the specific uses in socketmodule.c do not hit this
problem), and retains the limitations of select. 

It's not clear that the complexity of doing this is
worthwhile compared to just implementing the simple API
needed internally to socketmodule.c using both APIs (i.e.
just adding a poll() option).

Regardless, it'd be nice if at least the basic fix I wrote
up went in - it solves the immediate problem, at least.

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

Comment By: A.M. Kuchling (akuchling)
Date: 2006-05-31 20:39

Message:
Logged In: YES 
user_id=11375

I expect such a patch would be acceptable.  The largest
issue is probably whether poll() is available everywhere, or
if we'd be stuck maintaining both select() and poll() based
versions of internal_select().  Does Windows support poll()
at all?

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

Comment By: Michael Smith (mlrsmith)
Date: 2006-05-29 16:13

Message:
Logged In: YES 
user_id=1488997

Yes, I had my ulimit set appropriately.

There's no problem with _opening_ many sockets (at least, I
don't think there is) - the problem is with trying to do
something (like call socket.recv()) with them.

The code in socketmodule.c is pretty clear - and having
upgraded to 2.4.3 with ubuntu dapper, I _am_ running into this.

For now, we're having to keep all our production machines on
2.4.2.


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

Comment By: Gabriel Wicke (gabrielwicke)
Date: 2006-05-29 16:11

Message:
Logged In: YES 
user_id=956757

Please disregard my comments completely- just opening more
than 1024 files does not trigger this bug, but doing a
socket.send() on the 1025th socket does.

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

Comment By: Gabriel Wicke (gabrielwicke)
Date: 2006-05-29 16:00

Message:
Logged In: YES 
user_id=956757

Never mind- you already tried ulimit. It still works for me
though, 2.4.3 from Ubuntu Dapper.

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

Comment By: Gabriel Wicke (gabrielwicke)
Date: 2006-05-29 15:57

Message:
Logged In: YES 
user_id=956757

Try "ulimit -n 8096" (only permitted in a root shell) to set
your max socket usage to something larger. Opening more than
1024 sockets works for me in python 2.4.3 after changing the
limit for the terminal in question and restarting the
interpreter. Just ulimit -n will show you your current
limit. Ulimits are enforced by the Linux kernel and can
likely be configured system-wide in /etc/sysctl.cfg.

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

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

From noreply at sourceforge.net  Sat Jul  8 00:33:15 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 07 Jul 2006 15:33:15 -0700
Subject: [ python-Bugs-1519018 ] import_as_name and dotted_as_name fail to
	validate syntax
Message-ID: <E1Fyyst-000130-Ap@sc8-sf-web2.sourceforge.net>

Bugs item #1519018, was opened at 2006-07-07 18: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=1519018&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Scott Dial (geekmug)
Assigned to: Nobody/Anonymous (nobody)
Summary: import_as_name and dotted_as_name fail to validate syntax

Initial Comment:
The following import statements are invalidly accepted
by the current HEAD:

"import sys foo bar"
"from sys import path foo bar"

The current trunk excepts this input and merely ignores
"foo" failing to validate that the string is "as". I am
not familiar enough with Python's syntax checking to
locate it and submit a patch.


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

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

From noreply at sourceforge.net  Sat Jul  8 04:20:29 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 7 Jul 2006 19:20:29 -0700
Subject: [ python-Bugs-1501699 ] method format of logging.Formatter caches
	incorrectly
Message-ID: <200607080220.k682KTkE022713@sc8-sf-db2-new-b.sourceforge.net>

Bugs item #1501699, was opened at 06/06/06 08:14
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501699&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
>Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Boris Lorbeer (blorbeer)
Assigned to: Vinay Sajip (vsajip)
Summary: method format of logging.Formatter caches incorrectly

Initial Comment:
The format method of logging.Formatter is buggy in that
it doesn't call the method formatException if the cache
record.exc_text is set. If you have two Formatters that
should format the same log record differently (i.e. each
has its own overriding formatException method), the
formatException method of the second formatter will
never be called because the cache has been set by the
first formatter. The proper way of using the cache is
IMHO to check the cache only in the method
formatException of logging.Formatter.

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

>Comment By: SourceForge Robot (sf-robot)
Date: 07/07/06 19:20

Message:
Logged In: YES 
user_id=1312539

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

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

Comment By: Vinay Sajip (vsajip)
Date: 06/23/06 07:56

Message:
Logged In: YES 
user_id=308438

Hi Boris,

You didn't say in your comment what was wrong with my 
suggestion (setting record.exc_text to None in your 
formatter subclass).

I take your point, and understand your labeledCache 
suggestion, and will look at implementing something 
equivalent when time permits. However, other scenarios need 
to be considered, such as sending LogRecords over the wire. 
In this scenario (not uncommon in multi-process 
environments), the present implementation could send the 
formatted stack trace, as it is pickled in the LogRecord; 
implementing a cache in the Formatter will not allow the 
stack trace to be sent to be logged elsewhwere.



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

Comment By: Boris Lorbeer (blorbeer)
Date: 06/23/06 07:01

Message:
Logged In: YES 
user_id=1535177

Hi vsajip,
yes, it is by design, but I don't know whether the design is
ideal. But if this behaviour is really intended, it should
be documented clearly, such as:
formatException(exc_info): If you override this method, an
exception in the log record will be formatted by using this
method, but only if this log record wasn't given by the
framework to another formatter (that uses the default format
function) before your formatter got its turn (something you
cannot ensure)...

Now to the question of how to fix the design (provided one
wants to): clearly one cannot change the signature of
formatException without breaking existing code. But one
could change formatter to have an additional field
'labeledCache': a pair of an exc_info tuple and a string
(the cache). The formatException method would then use this
cache only if id() of its argument is the id() of the first
element in the pair, otherwise it would exchange
'labeledCache' by a new pair belonging to the current
exc_info tuple. That's only one posibility to fix this problem.

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

Comment By: Vinay Sajip (vsajip)
Date: 06/22/06 09:46

Message:
Logged In: YES 
user_id=308438

It's not a bug, it's by design. The formatException method
only takes the exception info as a parameter, and to change
the  method signature now could break some people's code, right?

A solution would be for you to also override the format
method in your custom formatter classes and set
record.exc_text to None if you want to invalidate the cache
before calling the base class implementation.

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

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

From noreply at sourceforge.net  Sat Jul  8 05:04:50 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 07 Jul 2006 20:04:50 -0700
Subject: [ python-Bugs-1519069 ] incorrect locale.strcoll() return in Windows
Message-ID: <E1Fz37i-0002GB-U8@sc8-sf-web3.sourceforge.net>

Bugs item #1519069, was opened at 2006-07-07 22: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=1519069&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Brian Matherly (pez4brian)
Assigned to: Nobody/Anonymous (nobody)
Summary: incorrect locale.strcoll() return in Windows

Initial Comment:
Python 2.4.2 in Windows (English locale):

>>> import locale
>>> locale.setlocale(locale.LC_ALL,'C')
'C'
>>> locale.setlocale(locale.LC_ALL,'')
'English_United States.1252'
>>> locale.strcoll("M","m")
1
>>> locale.strcoll("Ma","mz")
-1

It appears that when a string has one character, "M" is
greater than "m", but when it has more than one string,
"M" is equal to "m"

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

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

From noreply at sourceforge.net  Sat Jul  8 05:08:34 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 07 Jul 2006 20:08:34 -0700
Subject: [ python-Bugs-1519069 ] incorrect locale.strcoll() return in Windows
Message-ID: <E1Fz3BK-0006FK-Bg@sc8-sf-web1.sourceforge.net>

Bugs item #1519069, was opened at 2006-07-07 22:04
Message generated for change (Comment added) made by pez4brian
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519069&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Brian Matherly (pez4brian)
Assigned to: Nobody/Anonymous (nobody)
Summary: incorrect locale.strcoll() return in Windows

Initial Comment:
Python 2.4.2 in Windows (English locale):

>>> import locale
>>> locale.setlocale(locale.LC_ALL,'C')
'C'
>>> locale.setlocale(locale.LC_ALL,'')
'English_United States.1252'
>>> locale.strcoll("M","m")
1
>>> locale.strcoll("Ma","mz")
-1

It appears that when a string has one character, "M" is
greater than "m", but when it has more than one string,
"M" is equal to "m"

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

>Comment By: Brian Matherly (pez4brian)
Date: 2006-07-07 22:08

Message:
Logged In: YES 
user_id=726294

Correction:

It appears that when a string has one character, "M" is
greater than "m", but when it has more than one character,
"M" is equal to "m"

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

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

From noreply at sourceforge.net  Sat Jul  8 05:35:51 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 07 Jul 2006 20:35:51 -0700
Subject: [ python-Bugs-1519069 ] incorrect locale.strcoll() return in Windows
Message-ID: <E1Fz3bj-0002CF-Ib@sc8-sf-web3.sourceforge.net>

Bugs item #1519069, was opened at 2006-07-07 22:04
Message generated for change (Comment added) made by pez4brian
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519069&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Brian Matherly (pez4brian)
Assigned to: Nobody/Anonymous (nobody)
Summary: incorrect locale.strcoll() return in Windows

Initial Comment:
Python 2.4.2 in Windows (English locale):

>>> import locale
>>> locale.setlocale(locale.LC_ALL,'C')
'C'
>>> locale.setlocale(locale.LC_ALL,'')
'English_United States.1252'
>>> locale.strcoll("M","m")
1
>>> locale.strcoll("Ma","mz")
-1

It appears that when a string has one character, "M" is
greater than "m", but when it has more than one string,
"M" is equal to "m"

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

>Comment By: Brian Matherly (pez4brian)
Date: 2006-07-07 22:35

Message:
Logged In: YES 
user_id=726294

I see the same problem in python 2.4.3

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

Comment By: Brian Matherly (pez4brian)
Date: 2006-07-07 22:08

Message:
Logged In: YES 
user_id=726294

Correction:

It appears that when a string has one character, "M" is
greater than "m", but when it has more than one character,
"M" is equal to "m"

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

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

From noreply at sourceforge.net  Sat Jul  8 07:31:53 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 07 Jul 2006 22:31:53 -0700
Subject: [ python-Bugs-1519018 ] import_as_name and dotted_as_name fail to
	validate syntax
Message-ID: <E1Fz5Q1-0006lv-GZ@sc8-sf-web5.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Scott Dial (geekmug)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: import_as_name and dotted_as_name fail to validate syntax

Initial Comment:
The following import statements are invalidly accepted
by the current HEAD:

"import sys foo bar"
"from sys import path foo bar"

The current trunk excepts this input and merely ignores
"foo" failing to validate that the string is "as". I am
not familiar enough with Python's syntax checking to
locate it and submit a patch.


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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-07 22:31

Message:
Logged In: YES 
user_id=33168

Committed revision 50489.


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

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

From noreply at sourceforge.net  Sat Jul  8 19:38:49 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 08 Jul 2006 10:38:49 -0700
Subject: [ python-Bugs-1514451 ] zipfile "append" mode should create a file if
	not present
Message-ID: <E1FzGlV-0001Ka-0t@sc8-sf-web3.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ritesh Raj Sarraf (riteshsarraf)
Assigned to: Nobody/Anonymous (nobody)
Summary: zipfile "append" mode should create a file if not present

Initial Comment:
The line 

filename = zipfile.ZipFile(zip_file_name, "a") 

throws an exception if the given filename is not 
present already.

Shouldn't it create a file (in case one is not there) 
since it is "append" mode ??

It's throwing an OSError Exception stating "No such 
file/directory".

Normal convention has been that when opening a file 
in append mode, if the file is not present a new file 
is created.

Why is this non-standard?

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

>Comment By: Gregory P. Smith (greg)
Date: 2006-07-08 10:38

Message:
Logged In: YES 
user_id=413

I agree.  append semantics generally mean append or create.

+1 from me on fixing this bug.

if any existing code is depending on the side effect from
opening a zip file in 'a' mode to tell them that it doesn't
already exist this change would break that; but I'd argue
that such code is already broken and should be cleaned up.


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

Comment By: Thomas Lee (krumms)
Date: 2006-07-05 19:31

Message:
Logged In: YES 
user_id=315535

Patch #1517891 resolves this. See:

http://sourceforge.net/tracker/index.php?func=detail&aid=1517891&group_id=5470&atid=305470

Waiting for review.

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

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

From noreply at sourceforge.net  Sun Jul  9 04:47:10 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 08 Jul 2006 19:47:10 -0700
Subject: [ python-Feature Requests-1506340 ] Add some dicts to datetime module
Message-ID: <E1FzPKA-0000st-T2@sc8-sf-web2.sourceforge.net>

Feature Requests item #1506340, was opened at 2006-06-14 14:14
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506340&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Gregory Petrosyan (gregory_p)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add some dicts to datetime module

Initial Comment:
I think it would be nice to have dicts like

weekdays = {0:'Monday', ...}
isoweekdays = {1:'Monday', ...}
months = {1:'January', ...}

in the datetime module. IMO they are rather usefull.

--
Regards, Gregory.



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

Comment By: Gregory Petrosyan (gregory_p)
Date: 2006-06-14 14:18

Message:
Logged In: YES 
user_id=1405187

I am terribly sorry for that many duplicates of this and 
other tickets. This is a strange bug, i don't know why this 
had happened.


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

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

From noreply at sourceforge.net  Sun Jul  9 04:56:18 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 08 Jul 2006 19:56:18 -0700
Subject: [ python-Feature Requests-1399936 ] Add str.partition
Message-ID: <E1FzPT0-0007Uc-Dz@sc8-sf-web3.sourceforge.net>

Feature Requests item #1399936, was opened at 2006-01-08 13:50
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1399936&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Georg Brandl (birkenfeld)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Add str.partition

Initial Comment:
This is mostly here that the idea does not get lost.

See
http://mail.python.org/pipermail/python-dev/2005-August/055781.html
for reference implementation and discussion.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-08 19:56

Message:
Logged In: YES 
user_id=33168

There's a str.partition (and rpartition) in 2.5.  I assume
the request has been satisfied.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-01-08 16:50

Message:
Logged In: YES 
user_id=80475

It's not lost.  Will stay on my todo list until the time arises.

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

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

From noreply at sourceforge.net  Sun Jul  9 07:57:45 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 08 Jul 2006 22:57:45 -0700
Subject: [ python-Bugs-1519452 ] too many files?
Message-ID: <E1FzSIb-0003HI-DO@sc8-sf-web6.sourceforge.net>

Bugs item #1519452, was opened at 2006-07-09 01:57
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=1519452&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Joe Brown (shmengie)
Assigned to: Nobody/Anonymous (nobody)
Summary: too many files?

Initial Comment:
While creating a huge zipfile (probably too big) the
following error appeared.

Exception exceptions.OverflowError: 'long int too large
to convert to int' in <bound method ZipFile.__del__ of
<zipfile.ZipFile instance at 0x009BD198>> ignored

I assume this is during the closing of the zipfile,
further assuming too many files were added to the archive.

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

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

From noreply at sourceforge.net  Sun Jul  9 07:58:31 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 08 Jul 2006 22:58:31 -0700
Subject: [ python-Bugs-1519452 ] zipfile -- too many files?
Message-ID: <E1FzSJL-0004pY-Hp@sc8-sf-web6.sourceforge.net>

Bugs item #1519452, was opened at 2006-07-09 01:57
Message generated for change (Settings changed) made by shmengie
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519452&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Joe Brown (shmengie)
Assigned to: Nobody/Anonymous (nobody)
>Summary: zipfile -- too many files?

Initial Comment:
While creating a huge zipfile (probably too big) the
following error appeared.

Exception exceptions.OverflowError: 'long int too large
to convert to int' in <bound method ZipFile.__del__ of
<zipfile.ZipFile instance at 0x009BD198>> ignored

I assume this is during the closing of the zipfile,
further assuming too many files were added to the archive.

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

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

From noreply at sourceforge.net  Sun Jul  9 08:01:07 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 08 Jul 2006 23:01:07 -0700
Subject: [ python-Bugs-1519452 ] zipfile -- too many files?
Message-ID: <E1FzSLr-0007aA-Cg@sc8-sf-web3.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Joe Brown (shmengie)
Assigned to: Nobody/Anonymous (nobody)
Summary: zipfile -- too many files?

Initial Comment:
While creating a huge zipfile (probably too big) the
following error appeared.

Exception exceptions.OverflowError: 'long int too large
to convert to int' in <bound method ZipFile.__del__ of
<zipfile.ZipFile instance at 0x009BD198>> ignored

I assume this is during the closing of the zipfile,
further assuming too many files were added to the archive.

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

>Comment By: Joe Brown (shmengie)
Date: 2006-07-09 02:01

Message:
Logged In: YES 
user_id=729883

Platform: Windows SBS 2003
Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit
(Intel)] on win32

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

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

From noreply at sourceforge.net  Sun Jul  9 11:41:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 09 Jul 2006 02:41:42 -0700
Subject: [ python-Bugs-1508010 ] msvccompiler.py using VC6 with Python 2.5a2
Message-ID: <E1FzVnK-0002sP-8t@sc8-sf-web6.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils
Group: Python 2.5
Status: Open
Resolution: None
Priority: 7
Submitted By: Jimmy Retzlaff (jretz)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: msvccompiler.py using VC6 with Python 2.5a2

Initial Comment:
The change in revision 42515 checks if MSSdk is
defined, and if so it will "Assume that the SDK set up
everything alright." The problem is that the SDK may be
set up for a different version of cl.exe than is
expected. In my case I have VC6 and VC7.1 installed and
the SDK is set up for VC6. When building extensions for
Python 2.5a2, distutils tries to use VC6 in my case.

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

>Comment By: Martin v. L??wis (loewis)
Date: 2006-07-09 11:41

Message:
Logged In: YES 
user_id=21627

Here is a proposed patch: in addition to requiring MSSdk to
be set, distutils would also require DISTUTILS_USE_SDK to be
set.

Neal, can you please approve this new feature before beta 2?

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

Comment By: Jimmy Retzlaff (jretz)
Date: 2006-06-25 01:01

Message:
Logged In: YES 
user_id=101588

There is an option when installing VC (or at least there
used to be, I haven't checked lately) to set the environment
variables to take effect system wide. This is useful in that
the build environment is always available at any command
line (and they are also set when I build from my editor
which is not VS). I've left mine pointed at VC6 as I
typically do standalone DLLs using VC6 so they are easier to
redistribute. Distutils has always selected the right
version so it hasn't been an issue for me when working on
Python things before.

The issue wouldn't be as difficult if the resulting behavior
were more obvious. Unfortunately the initial errors in my
case were syntax errors arising from macro definitions that
changed between VC6 and VC7.1. Most of the time I spent
updating py2exe to work with 2.5 was spent on diagnosing
this. It wasn???t helped by the fact that I had a blind spot
regarding the compiler version. I use a batch file to build
py2exe for 2.3, then 2.4, and finally 2.5. Since 2.3 and 2.4
were building fine I didn???t even consider the idea of the
wrong compiler version being used for quite a while.

For now I just do "set MSSDK=" before building and then
everything works just fine.


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

Comment By: Martin v. L??wis (loewis)
Date: 2006-06-24 12:30

Message:
Logged In: YES 
user_id=21627

I don't understand the problem. MSSdk gets defined by
opening a specific SDK build environment. Just don't open
that build environment, but open a regular cmd.exe window,
and it should work fine.

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

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

From noreply at sourceforge.net  Sun Jul  9 16:49:34 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 09 Jul 2006 07:49:34 -0700
Subject: [ python-Bugs-1519571 ] turtle.py Docs still incomplete
Message-ID: <E1FzabG-0005vH-7h@sc8-sf-web1.sourceforge.net>

Bugs item #1519571, was opened at 2006-07-09 14: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=1519571&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Lingl (gregorlingl)
Assigned to: Nobody/Anonymous (nobody)
Summary: turtle.py Docs still incomplete

Initial Comment:
There are three functions in turtle.py (which do not
occur as methods of Pen), which are still not
documented:

setup()
title()
done()

Regards,
Gregor

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

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

From noreply at sourceforge.net  Sun Jul  9 16:50:28 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 09 Jul 2006 07:50:28 -0700
Subject: [ python-Bugs-1519571 ] turtle.py Docs still incomplete
Message-ID: <E1Fzac8-0000GL-S9@sc8-sf-web5.sourceforge.net>

Bugs item #1519571, was opened at 2006-07-09 14:49
Message generated for change (Settings changed) made by gregorlingl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519571&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Python Library
>Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Lingl (gregorlingl)
>Assigned to: Martin v. L??wis (loewis)
Summary: turtle.py Docs still incomplete

Initial Comment:
There are three functions in turtle.py (which do not
occur as methods of Pen), which are still not
documented:

setup()
title()
done()

Regards,
Gregor

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

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

From noreply at sourceforge.net  Sun Jul  9 18:17:21 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 09 Jul 2006 09:17:21 -0700
Subject: [ python-Bugs-1501934 ] incorrect LOAD/STORE_GLOBAL generation
Message-ID: <E1FzbyD-0006IT-In@sc8-sf-web2.sourceforge.net>

Bugs item #1501934, was opened at 2006-06-06 23:57
Message generated for change (Comment added) made by nascheme
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501934&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 8
Submitted By: Thomas Wouters (twouters)
>Assigned to: Neil Schemenauer (nascheme)
Summary: incorrect LOAD/STORE_GLOBAL generation

Initial Comment:
Python 2.5 compiles the following piece of code
differently than Python 2.4:

g = 1
def f():
    g += 1

In Python 2.4, this raises an UnboundLocalError. In
current svn trunk, it will increment the global g by 1.
(dis.dis shows that it actually compiles into
LOAD/STORE_GLOBAL opcodes.) It seems the compiler
doesn't treat augmented assignment as assignment for
the purpose of determining locals, as this still fails
correctly:

g = 1
def f():
    g += 1
    g = 5

I can't find where this optimization happens nowadays,
but it feels like a short fix.


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

>Comment By: Neil Schemenauer (nascheme)
Date: 2006-07-09 16:17

Message:
Logged In: YES 
user_id=35752

Checked in as SVN rev 50493.

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

Comment By: Neil Schemenauer (nascheme)
Date: 2006-06-30 22:03

Message:
Logged In: YES 
user_id=35752

Adding a patch to "fix" test_ast.py.  I have no idea what
the test is trying to verify.  It looks like it was written
by martin.v.loewis so maybe he can comment.

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

Comment By: Neil Schemenauer (nascheme)
Date: 2006-06-30 17:51

Message:
Logged In: YES 
user_id=35752

I've got a simple fix that seems to work.  I feel this part
of the compiler could use some more serious cleanups but
probably not for 2.5.  Note that test_ast fails after
applying my patch.  I haven't had time to look into that yet
but I think it's shallow.

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

Comment By: Neil Schemenauer (nascheme)
Date: 2006-06-30 16:22

Message:
Logged In: YES 
user_id=35752

Here are some notes in case I wear out before finding a fix.
 analyze_name() gets to the SET_SCOPE(dict, name,
GLOBAL_IMPLICIT) line because the name does not have the
DEF_LOCAL flag set as it should.  It does not have DEF_LOCAL
because Name.ctx for 'g' is Load.  I believe there should be
a set_context() call in ast_for_expr_stmt, as flagged as
TODO by  Jeremy.  Maybe set_context(..., Store, ...) would
work or maybe things need to be changed to allow ctx to have
AugAssign as a value.

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

Comment By: Thomas Wouters (twouters)
Date: 2006-06-19 17:44

Message:
Logged In: YES 
user_id=34209

Possibly related is the discovery of free variables (used
when forming closures) and optimized-out codeblocks:

>>> def foo(x):
...     def bar():
...         if 0:
...             print x
...     return bar

In 2.4, there is no closure:
>>> foo.func_code.co_cellvars
()
>>> foo(5).func_closure
>>>

In 2.5, there is:
>>> foo.func_code.co_cellvars
('x',)
>>> foo(5).func_closure
(<cell at 0x2b9abf6d7e30: int object at 0x6b6580>,)

(I don't think it's unreasonable to declare the old
behaviour bugged, though :-)


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

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

From noreply at sourceforge.net  Sun Jul  9 19:20:54 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 09 Jul 2006 10:20:54 -0700
Subject: [ python-Bugs-1508010 ] msvccompiler.py using VC6 with Python 2.5a2
Message-ID: <E1Fzcxi-0003OS-5K@sc8-sf-web2.sourceforge.net>

Bugs item #1508010, was opened at 2006-06-18 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=1508010&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils
Group: Python 2.5
Status: Open
>Resolution: Accepted
Priority: 7
Submitted By: Jimmy Retzlaff (jretz)
>Assigned to: Martin v. L??wis (loewis)
Summary: msvccompiler.py using VC6 with Python 2.5a2

Initial Comment:
The change in revision 42515 checks if MSSdk is
defined, and if so it will "Assume that the SDK set up
everything alright." The problem is that the SDK may be
set up for a different version of cl.exe than is
expected. In my case I have VC6 and VC7.1 installed and
the SDK is set up for VC6. When building extensions for
Python 2.5a2, distutils tries to use VC6 in my case.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-09 10:20

Message:
Logged In: YES 
user_id=33168

Martin, this looks fine if you think it's important.  Don't
forget to add a Misc/NEWS entry.

There are some typos in the doc:

chose -> choose

"most be both set" -> "must both be set"

Should the last distutils in the doc be:  \module{distutils}?

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-07-09 02:41

Message:
Logged In: YES 
user_id=21627

Here is a proposed patch: in addition to requiring MSSdk to
be set, distutils would also require DISTUTILS_USE_SDK to be
set.

Neal, can you please approve this new feature before beta 2?

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

Comment By: Jimmy Retzlaff (jretz)
Date: 2006-06-24 16:01

Message:
Logged In: YES 
user_id=101588

There is an option when installing VC (or at least there
used to be, I haven't checked lately) to set the environment
variables to take effect system wide. This is useful in that
the build environment is always available at any command
line (and they are also set when I build from my editor
which is not VS). I've left mine pointed at VC6 as I
typically do standalone DLLs using VC6 so they are easier to
redistribute. Distutils has always selected the right
version so it hasn't been an issue for me when working on
Python things before.

The issue wouldn't be as difficult if the resulting behavior
were more obvious. Unfortunately the initial errors in my
case were syntax errors arising from macro definitions that
changed between VC6 and VC7.1. Most of the time I spent
updating py2exe to work with 2.5 was spent on diagnosing
this. It wasn???t helped by the fact that I had a blind spot
regarding the compiler version. I use a batch file to build
py2exe for 2.3, then 2.4, and finally 2.5. Since 2.3 and 2.4
were building fine I didn???t even consider the idea of the
wrong compiler version being used for quite a while.

For now I just do "set MSSDK=" before building and then
everything works just fine.


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

Comment By: Martin v. L??wis (loewis)
Date: 2006-06-24 03:30

Message:
Logged In: YES 
user_id=21627

I don't understand the problem. MSSdk gets defined by
opening a specific SDK build environment. Just don't open
that build environment, but open a regular cmd.exe window,
and it should work fine.

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

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

From noreply at sourceforge.net  Sun Jul  9 20:34:12 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 09 Jul 2006 11:34:12 -0700
Subject: [ python-Bugs-1519638 ] Unmatched Group issue
Message-ID: <E1Fze6e-0006bN-Fl@sc8-sf-web2.sourceforge.net>

Bugs item #1519638, was opened at 2006-07-09 18:34
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=1519638&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Regular Expressions
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Bobby Xiao (nneonneo)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: Unmatched Group issue

Initial Comment:
Using sre.sub[n], an "unmatched group" error can occur.

The test I used is this pattern:

sre.sub("foo(?:b(ar)|baz)","\\1","foobaz")

This will cause the following backtrace to occur:

Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "lib/python2.4/sre.py", line 142, in sub
    return _compile(pattern, 0).sub(repl, string, count)
  File "lib/python2.4/sre.py", line 260, in filter
    return sre_parse.expand_template(template, match)
  File "lib/python2.4/sre_parse.py", line 782, in expand_template
    raise error, "unmatched group"
sre_constants.error: unmatched group

Python Version 2.4.3, Mac OS X (behaviour has been verified on 
Windows 2.4.3 as well).

This behaviour, while by design, is unwanted because this type of 
matching usually requests that a blank match be returned (i.e. the 
example should return '')

The example that I was trying resembles the following:

sre.sub("User: (?:Registered User #(\d+)|Guest)","%USERID|\1%",data)

The intended behaviour is that the function returns "" when the user is 
a guest and the user number if the user is a registered member.

However, when this function encounters a Guest, it raises an exception 
and terminates, which is not what is wanted.

Perl and other regex engines behave as I have described, substituting 
empty strings for unmatched groups. The code fix is relatively simple, 
and would really help out for these types of things.

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

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

From noreply at sourceforge.net  Sun Jul  9 23:05:44 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 09 Jul 2006 14:05:44 -0700
Subject: [ python-Bugs-1333982 ] Bugs of the new AST compiler
Message-ID: <E1FzgTI-00067n-8J@sc8-sf-web6.sourceforge.net>

Bugs item #1333982, was opened at 2005-10-21 10:08
Message generated for change (Comment added) made by nascheme
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1333982&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: AST
Status: Open
Resolution: None
Priority: 7
Submitted By: Armin Rigo (arigo)
Assigned to: Jeremy Hylton (jhylton)
Summary: Bugs of the new AST compiler

Initial Comment:
The newly merged AST branch is likely to expose
a number of small problems before it stabilizes,
so here is a tentative bug tracker entry to
collect such small problems.


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

>Comment By: Neil Schemenauer (nascheme)
Date: 2006-07-09 21:05

Message:
Logged In: YES 
user_id=35752

Regarding the -2147483648 bug: the old compiler tries to
fold unary +, - and ~ if the RHS is a constant.  I think
only the minus case is important since the others are just
optimizations, right?  Attaching what seems to be a minimum fix.

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

Comment By: Armin Rigo (arigo)
Date: 2006-07-02 11:29

Message:
Logged In: YES 
user_id=4771

Attached a patch for the LOAD_CONST POP_TOP optimization
(modified from Georg Brandl on python-dev).

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

Comment By: Michael Hudson (mwh)
Date: 2006-04-11 09:41

Message:
Logged In: YES 
user_id=6656

Good morning Armin!

I've reported that bug already: http://python.org/sf/1441486
There's a patch which purports to fix it: http://python.org/sf/1446922
but I haven't gotten around to testing it.

(this is running the pypy/module/array tests or something, isn't it?)

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

Comment By: Armin Rigo (arigo)
Date: 2006-04-11 08:45

Message:
Logged In: YES 
user_id=4771

Another one: the literal -2147483648 (i.e. the value of
-sys.maxint-1) gives a long in 2.5, but an int in <= 2.4.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-03 07:30

Message:
Logged In: YES 
user_id=33168

The tuple store problem is fixed.  The only outstanding item
is the LOAD_CONST/POP_TOP.  I will fix that soon.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-18 06:56

Message:
Logged In: YES 
user_id=33168

Jeremy, there's no need to read anything before my last
comment at 2005-12-17 23:10.  The last two by Armin,
Michael, then my last comment are the only important ones. 
Everything that occurred before my 2005-12-17 comment was
taken care of AFAIK.

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

Comment By: Armin Rigo (arigo)
Date: 2006-02-12 21:54

Message:
Logged In: YES 
user_id=4771

Subscripting is generally a bit sloppy: e.g. the AST model has
no way to distinguish between a single value and a one-element
tuple value!  See:

>>> d = {}
>>> d[1,] = 6
>>> d
{1: 6}        # !

I suggest we fix the model to turn the 'subs' of the 'Subscript' node
from a list of nodes to a single, mandatory 'sub' node.  If tupling is
necessary, it can be explicitly represented with a 'sub' containing a
'Tuple' node.

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

Comment By: Michael Hudson (mwh)
Date: 2006-02-09 15:02

Message:
Logged In: YES 
user_id=6656

We found another one.  Something is wrong in the compilation of augmented 
assignment to subscriptions containing tuples; running this code:

class C:
    def __setitem__(self, i, v):
        print i, v
    def __getitem__(self, i):
        print i
        return 0

c = C()
c[4,5] += 1

gives a spurious exception:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: object does not support item assignment

By contrast, "c[(4,5)] += 1" works fine.



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

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-12-18 07:10

Message:
Logged In: YES 
user_id=33168

EXTENDED_ARG problem was fixed a while ago.
The assert/pass problem was fixed with: 41756.

That leaves the LOAD_CONST/POP_TOP optimization that was
lost and one compiler warning: marshal_write_mod() not being
used.

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

Comment By: Michael Hudson (mwh)
Date: 2005-12-11 00:41

Message:
Logged In: YES 
user_id=6656

You have to include those lines in a source file.  It still crashes for me.

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

Comment By: Brett Cannon (bcannon)
Date: 2005-12-10 23:44

Message:
Logged In: YES 
user_id=357491

I just checked Armin's problem code on rev. 41638 and it
worked for me in the interpreter.  You still having
problems, Armin?

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

Comment By: Armin Rigo (arigo)
Date: 2005-12-04 10:30

Message:
Logged In: YES 
user_id=4771

At rev 41584, the following code snippet triggers an assert
if --with-pydebug is enabled:
Python/compile.c:3843: assemble_lnotab: Assertion 'd_lineno >= 0' failed

-----------------------
assert 1, ([s for s in x] +
           [s for s in x])
pass
-----------------------

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-23 19:14

Message:
Logged In: YES 
user_id=33168

Checkpoint of outstanding issues.  I think all the others
mentioned so far have been fixed:

 * Raymond's warnings in compile.c (unused locals are fixed)
 * EXTENDED_ARG problem
 * LOAD_CONST/POP_TOP (note we can fix this in the optimizer
generally which would get rid of other useless code too)


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

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-10-23 04:53

Message:
Logged In: YES 
user_id=80475

FWIW, here are the warnings issued by my compiler:

Python-ast.c
C:\py25\Python\Python-ast.c(1995) : warning C4101: 'i' : 
unreferenced local variable
C:\py25\Python\Python-ast.c(2070) : warning C4101: 'i' : 
unreferenced local variable
C:\py25\Python\Python-ast.c(2085) : warning C4101: 'i' : 
unreferenced local variable
C:\py25\Python\Python-ast.c(2130) : warning C4101: 'i' : 
unreferenced local variable
C:\py25\Python\Python-ast.c(2151) : warning C4101: 'i' : 
unreferenced local variable
C:\py25\Python\Python-ast.c(2261) : warning C4101: 'i' : 
unreferenced local variable
C:\py25\Python\Python-ast.c(2270) : warning C4101: 'i' : 
unreferenced local variable


compile.c
C:\py25\Python\compile.c(3782) : warning C4305: '=' : truncation 
from 'const int ' to 'char '
C:\py25\Python\compile.c(3802) : warning C4305: '=' : truncation 
from 'const int ' to 'char '
C:\py25\Python\compile.c(3806) : warning C4305: '=' : truncation 
from 'const int ' to 'char '


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-22 07:28

Message:
Logged In: YES 
user_id=33168

I assigned to Jeremy and Neil in the hopes they will see
this message and know about these problems.

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

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 12:45

Message:
Logged In: YES 
user_id=4771

The following (similarly strange-looking) code snippets
compiled successfully before, now they give SyntaxErrors:

--------------------
def f():
    class g:
        exec "hi"
        x
--------------------
def f(x):
    class g:
        exec "hi"
        x
--------------------
def f():
    class g:
        from a import *
        x
--------------------
def f(x):
    class g:
        from a import *
        x


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

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 12:33

Message:
Logged In: YES 
user_id=4771

I would suspect the following one to be due to incorrect
handling of EXTENDED_ARG -- it's from a PyPy test about that:

longexpr = 'x = x or ' + '-x' * 2500
code = '''
def f(x):
    %s
    %s
    %s
    %s
    %s
    %s
    %s
    %s
    %s
    %s
    while x:
        x -= 1
        # EXTENDED_ARG/JUMP_ABSOLUTE here
    return x
''' % ((longexpr,)*10)

exec code
f(5)
SystemError: unknown opcode

dis.dis() shows that the target of both the SETUP_LOOP and
the JUMP_IF_FALSE at the start of the loop are wrong.

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

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 12:15

Message:
Logged In: YES 
user_id=4771

The Python rules about which names get mangled are a bit
insane.  I share mwh's view that mangling should never have
been invented in the first place, but well:

>>> def f():
...   __x = 5
...   class X:
...     def g(self):
...       return __x
...   return X
... 
Fatal Python error: unknown scope for _X__x in X(135832776)
in <stdin>


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

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 12:01

Message:
Logged In: YES 
user_id=4771

For reference, an optimization that got lost:

    def f():
        'a'
        'b'

'a' is the docstring, but the 'b' previously did not show
up anywhere in the code object.  Now there is the
LOAD_CONST/POP_TOP pair.

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

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 11:54

Message:
Logged In: YES 
user_id=4771

any reason why lambda functions have a __name__ of
'lambda' now instead of '<lambda>' ?

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

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 10:22

Message:
Logged In: YES 
user_id=4771

import a as b, c

the 'c' part gets completely forgotten and there is
no 'IMPORT_NAME c' in the bytecode.

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

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 10:13

Message:
Logged In: YES 
user_id=4771

A scoping problem (comparing with the old compiler):

class X:
    print hello

The variable 'hello' is incorrectly looked up with
LOAD_GLOBAL instead of LOAD_NAME.  It causes a crash
in PyPy in a case where the name 'hello' is stored
into the class implicitely (via locals()).  It can
probably be discussed if the bug is in PyPy, but it
is a difference in behavior.

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

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

From noreply at sourceforge.net  Sun Jul  9 23:21:50 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 09 Jul 2006 14:21:50 -0700
Subject: [ python-Bugs-1441486 ] yet another svn head compiler change
Message-ID: <E1Fzgis-0003Q9-Pr@sc8-sf-web1.sourceforge.net>

Bugs item #1441486, was opened at 2006-03-02 06:39
Message generated for change (Settings changed) made by nascheme
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1441486&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Michael Hudson (mwh)
>Assigned to: Neil Schemenauer (nascheme)
Summary: yet another svn head compiler change

Initial Comment:
This one seems stangely familiar:

$ python2.4
Python 2.4.1 (#2, Mar 31 2005, 00:05:10) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> -2147483648
-2147483648
>>> 
$ ~/Source/python/build/python.exe 
Python 2.5a0 (trunk:42764M, Mar  1 2006, 18:21:57) 
[GCC 4.0.1 (Apple Computer, Inc. build 5247)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> -2147483648
-2147483648L


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

>Comment By: Neil Schemenauer (nascheme)
Date: 2006-07-09 21:21

Message:
Logged In: YES 
user_id=35752

Fixed in SVN rev 50495.  I did the folding in the CST->AST
phase, similar to how it was done in the old compiler.

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

Comment By: Grant Olson (logistix)
Date: 2006-03-10 02:33

Message:
Logged In: YES 
user_id=699438

Patch 1446922 posted.

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

Comment By: Grant Olson (logistix)
Date: 2006-03-06 23:47

Message:
Logged In: YES 
user_id=699438

It looks like the parser is seeing this as unary minus
applied to 2147483648 instead of the literal "-2147483648"

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

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

From noreply at sourceforge.net  Sun Jul  9 23:23:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 09 Jul 2006 14:23:05 -0700
Subject: [ python-Bugs-1333982 ] Bugs of the new AST compiler
Message-ID: <E1Fzgk5-0001Xh-FM@sc8-sf-web3.sourceforge.net>

Bugs item #1333982, was opened at 2005-10-21 10:08
Message generated for change (Comment added) made by nascheme
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1333982&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: AST
Status: Open
Resolution: None
Priority: 7
Submitted By: Armin Rigo (arigo)
Assigned to: Jeremy Hylton (jhylton)
Summary: Bugs of the new AST compiler

Initial Comment:
The newly merged AST branch is likely to expose
a number of small problems before it stabilizes,
so here is a tentative bug tracker entry to
collect such small problems.


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

>Comment By: Neil Schemenauer (nascheme)
Date: 2006-07-09 21:23

Message:
Logged In: YES 
user_id=35752

Unary minus bug has been fixed in SVN rev 50495.

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

Comment By: Neil Schemenauer (nascheme)
Date: 2006-07-09 21:05

Message:
Logged In: YES 
user_id=35752

Regarding the -2147483648 bug: the old compiler tries to
fold unary +, - and ~ if the RHS is a constant.  I think
only the minus case is important since the others are just
optimizations, right?  Attaching what seems to be a minimum fix.

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

Comment By: Armin Rigo (arigo)
Date: 2006-07-02 11:29

Message:
Logged In: YES 
user_id=4771

Attached a patch for the LOAD_CONST POP_TOP optimization
(modified from Georg Brandl on python-dev).

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

Comment By: Michael Hudson (mwh)
Date: 2006-04-11 09:41

Message:
Logged In: YES 
user_id=6656

Good morning Armin!

I've reported that bug already: http://python.org/sf/1441486
There's a patch which purports to fix it: http://python.org/sf/1446922
but I haven't gotten around to testing it.

(this is running the pypy/module/array tests or something, isn't it?)

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

Comment By: Armin Rigo (arigo)
Date: 2006-04-11 08:45

Message:
Logged In: YES 
user_id=4771

Another one: the literal -2147483648 (i.e. the value of
-sys.maxint-1) gives a long in 2.5, but an int in <= 2.4.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-03 07:30

Message:
Logged In: YES 
user_id=33168

The tuple store problem is fixed.  The only outstanding item
is the LOAD_CONST/POP_TOP.  I will fix that soon.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-18 06:56

Message:
Logged In: YES 
user_id=33168

Jeremy, there's no need to read anything before my last
comment at 2005-12-17 23:10.  The last two by Armin,
Michael, then my last comment are the only important ones. 
Everything that occurred before my 2005-12-17 comment was
taken care of AFAIK.

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

Comment By: Armin Rigo (arigo)
Date: 2006-02-12 21:54

Message:
Logged In: YES 
user_id=4771

Subscripting is generally a bit sloppy: e.g. the AST model has
no way to distinguish between a single value and a one-element
tuple value!  See:

>>> d = {}
>>> d[1,] = 6
>>> d
{1: 6}        # !

I suggest we fix the model to turn the 'subs' of the 'Subscript' node
from a list of nodes to a single, mandatory 'sub' node.  If tupling is
necessary, it can be explicitly represented with a 'sub' containing a
'Tuple' node.

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

Comment By: Michael Hudson (mwh)
Date: 2006-02-09 15:02

Message:
Logged In: YES 
user_id=6656

We found another one.  Something is wrong in the compilation of augmented 
assignment to subscriptions containing tuples; running this code:

class C:
    def __setitem__(self, i, v):
        print i, v
    def __getitem__(self, i):
        print i
        return 0

c = C()
c[4,5] += 1

gives a spurious exception:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: object does not support item assignment

By contrast, "c[(4,5)] += 1" works fine.



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

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-12-18 07:10

Message:
Logged In: YES 
user_id=33168

EXTENDED_ARG problem was fixed a while ago.
The assert/pass problem was fixed with: 41756.

That leaves the LOAD_CONST/POP_TOP optimization that was
lost and one compiler warning: marshal_write_mod() not being
used.

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

Comment By: Michael Hudson (mwh)
Date: 2005-12-11 00:41

Message:
Logged In: YES 
user_id=6656

You have to include those lines in a source file.  It still crashes for me.

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

Comment By: Brett Cannon (bcannon)
Date: 2005-12-10 23:44

Message:
Logged In: YES 
user_id=357491

I just checked Armin's problem code on rev. 41638 and it
worked for me in the interpreter.  You still having
problems, Armin?

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

Comment By: Armin Rigo (arigo)
Date: 2005-12-04 10:30

Message:
Logged In: YES 
user_id=4771

At rev 41584, the following code snippet triggers an assert
if --with-pydebug is enabled:
Python/compile.c:3843: assemble_lnotab: Assertion 'd_lineno >= 0' failed

-----------------------
assert 1, ([s for s in x] +
           [s for s in x])
pass
-----------------------

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-23 19:14

Message:
Logged In: YES 
user_id=33168

Checkpoint of outstanding issues.  I think all the others
mentioned so far have been fixed:

 * Raymond's warnings in compile.c (unused locals are fixed)
 * EXTENDED_ARG problem
 * LOAD_CONST/POP_TOP (note we can fix this in the optimizer
generally which would get rid of other useless code too)


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

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-10-23 04:53

Message:
Logged In: YES 
user_id=80475

FWIW, here are the warnings issued by my compiler:

Python-ast.c
C:\py25\Python\Python-ast.c(1995) : warning C4101: 'i' : 
unreferenced local variable
C:\py25\Python\Python-ast.c(2070) : warning C4101: 'i' : 
unreferenced local variable
C:\py25\Python\Python-ast.c(2085) : warning C4101: 'i' : 
unreferenced local variable
C:\py25\Python\Python-ast.c(2130) : warning C4101: 'i' : 
unreferenced local variable
C:\py25\Python\Python-ast.c(2151) : warning C4101: 'i' : 
unreferenced local variable
C:\py25\Python\Python-ast.c(2261) : warning C4101: 'i' : 
unreferenced local variable
C:\py25\Python\Python-ast.c(2270) : warning C4101: 'i' : 
unreferenced local variable


compile.c
C:\py25\Python\compile.c(3782) : warning C4305: '=' : truncation 
from 'const int ' to 'char '
C:\py25\Python\compile.c(3802) : warning C4305: '=' : truncation 
from 'const int ' to 'char '
C:\py25\Python\compile.c(3806) : warning C4305: '=' : truncation 
from 'const int ' to 'char '


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-22 07:28

Message:
Logged In: YES 
user_id=33168

I assigned to Jeremy and Neil in the hopes they will see
this message and know about these problems.

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

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 12:45

Message:
Logged In: YES 
user_id=4771

The following (similarly strange-looking) code snippets
compiled successfully before, now they give SyntaxErrors:

--------------------
def f():
    class g:
        exec "hi"
        x
--------------------
def f(x):
    class g:
        exec "hi"
        x
--------------------
def f():
    class g:
        from a import *
        x
--------------------
def f(x):
    class g:
        from a import *
        x


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

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 12:33

Message:
Logged In: YES 
user_id=4771

I would suspect the following one to be due to incorrect
handling of EXTENDED_ARG -- it's from a PyPy test about that:

longexpr = 'x = x or ' + '-x' * 2500
code = '''
def f(x):
    %s
    %s
    %s
    %s
    %s
    %s
    %s
    %s
    %s
    %s
    while x:
        x -= 1
        # EXTENDED_ARG/JUMP_ABSOLUTE here
    return x
''' % ((longexpr,)*10)

exec code
f(5)
SystemError: unknown opcode

dis.dis() shows that the target of both the SETUP_LOOP and
the JUMP_IF_FALSE at the start of the loop are wrong.

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

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 12:15

Message:
Logged In: YES 
user_id=4771

The Python rules about which names get mangled are a bit
insane.  I share mwh's view that mangling should never have
been invented in the first place, but well:

>>> def f():
...   __x = 5
...   class X:
...     def g(self):
...       return __x
...   return X
... 
Fatal Python error: unknown scope for _X__x in X(135832776)
in <stdin>


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

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 12:01

Message:
Logged In: YES 
user_id=4771

For reference, an optimization that got lost:

    def f():
        'a'
        'b'

'a' is the docstring, but the 'b' previously did not show
up anywhere in the code object.  Now there is the
LOAD_CONST/POP_TOP pair.

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

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 11:54

Message:
Logged In: YES 
user_id=4771

any reason why lambda functions have a __name__ of
'lambda' now instead of '<lambda>' ?

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

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 10:22

Message:
Logged In: YES 
user_id=4771

import a as b, c

the 'c' part gets completely forgotten and there is
no 'IMPORT_NAME c' in the bytecode.

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

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 10:13

Message:
Logged In: YES 
user_id=4771

A scoping problem (comparing with the old compiler):

class X:
    print hello

The variable 'hello' is incorrectly looked up with
LOAD_GLOBAL instead of LOAD_NAME.  It causes a crash
in PyPy in a case where the name 'hello' is stored
into the class implicitely (via locals()).  It can
probably be discussed if the bug is in PyPy, but it
is a difference in behavior.

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

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

From noreply at sourceforge.net  Mon Jul 10 01:55:44 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 09 Jul 2006 16:55:44 -0700
Subject: [ python-Bugs-1494314 ] Cannot use high-numbered sockets in 2.4.3
Message-ID: <E1Fzj7o-0005oY-UK@sc8-sf-web3.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Smith (mlrsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cannot use high-numbered sockets in 2.4.3

Initial Comment:
Python 2.4.3 introduced (in Modules/socketmodule.c) the
IS_SELECTABLE() macro, to check whether calling
select() on a given file descriptor is permissible.

However, it executes this check even when it won't
actually call select(). Specifically, select() is
called ONLY when s->sock_timeout > 0 (in
internal_select mostly, but also internal_connect).

I have a twisted application which uses many FDs
(several thousand), and upgrading python to 2.4.3 makes
it hit this limit (at 1024 file descriptors),
regardless of ulimit settings. Twisted itself always
uses non-blocking I/O on sockets, so with older
versions of python this worked fine.

A simple solution relies on the fact that select is
only ever actually called, and changes the
IS_SELECTABLE macro as in the attached fairly trivial
patch. This is sufficient to restore my application to
its previous state (where it works fine).

This doesn't solve the more general problem in
socketmodule - that we simply can't do all operations
properly with the current reliance on select(), though,
and it seems like a bit of a hack...  If I wrote up a
patch to use poll() on systems where it's available,
throughout socketmodule.c, in preference to select(),
would this be accepted?

Mike



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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-09 16:55

Message:
Logged In: YES 
user_id=33168

I think you're right Martin.  Looking at what it means to
have a broken poll, I don't think we can in this instance. 
So I removed all refs to HAVE_BROKEN_POLL.  What do you
think of the new version?  

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-07-07 08:50

Message:
Logged In: YES 
user_id=21627

The __APPLE__ stuff looks wrong in file 184131. You would
have to use selectmodule.c:select_have_broken_poll at
run-time to be sure you can use poll(2) on OS X (you can use
it on 10.4, but can't on 10.3, IIRC).

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-06 23:10

Message:
Logged In: YES 
user_id=33168

I've added a more complete patch (against 2.5, hopefully
applies to 2.4 too).  It cleans up some things and adds
support for SSL sockets too.  Can people please review/test
this?  I manually tested this with regular sockets and it
seemed to work.  All the tests pass, but this is somewhat
tricky.  I hate the duplicated code between socket and ssl
modules, but added to it.  It would be great to clean this
up for 2.6.

If you are forced to use select with a high socket, the
exception on connect is operation in progress rather than
can't select on socket.  I guess that's ok, it doesn't
actually change the existing behaviour.  That would have
been more involved and I'm not sure it's worth it.

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

Comment By: Michael Smith (mlrsmith)
Date: 2006-06-09 03:31

Message:
Logged In: YES 
user_id=1488997

Ok, I'll attach a patch that uses poll when available
(HAVE_POLL is already being set by the configure stuff
appropriately).

It replaces one of the two uses of select() (specifically,
the internal_select() function) in socketmodule.c. The other
is win32-specific, so replacing it with poll() wouldn't make
sense.

greg: epoll/kevent don't make sense for replacing the use of
select/poll in this particular case - socketmodule.c always
selects/polls precisely one file descriptor.

I've tested this locally, and it fixes the problem
(linux/x86). I don't have a windows system to test it on,
but it shouldn't change behaviour in any way for windows.



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

Comment By: Gregory P. Smith (greg)
Date: 2006-06-07 22:51

Message:
Logged In: YES 
user_id=413

eew yuck.  yes use poll at the very least.

we should also consider using epoll (linux) and kevent (bsd)
in the future as both of those scale better than O(n) unlike
select and poll.

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-06-04 13:14

Message:
Logged In: YES 
user_id=21627

A patch to replace internal_select with poll(2) where
available is acceptable. The current version should be
conditionally kept. That Windows doesn't have poll(2) is no
problem: its select implementation supports arbitrarily
large FDs (just like poll).

Relaxing the IS_SELECTABLE usage to cases where select is
actually going to be called is optional: there shouldn't be
too many systems left without select where people still want
to open many file descriptors.

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

Comment By: Tim Peters (tim_one)
Date: 2006-05-31 15:27

Message:
Logged In: YES 
user_id=31435

akuchling:  No, poll() is not part of the Windows socket API.

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

Comment By: Michael Smith (mlrsmith)
Date: 2006-05-31 14:39

Message:
Logged In: YES 
user_id=1488997

That, of course, is the problem - select() is available more
or less universally, but poll() is not. However, it's not
terribly difficult to write a poll() wrapper using select(),
though doing so in general would have serious performance
issues (the specific uses in socketmodule.c do not hit this
problem), and retains the limitations of select. 

It's not clear that the complexity of doing this is
worthwhile compared to just implementing the simple API
needed internally to socketmodule.c using both APIs (i.e.
just adding a poll() option).

Regardless, it'd be nice if at least the basic fix I wrote
up went in - it solves the immediate problem, at least.

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

Comment By: A.M. Kuchling (akuchling)
Date: 2006-05-31 11:39

Message:
Logged In: YES 
user_id=11375

I expect such a patch would be acceptable.  The largest
issue is probably whether poll() is available everywhere, or
if we'd be stuck maintaining both select() and poll() based
versions of internal_select().  Does Windows support poll()
at all?

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

Comment By: Michael Smith (mlrsmith)
Date: 2006-05-29 07:13

Message:
Logged In: YES 
user_id=1488997

Yes, I had my ulimit set appropriately.

There's no problem with _opening_ many sockets (at least, I
don't think there is) - the problem is with trying to do
something (like call socket.recv()) with them.

The code in socketmodule.c is pretty clear - and having
upgraded to 2.4.3 with ubuntu dapper, I _am_ running into this.

For now, we're having to keep all our production machines on
2.4.2.


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

Comment By: Gabriel Wicke (gabrielwicke)
Date: 2006-05-29 07:11

Message:
Logged In: YES 
user_id=956757

Please disregard my comments completely- just opening more
than 1024 files does not trigger this bug, but doing a
socket.send() on the 1025th socket does.

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

Comment By: Gabriel Wicke (gabrielwicke)
Date: 2006-05-29 07:00

Message:
Logged In: YES 
user_id=956757

Never mind- you already tried ulimit. It still works for me
though, 2.4.3 from Ubuntu Dapper.

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

Comment By: Gabriel Wicke (gabrielwicke)
Date: 2006-05-29 06:57

Message:
Logged In: YES 
user_id=956757

Try "ulimit -n 8096" (only permitted in a root shell) to set
your max socket usage to something larger. Opening more than
1024 sockets works for me in python 2.4.3 after changing the
limit for the terminal in question and restarting the
interpreter. Just ulimit -n will show you your current
limit. Ulimits are enforced by the Linux kernel and can
likely be configured system-wide in /etc/sysctl.cfg.

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

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

From noreply at sourceforge.net  Mon Jul 10 01:57:49 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 09 Jul 2006 16:57:49 -0700
Subject: [ python-Bugs-1494314 ] Cannot use high-numbered sockets in 2.4.3
Message-ID: <E1Fzj9p-0006wA-OY@sc8-sf-web3.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Smith (mlrsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cannot use high-numbered sockets in 2.4.3

Initial Comment:
Python 2.4.3 introduced (in Modules/socketmodule.c) the
IS_SELECTABLE() macro, to check whether calling
select() on a given file descriptor is permissible.

However, it executes this check even when it won't
actually call select(). Specifically, select() is
called ONLY when s->sock_timeout > 0 (in
internal_select mostly, but also internal_connect).

I have a twisted application which uses many FDs
(several thousand), and upgrading python to 2.4.3 makes
it hit this limit (at 1024 file descriptors),
regardless of ulimit settings. Twisted itself always
uses non-blocking I/O on sockets, so with older
versions of python this worked fine.

A simple solution relies on the fact that select is
only ever actually called, and changes the
IS_SELECTABLE macro as in the attached fairly trivial
patch. This is sufficient to restore my application to
its previous state (where it works fine).

This doesn't solve the more general problem in
socketmodule - that we simply can't do all operations
properly with the current reliance on select(), though,
and it seems like a bit of a hack...  If I wrote up a
patch to use poll() on systems where it's available,
throughout socketmodule.c, in preference to select(),
would this be accepted?

Mike



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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-09 16:57

Message:
Logged In: YES 
user_id=33168

I meant I don't think we *care* in this case (not can).

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-09 16:55

Message:
Logged In: YES 
user_id=33168

I think you're right Martin.  Looking at what it means to
have a broken poll, I don't think we can in this instance. 
So I removed all refs to HAVE_BROKEN_POLL.  What do you
think of the new version?  

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-07-07 08:50

Message:
Logged In: YES 
user_id=21627

The __APPLE__ stuff looks wrong in file 184131. You would
have to use selectmodule.c:select_have_broken_poll at
run-time to be sure you can use poll(2) on OS X (you can use
it on 10.4, but can't on 10.3, IIRC).

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-06 23:10

Message:
Logged In: YES 
user_id=33168

I've added a more complete patch (against 2.5, hopefully
applies to 2.4 too).  It cleans up some things and adds
support for SSL sockets too.  Can people please review/test
this?  I manually tested this with regular sockets and it
seemed to work.  All the tests pass, but this is somewhat
tricky.  I hate the duplicated code between socket and ssl
modules, but added to it.  It would be great to clean this
up for 2.6.

If you are forced to use select with a high socket, the
exception on connect is operation in progress rather than
can't select on socket.  I guess that's ok, it doesn't
actually change the existing behaviour.  That would have
been more involved and I'm not sure it's worth it.

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

Comment By: Michael Smith (mlrsmith)
Date: 2006-06-09 03:31

Message:
Logged In: YES 
user_id=1488997

Ok, I'll attach a patch that uses poll when available
(HAVE_POLL is already being set by the configure stuff
appropriately).

It replaces one of the two uses of select() (specifically,
the internal_select() function) in socketmodule.c. The other
is win32-specific, so replacing it with poll() wouldn't make
sense.

greg: epoll/kevent don't make sense for replacing the use of
select/poll in this particular case - socketmodule.c always
selects/polls precisely one file descriptor.

I've tested this locally, and it fixes the problem
(linux/x86). I don't have a windows system to test it on,
but it shouldn't change behaviour in any way for windows.



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

Comment By: Gregory P. Smith (greg)
Date: 2006-06-07 22:51

Message:
Logged In: YES 
user_id=413

eew yuck.  yes use poll at the very least.

we should also consider using epoll (linux) and kevent (bsd)
in the future as both of those scale better than O(n) unlike
select and poll.

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-06-04 13:14

Message:
Logged In: YES 
user_id=21627

A patch to replace internal_select with poll(2) where
available is acceptable. The current version should be
conditionally kept. That Windows doesn't have poll(2) is no
problem: its select implementation supports arbitrarily
large FDs (just like poll).

Relaxing the IS_SELECTABLE usage to cases where select is
actually going to be called is optional: there shouldn't be
too many systems left without select where people still want
to open many file descriptors.

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

Comment By: Tim Peters (tim_one)
Date: 2006-05-31 15:27

Message:
Logged In: YES 
user_id=31435

akuchling:  No, poll() is not part of the Windows socket API.

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

Comment By: Michael Smith (mlrsmith)
Date: 2006-05-31 14:39

Message:
Logged In: YES 
user_id=1488997

That, of course, is the problem - select() is available more
or less universally, but poll() is not. However, it's not
terribly difficult to write a poll() wrapper using select(),
though doing so in general would have serious performance
issues (the specific uses in socketmodule.c do not hit this
problem), and retains the limitations of select. 

It's not clear that the complexity of doing this is
worthwhile compared to just implementing the simple API
needed internally to socketmodule.c using both APIs (i.e.
just adding a poll() option).

Regardless, it'd be nice if at least the basic fix I wrote
up went in - it solves the immediate problem, at least.

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

Comment By: A.M. Kuchling (akuchling)
Date: 2006-05-31 11:39

Message:
Logged In: YES 
user_id=11375

I expect such a patch would be acceptable.  The largest
issue is probably whether poll() is available everywhere, or
if we'd be stuck maintaining both select() and poll() based
versions of internal_select().  Does Windows support poll()
at all?

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

Comment By: Michael Smith (mlrsmith)
Date: 2006-05-29 07:13

Message:
Logged In: YES 
user_id=1488997

Yes, I had my ulimit set appropriately.

There's no problem with _opening_ many sockets (at least, I
don't think there is) - the problem is with trying to do
something (like call socket.recv()) with them.

The code in socketmodule.c is pretty clear - and having
upgraded to 2.4.3 with ubuntu dapper, I _am_ running into this.

For now, we're having to keep all our production machines on
2.4.2.


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

Comment By: Gabriel Wicke (gabrielwicke)
Date: 2006-05-29 07:11

Message:
Logged In: YES 
user_id=956757

Please disregard my comments completely- just opening more
than 1024 files does not trigger this bug, but doing a
socket.send() on the 1025th socket does.

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

Comment By: Gabriel Wicke (gabrielwicke)
Date: 2006-05-29 07:00

Message:
Logged In: YES 
user_id=956757

Never mind- you already tried ulimit. It still works for me
though, 2.4.3 from Ubuntu Dapper.

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

Comment By: Gabriel Wicke (gabrielwicke)
Date: 2006-05-29 06:57

Message:
Logged In: YES 
user_id=956757

Try "ulimit -n 8096" (only permitted in a root shell) to set
your max socket usage to something larger. Opening more than
1024 sockets works for me in python 2.4.3 after changing the
limit for the terminal in question and restarting the
interpreter. Just ulimit -n will show you your current
limit. Ulimits are enforced by the Linux kernel and can
likely be configured system-wide in /etc/sysctl.cfg.

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

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

From noreply at sourceforge.net  Mon Jul 10 02:04:59 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 09 Jul 2006 17:04:59 -0700
Subject: [ python-Bugs-1512814 ] Incorrect lineno's in code objects
Message-ID: <E1FzjGl-0006qi-DK@sc8-sf-web1.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Thomas Wouters (twouters)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: Incorrect lineno's in code objects

Initial Comment:
The 2.5 compiler forgets how to count linenumbers in
certain situations:

>>> s255 = "".join(["\n"] * 255 + ["spam"])
>>> s256 = "".join(["\n"] * 256 + ["spam"])

>>> exec s255
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 256, in <module>
NameError: name 'spam' is not defined

>>> exec s256
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 1, in <module>
NameError: name 'spam' is not defined

Notice the 'line 1' linenumber in the case of 256 blank
lines. The same happens for 'pass' statements or 'if 0'
blocks instead of blank lines. The problem is in the
actual code objects created:

>>> dis.disco(compile(s255, "", "exec"))
256           0 LOAD_NAME                0 (spam)
              3 POP_TOP             
              4 LOAD_CONST               0 (None)
              7 RETURN_VALUE        
>>> dis.disco(compile(s256, "", "exec"))
  1           0 LOAD_NAME                0 (spam)
              3 POP_TOP             
              4 LOAD_CONST               0 (None)
              7 RETURN_VALUE        



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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-09 17:04

Message:
Logged In: YES 
user_id=33168

Committed revision 50500.


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

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

From noreply at sourceforge.net  Mon Jul 10 02:32:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 09 Jul 2006 17:32:42 -0700
Subject: [ python-Bugs-1518190 ] c_void_pointer should accept a long pointer >
	0x7fffffff
Message-ID: <E1Fzjha-0000tI-HJ@sc8-sf-web2.sourceforge.net>

Bugs item #1518190, was opened at 2006-07-06 07:46
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1518190&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Thomas Heller (theller)
>Assigned to: Thomas Heller (theller)
Summary: c_void_pointer should accept a long pointer > 0x7fffffff

Initial Comment:
Mike Fletcher reported this problem:

http://tinyurl.com/esneq

Currently, the c_void_p constructor calls
PyLong_AsVoidPtr(value), in Modules/_ctypes/cfield.c,
near line 1491.

This call should be changed to use either
PyLong_AsUnsignedLongMask() or
PyLong_AsUnsignedLongLongMask() depending on
sizeof(void *), and cast the result to (void *).

This change would also make the c_void_p behaviour more
consistent with the other c_int, c_long and so on
constructors since all of them mask the value to the
number of bits they can accept.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-09 17:32

Message:
Logged In: YES 
user_id=33168

This patch is fine.  Please try to apply before the freeze
for b2.

Also, please use #elif instead of nested #if.  It makes the
code a little shorter and easier to read.

This looks like a bug fix which is fine, though I'm not sure
of all the consequences of the change.  Be sure to add a
note to Misc/NEWS.


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

Comment By: Thomas Heller (theller)
Date: 2006-07-06 10:03

Message:
Logged In: YES 
user_id=11105

Assigning to Neal for review (please).  The #if block is not
really needed imo, but I used it for clarity - it is copied
verbatim from Objects/longobject.c, which would throw
compile errors if the conditions are not fulfilled.

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

Comment By: Thomas Heller (theller)
Date: 2006-07-06 09:56

Message:
Logged In: YES 
user_id=11105

Attached a patch, with tests, that fixes this bug.
PyInt_AsUnsignedLongMask() and
PyInt_AsUnsignedLongLongMask() is what we need to use.

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

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

From noreply at sourceforge.net  Mon Jul 10 03:11:02 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 09 Jul 2006 18:11:02 -0700
Subject: [ python-Bugs-1515169 ] ImportWarning should be removed
Message-ID: <E1FzkIg-0003kg-UL@sc8-sf-web3.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
>Status: Closed
>Resolution: Later
Priority: 5
Submitted By: James Y Knight (foom)
Assigned to: Nobody/Anonymous (nobody)
Summary: ImportWarning should be removed

Initial Comment:
As discussed in email thread:
http://www.gossamer-threads.com/lists/python/dev/497487

In particular, there are three specific reasons for not having it. I expect 
these reasons to translate to a larger number of specific reasons as 
more people use python 2.5.

1) Ralf's software gets a flood of ImportWarnings
2) Twisted's plugin system uses a directory named "twisted" without an 
__init__.py in it on the python path to store plugins in. Therefore, 
anybody running (importing) twisted will produce annoying warnings.
3) I have a directory in my homedir called "readline".

Quoted from my email:
I just found another reason to dislike the warnings: my homedir on 
one machine has a lot of random directories in it. One of them is 
named "readline". Every time I run python 2.5, it now helpfully notes: 
sys:1: ImportWarning: Not importing directory 'readline': missing 
__init__.py 

It used to be the case that it was very unlikely that running python 
in your homedir would cause issues. Even though the current directory 
is on the default pythonpath, you needed to have either a file ending 
in .py or a directory with an __init__.py with the same name as a 
python module to cause problems. And that is generally unlikely to 
happen. Now, however, you get warnings just by having _any_ directory 
in your CWD with the same name as a python module. That's much 
more 
likely to happen; I can't be the only one who will have this issue. 



Suggested solution: Remove ImportWarning, and make the ImportError 
message say:
>> ImportError: No module named mypackage.foo 
>> Note that subdirectories are searched for imports only if they 
contain an 
>> __init__.py file: http://www.python.org/doc/essays/packages.html 

I really think this should be addressed before 2.5 is released.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-09 18:11

Message:
Logged In: YES 
user_id=33168

The warning is now off by default.  The behaviour will be
revisited for 2.6.  See PEP 361 for 2.6.

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

Comment By: Shane Hathaway (hathawsh)
Date: 2006-06-30 16:17

Message:
Logged In: YES 
user_id=16701

I have submitted a patch (#1515361) that causes
find_module() to only generate these warnings if the import
fails.


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

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

From noreply at sourceforge.net  Mon Jul 10 06:14:11 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 09 Jul 2006 21:14:11 -0700
Subject: [ python-Bugs-1467201 ] size_t warnings on OSX 10.3
Message-ID: <E1Fzn9v-0007N3-92@sc8-sf-web3.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Nobody/Anonymous (nobody)
Summary: size_t warnings on OSX 10.3

Initial Comment:
Building on my mac, running
sam% uname -a
Darwin sam.local 7.9.0 Darwin Kernel Version 7.9.0: Wed
Mar 30 20:11:17 PST 2005;
root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC  Power
Macintosh powerpc
sam% gcc -v
Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs
Thread model: posix
gcc version 3.3 20030304 (Apple Computer, Inc. build 1640)

I get a whole pile of warnings, like the following:
Python/exceptions.c: In function
`UnicodeEncodeError__str__':
Python/exceptions.c:1340: warning: signed size_t
format, Py_ssize_t arg (arg 4)
Python/exceptions.c:1349: warning: signed size_t
format, Py_ssize_t arg (arg 3)
Python/exceptions.c:1349: warning: signed size_t
format, int arg (arg 4)

Attached is full build log. config.status says
"HAVE_SSIZE_T" is defined.
${ac_dA}HAVE_SSIZE_T${ac_dB}HAVE_SSIZE_T${ac_dC}1${ac_dD}


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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-09 21:14

Message:
Logged In: YES 
user_id=33168

Anthony is this still a problem?

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-09 23:30

Message:
Logged In: YES 
user_id=21627

Sure. The question then is: what is ssize_t, as opposed to
size_t.

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

Comment By: Tim Peters (tim_one)
Date: 2006-04-09 18:56

Message:
Logged In: YES 
user_id=31435

Since Anthony reported that config.status says HAVE_SSIZE_T
is defined, doesn't

#ifdef HAVE_SSIZE_T
typedef ssize_t		Py_ssize_t;

in pyport.h rule here?  Pretty bizarre, if so :-)

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-09 14:02

Message:
Logged In: YES 
user_id=21627

Can you find out what Py_ssize_t is eventually defined as
(i.e. how is ssize_t defined); how is size_t defined
(looking at the preprocessor output might help)? What type
would the compiler accept for a signed size_t format?

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

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

From noreply at sourceforge.net  Mon Jul 10 06:14:32 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 09 Jul 2006 21:14:32 -0700
Subject: [ python-Bugs-1467450 ] test_ctypes fails on OSX 10.3
Message-ID: <E1FznAG-0008KN-SP@sc8-sf-web5.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Thomas Heller (theller)
Summary: test_ctypes fails on OSX 10.3

Initial Comment:
test test_ctypes failed -- Traceback (most recent call
last):
  File
"/Users/anthonybaxter/python/Lib/ctypes/test/test_loading.py",
line 30, in test_load
    cdll.load(libc_name)
  File
"/Users/anthonybaxter/python/Lib/ctypes/_loader.py",
line 112, in load
    return self._load(libname, mode)
  File
"/Users/anthonybaxter/python/Lib/ctypes/_loader.py",
line 153, in _load
    return self.load_library(pathname, mode)
  File
"/Users/anthonybaxter/python/Lib/ctypes/_loader.py",
line 124, in load_library
    return self._dlltype(libname, mode)
  File
"/Users/anthonybaxter/python/Lib/ctypes/__init__.py",
line 288, in __init__
    self._handle = _dlopen(self._name, mode)
OSError: dlcompat: unable to open this file with RTLD_LOCAL

This happens both with and without the patch in r43748.

Darwin sam.local 7.9.0 Darwin Kernel Version 7.9.0: Wed
Mar 30 20:11:17 PST 2005;
root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC  Power
Macintosh powerpc

GCC version:
Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs
Thread model: posix
gcc version 3.3 20030304 (Apple Computer, Inc. build 1640)


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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-09 21:14

Message:
Logged In: YES 
user_id=33168

Anthony is this still a problem?

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

Comment By: Thomas Heller (theller)
Date: 2006-05-09 11:38

Message:
Logged In: YES 
user_id=11105

Does this failure still occur with Python 2.5a2, or the
current SVN trunk?

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

Comment By: Thomas Heller (theller)
Date: 2006-04-12 23:59

Message:
Logged In: YES 
user_id=11105

I'm trying to get a copy of OS X 10.3, then will try to
install it and look after this problem.
OTOH, the ctypes loading code is currently rewritten in the
upstream version - this will probably prevent this failure.

In the meantime, can you try to find out the cause of this
failure?  Would RTLD_GLOBAL instead of RTLD_LOCAL work? Is
the library file missing?

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

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

From noreply at sourceforge.net  Mon Jul 10 07:47:04 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 09 Jul 2006 22:47:04 -0700
Subject: [ python-Bugs-1494314 ] Cannot use high-numbered sockets in 2.4.3
Message-ID: <E1Fzobo-0006Ch-V4@sc8-sf-web5.sourceforge.net>

Bugs item #1494314, was opened at 2006-05-24 15:51
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494314&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.4
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Michael Smith (mlrsmith)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: Cannot use high-numbered sockets in 2.4.3

Initial Comment:
Python 2.4.3 introduced (in Modules/socketmodule.c) the
IS_SELECTABLE() macro, to check whether calling
select() on a given file descriptor is permissible.

However, it executes this check even when it won't
actually call select(). Specifically, select() is
called ONLY when s->sock_timeout > 0 (in
internal_select mostly, but also internal_connect).

I have a twisted application which uses many FDs
(several thousand), and upgrading python to 2.4.3 makes
it hit this limit (at 1024 file descriptors),
regardless of ulimit settings. Twisted itself always
uses non-blocking I/O on sockets, so with older
versions of python this worked fine.

A simple solution relies on the fact that select is
only ever actually called, and changes the
IS_SELECTABLE macro as in the attached fairly trivial
patch. This is sufficient to restore my application to
its previous state (where it works fine).

This doesn't solve the more general problem in
socketmodule - that we simply can't do all operations
properly with the current reliance on select(), though,
and it seems like a bit of a hack...  If I wrote up a
patch to use poll() on systems where it's available,
throughout socketmodule.c, in preference to select(),
would this be accepted?

Mike



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

>Comment By: Martin v. L??wis (loewis)
Date: 2006-07-10 07:47

Message:
Logged In: YES 
user_id=21627

The patch is fine, please apply.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-10 01:57

Message:
Logged In: YES 
user_id=33168

I meant I don't think we *care* in this case (not can).

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-10 01:55

Message:
Logged In: YES 
user_id=33168

I think you're right Martin.  Looking at what it means to
have a broken poll, I don't think we can in this instance. 
So I removed all refs to HAVE_BROKEN_POLL.  What do you
think of the new version?  

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-07-07 17:50

Message:
Logged In: YES 
user_id=21627

The __APPLE__ stuff looks wrong in file 184131. You would
have to use selectmodule.c:select_have_broken_poll at
run-time to be sure you can use poll(2) on OS X (you can use
it on 10.4, but can't on 10.3, IIRC).

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-07 08:10

Message:
Logged In: YES 
user_id=33168

I've added a more complete patch (against 2.5, hopefully
applies to 2.4 too).  It cleans up some things and adds
support for SSL sockets too.  Can people please review/test
this?  I manually tested this with regular sockets and it
seemed to work.  All the tests pass, but this is somewhat
tricky.  I hate the duplicated code between socket and ssl
modules, but added to it.  It would be great to clean this
up for 2.6.

If you are forced to use select with a high socket, the
exception on connect is operation in progress rather than
can't select on socket.  I guess that's ok, it doesn't
actually change the existing behaviour.  That would have
been more involved and I'm not sure it's worth it.

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

Comment By: Michael Smith (mlrsmith)
Date: 2006-06-09 12:31

Message:
Logged In: YES 
user_id=1488997

Ok, I'll attach a patch that uses poll when available
(HAVE_POLL is already being set by the configure stuff
appropriately).

It replaces one of the two uses of select() (specifically,
the internal_select() function) in socketmodule.c. The other
is win32-specific, so replacing it with poll() wouldn't make
sense.

greg: epoll/kevent don't make sense for replacing the use of
select/poll in this particular case - socketmodule.c always
selects/polls precisely one file descriptor.

I've tested this locally, and it fixes the problem
(linux/x86). I don't have a windows system to test it on,
but it shouldn't change behaviour in any way for windows.



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

Comment By: Gregory P. Smith (greg)
Date: 2006-06-08 07:51

Message:
Logged In: YES 
user_id=413

eew yuck.  yes use poll at the very least.

we should also consider using epoll (linux) and kevent (bsd)
in the future as both of those scale better than O(n) unlike
select and poll.

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

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

Message:
Logged In: YES 
user_id=21627

A patch to replace internal_select with poll(2) where
available is acceptable. The current version should be
conditionally kept. That Windows doesn't have poll(2) is no
problem: its select implementation supports arbitrarily
large FDs (just like poll).

Relaxing the IS_SELECTABLE usage to cases where select is
actually going to be called is optional: there shouldn't be
too many systems left without select where people still want
to open many file descriptors.

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

Comment By: Tim Peters (tim_one)
Date: 2006-06-01 00:27

Message:
Logged In: YES 
user_id=31435

akuchling:  No, poll() is not part of the Windows socket API.

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

Comment By: Michael Smith (mlrsmith)
Date: 2006-05-31 23:39

Message:
Logged In: YES 
user_id=1488997

That, of course, is the problem - select() is available more
or less universally, but poll() is not. However, it's not
terribly difficult to write a poll() wrapper using select(),
though doing so in general would have serious performance
issues (the specific uses in socketmodule.c do not hit this
problem), and retains the limitations of select. 

It's not clear that the complexity of doing this is
worthwhile compared to just implementing the simple API
needed internally to socketmodule.c using both APIs (i.e.
just adding a poll() option).

Regardless, it'd be nice if at least the basic fix I wrote
up went in - it solves the immediate problem, at least.

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

Comment By: A.M. Kuchling (akuchling)
Date: 2006-05-31 20:39

Message:
Logged In: YES 
user_id=11375

I expect such a patch would be acceptable.  The largest
issue is probably whether poll() is available everywhere, or
if we'd be stuck maintaining both select() and poll() based
versions of internal_select().  Does Windows support poll()
at all?

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

Comment By: Michael Smith (mlrsmith)
Date: 2006-05-29 16:13

Message:
Logged In: YES 
user_id=1488997

Yes, I had my ulimit set appropriately.

There's no problem with _opening_ many sockets (at least, I
don't think there is) - the problem is with trying to do
something (like call socket.recv()) with them.

The code in socketmodule.c is pretty clear - and having
upgraded to 2.4.3 with ubuntu dapper, I _am_ running into this.

For now, we're having to keep all our production machines on
2.4.2.


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

Comment By: Gabriel Wicke (gabrielwicke)
Date: 2006-05-29 16:11

Message:
Logged In: YES 
user_id=956757

Please disregard my comments completely- just opening more
than 1024 files does not trigger this bug, but doing a
socket.send() on the 1025th socket does.

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

Comment By: Gabriel Wicke (gabrielwicke)
Date: 2006-05-29 16:00

Message:
Logged In: YES 
user_id=956757

Never mind- you already tried ulimit. It still works for me
though, 2.4.3 from Ubuntu Dapper.

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

Comment By: Gabriel Wicke (gabrielwicke)
Date: 2006-05-29 15:57

Message:
Logged In: YES 
user_id=956757

Try "ulimit -n 8096" (only permitted in a root shell) to set
your max socket usage to something larger. Opening more than
1024 sockets works for me in python 2.4.3 after changing the
limit for the terminal in question and restarting the
interpreter. Just ulimit -n will show you your current
limit. Ulimits are enforced by the Linux kernel and can
likely be configured system-wide in /etc/sysctl.cfg.

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

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

From noreply at sourceforge.net  Mon Jul 10 08:25:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 09 Jul 2006 23:25:24 -0700
Subject: [ python-Bugs-1519786 ] AttributeError in the shelve module
Message-ID: <E1FzpCu-00063D-HH@sc8-sf-web6.sourceforge.net>

Bugs item #1519786, was opened at 2006-07-09 23: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=1519786&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin Kelly (aomighty)
Assigned to: Nobody/Anonymous (nobody)
Summary: AttributeError in the shelve module

Initial Comment:
This is Python 2.4.4 on Debian Etch.

Look at the following interpreter session:

    Python 2.4.4c0 (#2, Jun 14 2006, 22:35:41)
    [GCC 4.1.2 20060613 (prerelease) (Debian 4.1.1-4)]
        on linux2
    Type "help", "copyright", "credits" or "license"
for more information.
    >>> import shelve
    >>> import anydbm
    >>> try:
    ...     shelve.open('nonexistent', 'r')
    ... except anydbm.error:
    ...     print 'caught it'
    ... 
    caught it
    Exception exceptions.AttributeError:
"DbfilenameShelf instance has no
    attribute 'writeback'" in  ignored
    >>> anydbm.error
    (<class anydbm.error at 0xb7f48bfc>,
     <class bsddb._db.DBError at 0xb7f5623c>,
     <class gdbm.error at 0xb7f48cbc>,
     <class dbm.error at 0xb7f5b38c>,
     <class exceptions.IOError at 0xb7f774ac>)
    >>>

Shelf.__del__() calls Shelf.close() calls Shelf.sync()
which
references self.writeback even though that attribute
doesn't exist.
It also references self.dict which also doesn't exist.

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

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

From noreply at sourceforge.net  Mon Jul 10 08:50:50 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 09 Jul 2006 23:50:50 -0700
Subject: [ python-Bugs-1519786 ] AttributeError in the shelve module
Message-ID: <E1FzpbW-0001jw-3x@sc8-sf-web4.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.4
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Martin Kelly (aomighty)
Assigned to: Nobody/Anonymous (nobody)
Summary: AttributeError in the shelve module

Initial Comment:
This is Python 2.4.4 on Debian Etch.

Look at the following interpreter session:

    Python 2.4.4c0 (#2, Jun 14 2006, 22:35:41)
    [GCC 4.1.2 20060613 (prerelease) (Debian 4.1.1-4)]
        on linux2
    Type "help", "copyright", "credits" or "license"
for more information.
    >>> import shelve
    >>> import anydbm
    >>> try:
    ...     shelve.open('nonexistent', 'r')
    ... except anydbm.error:
    ...     print 'caught it'
    ... 
    caught it
    Exception exceptions.AttributeError:
"DbfilenameShelf instance has no
    attribute 'writeback'" in  ignored
    >>> anydbm.error
    (<class anydbm.error at 0xb7f48bfc>,
     <class bsddb._db.DBError at 0xb7f5623c>,
     <class gdbm.error at 0xb7f48cbc>,
     <class dbm.error at 0xb7f5b38c>,
     <class exceptions.IOError at 0xb7f774ac>)
    >>>

Shelf.__del__() calls Shelf.close() calls Shelf.sync()
which
references self.writeback even though that attribute
doesn't exist.
It also references self.dict which also doesn't exist.

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

>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-10 06:50

Message:
Logged In: YES 
user_id=849994

Thanks for reporting. This was already fixed in SVN head.

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

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

From noreply at sourceforge.net  Mon Jul 10 09:37:33 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 10 Jul 2006 00:37:33 -0700
Subject: [ python-Bugs-1513611 ] xml.sax.ParseException weirdness in python
	2.5b1
Message-ID: <E1FzqKj-0000KV-9M@sc8-sf-web3.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: XML
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Marien Zwart (marienz)
Assigned to: Nobody/Anonymous (nobody)
Summary: xml.sax.ParseException weirdness in python 2.5b1

Initial Comment:
There is something weird going on with xml.sax
exceptions, probably related to the xml/xmlcore shuffle:

from xml.sax import make_parser, SAXParseException
from StringIO import StringIO

parser = make_parser()

try:
    parser.parse(StringIO('invalid'))
except SAXParseException:
    print 'caught it!'

On python 2.4.3 this prints "caught it!". On python
2.5b1 the exception is not caught, because it is a
different  exception: an
xmlcore.sax._exceptions.SAXParseException. Printing the
SAXParseException imported from xml.sax gives "<class
'xml.sax._exceptions.SAXParseException'>".

Stumbled on this running the logilab-common (see
logilab.org) tests with python 2.5b1, but it seems
likely other code will be affected.

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

Comment By: ?iga Seilnacht (zseil)
Date: 2006-07-10 09:37

Message:
Logged In: YES 
user_id=1326842

This bug is simmilar to http://python.org/sf/1511497.
It is caused by absolute imports in xmlcore.sax.expatreader.
Patch #1519796 ( http://python.org/sf/1519796 )
should fix it.

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

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

From noreply at sourceforge.net  Mon Jul 10 09:38:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 10 Jul 2006 00:38:24 -0700
Subject: [ python-Bugs-1511497 ] xml.sax.expatreader is missing
Message-ID: <E1FzqLY-0008Tm-Pa@sc8-sf-web6.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: XML
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Wummel (calvin)
Assigned to: Nobody/Anonymous (nobody)
Summary: xml.sax.expatreader is missing

Initial Comment:
Hi,

when testing the new Python 2.5 subversion tree I
encountered this behaviour:
$ python2.5
Python 2.5b1 (trunk:47065, Jun 22 2006, 20:56:23) 
[GCC 4.1.2 20060613 (prerelease) (Debian 4.1.1-5)] on
linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import xml.sax.expatreader
>>> print xml.sax.expatreader
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute
'expatreader'
>>> 

So the import went ok, but using the attribute gave an
error. This is very strange. Python 2.4 did not have
this behaviour.

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

Comment By: ?iga Seilnacht (zseil)
Date: 2006-07-10 09:38

Message:
Logged In: YES 
user_id=1326842

See patch #1519796:
http://python.org/sf/1519796

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

Comment By: ?iga Seilnacht (zseil)
Date: 2006-06-27 00:52

Message:
Logged In: YES 
user_id=1326842

I see the same behaviour with the official Python 2.5
beta 1 Windows installer. The interesting thing is that
the expatreader module is present in sys.modules:

Python 2.5b1 (r25b1:47027, Jun 20 2006, 09:31:33)
[MSC v.1310 32 bit (Intel)] on win32
...
>>> import xml.sax.expatreader
>>> xml.sax.expatreader
Traceback (most recent call last):
  ...
AttributeError: 'module' object has no attribute 'expatreader'
>>> import sys
>>> sys.modules['xml.sax.expatreader']
<module 'xml.sax.expatreader' from
'...\lib\xmlcore\sax\expatreader.pyc'>

All of the other modules in xml package can be imported
without any trouble.
I don't understand what is the real problem here,
but it goes away if you import xmlcore.sax package
before expatreader:

[restart python]
>>> import xmlcore.sax
>>> import xml.sax.expatreader
>>> xml.sax.expatreader
<module 'xml.sax.expatreader' from
'...\lib\xmlcore\sax\expatreader.pyc'>

The simplest fix would be to use at least one absolute
import in ...\lib\xmlcore\sax\__init__.py, for example
you could change line 22:

from xmlreader import InputSource

to:

from xmlcore.sax.xmlreader import InputSource

but that might just hide the real bug.

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

Comment By: Wummel (calvin)
Date: 2006-06-26 20:15

Message:
Logged In: YES 
user_id=9205

I built Python directly from the SVN trunk repository with
$ ./configure && make altinstall
I attached the pyconfig.h that was generated. If you need
more info, feel free to ask.

After building and installing, I started up python2.5 and
executed "import xml.sax.expatreader" and then "print
xml.sax.expatreader", and nothing else.

Another thing I tried is "import from", which works.
But importing xml.sax.expatreader directly, as noted above,
does not work.

Here is the log with the "import from" test:
Python 2.5b1 (trunk:47090, Jun 25 2006, 09:59:02) 
[GCC 4.1.2 20060613 (prerelease) (Debian 4.1.1-5)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> from xml.sax import expatreader
>>> print expatreader
<module 'xml.sax.expatreader' from
'/usr/local/lib/python2.5/xmlcore/sax/expatreader.pyc'>
>>> print xml.sax.expatreader
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'expatreader'


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

Comment By: Martin v. L??wis (loewis)
Date: 2006-06-24 12:39

Message:
Logged In: YES 
user_id=21627

How precisely did you test it? What configure options did
you set up, what commands did you provide to build Python?

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

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

From noreply at sourceforge.net  Mon Jul 10 10:13:39 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 10 Jul 2006 01:13:39 -0700
Subject: [ python-Bugs-1467450 ] test_ctypes fails on OSX 10.3
Message-ID: <E1Fzqtf-0002i2-LX@sc8-sf-web1.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Thomas Heller (theller)
Summary: test_ctypes fails on OSX 10.3

Initial Comment:
test test_ctypes failed -- Traceback (most recent call
last):
  File
"/Users/anthonybaxter/python/Lib/ctypes/test/test_loading.py",
line 30, in test_load
    cdll.load(libc_name)
  File
"/Users/anthonybaxter/python/Lib/ctypes/_loader.py",
line 112, in load
    return self._load(libname, mode)
  File
"/Users/anthonybaxter/python/Lib/ctypes/_loader.py",
line 153, in _load
    return self.load_library(pathname, mode)
  File
"/Users/anthonybaxter/python/Lib/ctypes/_loader.py",
line 124, in load_library
    return self._dlltype(libname, mode)
  File
"/Users/anthonybaxter/python/Lib/ctypes/__init__.py",
line 288, in __init__
    self._handle = _dlopen(self._name, mode)
OSError: dlcompat: unable to open this file with RTLD_LOCAL

This happens both with and without the patch in r43748.

Darwin sam.local 7.9.0 Darwin Kernel Version 7.9.0: Wed
Mar 30 20:11:17 PST 2005;
root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC  Power
Macintosh powerpc

GCC version:
Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs
Thread model: posix
gcc version 3.3 20030304 (Apple Computer, Inc. build 1640)


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

>Comment By: Thomas Heller (theller)
Date: 2006-07-10 10:13

Message:
Logged In: YES 
user_id=11105

Here is a patch that I hope will fix this problem.  Ronald
Oussuren suggested in private email to use RTLD_GLOBAL as
default library loading mode on OS X 10.3.  He suggested to
use the platform module to find out the osx version, however
I don't like.  Instead I found by examining platform that
gestalt.gestalt("sysv") returns the information I need.

I still don't have access to 10.3 (and Python does not
compile on the 10.2.8 sourceforge osx compile farm machine -
should I add a bug for that one?), so I cannot really test
the patch myself.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-10 06:14

Message:
Logged In: YES 
user_id=33168

Anthony is this still a problem?

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

Comment By: Thomas Heller (theller)
Date: 2006-05-09 20:38

Message:
Logged In: YES 
user_id=11105

Does this failure still occur with Python 2.5a2, or the
current SVN trunk?

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

Comment By: Thomas Heller (theller)
Date: 2006-04-13 08:59

Message:
Logged In: YES 
user_id=11105

I'm trying to get a copy of OS X 10.3, then will try to
install it and look after this problem.
OTOH, the ctypes loading code is currently rewritten in the
upstream version - this will probably prevent this failure.

In the meantime, can you try to find out the cause of this
failure?  Would RTLD_GLOBAL instead of RTLD_LOCAL work? Is
the library file missing?

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

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

From noreply at sourceforge.net  Mon Jul 10 10:29:56 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 10 Jul 2006 01:29:56 -0700
Subject: [ python-Bugs-1519816 ] Proxy does not work in 2.4.3
Message-ID: <E1Fzr9Q-0008Ho-2Y@sc8-sf-web5.sourceforge.net>

Bugs item #1519816, was opened at 2006-07-10 10: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=1519816&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Michal Niklas (mniklas)
Assigned to: Nobody/Anonymous (nobody)
Summary: Proxy does not work in 2.4.3

Initial Comment:
My python app had to retrieve some web pages and while 
our network environment requires proxy it uses urllib2 
opener (source is in attachment). It worked very well 
on older Python interpreters:
ActivePython 2.4.2 Build 248 (ActiveState Corp.) based 
on
Python 2.4.2 (#67, Oct 30 2005, 16:11:18) [MSC v.1310 
32 bit (Intel)] on win32

It works on linux with 2.3 and 2.4.1:
Python 2.4.1 (#2, May 5 2005, 11:32:06)
[GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2

But it does not work with newest 2.4.3 on Linux:
Python 2.4.3 (#1, Jul 10 2006, 09:57:52)
[GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2

Desired result:
isof-mark:~# python2.3 proxy_bug.py
trying http://www.python.org ...
OK.  We have reply from http://www.python.org.
Size: 13757 [b]
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 
Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/
xhtml1-transitional.dtd">
<html lang="en" xml:lang="en" xmlns="http://www.w3.org/
1999/xhtml">
<head>
<me
...
 Yorkshire">design by pollenation</a>
</div>
Copyright ???? 1990-2006, <a href="psf">Python Software 
Foundation</a><br />
<a href="about/legal">Legal Statements</a>
</div>
</div>
</div>
</body>
</html>


isof-mark:~# /usr/local/bin/python proxy_bug.py
trying http://www.python.org ...
Traceback (most recent call last):
  File "proxy_bug.py", line 37, in ?
    get_page()
  File "proxy_bug.py", line 27, in get_page
    f = urllib2.urlopen(request)
  File "/usr/local/lib/python2.4/urllib2.py", line 
130, in urlopen
    return _opener.open(url, data)
  File "/usr/local/lib/python2.4/urllib2.py", line 
364, in open
    response = meth(req, response)
  File "/usr/local/lib/python2.4/urllib2.py", line 
471, in http_response
    response = self.parent.error(
  File "/usr/local/lib/python2.4/urllib2.py", line 
402, in error
    return self._call_chain(*args)
  File "/usr/local/lib/python2.4/urllib2.py", line 
337, in _call_chain
    result = func(*args)
  File "/usr/local/lib/python2.4/urllib2.py", line 
480, in http_error_default
    raise HTTPError(req.get_full_url(), code, msg, 
hdrs, fp)
urllib2.HTTPError: HTTP Error 407: Proxy 
Authentication Required

I have raported it on ActiveState bug list (http://
bugs.activestate.com/show_bug.cgi?id=47018) while I 
first spot this bug on their destribution but it seems 
that bug is in others distributions too.

Regards,
Michal Niklas


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

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

From noreply at sourceforge.net  Mon Jul 10 10:41:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 10 Jul 2006 01:41:05 -0700
Subject: [ python-Bugs-1519816 ] Proxy does not work in 2.4.3
Message-ID: <E1FzrKD-0004pA-OT@sc8-sf-web5.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Michal Niklas (mniklas)
Assigned to: Nobody/Anonymous (nobody)
Summary: Proxy does not work in 2.4.3

Initial Comment:
My python app had to retrieve some web pages and while 
our network environment requires proxy it uses urllib2 
opener (source is in attachment). It worked very well 
on older Python interpreters:
ActivePython 2.4.2 Build 248 (ActiveState Corp.) based 
on
Python 2.4.2 (#67, Oct 30 2005, 16:11:18) [MSC v.1310 
32 bit (Intel)] on win32

It works on linux with 2.3 and 2.4.1:
Python 2.4.1 (#2, May 5 2005, 11:32:06)
[GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2

But it does not work with newest 2.4.3 on Linux:
Python 2.4.3 (#1, Jul 10 2006, 09:57:52)
[GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2

Desired result:
isof-mark:~# python2.3 proxy_bug.py
trying http://www.python.org ...
OK.  We have reply from http://www.python.org.
Size: 13757 [b]
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 
Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/
xhtml1-transitional.dtd">
<html lang="en" xml:lang="en" xmlns="http://www.w3.org/
1999/xhtml">
<head>
<me
...
 Yorkshire">design by pollenation</a>
</div>
Copyright ???? 1990-2006, <a href="psf">Python Software 
Foundation</a><br />
<a href="about/legal">Legal Statements</a>
</div>
</div>
</div>
</body>
</html>


isof-mark:~# /usr/local/bin/python proxy_bug.py
trying http://www.python.org ...
Traceback (most recent call last):
  File "proxy_bug.py", line 37, in ?
    get_page()
  File "proxy_bug.py", line 27, in get_page
    f = urllib2.urlopen(request)
  File "/usr/local/lib/python2.4/urllib2.py", line 
130, in urlopen
    return _opener.open(url, data)
  File "/usr/local/lib/python2.4/urllib2.py", line 
364, in open
    response = meth(req, response)
  File "/usr/local/lib/python2.4/urllib2.py", line 
471, in http_response
    response = self.parent.error(
  File "/usr/local/lib/python2.4/urllib2.py", line 
402, in error
    return self._call_chain(*args)
  File "/usr/local/lib/python2.4/urllib2.py", line 
337, in _call_chain
    result = func(*args)
  File "/usr/local/lib/python2.4/urllib2.py", line 
480, in http_error_default
    raise HTTPError(req.get_full_url(), code, msg, 
hdrs, fp)
urllib2.HTTPError: HTTP Error 407: Proxy 
Authentication Required

I have raported it on ActiveState bug list (http://
bugs.activestate.com/show_bug.cgi?id=47018) while I 
first spot this bug on their destribution but it seems 
that bug is in others distributions too.

Regards,
Michal Niklas


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

>Comment By: Michal Niklas (mniklas)
Date: 2006-07-10 10:41

Message:
Logged In: YES 
user_id=226518

Cannot add attachment via upload so I put it here:
#!/usr/bin/python
# -*- coding: cp1250 -*-

import urllib
import urllib2

def get_page():
	url = 'http://www.python.org'
	print "trying %s ..." % (url)

	# Setup proxy & authentication
	proxy = "poczta.heuthes:8080"
	usr1 = "USER"
	pass1 = "PASSWD"
	proxy_handler = urllib2.ProxyHandler({"http" : "http:/
/" + proxy})
	pass_mgr = urllib2.HTTPPasswordMgrWithDefaultRealm()
	pass_mgr.add_password(None, "http://" + proxy, usr1, 
pass1)
	pass_mgr.add_password(None, proxy, usr1, pass1)
	auth_handler = urllib2.HTTPBasicAuthHandler(pass_mgr)
	proxy_auth_handler = 
urllib2.ProxyBasicAuthHandler(pass_mgr)

	# Now build a new URL opener and install it
	opener = urllib2.build_opener(proxy_handler, 
proxy_auth_handler, auth_handler, urllib2.HTTPHandler)
	urllib2.install_opener(opener)

	request = urllib2.Request(url)
	f = urllib2.urlopen(request)
	data = f.read()
	print "OK.  We have reply from %s.\nSize: %d [b]" % 
(url, len(data))
	if len(data) < 400:
		print data
	else:
		print data[:200]
		print "..."
		print data[-200:]

get_page()


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

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

From noreply at sourceforge.net  Mon Jul 10 11:07:49 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 10 Jul 2006 02:07:49 -0700
Subject: [ python-Bugs-1467450 ] test_ctypes fails on OSX 10.3
Message-ID: <E1Fzrk5-0004SC-5d@sc8-sf-web4.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Thomas Heller (theller)
Summary: test_ctypes fails on OSX 10.3

Initial Comment:
test test_ctypes failed -- Traceback (most recent call
last):
  File
"/Users/anthonybaxter/python/Lib/ctypes/test/test_loading.py",
line 30, in test_load
    cdll.load(libc_name)
  File
"/Users/anthonybaxter/python/Lib/ctypes/_loader.py",
line 112, in load
    return self._load(libname, mode)
  File
"/Users/anthonybaxter/python/Lib/ctypes/_loader.py",
line 153, in _load
    return self.load_library(pathname, mode)
  File
"/Users/anthonybaxter/python/Lib/ctypes/_loader.py",
line 124, in load_library
    return self._dlltype(libname, mode)
  File
"/Users/anthonybaxter/python/Lib/ctypes/__init__.py",
line 288, in __init__
    self._handle = _dlopen(self._name, mode)
OSError: dlcompat: unable to open this file with RTLD_LOCAL

This happens both with and without the patch in r43748.

Darwin sam.local 7.9.0 Darwin Kernel Version 7.9.0: Wed
Mar 30 20:11:17 PST 2005;
root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC  Power
Macintosh powerpc

GCC version:
Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs
Thread model: posix
gcc version 3.3 20030304 (Apple Computer, Inc. build 1640)


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

>Comment By: Thomas Heller (theller)
Date: 2006-07-10 11:07

Message:
Logged In: YES 
user_id=11105

Even better would imo be to call the Gestalt function in the
_ctypes extensions module itself.

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

Comment By: Thomas Heller (theller)
Date: 2006-07-10 10:13

Message:
Logged In: YES 
user_id=11105

Here is a patch that I hope will fix this problem.  Ronald
Oussuren suggested in private email to use RTLD_GLOBAL as
default library loading mode on OS X 10.3.  He suggested to
use the platform module to find out the osx version, however
I don't like.  Instead I found by examining platform that
gestalt.gestalt("sysv") returns the information I need.

I still don't have access to 10.3 (and Python does not
compile on the 10.2.8 sourceforge osx compile farm machine -
should I add a bug for that one?), so I cannot really test
the patch myself.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-10 06:14

Message:
Logged In: YES 
user_id=33168

Anthony is this still a problem?

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

Comment By: Thomas Heller (theller)
Date: 2006-05-09 20:38

Message:
Logged In: YES 
user_id=11105

Does this failure still occur with Python 2.5a2, or the
current SVN trunk?

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

Comment By: Thomas Heller (theller)
Date: 2006-04-13 08:59

Message:
Logged In: YES 
user_id=11105

I'm trying to get a copy of OS X 10.3, then will try to
install it and look after this problem.
OTOH, the ctypes loading code is currently rewritten in the
upstream version - this will probably prevent this failure.

In the meantime, can you try to find out the cause of this
failure?  Would RTLD_GLOBAL instead of RTLD_LOCAL work? Is
the library file missing?

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

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

From noreply at sourceforge.net  Mon Jul 10 11:12:22 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 10 Jul 2006 02:12:22 -0700
Subject: [ python-Bugs-1518190 ] c_void_pointer should accept a long pointer >
	0x7fffffff
Message-ID: <E1FzroU-0001JC-4j@sc8-sf-web5.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Thomas Heller (theller)
Summary: c_void_pointer should accept a long pointer > 0x7fffffff

Initial Comment:
Mike Fletcher reported this problem:

http://tinyurl.com/esneq

Currently, the c_void_p constructor calls
PyLong_AsVoidPtr(value), in Modules/_ctypes/cfield.c,
near line 1491.

This call should be changed to use either
PyLong_AsUnsignedLongMask() or
PyLong_AsUnsignedLongLongMask() depending on
sizeof(void *), and cast the result to (void *).

This change would also make the c_void_p behaviour more
consistent with the other c_int, c_long and so on
constructors since all of them mask the value to the
number of bits they can accept.

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

>Comment By: Thomas Heller (theller)
Date: 2006-07-10 11:12

Message:
Logged In: YES 
user_id=11105

Committed as r50513.

Neal, I'm not sure I got the #elif instead of #if issue as
you were requesting it, if not, feel free to fix that yourself.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-10 02:32

Message:
Logged In: YES 
user_id=33168

This patch is fine.  Please try to apply before the freeze
for b2.

Also, please use #elif instead of nested #if.  It makes the
code a little shorter and easier to read.

This looks like a bug fix which is fine, though I'm not sure
of all the consequences of the change.  Be sure to add a
note to Misc/NEWS.


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

Comment By: Thomas Heller (theller)
Date: 2006-07-06 19:03

Message:
Logged In: YES 
user_id=11105

Assigning to Neal for review (please).  The #if block is not
really needed imo, but I used it for clarity - it is copied
verbatim from Objects/longobject.c, which would throw
compile errors if the conditions are not fulfilled.

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

Comment By: Thomas Heller (theller)
Date: 2006-07-06 18:56

Message:
Logged In: YES 
user_id=11105

Attached a patch, with tests, that fixes this bug.
PyInt_AsUnsignedLongMask() and
PyInt_AsUnsignedLongLongMask() is what we need to use.

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

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

From noreply at sourceforge.net  Mon Jul 10 11:43:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 10 Jul 2006 02:43:05 -0700
Subject: [ python-Bugs-1467450 ] test_ctypes fails on OSX 10.3
Message-ID: <E1FzsID-0005qN-Km@sc8-sf-web5.sourceforge.net>

Bugs item #1467450, was opened at 2006-04-10 11:21
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467450&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Thomas Heller (theller)
Summary: test_ctypes fails on OSX 10.3

Initial Comment:
test test_ctypes failed -- Traceback (most recent call
last):
  File
"/Users/anthonybaxter/python/Lib/ctypes/test/test_loading.py",
line 30, in test_load
    cdll.load(libc_name)
  File
"/Users/anthonybaxter/python/Lib/ctypes/_loader.py",
line 112, in load
    return self._load(libname, mode)
  File
"/Users/anthonybaxter/python/Lib/ctypes/_loader.py",
line 153, in _load
    return self.load_library(pathname, mode)
  File
"/Users/anthonybaxter/python/Lib/ctypes/_loader.py",
line 124, in load_library
    return self._dlltype(libname, mode)
  File
"/Users/anthonybaxter/python/Lib/ctypes/__init__.py",
line 288, in __init__
    self._handle = _dlopen(self._name, mode)
OSError: dlcompat: unable to open this file with RTLD_LOCAL

This happens both with and without the patch in r43748.

Darwin sam.local 7.9.0 Darwin Kernel Version 7.9.0: Wed
Mar 30 20:11:17 PST 2005;
root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC  Power
Macintosh powerpc

GCC version:
Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs
Thread model: posix
gcc version 3.3 20030304 (Apple Computer, Inc. build 1640)


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

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-07-10 19:43

Message:
Logged In: YES 
user_id=29957

I'm not going to get the opportunity to look at this before
the b2 freeze tomorrow morning, but will look at it soon after.



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

Comment By: Thomas Heller (theller)
Date: 2006-07-10 19:07

Message:
Logged In: YES 
user_id=11105

Even better would imo be to call the Gestalt function in the
_ctypes extensions module itself.

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

Comment By: Thomas Heller (theller)
Date: 2006-07-10 18:13

Message:
Logged In: YES 
user_id=11105

Here is a patch that I hope will fix this problem.  Ronald
Oussuren suggested in private email to use RTLD_GLOBAL as
default library loading mode on OS X 10.3.  He suggested to
use the platform module to find out the osx version, however
I don't like.  Instead I found by examining platform that
gestalt.gestalt("sysv") returns the information I need.

I still don't have access to 10.3 (and Python does not
compile on the 10.2.8 sourceforge osx compile farm machine -
should I add a bug for that one?), so I cannot really test
the patch myself.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-10 14:14

Message:
Logged In: YES 
user_id=33168

Anthony is this still a problem?

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

Comment By: Thomas Heller (theller)
Date: 2006-05-10 04:38

Message:
Logged In: YES 
user_id=11105

Does this failure still occur with Python 2.5a2, or the
current SVN trunk?

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

Comment By: Thomas Heller (theller)
Date: 2006-04-13 16:59

Message:
Logged In: YES 
user_id=11105

I'm trying to get a copy of OS X 10.3, then will try to
install it and look after this problem.
OTOH, the ctypes loading code is currently rewritten in the
upstream version - this will probably prevent this failure.

In the meantime, can you try to find out the cause of this
failure?  Would RTLD_GLOBAL instead of RTLD_LOCAL work? Is
the library file missing?

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

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

From noreply at sourceforge.net  Mon Jul 10 13:08:21 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 10 Jul 2006 04:08:21 -0700
Subject: [ python-Bugs-1510172 ] Absolute/relative import not working?
Message-ID: <E1Fztcj-0002CJ-R6@sc8-sf-web2.sourceforge.net>

Bugs item #1510172, was opened at 2006-06-22 05:35
Message generated for change (Settings changed) made by ncoghlan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510172&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
>Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Submitted By: Mitch Chapman (mitchchapman)
Assigned to: Nick Coghlan (ncoghlan)
Summary: Absolute/relative import not working?

Initial Comment:
Trying to import from a module using dotted import syntax produces 
this exception:

ValueError: Relative importpath too deep

This behavior has been confirmed on Mac OS X 10.4 using the Python 
2.5b1 disk image; and on CentOS 4 using the Python 2.5b1 source 
tarball.

The exception is raised regardless of whether the PYTHONPATH 
environment variable can see the toplevel directory of the package 
being tested; regardless of whether the import is performed from an 
interactive Python session or from a script invoked from the command 
line; and regardless of whether the main script starts with

from __future__ import absolute_import

To test, I tried to re-create the package structure used as an example 
in PEP 328.  (See attachments.)

Most of the files were empty, except moduleX.py and moduleY.py:

#moduleX.py:
from __future__ import absolute_import

from .moduleY import spam

#moduleY.py:
spam = "spam"

According to the PEP, if should be possible to import moduleX without 
error.  But I get the above exception whenever I try to import moduleX 
or to run it from the command line.

$ python2.5 moduleX.py 
Traceback (most recent call last):
  File "moduleX.py", line 3, in <module>
    from .moduleY import spam
ValueError: Relative importpath too deep


Is this a usage/documentation error?


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

>Comment By: Nick Coghlan (ncoghlan)
Date: 2006-07-10 21:08

Message:
Logged In: YES 
user_id=1038590

Punting on this until 2.6. See updated PEP 338 for the gory
details.

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

Comment By: Nick Coghlan (ncoghlan)
Date: 2006-07-01 02:51

Message:
Logged In: YES 
user_id=1038590

Patch attached that allows relative imports from a main
module to work so long as:
  a. the top level package is either in the current
directory or somewhere else on sys.path; and
  b. the module is executed using -m so Python knows where
it fits in the package hierarchy

So to get the PEP 328 example to work, you'd have to run it as:

$python2.5 -m package.subpackage1.moduleX

The patch relies on a feature added to runpy in rev 47142
(post beta 1). I've added a question to PEP 356 as to how
this should be handled, since we're technically in feature
freeze.

Patch attached directly to the bug report because it's
stupidly early in the morning and I don't feel like dealing
with SF and then copying the patch tracker number here :)

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

Comment By: Nick Coghlan (ncoghlan)
Date: 2006-06-27 21:46

Message:
Logged In: YES 
user_id=1038590

All that said, PEP 328 currently says that "from ...sys
import path" should be legal from moduleX in the example.

I tried it, and it currently fails - the ValueError gets
raised as soon as the number of dots in the relative path
exceeds the number of dots in __name__, instead of treating
a single excess dot as requesting an absolute import
instead. (All of the other examples in the PEP work as
specified when moduleX and subpackage1 are imported rather
than executed directly)

I believe fixing this would also fix Mitch's problem - an
explicit relative import from __main__ would be treated as a
top level import.

I also have an idea regarding the -m switch that I will
raise on python-dev.

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

Comment By: Nick Coghlan (ncoghlan)
Date: 2006-06-27 21:34

Message:
Logged In: YES 
user_id=1038590

The issue isn't actually unique to the -m switch - the
problem is that relative imports are based on __name__, and
in the main module, __name__ always has the value
'__main__'. Hence, relative imports currently can't work
properly from the main module of an application, because the
main module doesn't know where it really fits in the Python
module namespace (this is at least fixable in theory for the
 main modules executed through the -m switch, but directly
executed files and the interactive interpreter are
completely out of luck).

With the old implicit relative imports this behaviour is
masked by the fact that executing a module puts that
module's directory on sys.path. When you execute a module in
a package directly, it actually imports its sibling modules
as top-level modules. The fact that the -m switch doesn't
allow this to occur is a deliberate design decision (putting
package directories on the system level path is a bad idea
because you can get multiple copies of the same module under
different names).

You should be able get something similar to the old implicit
relative import behaviour by sticking the following at the
top of your module (before doing any relative imports):

if __name__ = '__main__':
   from os.path import dirname
   __path__ = [dirname(__file__)]
   del dirname

This makes the relative import machinery treat your main
module as a package. The problem with this workaround is
that, just like the old situation with implicit relative
imports from the main module, you may end up with two
different copies of the sibling modules in sys.modules. One
copy will be '__main__.foo' while the other will be
'package.foo' (with implicit relative imports, the first
copy would have been a top level module called 'foo').

When I went to document this, I got stuck on the fact that
section 6 of the tutorial hasn't been updated for PEP 328 at
*all*. And the language ref palms the details off on to
Guido's packages essay. So describing the limitation in the
real documentation entails documenting PEP 328 properly in
the first place (which I'm *not* volunteering to do :).

However, I'll add a section to PEP 328 about '__main__' and
relative imports (including the workaround to get something
similar to the old behaviour back).


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-06-27 14:41

Message:
Logged In: YES 
user_id=33168

http://mail.python.org/pipermail/python-dev/2006-June/066197.html

Nick you made mention of changing the docs, but I'm not sure
if you did or not.  Could you address this bug?  Thanks.

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

Comment By: Thomas Wouters (twouters)
Date: 2006-06-23 23:52

Message:
Logged In: YES 
user_id=34209

See the discussion started at:
http://mail.python.org/pipermail/python-dev/2006-June/066161.html

It's not a bug in 328 or 338 (the PEP that adds the -m
switch for packages), but in the interaction between the
two. I don't think this will be fixed for 2.5, since there
is no obvious fix. If it hurts when you press there, don't
press there. Either don't use -m for packaged modules, or
have the packaged module only use absolute imports. (But
don't be surprised if the script-module is imported twice,
once as __main__ and once as the module itself. That's a
whole other bug/feature.)





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

Comment By: Mitch Chapman (mitchchapman)
Date: 2006-06-22 09:57

Message:
Logged In: YES 
user_id=348188

Hm... but the same error occurs if one tries to import moduleX from an 
interactive Python session, or from a sibling module.

In other words, in 2.5b1 any module which uses relative imports can be used 
only as a fully-qualified member of a package.  It cannot be imported directly 
by a sibling module, and it cannot be used as a main module at all:

$ python2.5 -m package.subpackage1.moduleX
...
    from .moduleY import spam
ValueError: Relative importpath too deep

Given other efforts (PEP 299; PEP 338) to make it easier to use modules both 
as mainlines and as imports, I still think this is a bug.


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

Comment By: ?iga Seilnacht (zseil)
Date: 2006-06-22 08:59

Message:
Logged In: YES 
user_id=1326842

I think this is a usage error. The problem is that
you run moduleX as a script. This puts the module's
directory as the first entry in sys.path (see
http://docs.python.org/dev/lib/module-sys.html#l2h-5058
for detais).
As a consequence, moduleX is recognised as a top
level module, not as part of a package.

If you want to test relative import, try opening an
interactive shell in the directory where `package`
resides, and type:

>>> from package.subpackage1 import moduleX
>>> moduleX.spam
'spam'


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

Comment By: Mark Nottingham (mnot)
Date: 2006-06-22 07:16

Message:
Logged In: YES 
user_id=21868

Seeing the same behaviour; OSX with the installer.

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

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

From noreply at sourceforge.net  Mon Jul 10 14:49:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 10 Jul 2006 05:49:05 -0700
Subject: [ python-Bugs-1519816 ] urllib2 proxy does not work in 2.4.3
Message-ID: <E1FzvCD-000710-Jj@sc8-sf-web4.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Michal Niklas (mniklas)
Assigned to: Nobody/Anonymous (nobody)
>Summary: urllib2 proxy does not work in 2.4.3

Initial Comment:
My python app had to retrieve some web pages and while 
our network environment requires proxy it uses urllib2 
opener (source is in attachment). It worked very well 
on older Python interpreters:
ActivePython 2.4.2 Build 248 (ActiveState Corp.) based 
on
Python 2.4.2 (#67, Oct 30 2005, 16:11:18) [MSC v.1310 
32 bit (Intel)] on win32

It works on linux with 2.3 and 2.4.1:
Python 2.4.1 (#2, May 5 2005, 11:32:06)
[GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2

But it does not work with newest 2.4.3 on Linux:
Python 2.4.3 (#1, Jul 10 2006, 09:57:52)
[GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2

Desired result:
isof-mark:~# python2.3 proxy_bug.py
trying http://www.python.org ...
OK.  We have reply from http://www.python.org.
Size: 13757 [b]
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 
Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/
xhtml1-transitional.dtd">
<html lang="en" xml:lang="en" xmlns="http://www.w3.org/
1999/xhtml">
<head>
<me
...
 Yorkshire">design by pollenation</a>
</div>
Copyright ???? 1990-2006, <a href="psf">Python Software 
Foundation</a><br />
<a href="about/legal">Legal Statements</a>
</div>
</div>
</div>
</body>
</html>


isof-mark:~# /usr/local/bin/python proxy_bug.py
trying http://www.python.org ...
Traceback (most recent call last):
  File "proxy_bug.py", line 37, in ?
    get_page()
  File "proxy_bug.py", line 27, in get_page
    f = urllib2.urlopen(request)
  File "/usr/local/lib/python2.4/urllib2.py", line 
130, in urlopen
    return _opener.open(url, data)
  File "/usr/local/lib/python2.4/urllib2.py", line 
364, in open
    response = meth(req, response)
  File "/usr/local/lib/python2.4/urllib2.py", line 
471, in http_response
    response = self.parent.error(
  File "/usr/local/lib/python2.4/urllib2.py", line 
402, in error
    return self._call_chain(*args)
  File "/usr/local/lib/python2.4/urllib2.py", line 
337, in _call_chain
    result = func(*args)
  File "/usr/local/lib/python2.4/urllib2.py", line 
480, in http_error_default
    raise HTTPError(req.get_full_url(), code, msg, 
hdrs, fp)
urllib2.HTTPError: HTTP Error 407: Proxy 
Authentication Required

I have raported it on ActiveState bug list (http://
bugs.activestate.com/show_bug.cgi?id=47018) while I 
first spot this bug on their destribution but it seems 
that bug is in others distributions too.

Regards,
Michal Niklas


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

>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-10 12:49

Message:
Logged In: YES 
user_id=849994

Can you please try with 2.5b1? A lot of urllib2 related bugs
have been fixed before this release.

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

Comment By: Michal Niklas (mniklas)
Date: 2006-07-10 08:41

Message:
Logged In: YES 
user_id=226518

Cannot add attachment via upload so I put it here:
#!/usr/bin/python
# -*- coding: cp1250 -*-

import urllib
import urllib2

def get_page():
	url = 'http://www.python.org'
	print "trying %s ..." % (url)

	# Setup proxy & authentication
	proxy = "poczta.heuthes:8080"
	usr1 = "USER"
	pass1 = "PASSWD"
	proxy_handler = urllib2.ProxyHandler({"http" : "http:/
/" + proxy})
	pass_mgr = urllib2.HTTPPasswordMgrWithDefaultRealm()
	pass_mgr.add_password(None, "http://" + proxy, usr1, 
pass1)
	pass_mgr.add_password(None, proxy, usr1, pass1)
	auth_handler = urllib2.HTTPBasicAuthHandler(pass_mgr)
	proxy_auth_handler = 
urllib2.ProxyBasicAuthHandler(pass_mgr)

	# Now build a new URL opener and install it
	opener = urllib2.build_opener(proxy_handler, 
proxy_auth_handler, auth_handler, urllib2.HTTPHandler)
	urllib2.install_opener(opener)

	request = urllib2.Request(url)
	f = urllib2.urlopen(request)
	data = f.read()
	print "OK.  We have reply from %s.\nSize: %d [b]" % 
(url, len(data))
	if len(data) < 400:
		print data
	else:
		print data[:200]
		print "..."
		print data[-200:]

get_page()


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

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

From noreply at sourceforge.net  Mon Jul 10 21:05:27 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 10 Jul 2006 12:05:27 -0700
Subject: [ python-Bugs-1516184 ] inspect.py: still infinite recursion
	inspecting frames
Message-ID: <E1G014R-0000Tw-18@sc8-sf-web2.sourceforge.net>

Bugs item #1516184, was opened at 2006-07-03 08:39
Message generated for change (Comment added) made by pje
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1516184&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Don Quijote (dq_searchlores)
Assigned to: Phillip J. Eby (pje)
Summary: inspect.py: still infinite recursion inspecting frames

Initial Comment:
Using python 2.5 beta 1 on Windows XP, and py2exe 0.6.5.

After packing and compressing a project via py2exe,
there's still an infinite recursion involving functions
getsourcefile, getmodule and getabsfile in module
inspect.py.

I was able to fix this infinite recursion by

1) changing the declaration of getabsfile & getmodule to:
def getabsfile(object, filename=None):
def getmodule(object, filename=None):

2) including the "filename" parameter in all calls to
getabsfile inside of function getmodule.

3) having getabsfile return the absolute and normalized
filename if not null.

Perhaps this change helps to clean up the 'ugliness'
introduced in version 45822.

Kind regards,
Don Quijote 

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

>Comment By: Phillip J. Eby (pje)
Date: 2006-07-10 19:05

Message:
Logged In: YES 
user_id=56214

Fixed in revision 50526.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-05 01:53

Message:
Logged In: YES 
user_id=33168

Phillip any comments?

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

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

From noreply at sourceforge.net  Mon Jul 10 21:18:59 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 10 Jul 2006 12:18:59 -0700
Subject: [ python-Bugs-1457312 ] AttributeError in upload_file on interrupted
	connection
Message-ID: <E1G01HX-00061T-OC@sc8-sf-web2.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Stefan Behnel (scoder)
Assigned to: Phillip J. Eby (pje)
Summary: AttributeError in upload_file on interrupted connection

Initial Comment:
I got the following error when my network interface
went down while I was uploading a file to PyPI:

---------------------------------
Traceback (most recent call last):
  File "setup.py", line 109, in ?
    classifiers = [
  File "/usr/lib64/python2.4/distutils/core.py", line
149, in setup
    dist.run_commands()
  File "/usr/lib64/python2.4/distutils/dist.py", line
946, in run_commands
    self.run_command(cmd)
  File "/usr/lib64/python2.4/distutils/dist.py", line
966, in run_command
    cmd_obj.run()
  File
"/usr/lib64/python2.4/site-packages/setuptools-0.6a10-py2.4.egg/setuptools/command/upload.py",
line 65, in run
    self.upload_file(command, pyversion, filename)
  File
"/usr/lib64/python2.4/site-packages/setuptools-0.6a10-py2.4.egg/setuptools/command/upload.py",
line 158, in upload_file
    self.announce(e.msg, log.ERROR)
AttributeError: error instance has no attribute 'msg'
---------------------------------

I was told that these setuptools files were copied from
Py2.5 distutils, that's why I'm reporting the error here.


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

>Comment By: Phillip J. Eby (pje)
Date: 2006-07-10 19:18

Message:
Logged In: YES 
user_id=56214

Fixed in revision 50528.

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

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

From noreply at sourceforge.net  Mon Jul 10 21:49:26 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 10 Jul 2006 12:49:26 -0700
Subject: [ python-Bugs-1520176 ] non-uniform behavior in 'startswith' /
	'endswith'
Message-ID: <E1G01l0-0004B0-M9@sc8-sf-web5.sourceforge.net>

Bugs item #1520176, was opened at 2006-07-10 19: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=1520176&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Milind (t-milich)
Assigned to: Nobody/Anonymous (nobody)
Summary: non-uniform behavior in  'startswith' / 'endswith'

Initial Comment:
compare the two versions of 'endswith'.
Either  both of them should throw TypeErorr or both 
should return boolean value. 


>>> 'abc'.endswith( ('abc',None))

True

>>> 'abc'.endswith( ('abc',None),4,3)

Traceback (most recent call last):

  File "<stdin>", line 1, in <module>

TypeError: expected a character buffer object



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

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

From noreply at sourceforge.net  Mon Jul 10 22:12:18 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 10 Jul 2006 13:12:18 -0700
Subject: [ python-Bugs-1446119 ] subprocess interpreted double quotation wrong
	on windows
Message-ID: <E1G0278-0000Ea-Ce@sc8-sf-web6.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: simon (simonhang)
Assigned to: Peter ?
strand (astrand)
Summary: subprocess interpreted double quotation wrong on windows

Initial Comment:
If we run below python command
print subprocess.Popen([r'c:\test.bat', 
r'test"string:']).pid
Actually c:\test.bat test\"string\" is executed.
Module subprocess doesn't interpret double quotation 
mark right. Back slash shouldn't be added.

I believe problem is in function 
subprocess.list2cmdline.


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

>Comment By: Peter ?
strand (astrand)
Date: 2006-07-10 22:12

Message:
Logged In: YES 
user_id=344921

As far as I can tell, there's nothing wrong with
subprocess.list2cmdline. Take a look at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccelng/htm/progs_12.asp.
There, you will find:

ab"c

which corresponds to:

"ab\"c"

In other words: a backslash should be added when converting
from an argument to a string. Or do you intepret the MS web
page differently?


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

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

From noreply at sourceforge.net  Mon Jul 10 22:15:11 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 10 Jul 2006 13:15:11 -0700
Subject: [ python-Bugs-1520176 ] non-uniform behavior in 'startswith' /
	'endswith'
Message-ID: <E1G029v-0006Yx-67@sc8-sf-web5.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Milind (t-milich)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: non-uniform behavior in  'startswith' / 'endswith'

Initial Comment:
compare the two versions of 'endswith'.
Either  both of them should throw TypeErorr or both 
should return boolean value. 


>>> 'abc'.endswith( ('abc',None))

True

>>> 'abc'.endswith( ('abc',None),4,3)

Traceback (most recent call last):

  File "<stdin>", line 1, in <module>

TypeError: expected a character buffer object



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

>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-10 20:15

Message:
Logged In: YES 
user_id=849994

The current code shortcuts if it finds a match, so I think
this is not a bug. Raymond?

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

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

From noreply at sourceforge.net  Mon Jul 10 22:30:20 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 10 Jul 2006 13:30:20 -0700
Subject: [ python-Bugs-1444408 ] subprocess test cases fail with
	noexec-mounted /tmp
Message-ID: <E1G02Oa-0004Yu-BT@sc8-sf-web5.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Python Library
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Wummel (calvin)
Assigned to: Peter ?
strand (astrand)
Summary: subprocess test cases fail with noexec-mounted /tmp

Initial Comment:
Hi,

on my Linux box two subprocess tests always fail (see
below for a log output).
The reason is those two tests try to execute files
created with tempfile.mkstemp(), which generates files
in /tmp. And my /tmp directory forbids to execute
files, it is mounted with the "noexec" option.

What I expected from the tests is to either find a
temporary directory where execution is allowed (eg. the
directory where sys.executable lies), or simply skip
those tests.


Test output:
[...]
======================================================================
ERROR: test_args_string
(test.test_subprocess.ProcessTestCase)     
----------------------------------------------------------------------
Traceback (most recent call last):                    
            
  File
"/home/calvin/src/python-svn/Lib/test/test_subprocess.py",
line 490, in test_args_string
    p = subprocess.Popen(fname)
  File "/home/calvin/src/python-svn/Lib/subprocess.py",
line 580, in __init__
    errread, errwrite)
  File "/home/calvin/src/python-svn/Lib/subprocess.py",
line 1033, in _execute_child
    raise child_exception
OSError: [Errno 13] Permission denied

======================================================================
ERROR: test_call_string
(test.test_subprocess.ProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/home/calvin/src/python-svn/Lib/test/test_subprocess.py",
line 532, in test_call_string
    rc = subprocess.call(fname)
  File "/home/calvin/src/python-svn/Lib/subprocess.py",
line 431, in call
    return Popen(*popenargs, **kwargs).wait()
  File "/home/calvin/src/python-svn/Lib/subprocess.py",
line 580, in __init__
    errread, errwrite)
  File "/home/calvin/src/python-svn/Lib/subprocess.py",
line 1033, in _execute_child
    raise child_exception
OSError: [Errno 13] Permission denied


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

>Comment By: Peter ?
strand (astrand)
Date: 2006-07-10 22:30

Message:
Logged In: YES 
user_id=344921

The directory with sys.executable is certainly not
guaranteed to be writable. For example, when I run the test
suite with the Python shipped with my Linux distribution,
os.path.dirname(sys.executable) is /usr/bin, which I cannot
write to. So, I don't like this patch. 

Having /tmp mounted with "noexec" is just stupid, IMHO.
Which Linux distribution does this?

I do have some experience with working around "noexec"
mounts and my experience is that /tmp is "as good as it
gets". If someone can prove me wrong, then we can think of
patching test_subprocess, but until that, I'm going to close
this bug. 


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

Comment By: Wummel (calvin)
Date: 2006-03-16 17:20

Message:
Logged In: YES 
user_id=9205

I attached a patch that creates temp files in the directory
of sys.executable. This directory is guaranteed to have
executable permissions, and should also have write
permissions (since sys.executable should have been generated
from a previous make run).

With the patch the test case runs ok.

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

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

From noreply at sourceforge.net  Mon Jul 10 22:33:11 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 10 Jul 2006 13:33:11 -0700
Subject: [ python-Bugs-1376309 ] subprocess.CalledProcessError uses errno
	incorrectly
Message-ID: <E1G02RL-0000w8-TY@sc8-sf-web6.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 2.5
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Michael Hoffman (hoffmanm)
Assigned to: Peter ?
strand (astrand)
Summary: subprocess.CalledProcessError uses errno incorrectly

Initial Comment:
I have some code which uses subprocess.check_call(),
which is buried in other code that catches an OSError,
and does different things depending on OSError.errno.
Since subprocess.CalledProcessError overloads errno for
its own return code values, this leads to confusing
error messages.

The return code is NOT an errno, and I do not think
this field should be overloaded in this way.
Additionally, since OSError exceptions generally have
an errno attribute set, and exception-handling code
expects this, I do not think that CalledProcessError
should subclass from it.

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

>Comment By: Peter ?
strand (astrand)
Date: 2006-07-10 22:33

Message:
Logged In: YES 
user_id=344921

Duplicate of 1223937. 

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

Comment By: Michael Hoffman (hoffmanm)
Date: 2005-12-08 15:27

Message:
Logged In: YES 
user_id=987664

Ugh, this was supposed to be a bug, not a patch. Is there
anyway to change this or should I just resumbit?

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

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

From noreply at sourceforge.net  Mon Jul 10 22:34:15 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 10 Jul 2006 13:34:15 -0700
Subject: [ python-Bugs-1223937 ] subprocess.py abuse of errno
Message-ID: <E1G02SN-0006DK-CV@sc8-sf-web5.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Oren Tirosh (orenti)
Assigned to: Peter ?
strand (astrand)
Summary: subprocess.py abuse of errno

Initial Comment:
The CalledProcessError exception's .errno attribute is
set to a child process return code which is not an
errno. Any attempt to look up this number with
os.strerror() or errno.errorcode[] will result in
meaningless output. This can break existing code that
catches OSError and does not expect CalledProcessError.

Possible resolutions:

1. Don't make CalledProcessError a subclass of OSError
2. If CalledProcessError stays a subclass of OSError
.errno should be set to some specific meaningful value
(which one? add new value to errnomodule.c?) and use a
separate attribute for the child process return code.


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

>Comment By: Peter ?
strand (astrand)
Date: 2006-07-10 22:34

Message:
Logged In: YES 
user_id=344921

Bug 1376309 has been marked as a duplicate of this bug. 

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

Comment By: Peter ?
strand (astrand)
Date: 2005-06-21 22:13

Message:
Logged In: YES 
user_id=344921

I've changed my mind, since CalledProcessError is only in
the development version of Python. Perhaps it's acceptable
to change the API after all, then. Re-opening. 

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

Comment By: Peter ?
strand (astrand)
Date: 2005-06-21 17:52

Message:
Logged In: YES 
user_id=344921

In hindsight, CalledProcessError should perhaps have been
designed some other way. But now when we have it, it's not
easy to change it. 

It all comes down to what is the documented behaviour and
not. As far as I understand, there's no requirement that the
errno number or an OSError should be possible to look up
with os.strerror(). I cannot find anything about this at
http://docs.python.org/lib/module-exceptions.html, at least.
All it says is "[errno is] assumed to be an error number". 

In my opinion, code should be prepared for "unknown" error
numbers. So currently, I'm not prepared to make any changes
to CalledProcessError. (If you disagree with me, post to
python-dev and see what others think.)

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

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

From noreply at sourceforge.net  Tue Jul 11 00:53:38 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 10 Jul 2006 15:53:38 -0700
Subject: [ python-Bugs-1223937 ] subprocess.py abuse of errno
Message-ID: <E1G04dG-0001MX-OK@sc8-sf-web2.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Oren Tirosh (orenti)
Assigned to: Peter ?
strand (astrand)
Summary: subprocess.py abuse of errno

Initial Comment:
The CalledProcessError exception's .errno attribute is
set to a child process return code which is not an
errno. Any attempt to look up this number with
os.strerror() or errno.errorcode[] will result in
meaningless output. This can break existing code that
catches OSError and does not expect CalledProcessError.

Possible resolutions:

1. Don't make CalledProcessError a subclass of OSError
2. If CalledProcessError stays a subclass of OSError
.errno should be set to some specific meaningful value
(which one? add new value to errnomodule.c?) and use a
separate attribute for the child process return code.


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

>Comment By: Peter ?
strand (astrand)
Date: 2006-07-11 00:53

Message:
Logged In: YES 
user_id=344921

If we fix this before Python 2.5, I guess we don't need to
think about backwards compatibility. See the attached patch
for a suggested solution. 

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

Comment By: Peter ?
strand (astrand)
Date: 2006-07-10 22:34

Message:
Logged In: YES 
user_id=344921

Bug 1376309 has been marked as a duplicate of this bug. 

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

Comment By: Peter ?
strand (astrand)
Date: 2005-06-21 22:13

Message:
Logged In: YES 
user_id=344921

I've changed my mind, since CalledProcessError is only in
the development version of Python. Perhaps it's acceptable
to change the API after all, then. Re-opening. 

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

Comment By: Peter ?
strand (astrand)
Date: 2005-06-21 17:52

Message:
Logged In: YES 
user_id=344921

In hindsight, CalledProcessError should perhaps have been
designed some other way. But now when we have it, it's not
easy to change it. 

It all comes down to what is the documented behaviour and
not. As far as I understand, there's no requirement that the
errno number or an OSError should be possible to look up
with os.strerror(). I cannot find anything about this at
http://docs.python.org/lib/module-exceptions.html, at least.
All it says is "[errno is] assumed to be an error number". 

In my opinion, code should be prepared for "unknown" error
numbers. So currently, I'm not prepared to make any changes
to CalledProcessError. (If you disagree with me, post to
python-dev and see what others think.)

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

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

From noreply at sourceforge.net  Tue Jul 11 04:53:13 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 10 Jul 2006 19:53:13 -0700
Subject: [ python-Bugs-1494314 ] Cannot use high-numbered sockets in 2.4.3
Message-ID: <E1G08N7-0004aM-6Y@sc8-sf-web3.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Michael Smith (mlrsmith)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Cannot use high-numbered sockets in 2.4.3

Initial Comment:
Python 2.4.3 introduced (in Modules/socketmodule.c) the
IS_SELECTABLE() macro, to check whether calling
select() on a given file descriptor is permissible.

However, it executes this check even when it won't
actually call select(). Specifically, select() is
called ONLY when s->sock_timeout > 0 (in
internal_select mostly, but also internal_connect).

I have a twisted application which uses many FDs
(several thousand), and upgrading python to 2.4.3 makes
it hit this limit (at 1024 file descriptors),
regardless of ulimit settings. Twisted itself always
uses non-blocking I/O on sockets, so with older
versions of python this worked fine.

A simple solution relies on the fact that select is
only ever actually called, and changes the
IS_SELECTABLE macro as in the attached fairly trivial
patch. This is sufficient to restore my application to
its previous state (where it works fine).

This doesn't solve the more general problem in
socketmodule - that we simply can't do all operations
properly with the current reliance on select(), though,
and it seems like a bit of a hack...  If I wrote up a
patch to use poll() on systems where it's available,
throughout socketmodule.c, in preference to select(),
would this be accepted?

Mike



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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-10 19:53

Message:
Logged In: YES 
user_id=33168

Anthony checked this in to 2.5 as 50567.  I will backport at
least part of it later.

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-07-09 22:47

Message:
Logged In: YES 
user_id=21627

The patch is fine, please apply.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-09 16:57

Message:
Logged In: YES 
user_id=33168

I meant I don't think we *care* in this case (not can).

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-09 16:55

Message:
Logged In: YES 
user_id=33168

I think you're right Martin.  Looking at what it means to
have a broken poll, I don't think we can in this instance. 
So I removed all refs to HAVE_BROKEN_POLL.  What do you
think of the new version?  

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-07-07 08:50

Message:
Logged In: YES 
user_id=21627

The __APPLE__ stuff looks wrong in file 184131. You would
have to use selectmodule.c:select_have_broken_poll at
run-time to be sure you can use poll(2) on OS X (you can use
it on 10.4, but can't on 10.3, IIRC).

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-06 23:10

Message:
Logged In: YES 
user_id=33168

I've added a more complete patch (against 2.5, hopefully
applies to 2.4 too).  It cleans up some things and adds
support for SSL sockets too.  Can people please review/test
this?  I manually tested this with regular sockets and it
seemed to work.  All the tests pass, but this is somewhat
tricky.  I hate the duplicated code between socket and ssl
modules, but added to it.  It would be great to clean this
up for 2.6.

If you are forced to use select with a high socket, the
exception on connect is operation in progress rather than
can't select on socket.  I guess that's ok, it doesn't
actually change the existing behaviour.  That would have
been more involved and I'm not sure it's worth it.

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

Comment By: Michael Smith (mlrsmith)
Date: 2006-06-09 03:31

Message:
Logged In: YES 
user_id=1488997

Ok, I'll attach a patch that uses poll when available
(HAVE_POLL is already being set by the configure stuff
appropriately).

It replaces one of the two uses of select() (specifically,
the internal_select() function) in socketmodule.c. The other
is win32-specific, so replacing it with poll() wouldn't make
sense.

greg: epoll/kevent don't make sense for replacing the use of
select/poll in this particular case - socketmodule.c always
selects/polls precisely one file descriptor.

I've tested this locally, and it fixes the problem
(linux/x86). I don't have a windows system to test it on,
but it shouldn't change behaviour in any way for windows.



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

Comment By: Gregory P. Smith (greg)
Date: 2006-06-07 22:51

Message:
Logged In: YES 
user_id=413

eew yuck.  yes use poll at the very least.

we should also consider using epoll (linux) and kevent (bsd)
in the future as both of those scale better than O(n) unlike
select and poll.

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-06-04 13:14

Message:
Logged In: YES 
user_id=21627

A patch to replace internal_select with poll(2) where
available is acceptable. The current version should be
conditionally kept. That Windows doesn't have poll(2) is no
problem: its select implementation supports arbitrarily
large FDs (just like poll).

Relaxing the IS_SELECTABLE usage to cases where select is
actually going to be called is optional: there shouldn't be
too many systems left without select where people still want
to open many file descriptors.

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

Comment By: Tim Peters (tim_one)
Date: 2006-05-31 15:27

Message:
Logged In: YES 
user_id=31435

akuchling:  No, poll() is not part of the Windows socket API.

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

Comment By: Michael Smith (mlrsmith)
Date: 2006-05-31 14:39

Message:
Logged In: YES 
user_id=1488997

That, of course, is the problem - select() is available more
or less universally, but poll() is not. However, it's not
terribly difficult to write a poll() wrapper using select(),
though doing so in general would have serious performance
issues (the specific uses in socketmodule.c do not hit this
problem), and retains the limitations of select. 

It's not clear that the complexity of doing this is
worthwhile compared to just implementing the simple API
needed internally to socketmodule.c using both APIs (i.e.
just adding a poll() option).

Regardless, it'd be nice if at least the basic fix I wrote
up went in - it solves the immediate problem, at least.

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

Comment By: A.M. Kuchling (akuchling)
Date: 2006-05-31 11:39

Message:
Logged In: YES 
user_id=11375

I expect such a patch would be acceptable.  The largest
issue is probably whether poll() is available everywhere, or
if we'd be stuck maintaining both select() and poll() based
versions of internal_select().  Does Windows support poll()
at all?

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

Comment By: Michael Smith (mlrsmith)
Date: 2006-05-29 07:13

Message:
Logged In: YES 
user_id=1488997

Yes, I had my ulimit set appropriately.

There's no problem with _opening_ many sockets (at least, I
don't think there is) - the problem is with trying to do
something (like call socket.recv()) with them.

The code in socketmodule.c is pretty clear - and having
upgraded to 2.4.3 with ubuntu dapper, I _am_ running into this.

For now, we're having to keep all our production machines on
2.4.2.


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

Comment By: Gabriel Wicke (gabrielwicke)
Date: 2006-05-29 07:11

Message:
Logged In: YES 
user_id=956757

Please disregard my comments completely- just opening more
than 1024 files does not trigger this bug, but doing a
socket.send() on the 1025th socket does.

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

Comment By: Gabriel Wicke (gabrielwicke)
Date: 2006-05-29 07:00

Message:
Logged In: YES 
user_id=956757

Never mind- you already tried ulimit. It still works for me
though, 2.4.3 from Ubuntu Dapper.

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

Comment By: Gabriel Wicke (gabrielwicke)
Date: 2006-05-29 06:57

Message:
Logged In: YES 
user_id=956757

Try "ulimit -n 8096" (only permitted in a root shell) to set
your max socket usage to something larger. Opening more than
1024 sockets works for me in python 2.4.3 after changing the
limit for the terminal in question and restarting the
interpreter. Just ulimit -n will show you your current
limit. Ulimits are enforced by the Linux kernel and can
likely be configured system-wide in /etc/sysctl.cfg.

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

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

From noreply at sourceforge.net  Tue Jul 11 05:40:33 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 10 Jul 2006 20:40:33 -0700
Subject: [ python-Bugs-1520327 ] __missing__ does not get called
Message-ID: <E1G096v-0004cZ-6o@sc8-sf-web1.sourceforge.net>

Bugs item #1520327, was opened at 2006-07-11 03: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=1520327&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Milind (t-milich)
Assigned to: Nobody/Anonymous (nobody)
Summary: __missing__ does not get called

Initial Comment:
On the last step a[10] we expect 100
>>> class A(dict):
...     pass
...
>>> a = A({1:2})
>>> def foo(a,b): return 100
...
>>> a.__missing__ = foo
>>> a[1]
2
>>> a.__missing__(10,20)
100
>>> a[10]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: 10

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

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

From noreply at sourceforge.net  Tue Jul 11 05:52:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 10 Jul 2006 20:52:24 -0700
Subject: [ python-Bugs-1494314 ] Cannot use high-numbered sockets in 2.4.3
Message-ID: <E1G09IO-0007Le-8X@sc8-sf-web6.sourceforge.net>

Bugs item #1494314, was opened at 2006-05-24 23:51
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494314&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.4
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Michael Smith (mlrsmith)
>Assigned to: Anthony Baxter (anthonybaxter)
Summary: Cannot use high-numbered sockets in 2.4.3

Initial Comment:
Python 2.4.3 introduced (in Modules/socketmodule.c) the
IS_SELECTABLE() macro, to check whether calling
select() on a given file descriptor is permissible.

However, it executes this check even when it won't
actually call select(). Specifically, select() is
called ONLY when s->sock_timeout > 0 (in
internal_select mostly, but also internal_connect).

I have a twisted application which uses many FDs
(several thousand), and upgrading python to 2.4.3 makes
it hit this limit (at 1024 file descriptors),
regardless of ulimit settings. Twisted itself always
uses non-blocking I/O on sockets, so with older
versions of python this worked fine.

A simple solution relies on the fact that select is
only ever actually called, and changes the
IS_SELECTABLE macro as in the attached fairly trivial
patch. This is sufficient to restore my application to
its previous state (where it works fine).

This doesn't solve the more general problem in
socketmodule - that we simply can't do all operations
properly with the current reliance on select(), though,
and it seems like a bit of a hack...  If I wrote up a
patch to use poll() on systems where it's available,
throughout socketmodule.c, in preference to select(),
would this be accepted?

Mike



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

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-07-11 13:52

Message:
Logged In: YES 
user_id=29957

Applied. Patch will be in 2.5b2 (to be released shortly).


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-11 12:53

Message:
Logged In: YES 
user_id=33168

Anthony checked this in to 2.5 as 50567.  I will backport at
least part of it later.

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-07-10 15:47

Message:
Logged In: YES 
user_id=21627

The patch is fine, please apply.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-10 09:57

Message:
Logged In: YES 
user_id=33168

I meant I don't think we *care* in this case (not can).

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-10 09:55

Message:
Logged In: YES 
user_id=33168

I think you're right Martin.  Looking at what it means to
have a broken poll, I don't think we can in this instance. 
So I removed all refs to HAVE_BROKEN_POLL.  What do you
think of the new version?  

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-07-08 01:50

Message:
Logged In: YES 
user_id=21627

The __APPLE__ stuff looks wrong in file 184131. You would
have to use selectmodule.c:select_have_broken_poll at
run-time to be sure you can use poll(2) on OS X (you can use
it on 10.4, but can't on 10.3, IIRC).

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-07 16:10

Message:
Logged In: YES 
user_id=33168

I've added a more complete patch (against 2.5, hopefully
applies to 2.4 too).  It cleans up some things and adds
support for SSL sockets too.  Can people please review/test
this?  I manually tested this with regular sockets and it
seemed to work.  All the tests pass, but this is somewhat
tricky.  I hate the duplicated code between socket and ssl
modules, but added to it.  It would be great to clean this
up for 2.6.

If you are forced to use select with a high socket, the
exception on connect is operation in progress rather than
can't select on socket.  I guess that's ok, it doesn't
actually change the existing behaviour.  That would have
been more involved and I'm not sure it's worth it.

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

Comment By: Michael Smith (mlrsmith)
Date: 2006-06-09 20:31

Message:
Logged In: YES 
user_id=1488997

Ok, I'll attach a patch that uses poll when available
(HAVE_POLL is already being set by the configure stuff
appropriately).

It replaces one of the two uses of select() (specifically,
the internal_select() function) in socketmodule.c. The other
is win32-specific, so replacing it with poll() wouldn't make
sense.

greg: epoll/kevent don't make sense for replacing the use of
select/poll in this particular case - socketmodule.c always
selects/polls precisely one file descriptor.

I've tested this locally, and it fixes the problem
(linux/x86). I don't have a windows system to test it on,
but it shouldn't change behaviour in any way for windows.



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

Comment By: Gregory P. Smith (greg)
Date: 2006-06-08 15:51

Message:
Logged In: YES 
user_id=413

eew yuck.  yes use poll at the very least.

we should also consider using epoll (linux) and kevent (bsd)
in the future as both of those scale better than O(n) unlike
select and poll.

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-06-05 06:14

Message:
Logged In: YES 
user_id=21627

A patch to replace internal_select with poll(2) where
available is acceptable. The current version should be
conditionally kept. That Windows doesn't have poll(2) is no
problem: its select implementation supports arbitrarily
large FDs (just like poll).

Relaxing the IS_SELECTABLE usage to cases where select is
actually going to be called is optional: there shouldn't be
too many systems left without select where people still want
to open many file descriptors.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-06-01 08:27

Message:
Logged In: YES 
user_id=31435

akuchling:  No, poll() is not part of the Windows socket API.

----------------------------------------------------------------------

Comment By: Michael Smith (mlrsmith)
Date: 2006-06-01 07:39

Message:
Logged In: YES 
user_id=1488997

That, of course, is the problem - select() is available more
or less universally, but poll() is not. However, it's not
terribly difficult to write a poll() wrapper using select(),
though doing so in general would have serious performance
issues (the specific uses in socketmodule.c do not hit this
problem), and retains the limitations of select. 

It's not clear that the complexity of doing this is
worthwhile compared to just implementing the simple API
needed internally to socketmodule.c using both APIs (i.e.
just adding a poll() option).

Regardless, it'd be nice if at least the basic fix I wrote
up went in - it solves the immediate problem, at least.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-06-01 04:39

Message:
Logged In: YES 
user_id=11375

I expect such a patch would be acceptable.  The largest
issue is probably whether poll() is available everywhere, or
if we'd be stuck maintaining both select() and poll() based
versions of internal_select().  Does Windows support poll()
at all?

----------------------------------------------------------------------

Comment By: Michael Smith (mlrsmith)
Date: 2006-05-30 00:13

Message:
Logged In: YES 
user_id=1488997

Yes, I had my ulimit set appropriately.

There's no problem with _opening_ many sockets (at least, I
don't think there is) - the problem is with trying to do
something (like call socket.recv()) with them.

The code in socketmodule.c is pretty clear - and having
upgraded to 2.4.3 with ubuntu dapper, I _am_ running into this.

For now, we're having to keep all our production machines on
2.4.2.


----------------------------------------------------------------------

Comment By: Gabriel Wicke (gabrielwicke)
Date: 2006-05-30 00:11

Message:
Logged In: YES 
user_id=956757

Please disregard my comments completely- just opening more
than 1024 files does not trigger this bug, but doing a
socket.send() on the 1025th socket does.

----------------------------------------------------------------------

Comment By: Gabriel Wicke (gabrielwicke)
Date: 2006-05-30 00:00

Message:
Logged In: YES 
user_id=956757

Never mind- you already tried ulimit. It still works for me
though, 2.4.3 from Ubuntu Dapper.

----------------------------------------------------------------------

Comment By: Gabriel Wicke (gabrielwicke)
Date: 2006-05-29 23:57

Message:
Logged In: YES 
user_id=956757

Try "ulimit -n 8096" (only permitted in a root shell) to set
your max socket usage to something larger. Opening more than
1024 sockets works for me in python 2.4.3 after changing the
limit for the terminal in question and restarting the
interpreter. Just ulimit -n will show you your current
limit. Ulimits are enforced by the Linux kernel and can
likely be configured system-wide in /etc/sysctl.cfg.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494314&group_id=5470

From noreply at sourceforge.net  Tue Jul 11 08:27:10 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 10 Jul 2006 23:27:10 -0700
Subject: [ python-Bugs-1519816 ] urllib2 proxy does not work in 2.4.3
Message-ID: <E1G0BiA-0006Wm-IM@sc8-sf-web1.sourceforge.net>

Bugs item #1519816, was opened at 2006-07-10 10:29
Message generated for change (Comment added) made by mniklas
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519816&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Michal Niklas (mniklas)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 proxy does not work in 2.4.3

Initial Comment:
My python app had to retrieve some web pages and while 
our network environment requires proxy it uses urllib2 
opener (source is in attachment). It worked very well 
on older Python interpreters:
ActivePython 2.4.2 Build 248 (ActiveState Corp.) based 
on
Python 2.4.2 (#67, Oct 30 2005, 16:11:18) [MSC v.1310 
32 bit (Intel)] on win32

It works on linux with 2.3 and 2.4.1:
Python 2.4.1 (#2, May 5 2005, 11:32:06)
[GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2

But it does not work with newest 2.4.3 on Linux:
Python 2.4.3 (#1, Jul 10 2006, 09:57:52)
[GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2

Desired result:
isof-mark:~# python2.3 proxy_bug.py
trying http://www.python.org ...
OK.  We have reply from http://www.python.org.
Size: 13757 [b]
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 
Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/
xhtml1-transitional.dtd">
<html lang="en" xml:lang="en" xmlns="http://www.w3.org/
1999/xhtml">
<head>
<me
...
 Yorkshire">design by pollenation</a>
</div>
Copyright ???? 1990-2006, <a href="psf">Python Software 
Foundation</a><br />
<a href="about/legal">Legal Statements</a>
</div>
</div>
</div>
</body>
</html>


isof-mark:~# /usr/local/bin/python proxy_bug.py
trying http://www.python.org ...
Traceback (most recent call last):
  File "proxy_bug.py", line 37, in ?
    get_page()
  File "proxy_bug.py", line 27, in get_page
    f = urllib2.urlopen(request)
  File "/usr/local/lib/python2.4/urllib2.py", line 
130, in urlopen
    return _opener.open(url, data)
  File "/usr/local/lib/python2.4/urllib2.py", line 
364, in open
    response = meth(req, response)
  File "/usr/local/lib/python2.4/urllib2.py", line 
471, in http_response
    response = self.parent.error(
  File "/usr/local/lib/python2.4/urllib2.py", line 
402, in error
    return self._call_chain(*args)
  File "/usr/local/lib/python2.4/urllib2.py", line 
337, in _call_chain
    result = func(*args)
  File "/usr/local/lib/python2.4/urllib2.py", line 
480, in http_error_default
    raise HTTPError(req.get_full_url(), code, msg, 
hdrs, fp)
urllib2.HTTPError: HTTP Error 407: Proxy 
Authentication Required

I have raported it on ActiveState bug list (http://
bugs.activestate.com/show_bug.cgi?id=47018) while I 
first spot this bug on their destribution but it seems 
that bug is in others distributions too.

Regards,
Michal Niklas


----------------------------------------------------------------------

>Comment By: Michal Niklas (mniklas)
Date: 2006-07-11 08:27

Message:
Logged In: YES 
user_id=226518

Tried it with 2.5 beta 1 and it is not better :(

c:\tools\pyscripts\scripts>c:\python25\python2.5
Python 2.5b1 (r25b1:47027, Jun 20 2006, 09:31:33) [MSC 
v.1310 32 bit (Intel)] on win32


c:\tools\pyscripts\scripts>c:\python25\python2.5 
proxy_bug.py
trying http://www.python.org ...
Traceback (most recent call last):
  File "proxy_bug.py", line 37, in <module>
    get_page()
  File "proxy_bug.py", line 27, in get_page
    f = urllib2.urlopen(request)
  File "c:\python25\lib\urllib2.py", line 121, in urlopen
    return _opener.open(url, data)
  File "c:\python25\lib\urllib2.py", line 380, in open
    response = meth(req, response)
  File "c:\python25\lib\urllib2.py", line 491, in 
http_response
    'http', request, response, code, msg, hdrs)
  File "c:\python25\lib\urllib2.py", line 412, in error
    result = self._call_chain(*args)
  File "c:\python25\lib\urllib2.py", line 353, in 
_call_chain
    result = func(*args)
  File "c:\python25\lib\urllib2.py", line 831, in 
http_error_407
    authority, req, headers)
  File "c:\python25\lib\urllib2.py", line 795, in 
http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "c:\python25\lib\urllib2.py", line 805, in 
retry_http_basic_auth
    return self.parent.open(req)
  File "c:\python25\lib\urllib2.py", line 380, in open
    response = meth(req, response)
  File "c:\python25\lib\urllib2.py", line 491, in 
http_response
    'http', request, response, code, msg, hdrs)
  File "c:\python25\lib\urllib2.py", line 418, in error
    return self._call_chain(*args)
  File "c:\python25\lib\urllib2.py", line 353, in 
_call_chain
    result = func(*args)
  File "c:\python25\lib\urllib2.py", line 499, in 
http_error_default
    raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
urllib2.HTTPError: HTTP Error 407: Proxy Authentication 
Required

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-07-10 14:49

Message:
Logged In: YES 
user_id=849994

Can you please try with 2.5b1? A lot of urllib2 related bugs
have been fixed before this release.

----------------------------------------------------------------------

Comment By: Michal Niklas (mniklas)
Date: 2006-07-10 10:41

Message:
Logged In: YES 
user_id=226518

Cannot add attachment via upload so I put it here:
#!/usr/bin/python
# -*- coding: cp1250 -*-

import urllib
import urllib2

def get_page():
	url = 'http://www.python.org'
	print "trying %s ..." % (url)

	# Setup proxy & authentication
	proxy = "poczta.heuthes:8080"
	usr1 = "USER"
	pass1 = "PASSWD"
	proxy_handler = urllib2.ProxyHandler({"http" : "http:/
/" + proxy})
	pass_mgr = urllib2.HTTPPasswordMgrWithDefaultRealm()
	pass_mgr.add_password(None, "http://" + proxy, usr1, 
pass1)
	pass_mgr.add_password(None, proxy, usr1, pass1)
	auth_handler = urllib2.HTTPBasicAuthHandler(pass_mgr)
	proxy_auth_handler = 
urllib2.ProxyBasicAuthHandler(pass_mgr)

	# Now build a new URL opener and install it
	opener = urllib2.build_opener(proxy_handler, 
proxy_auth_handler, auth_handler, urllib2.HTTPHandler)
	urllib2.install_opener(opener)

	request = urllib2.Request(url)
	f = urllib2.urlopen(request)
	data = f.read()
	print "OK.  We have reply from %s.\nSize: %d [b]" % 
(url, len(data))
	if len(data) < 400:
		print data
	else:
		print data[:200]
		print "..."
		print data[-200:]

get_page()


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519816&group_id=5470

From noreply at sourceforge.net  Tue Jul 11 09:01:13 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 11 Jul 2006 00:01:13 -0700
Subject: [ python-Bugs-1520327 ] __missing__ does not get called
Message-ID: <E1G0CF7-0004i3-3h@sc8-sf-web3.sourceforge.net>

Bugs item #1520327, was opened at 2006-07-11 03:40
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1520327&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Milind (t-milich)
Assigned to: Nobody/Anonymous (nobody)
Summary: __missing__ does not get called

Initial Comment:
On the last step a[10] we expect 100
>>> class A(dict):
...     pass
...
>>> a = A({1:2})
>>> def foo(a,b): return 100
...
>>> a.__missing__ = foo
>>> a[1]
2
>>> a.__missing__(10,20)
100
>>> a[10]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: 10

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-11 07:01

Message:
Logged In: YES 
user_id=849994

Methods are looked up on the type, not the instance. Add
your __missing__ method to A to make it work.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1520327&group_id=5470

From noreply at sourceforge.net  Tue Jul 11 10:16:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 11 Jul 2006 01:16:46 -0700
Subject: [ python-Bugs-1223937 ] subprocess.py abuse of errno
Message-ID: <E1G0DQE-0000g2-Jn@sc8-sf-web5.sourceforge.net>

Bugs item #1223937, was opened at 2005-06-20 06:56
Message generated for change (Comment added) made by hoffmanm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223937&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Oren Tirosh (orenti)
Assigned to: Peter ?
strand (astrand)
Summary: subprocess.py abuse of errno

Initial Comment:
The CalledProcessError exception's .errno attribute is
set to a child process return code which is not an
errno. Any attempt to look up this number with
os.strerror() or errno.errorcode[] will result in
meaningless output. This can break existing code that
catches OSError and does not expect CalledProcessError.

Possible resolutions:

1. Don't make CalledProcessError a subclass of OSError
2. If CalledProcessError stays a subclass of OSError
.errno should be set to some specific meaningful value
(which one? add new value to errnomodule.c?) and use a
separate attribute for the child process return code.


----------------------------------------------------------------------

Comment By: Michael Hoffman (hoffmanm)
Date: 2006-07-11 08:16

Message:
Logged In: YES 
user_id=987664

+1 from me. Thanks.

----------------------------------------------------------------------

Comment By: Peter ?
strand (astrand)
Date: 2006-07-10 22:53

Message:
Logged In: YES 
user_id=344921

If we fix this before Python 2.5, I guess we don't need to
think about backwards compatibility. See the attached patch
for a suggested solution. 

----------------------------------------------------------------------

Comment By: Peter ?
strand (astrand)
Date: 2006-07-10 20:34

Message:
Logged In: YES 
user_id=344921

Bug 1376309 has been marked as a duplicate of this bug. 

----------------------------------------------------------------------

Comment By: Peter ?
strand (astrand)
Date: 2005-06-21 20:13

Message:
Logged In: YES 
user_id=344921

I've changed my mind, since CalledProcessError is only in
the development version of Python. Perhaps it's acceptable
to change the API after all, then. Re-opening. 

----------------------------------------------------------------------

Comment By: Peter ?
strand (astrand)
Date: 2005-06-21 15:52

Message:
Logged In: YES 
user_id=344921

In hindsight, CalledProcessError should perhaps have been
designed some other way. But now when we have it, it's not
easy to change it. 

It all comes down to what is the documented behaviour and
not. As far as I understand, there's no requirement that the
errno number or an OSError should be possible to look up
with os.strerror(). I cannot find anything about this at
http://docs.python.org/lib/module-exceptions.html, at least.
All it says is "[errno is] assumed to be an error number". 

In my opinion, code should be prepared for "unknown" error
numbers. So currently, I'm not prepared to make any changes
to CalledProcessError. (If you disagree with me, post to
python-dev and see what others think.)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223937&group_id=5470

From noreply at sourceforge.net  Tue Jul 11 16:02:52 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 11 Jul 2006 07:02:52 -0700
Subject: [ python-Bugs-1472251 ] pdb 'run' crashes when the it's first
	argument is non-string
Message-ID: <E1G0IpA-0004Md-9w@sc8-sf-web4.sourceforge.net>

Bugs item #1472251, was opened at 2006-04-18 12:16
Message generated for change (Comment added) made by jakamkon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472251&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 3
Submitted By: Kuba Ko??czyk (jakamkon)
Assigned to: Nobody/Anonymous (nobody)
Summary: pdb 'run' crashes when the it's first argument is non-string

Initial Comment:
Pdb 'run/runeval' commands fails to check the type of
given argument.When argument to 'run/runeval' is
non-string the functions crashes with further
impilications on (correctly)invoking this functions: 

Python 2.5a1 (trunk:45527, Apr 18 2006, 11:12:31)

>>> def x(): pass
>>> import pdb
>>> pdb.run(x())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/jkk/python/python-svn/Lib/pdb.py", line
1113, in run
    Pdb().run(statement, globals, locals)
  File "/home/jkk/python/python-svn/Lib/bdb.py", line
363, in run
    cmd = cmd+'\n'
TypeError: unsupported operand type(s) for +:
'NoneType' and 'str'
>>> pdb.run('x()')
> /home/jkk/python/python-svn/Lib/pdb.py(1113)run()
-> Pdb().run(statement, globals, locals)
(Pdb)
# CTRL-D pressed
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/jkk/python/python-svn/Lib/pdb.py", line
1113, in run
    Pdb().run(statement, globals, locals)
  File "/home/jkk/python/python-svn/Lib/pdb.py", line
1113, in run
    Pdb().run(statement, globals, locals)
  File "/home/jkk/python/python-svn/Lib/bdb.py", line
48, in trace_dispatch
    return self.dispatch_line(frame)
  File "/home/jkk/python/python-svn/Lib/bdb.py", line
67, in dispatch_line
    if self.quitting: raise BdbQuit
bdb.BdbQuit

The solution is to simply ensure that the first
argument passed to the 'run/runeval' functions is string.

----------------------------------------------------------------------

>Comment By: Kuba Ko??czyk (jakamkon)
Date: 2006-07-11 14:02

Message:
Logged In: YES 
user_id=1491175

Is your comment directly related to this bug?
Maybe you should create separete bug tracker item to discuss
problem presented in your comment?

----------------------------------------------------------------------

Comment By: Ilya Sandler (isandler)
Date: 2006-06-25 18:54

Message:
Logged In: YES 
user_id=971153

I have looked at what's happening in a bit more detail and
now I agree that the current behaviour seems wrong.

Apparently, when one passes a nonstring to bdb's run(), bdb
sets tracing first and only then throws an exception...
Leaving tracing on seems like a bad thing to do 

Would calling settrace() a couple lines later be the
simplest solution then?

so relevant fragment of  bdb.py's run() becomes:
        if not isinstance(cmd, types.CodeType):
            cmd = cmd+'\n'
        sys.settrace(self.trace_dispatch)

This should prevent bdb from turning tracing too early.
What do you think?

----------------------------------------------------------------------

Comment By: Kuba Ko??czyk (jakamkon)
Date: 2006-06-19 13:48

Message:
Logged In: YES 
user_id=1491175

You're right,but don't you think that this kind of switching
between namespaces could confuse users?

----------------------------------------------------------------------

Comment By: Ilya Sandler (isandler)
Date: 2006-05-23 03:36

Message:
Logged In: YES 
user_id=971153


Well, I don't see anything in bdb's run which could
overwrite your namespace..

What seems to be happenning in your example is that bdb's
first line event happens while bdb is still in run(), so you
when you see pdb's prompt, are in bdb's namespace not in
yours.. If you do "next" you will get where you should be..

 bagira:~> python2.4
 Python 2.4.1 (#2, May  5 2005, 11:32:06) 
 >>> def x(): print "in x"
 >>> import pdb
 >>> pdb.run( x())
 in x
 TypeError: unsupported operand type(s) for +: 'NoneType'
and 'str'
 >>> pdb.run( 'x()' )
 > /usr/lib/python2.4/pdb.py(987)run()
 -> Pdb().run(statement, globals, locals)
 (Pdb) n          #now you are back in your namespace
 > <string>(1)?()
 (Pdb) p x        #and you get your symbols back
 <function x at 0x4021be2c>
 (Pdb) p pdb
 <module 'pdb' from '/usr/lib/python2.4/pdb.pyc'>
 (Pdb) n
 in x
 --Return--
 > <string>(1)?()->None


What do you think?

----------------------------------------------------------------------

Comment By: Kuba Ko??czyk (jakamkon)
Date: 2006-05-22 09:20

Message:
Logged In: YES 
user_id=1491175

The point is that when you want to invoke pdb.run correctly
(with string argument) after getting TypeError as in above
example,
your namespace is probably overwritten or deleted so that
you don't have access to previously defined symbols.

>>> def x():pass
>>> import pdb
>>> pdb.run(x())
TypeError
>>> pdb.run('x()')
> /home/jkk/python-svn/Lib/pdb.py(1122)run()
-> Pdb().run(statement, globals, locals)
(Pdb) pdb
*** NameError: name 'pdb' is not defined
(Pdb) x
*** NameError: name 'x' is not defined


----------------------------------------------------------------------

Comment By: Ilya Sandler (isandler)
Date: 2006-05-21 23:25

Message:
Logged In: YES 
user_id=971153


I would not classify your example as a crash. You passed a
wrong value (None in your case) into pdb.run() and got back
a TypeError...Isn't it an expected response?

E.g if you do:  >>>max(13)

You'll also get: "TypeError"


Am I missing something? Could you clarify?



----------------------------------------------------------------------

Comment By: Kuba Ko??czyk (jakamkon)
Date: 2006-04-18 12:36

Message:
Logged In: YES 
user_id=1491175

Patch is in #1472257

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472251&group_id=5470

From noreply at sourceforge.net  Tue Jul 11 17:02:28 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 11 Jul 2006 08:02:28 -0700
Subject: [ python-Bugs-1472251 ] pdb 'run' crashes when the it's first
	argument is non-string
Message-ID: <E1G0Jkq-00037w-1m@sc8-sf-web1.sourceforge.net>

Bugs item #1472251, was opened at 2006-04-18 12:16
Message generated for change (Comment added) made by jakamkon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472251&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 3
Submitted By: Kuba Ko??czyk (jakamkon)
Assigned to: Nobody/Anonymous (nobody)
Summary: pdb 'run' crashes when the it's first argument is non-string

Initial Comment:
Pdb 'run/runeval' commands fails to check the type of
given argument.When argument to 'run/runeval' is
non-string the functions crashes with further
impilications on (correctly)invoking this functions: 

Python 2.5a1 (trunk:45527, Apr 18 2006, 11:12:31)

>>> def x(): pass
>>> import pdb
>>> pdb.run(x())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/jkk/python/python-svn/Lib/pdb.py", line
1113, in run
    Pdb().run(statement, globals, locals)
  File "/home/jkk/python/python-svn/Lib/bdb.py", line
363, in run
    cmd = cmd+'\n'
TypeError: unsupported operand type(s) for +:
'NoneType' and 'str'
>>> pdb.run('x()')
> /home/jkk/python/python-svn/Lib/pdb.py(1113)run()
-> Pdb().run(statement, globals, locals)
(Pdb)
# CTRL-D pressed
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/jkk/python/python-svn/Lib/pdb.py", line
1113, in run
    Pdb().run(statement, globals, locals)
  File "/home/jkk/python/python-svn/Lib/pdb.py", line
1113, in run
    Pdb().run(statement, globals, locals)
  File "/home/jkk/python/python-svn/Lib/bdb.py", line
48, in trace_dispatch
    return self.dispatch_line(frame)
  File "/home/jkk/python/python-svn/Lib/bdb.py", line
67, in dispatch_line
    if self.quitting: raise BdbQuit
bdb.BdbQuit

The solution is to simply ensure that the first
argument passed to the 'run/runeval' functions is string.

----------------------------------------------------------------------

>Comment By: Kuba Ko??czyk (jakamkon)
Date: 2006-07-11 15:02

Message:
Logged In: YES 
user_id=1491175

Simple solution is to catch TypeError in bdb's run function:
         try:
            if not isinstance(cmd, types.CodeType):
                    cmd = cmd+'\n'
         except TypeError:
                    pass

Now it seems that handling nonstring arguments is better:

>>> import pdb
>>> def x():pass
...
>>> pdb.run(x())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/jkk/python-svn/Lib/pdb.py", line 1122, in run
    Pdb().run(statement, globals, locals)
  File "/home/jkk/python-svn/Lib/bdb.py", line 369, in run
    exec cmd in globals, locals
TypeError: exec: arg 1 must be a string, file, or code object
>>> pdb.run('x()')
> <string>(1)<module>()
(Pdb) x
<function x at 0x4024a9cc>
(Pdb) pdb.run('x()')
(Pdb)
>>>



----------------------------------------------------------------------

Comment By: Kuba Ko??czyk (jakamkon)
Date: 2006-07-11 14:02

Message:
Logged In: YES 
user_id=1491175

Is your comment directly related to this bug?
Maybe you should create separete bug tracker item to discuss
problem presented in your comment?

----------------------------------------------------------------------

Comment By: Ilya Sandler (isandler)
Date: 2006-06-25 18:54

Message:
Logged In: YES 
user_id=971153

I have looked at what's happening in a bit more detail and
now I agree that the current behaviour seems wrong.

Apparently, when one passes a nonstring to bdb's run(), bdb
sets tracing first and only then throws an exception...
Leaving tracing on seems like a bad thing to do 

Would calling settrace() a couple lines later be the
simplest solution then?

so relevant fragment of  bdb.py's run() becomes:
        if not isinstance(cmd, types.CodeType):
            cmd = cmd+'\n'
        sys.settrace(self.trace_dispatch)

This should prevent bdb from turning tracing too early.
What do you think?

----------------------------------------------------------------------

Comment By: Kuba Ko??czyk (jakamkon)
Date: 2006-06-19 13:48

Message:
Logged In: YES 
user_id=1491175

You're right,but don't you think that this kind of switching
between namespaces could confuse users?

----------------------------------------------------------------------

Comment By: Ilya Sandler (isandler)
Date: 2006-05-23 03:36

Message:
Logged In: YES 
user_id=971153


Well, I don't see anything in bdb's run which could
overwrite your namespace..

What seems to be happenning in your example is that bdb's
first line event happens while bdb is still in run(), so you
when you see pdb's prompt, are in bdb's namespace not in
yours.. If you do "next" you will get where you should be..

 bagira:~> python2.4
 Python 2.4.1 (#2, May  5 2005, 11:32:06) 
 >>> def x(): print "in x"
 >>> import pdb
 >>> pdb.run( x())
 in x
 TypeError: unsupported operand type(s) for +: 'NoneType'
and 'str'
 >>> pdb.run( 'x()' )
 > /usr/lib/python2.4/pdb.py(987)run()
 -> Pdb().run(statement, globals, locals)
 (Pdb) n          #now you are back in your namespace
 > <string>(1)?()
 (Pdb) p x        #and you get your symbols back
 <function x at 0x4021be2c>
 (Pdb) p pdb
 <module 'pdb' from '/usr/lib/python2.4/pdb.pyc'>
 (Pdb) n
 in x
 --Return--
 > <string>(1)?()->None


What do you think?

----------------------------------------------------------------------

Comment By: Kuba Ko??czyk (jakamkon)
Date: 2006-05-22 09:20

Message:
Logged In: YES 
user_id=1491175

The point is that when you want to invoke pdb.run correctly
(with string argument) after getting TypeError as in above
example,
your namespace is probably overwritten or deleted so that
you don't have access to previously defined symbols.

>>> def x():pass
>>> import pdb
>>> pdb.run(x())
TypeError
>>> pdb.run('x()')
> /home/jkk/python-svn/Lib/pdb.py(1122)run()
-> Pdb().run(statement, globals, locals)
(Pdb) pdb
*** NameError: name 'pdb' is not defined
(Pdb) x
*** NameError: name 'x' is not defined


----------------------------------------------------------------------

Comment By: Ilya Sandler (isandler)
Date: 2006-05-21 23:25

Message:
Logged In: YES 
user_id=971153


I would not classify your example as a crash. You passed a
wrong value (None in your case) into pdb.run() and got back
a TypeError...Isn't it an expected response?

E.g if you do:  >>>max(13)

You'll also get: "TypeError"


Am I missing something? Could you clarify?



----------------------------------------------------------------------

Comment By: Kuba Ko??czyk (jakamkon)
Date: 2006-04-18 12:36

Message:
Logged In: YES 
user_id=1491175

Patch is in #1472257

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472251&group_id=5470

From noreply at sourceforge.net  Tue Jul 11 18:58:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 11 Jul 2006 09:58:25 -0700
Subject: [ python-Feature Requests-1520662 ] support all of strftime(3)
Message-ID: <E1G0LZ3-0007K7-Js@sc8-sf-web5.sourceforge.net>

Feature Requests item #1520662, was opened at 2006-07-11 18:58
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=1520662&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Toni Mueller (tonimueller)
Assigned to: Nobody/Anonymous (nobody)
Summary: support all of strftime(3)

Initial Comment:
Hello,

I'd like to see support for all of strftime(3) in
time.strftime() and time.strptime().

Thank you!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1520662&group_id=5470

From noreply at sourceforge.net  Tue Jul 11 19:21:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 11 Jul 2006 10:21:23 -0700
Subject: [ python-Bugs-1494314 ] Cannot use high-numbered sockets in 2.4.3
Message-ID: <E1G0LvH-0003sd-O7@sc8-sf-web2.sourceforge.net>

Bugs item #1494314, was opened at 2006-05-24 23:51
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494314&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.4
>Status: Open
>Resolution: Remind
Priority: 5
Submitted By: Michael Smith (mlrsmith)
Assigned to: Anthony Baxter (anthonybaxter)
Summary: Cannot use high-numbered sockets in 2.4.3

Initial Comment:
Python 2.4.3 introduced (in Modules/socketmodule.c) the
IS_SELECTABLE() macro, to check whether calling
select() on a given file descriptor is permissible.

However, it executes this check even when it won't
actually call select(). Specifically, select() is
called ONLY when s->sock_timeout > 0 (in
internal_select mostly, but also internal_connect).

I have a twisted application which uses many FDs
(several thousand), and upgrading python to 2.4.3 makes
it hit this limit (at 1024 file descriptors),
regardless of ulimit settings. Twisted itself always
uses non-blocking I/O on sockets, so with older
versions of python this worked fine.

A simple solution relies on the fact that select is
only ever actually called, and changes the
IS_SELECTABLE macro as in the attached fairly trivial
patch. This is sufficient to restore my application to
its previous state (where it works fine).

This doesn't solve the more general problem in
socketmodule - that we simply can't do all operations
properly with the current reliance on select(), though,
and it seems like a bit of a hack...  If I wrote up a
patch to use poll() on systems where it's available,
throughout socketmodule.c, in preference to select(),
would this be accepted?

Mike



----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-07-12 03:21

Message:
Logged In: YES 
user_id=29957

Re-opening to remind myself to apply this to release24-maint
for the eventual 2.4.4 release.


----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-07-11 13:52

Message:
Logged In: YES 
user_id=29957

Applied. Patch will be in 2.5b2 (to be released shortly).


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-11 12:53

Message:
Logged In: YES 
user_id=33168

Anthony checked this in to 2.5 as 50567.  I will backport at
least part of it later.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-07-10 15:47

Message:
Logged In: YES 
user_id=21627

The patch is fine, please apply.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-10 09:57

Message:
Logged In: YES 
user_id=33168

I meant I don't think we *care* in this case (not can).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-10 09:55

Message:
Logged In: YES 
user_id=33168

I think you're right Martin.  Looking at what it means to
have a broken poll, I don't think we can in this instance. 
So I removed all refs to HAVE_BROKEN_POLL.  What do you
think of the new version?  

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-07-08 01:50

Message:
Logged In: YES 
user_id=21627

The __APPLE__ stuff looks wrong in file 184131. You would
have to use selectmodule.c:select_have_broken_poll at
run-time to be sure you can use poll(2) on OS X (you can use
it on 10.4, but can't on 10.3, IIRC).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-07 16:10

Message:
Logged In: YES 
user_id=33168

I've added a more complete patch (against 2.5, hopefully
applies to 2.4 too).  It cleans up some things and adds
support for SSL sockets too.  Can people please review/test
this?  I manually tested this with regular sockets and it
seemed to work.  All the tests pass, but this is somewhat
tricky.  I hate the duplicated code between socket and ssl
modules, but added to it.  It would be great to clean this
up for 2.6.

If you are forced to use select with a high socket, the
exception on connect is operation in progress rather than
can't select on socket.  I guess that's ok, it doesn't
actually change the existing behaviour.  That would have
been more involved and I'm not sure it's worth it.

----------------------------------------------------------------------

Comment By: Michael Smith (mlrsmith)
Date: 2006-06-09 20:31

Message:
Logged In: YES 
user_id=1488997

Ok, I'll attach a patch that uses poll when available
(HAVE_POLL is already being set by the configure stuff
appropriately).

It replaces one of the two uses of select() (specifically,
the internal_select() function) in socketmodule.c. The other
is win32-specific, so replacing it with poll() wouldn't make
sense.

greg: epoll/kevent don't make sense for replacing the use of
select/poll in this particular case - socketmodule.c always
selects/polls precisely one file descriptor.

I've tested this locally, and it fixes the problem
(linux/x86). I don't have a windows system to test it on,
but it shouldn't change behaviour in any way for windows.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2006-06-08 15:51

Message:
Logged In: YES 
user_id=413

eew yuck.  yes use poll at the very least.

we should also consider using epoll (linux) and kevent (bsd)
in the future as both of those scale better than O(n) unlike
select and poll.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-06-05 06:14

Message:
Logged In: YES 
user_id=21627

A patch to replace internal_select with poll(2) where
available is acceptable. The current version should be
conditionally kept. That Windows doesn't have poll(2) is no
problem: its select implementation supports arbitrarily
large FDs (just like poll).

Relaxing the IS_SELECTABLE usage to cases where select is
actually going to be called is optional: there shouldn't be
too many systems left without select where people still want
to open many file descriptors.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-06-01 08:27

Message:
Logged In: YES 
user_id=31435

akuchling:  No, poll() is not part of the Windows socket API.

----------------------------------------------------------------------

Comment By: Michael Smith (mlrsmith)
Date: 2006-06-01 07:39

Message:
Logged In: YES 
user_id=1488997

That, of course, is the problem - select() is available more
or less universally, but poll() is not. However, it's not
terribly difficult to write a poll() wrapper using select(),
though doing so in general would have serious performance
issues (the specific uses in socketmodule.c do not hit this
problem), and retains the limitations of select. 

It's not clear that the complexity of doing this is
worthwhile compared to just implementing the simple API
needed internally to socketmodule.c using both APIs (i.e.
just adding a poll() option).

Regardless, it'd be nice if at least the basic fix I wrote
up went in - it solves the immediate problem, at least.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-06-01 04:39

Message:
Logged In: YES 
user_id=11375

I expect such a patch would be acceptable.  The largest
issue is probably whether poll() is available everywhere, or
if we'd be stuck maintaining both select() and poll() based
versions of internal_select().  Does Windows support poll()
at all?

----------------------------------------------------------------------

Comment By: Michael Smith (mlrsmith)
Date: 2006-05-30 00:13

Message:
Logged In: YES 
user_id=1488997

Yes, I had my ulimit set appropriately.

There's no problem with _opening_ many sockets (at least, I
don't think there is) - the problem is with trying to do
something (like call socket.recv()) with them.

The code in socketmodule.c is pretty clear - and having
upgraded to 2.4.3 with ubuntu dapper, I _am_ running into this.

For now, we're having to keep all our production machines on
2.4.2.


----------------------------------------------------------------------

Comment By: Gabriel Wicke (gabrielwicke)
Date: 2006-05-30 00:11

Message:
Logged In: YES 
user_id=956757

Please disregard my comments completely- just opening more
than 1024 files does not trigger this bug, but doing a
socket.send() on the 1025th socket does.

----------------------------------------------------------------------

Comment By: Gabriel Wicke (gabrielwicke)
Date: 2006-05-30 00:00

Message:
Logged In: YES 
user_id=956757

Never mind- you already tried ulimit. It still works for me
though, 2.4.3 from Ubuntu Dapper.

----------------------------------------------------------------------

Comment By: Gabriel Wicke (gabrielwicke)
Date: 2006-05-29 23:57

Message:
Logged In: YES 
user_id=956757

Try "ulimit -n 8096" (only permitted in a root shell) to set
your max socket usage to something larger. Opening more than
1024 sockets works for me in python 2.4.3 after changing the
limit for the terminal in question and restarting the
interpreter. Just ulimit -n will show you your current
limit. Ulimits are enforced by the Linux kernel and can
likely be configured system-wide in /etc/sysctl.cfg.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494314&group_id=5470

From noreply at sourceforge.net  Tue Jul 11 19:45:37 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 11 Jul 2006 10:45:37 -0700
Subject: [ python-Bugs-1467450 ] test_ctypes fails on OSX 10.3
Message-ID: <E1G0MIj-0005dI-Rn@sc8-sf-web2.sourceforge.net>

Bugs item #1467450, was opened at 2006-04-10 03:21
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467450&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Thomas Heller (theller)
Summary: test_ctypes fails on OSX 10.3

Initial Comment:
test test_ctypes failed -- Traceback (most recent call
last):
  File
"/Users/anthonybaxter/python/Lib/ctypes/test/test_loading.py",
line 30, in test_load
    cdll.load(libc_name)
  File
"/Users/anthonybaxter/python/Lib/ctypes/_loader.py",
line 112, in load
    return self._load(libname, mode)
  File
"/Users/anthonybaxter/python/Lib/ctypes/_loader.py",
line 153, in _load
    return self.load_library(pathname, mode)
  File
"/Users/anthonybaxter/python/Lib/ctypes/_loader.py",
line 124, in load_library
    return self._dlltype(libname, mode)
  File
"/Users/anthonybaxter/python/Lib/ctypes/__init__.py",
line 288, in __init__
    self._handle = _dlopen(self._name, mode)
OSError: dlcompat: unable to open this file with RTLD_LOCAL

This happens both with and without the patch in r43748.

Darwin sam.local 7.9.0 Darwin Kernel Version 7.9.0: Wed
Mar 30 20:11:17 PST 2005;
root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC  Power
Macintosh powerpc

GCC version:
Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs
Thread model: posix
gcc version 3.3 20030304 (Apple Computer, Inc. build 1640)


----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-11 19:45

Message:
Logged In: YES 
user_id=580910

With this patch test_ctypes passed on 10.3. 

I'm in favor of applying this patch. 

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-07-10 11:43

Message:
Logged In: YES 
user_id=29957

I'm not going to get the opportunity to look at this before
the b2 freeze tomorrow morning, but will look at it soon after.



----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2006-07-10 11:07

Message:
Logged In: YES 
user_id=11105

Even better would imo be to call the Gestalt function in the
_ctypes extensions module itself.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2006-07-10 10:13

Message:
Logged In: YES 
user_id=11105

Here is a patch that I hope will fix this problem.  Ronald
Oussuren suggested in private email to use RTLD_GLOBAL as
default library loading mode on OS X 10.3.  He suggested to
use the platform module to find out the osx version, however
I don't like.  Instead I found by examining platform that
gestalt.gestalt("sysv") returns the information I need.

I still don't have access to 10.3 (and Python does not
compile on the 10.2.8 sourceforge osx compile farm machine -
should I add a bug for that one?), so I cannot really test
the patch myself.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-10 06:14

Message:
Logged In: YES 
user_id=33168

Anthony is this still a problem?

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2006-05-09 20:38

Message:
Logged In: YES 
user_id=11105

Does this failure still occur with Python 2.5a2, or the
current SVN trunk?

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2006-04-13 08:59

Message:
Logged In: YES 
user_id=11105

I'm trying to get a copy of OS X 10.3, then will try to
install it and look after this problem.
OTOH, the ctypes loading code is currently rewritten in the
upstream version - this will probably prevent this failure.

In the meantime, can you try to find out the cause of this
failure?  Would RTLD_GLOBAL instead of RTLD_LOCAL work? Is
the library file missing?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467450&group_id=5470

From noreply at sourceforge.net  Tue Jul 11 19:47:45 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 11 Jul 2006 10:47:45 -0700
Subject: [ python-Bugs-1519452 ] zipfile -- too many files?
Message-ID: <E1G0MKn-0006VX-I8@sc8-sf-web2.sourceforge.net>

Bugs item #1519452, was opened at 2006-07-09 07:57
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519452&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Joe Brown (shmengie)
Assigned to: Nobody/Anonymous (nobody)
Summary: zipfile -- too many files?

Initial Comment:
While creating a huge zipfile (probably too big) the
following error appeared.

Exception exceptions.OverflowError: 'long int too large
to convert to int' in <bound method ZipFile.__del__ of
<zipfile.ZipFile instance at 0x009BD198>> ignored

I assume this is during the closing of the zipfile,
further assuming too many files were added to the archive.

----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-11 19:47

Message:
Logged In: YES 
user_id=580910

How large is the resulting file? Zipfile in python2.4 cannot handle zipfiles that 
require the zip64 extensions and fails misserably when you do cross that limit.

This was fixed in python 2.5.

----------------------------------------------------------------------

Comment By: Joe Brown (shmengie)
Date: 2006-07-09 08:01

Message:
Logged In: YES 
user_id=729883

Platform: Windows SBS 2003
Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit
(Intel)] on win32

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519452&group_id=5470

From noreply at sourceforge.net  Tue Jul 11 22:08:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 11 Jul 2006 13:08:23 -0700
Subject: [ python-Bugs-1519452 ] zipfile -- too many files?
Message-ID: <E1G0OWt-0002PJ-Ar@sc8-sf-web3.sourceforge.net>

Bugs item #1519452, was opened at 2006-07-09 01:57
Message generated for change (Comment added) made by shmengie
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519452&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Joe Brown (shmengie)
Assigned to: Nobody/Anonymous (nobody)
Summary: zipfile -- too many files?

Initial Comment:
While creating a huge zipfile (probably too big) the
following error appeared.

Exception exceptions.OverflowError: 'long int too large
to convert to int' in <bound method ZipFile.__del__ of
<zipfile.ZipFile instance at 0x009BD198>> ignored

I assume this is during the closing of the zipfile,
further assuming too many files were added to the archive.

----------------------------------------------------------------------

>Comment By: Joe Brown (shmengie)
Date: 2006-07-11 16:08

Message:
Logged In: YES 
user_id=729883

The zip file was on order of 6-9 GBs, surely over 32000
files.  I will give Python2.5 a shot and see how that works.

I've stumbled on another bug with tarfile.  It's not
reporting an error, but I only find 350 files when I
unarchive.  That's entirely different bug tho :-o

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-11 13:47

Message:
Logged In: YES 
user_id=580910

How large is the resulting file? Zipfile in python2.4 cannot handle zipfiles that 
require the zip64 extensions and fails misserably when you do cross that limit.

This was fixed in python 2.5.

----------------------------------------------------------------------

Comment By: Joe Brown (shmengie)
Date: 2006-07-09 02:01

Message:
Logged In: YES 
user_id=729883

Platform: Windows SBS 2003
Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit
(Intel)] on win32

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519452&group_id=5470

From noreply at sourceforge.net  Tue Jul 11 23:39:00 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 11 Jul 2006 14:39:00 -0700
Subject: [ python-Bugs-1520818 ] fcntl.ioctl fails to copy back exactly-1024
	buffer
Message-ID: <E1G0Pwa-0002QZ-3H@sc8-sf-web2.sourceforge.net>

Bugs item #1520818, was opened at 2006-07-11 17: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=1520818&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Eichin (eichin)
Assigned to: Nobody/Anonymous (nobody)
Summary: fcntl.ioctl fails to copy back exactly-1024 buffer

Initial Comment:
The appended code is a simple call of the SCSI Inquiry
ioctl, based on what scsi-tools scsiinfo.c does.  The
intended behaviour is simple - pass it /dev/sg0 (or any
scsi device, really) and it pulls out the vendor,
product and revision from the returned buffer.

However, if you change PAD_SIZE, the behaviour changes:
at 1023 and 1025, it does what is expected; at 1024,
the second assertion fires, because the array b on
output hasn't changed at all.

Not sure if there's a different ioctl that can
demonstrate this more easily (this needs root and a
scsi device, though it does explicitly open it
readonly) but it points in the direction of a fencepost
error in the "if the supplied buffer is less than 1024
bytes long it is first copied into a static buffer 1024
bytes long which is then passed to ioctl and copied
back into the supplied buffer" behaviour in current
documentation.

observed under:
Python 2.4.1 (#2, May  5 2005, 11:32:06)
[GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2
(on debian sarge.)

I didn't see it mentioned among the ioctl bugs in the
sourceforge tracker...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1520818&group_id=5470

From noreply at sourceforge.net  Wed Jul 12 00:16:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 11 Jul 2006 15:16:23 -0700
Subject: [ python-Bugs-1520831 ] urrlib2 max_redirections=0 disables redirects
Message-ID: <E1G0QWl-0003t3-8U@sc8-sf-web6.sourceforge.net>

Bugs item #1520831, was opened at 2006-07-11 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=1520831&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: rus_r_orange (rus_r_orange)
Assigned to: Nobody/Anonymous (nobody)
Summary: urrlib2 max_redirections=0 disables redirects

Initial Comment:
When using urllib2, I wanted to be able to see all
redirects that come back from an http server. I set the
variable max_redirections in HTTPRedirectHandler to 0.
However, redirects were still being followed because
the req didn't have a redirect_dict set.

IMHO, if max_redirections is set to 0, redirects should
not be followed, no matter what. 

For my personal situation, I copied urllib2 and hacked
it to that if max_redirections is 0 (or less), it will
always raise the HTTPError that is associated with the
status code received by the request.

I saw this issue on WinXP with 2.4.1 and on Linux with
2.4.3.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1520831&group_id=5470

From noreply at sourceforge.net  Wed Jul 12 01:21:13 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 11 Jul 2006 16:21:13 -0700
Subject: [ python-Bugs-1520864 ] unpack list of singleton tuples not unpacking
Message-ID: <E1G0RXV-0000ry-I1@sc8-sf-web2.sourceforge.net>

Bugs item #1520864, was opened at 2006-07-11 17: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=1520864&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Tuininga (atuining)
Assigned to: Nobody/Anonymous (nobody)
Summary: unpack list of singleton tuples not unpacking

Initial Comment:
The following code works differently in Python 2.5 than
Python 2.4:

x = [(1,), (2,), (3,)]
for y, in x:
    print y

In Python 2.4, this code produces the following:
1
2
3

In Python 2.5, this code produces the following:
(1,)
(2,)
(3,)

Interestingly enough the following code:

x = (1,)
y, = x
print y

produces the output
1

in both Python 2.4 and Python 2.5. I'm thinking this is
not intentional. :-)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1520864&group_id=5470

From noreply at sourceforge.net  Wed Jul 12 03:52:59 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 11 Jul 2006 18:52:59 -0700
Subject: [ python-Bugs-1520914 ] time.strftime breakage in 2.4/2.5
Message-ID: <E1G0TuN-00031I-Qo@sc8-sf-web2.sourceforge.net>

Bugs item #1520914, was opened at 2006-07-11 20: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=1520914&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: time.strftime breakage in 2.4/2.5

Initial Comment:
Up to Python 2.3 this worked just fine:

    >>> import time
    >>> time.strftime("%Y-%m-%d", (2005, 6, 4) + (0,)*6)
    '2005-06-04'

Starting with 2.4 it broke:

    >>> import time
    >>> time.strftime("%Y-%m-%d", (2005, 6, 4) + (0,)*6)
    Traceback (most recent call last):
      File "<stdin>", line 1, in ?
    ValueError: day of year out of range

though if you change the unused fields to 1 it works:

    >>> time.strftime("%Y-%m-%d", (2005, 6, 4) + (1,)*6)
    '2005-06-04'

While this wasn't documented behavior, it was certainly behaviour that 
worked for a long time.  It should probably be allowed to continue 
working.

Skip


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1520914&group_id=5470

From noreply at sourceforge.net  Wed Jul 12 04:17:57 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 11 Jul 2006 19:17:57 -0700
Subject: [ python-Bugs-1519452 ] zipfile -- too many files?
Message-ID: <E1G0UIX-0005uw-Vo@sc8-sf-web5.sourceforge.net>

Bugs item #1519452, was opened at 2006-07-09 01:57
Message generated for change (Comment added) made by shmengie
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519452&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Joe Brown (shmengie)
Assigned to: Nobody/Anonymous (nobody)
Summary: zipfile -- too many files?

Initial Comment:
While creating a huge zipfile (probably too big) the
following error appeared.

Exception exceptions.OverflowError: 'long int too large
to convert to int' in <bound method ZipFile.__del__ of
<zipfile.ZipFile instance at 0x009BD198>> ignored

I assume this is during the closing of the zipfile,
further assuming too many files were added to the archive.

----------------------------------------------------------------------

>Comment By: Joe Brown (shmengie)
Date: 2006-07-11 22:17

Message:
Logged In: YES 
user_id=729883

Windows 2.5 beta 2 responded like this:

Traceback (most recent call last):
  File "C:\python_scripts\archive.py", line 27, in <module>
    main()
  File "C:\python_scripts\archive.py", line 23, in main
    zipper(zip, folder)
  File "C:\python_scripts\archive.py", line 15, in zipper
    zip.write(os.path.join(root, item))
  File "C:\Python25\lib\zipfile.py", line 561, in write
    self._writecheck(zinfo)
  File "C:\Python25\lib\zipfile.py", line 536, in _writecheck
    raise LargeZipFile("Zipfile size would require ZIP64
extensions")
zipfile.LargeZipFile: Zipfile size would require ZIP64
extensions
C:\Python25\lib\struct.py:63: DeprecationWarning: struct
integer overflow maskin
g is deprecated
  return o.pack(*args)

----------------------------------------------------------------------

Comment By: Joe Brown (shmengie)
Date: 2006-07-11 16:08

Message:
Logged In: YES 
user_id=729883

The zip file was on order of 6-9 GBs, surely over 32000
files.  I will give Python2.5 a shot and see how that works.

I've stumbled on another bug with tarfile.  It's not
reporting an error, but I only find 350 files when I
unarchive.  That's entirely different bug tho :-o

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-11 13:47

Message:
Logged In: YES 
user_id=580910

How large is the resulting file? Zipfile in python2.4 cannot handle zipfiles that 
require the zip64 extensions and fails misserably when you do cross that limit.

This was fixed in python 2.5.

----------------------------------------------------------------------

Comment By: Joe Brown (shmengie)
Date: 2006-07-09 02:01

Message:
Logged In: YES 
user_id=729883

Platform: Windows SBS 2003
Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit
(Intel)] on win32

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519452&group_id=5470

From noreply at sourceforge.net  Wed Jul 12 04:38:08 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 11 Jul 2006 19:38:08 -0700
Subject: [ python-Bugs-1520864 ] unpack list of singleton tuples not unpacking
Message-ID: <E1G0Uc4-0007xj-ID@sc8-sf-web5.sourceforge.net>

Bugs item #1520864, was opened at 2006-07-11 18:21
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1520864&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
>Priority: 9
Submitted By: Anthony Tuininga (atuining)
Assigned to: Nobody/Anonymous (nobody)
Summary: unpack list of singleton tuples not unpacking

Initial Comment:
The following code works differently in Python 2.5 than
Python 2.4:

x = [(1,), (2,), (3,)]
for y, in x:
    print y

In Python 2.4, this code produces the following:
1
2
3

In Python 2.5, this code produces the following:
(1,)
(2,)
(3,)

Interestingly enough the following code:

x = (1,)
y, = x
print y

produces the output
1

in both Python 2.4 and Python 2.5. I'm thinking this is
not intentional. :-)

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2006-07-11 21:38

Message:
Logged In: YES 
user_id=80475

Ouch.  This is bad.  The disassembly shows that the compiler
 isn't generating the unpack_sequence opcode.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1520864&group_id=5470

From noreply at sourceforge.net  Wed Jul 12 04:46:30 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 11 Jul 2006 19:46:30 -0700
Subject: [ python-Bugs-1520914 ] time.strftime breakage in 2.4/2.5
Message-ID: <E1G0UkA-0001D8-0e@sc8-sf-web3.sourceforge.net>

Bugs item #1520914, was opened at 2006-07-11 18:52
Message generated for change (Settings changed) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1520914&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
>Assigned to: Brett Cannon (bcannon)
Summary: time.strftime breakage in 2.4/2.5

Initial Comment:
Up to Python 2.3 this worked just fine:

    >>> import time
    >>> time.strftime("%Y-%m-%d", (2005, 6, 4) + (0,)*6)
    '2005-06-04'

Starting with 2.4 it broke:

    >>> import time
    >>> time.strftime("%Y-%m-%d", (2005, 6, 4) + (0,)*6)
    Traceback (most recent call last):
      File "<stdin>", line 1, in ?
    ValueError: day of year out of range

though if you change the unused fields to 1 it works:

    >>> time.strftime("%Y-%m-%d", (2005, 6, 4) + (1,)*6)
    '2005-06-04'

While this wasn't documented behavior, it was certainly behaviour that 
worked for a long time.  It should probably be allowed to continue 
working.

Skip


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1520914&group_id=5470

From noreply at sourceforge.net  Wed Jul 12 07:26:45 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 11 Jul 2006 22:26:45 -0700
Subject: [ python-Bugs-1520864 ] unpack list of singleton tuples not unpacking
Message-ID: <E1G0XFE-0003UY-VG@sc8-sf-web2.sourceforge.net>

Bugs item #1520864, was opened at 2006-07-11 16:21
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1520864&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 9
Submitted By: Anthony Tuininga (atuining)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: unpack list of singleton tuples not unpacking

Initial Comment:
The following code works differently in Python 2.5 than
Python 2.4:

x = [(1,), (2,), (3,)]
for y, in x:
    print y

In Python 2.4, this code produces the following:
1
2
3

In Python 2.5, this code produces the following:
(1,)
(2,)
(3,)

Interestingly enough the following code:

x = (1,)
y, = x
print y

produces the output
1

in both Python 2.4 and Python 2.5. I'm thinking this is
not intentional. :-)

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-11 22:26

Message:
Logged In: YES 
user_id=33168

Awww come on, can't we change the language just to make your
life difficult? ;-)

Thanks a lot for catching this!

Committed revision 50597.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-07-11 19:38

Message:
Logged In: YES 
user_id=80475

Ouch.  This is bad.  The disassembly shows that the compiler
 isn't generating the unpack_sequence opcode.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1520864&group_id=5470

From noreply at sourceforge.net  Wed Jul 12 07:33:38 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 11 Jul 2006 22:33:38 -0700
Subject: [ python-Bugs-1520818 ] fcntl.ioctl fails to copy back exactly-1024
	buffer
Message-ID: <E1G0XLu-0006KA-Bk@sc8-sf-web5.sourceforge.net>

Bugs item #1520818, was opened at 2006-07-11 14:38
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1520818&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Eichin (eichin)
Assigned to: Nobody/Anonymous (nobody)
Summary: fcntl.ioctl fails to copy back exactly-1024 buffer

Initial Comment:
The appended code is a simple call of the SCSI Inquiry
ioctl, based on what scsi-tools scsiinfo.c does.  The
intended behaviour is simple - pass it /dev/sg0 (or any
scsi device, really) and it pulls out the vendor,
product and revision from the returned buffer.

However, if you change PAD_SIZE, the behaviour changes:
at 1023 and 1025, it does what is expected; at 1024,
the second assertion fires, because the array b on
output hasn't changed at all.

Not sure if there's a different ioctl that can
demonstrate this more easily (this needs root and a
scsi device, though it does explicitly open it
readonly) but it points in the direction of a fencepost
error in the "if the supplied buffer is less than 1024
bytes long it is first copied into a static buffer 1024
bytes long which is then passed to ioctl and copied
back into the supplied buffer" behaviour in current
documentation.

observed under:
Python 2.4.1 (#2, May  5 2005, 11:32:06)
[GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2
(on debian sarge.)

I didn't see it mentioned among the ioctl bugs in the
sourceforge tracker...

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-11 22:33

Message:
Logged In: YES 
user_id=33168

This code was recently changed.  It is not in any released
version AFAIK.  Can you try 2.5b2 which recently came out? 
If not, can you try 2.4.3+ from SVN?  This is the version
that will become 2.4.4.  I think the problem may be fixed. 
The patch was for http://python.org/sf/1433877 .

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1520818&group_id=5470

From noreply at sourceforge.net  Wed Jul 12 10:44:27 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 12 Jul 2006 01:44:27 -0700
Subject: [ python-Bugs-1467450 ] test_ctypes fails on OSX 10.3
Message-ID: <E1G0aKZ-0008Iy-BX@sc8-sf-web2.sourceforge.net>

Bugs item #1467450, was opened at 2006-04-10 03:21
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467450&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Thomas Heller (theller)
Summary: test_ctypes fails on OSX 10.3

Initial Comment:
test test_ctypes failed -- Traceback (most recent call
last):
  File
"/Users/anthonybaxter/python/Lib/ctypes/test/test_loading.py",
line 30, in test_load
    cdll.load(libc_name)
  File
"/Users/anthonybaxter/python/Lib/ctypes/_loader.py",
line 112, in load
    return self._load(libname, mode)
  File
"/Users/anthonybaxter/python/Lib/ctypes/_loader.py",
line 153, in _load
    return self.load_library(pathname, mode)
  File
"/Users/anthonybaxter/python/Lib/ctypes/_loader.py",
line 124, in load_library
    return self._dlltype(libname, mode)
  File
"/Users/anthonybaxter/python/Lib/ctypes/__init__.py",
line 288, in __init__
    self._handle = _dlopen(self._name, mode)
OSError: dlcompat: unable to open this file with RTLD_LOCAL

This happens both with and without the patch in r43748.

Darwin sam.local 7.9.0 Darwin Kernel Version 7.9.0: Wed
Mar 30 20:11:17 PST 2005;
root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC  Power
Macintosh powerpc

GCC version:
Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs
Thread model: posix
gcc version 3.3 20030304 (Apple Computer, Inc. build 1640)


----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2006-07-12 10:44

Message:
Logged In: YES 
user_id=11105

Committed as r50601.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-11 19:45

Message:
Logged In: YES 
user_id=580910

With this patch test_ctypes passed on 10.3. 

I'm in favor of applying this patch. 

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-07-10 11:43

Message:
Logged In: YES 
user_id=29957

I'm not going to get the opportunity to look at this before
the b2 freeze tomorrow morning, but will look at it soon after.



----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2006-07-10 11:07

Message:
Logged In: YES 
user_id=11105

Even better would imo be to call the Gestalt function in the
_ctypes extensions module itself.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2006-07-10 10:13

Message:
Logged In: YES 
user_id=11105

Here is a patch that I hope will fix this problem.  Ronald
Oussuren suggested in private email to use RTLD_GLOBAL as
default library loading mode on OS X 10.3.  He suggested to
use the platform module to find out the osx version, however
I don't like.  Instead I found by examining platform that
gestalt.gestalt("sysv") returns the information I need.

I still don't have access to 10.3 (and Python does not
compile on the 10.2.8 sourceforge osx compile farm machine -
should I add a bug for that one?), so I cannot really test
the patch myself.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-10 06:14

Message:
Logged In: YES 
user_id=33168

Anthony is this still a problem?

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2006-05-09 20:38

Message:
Logged In: YES 
user_id=11105

Does this failure still occur with Python 2.5a2, or the
current SVN trunk?

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2006-04-13 08:59

Message:
Logged In: YES 
user_id=11105

I'm trying to get a copy of OS X 10.3, then will try to
install it and look after this problem.
OTOH, the ctypes loading code is currently rewritten in the
upstream version - this will probably prevent this failure.

In the meantime, can you try to find out the cause of this
failure?  Would RTLD_GLOBAL instead of RTLD_LOCAL work? Is
the library file missing?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467450&group_id=5470

From noreply at sourceforge.net  Wed Jul 12 15:11:56 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 12 Jul 2006 06:11:56 -0700
Subject: [ python-Bugs-1512814 ] Incorrect lineno's in code objects
Message-ID: <E1G0eVQ-0001nJ-HE@sc8-sf-web5.sourceforge.net>

Bugs item #1512814, was opened at 2006-06-26 18:01
Message generated for change (Comment added) made by twouters
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512814&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.5
>Status: Open
>Resolution: None
>Priority: 7
Submitted By: Thomas Wouters (twouters)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Incorrect lineno's in code objects

Initial Comment:
The 2.5 compiler forgets how to count linenumbers in
certain situations:

>>> s255 = "".join(["\n"] * 255 + ["spam"])
>>> s256 = "".join(["\n"] * 256 + ["spam"])

>>> exec s255
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 256, in <module>
NameError: name 'spam' is not defined

>>> exec s256
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 1, in <module>
NameError: name 'spam' is not defined

Notice the 'line 1' linenumber in the case of 256 blank
lines. The same happens for 'pass' statements or 'if 0'
blocks instead of blank lines. The problem is in the
actual code objects created:

>>> dis.disco(compile(s255, "", "exec"))
256           0 LOAD_NAME                0 (spam)
              3 POP_TOP             
              4 LOAD_CONST               0 (None)
              7 RETURN_VALUE        
>>> dis.disco(compile(s256, "", "exec"))
  1           0 LOAD_NAME                0 (spam)
              3 POP_TOP             
              4 LOAD_CONST               0 (None)
              7 RETURN_VALUE        



----------------------------------------------------------------------

>Comment By: Thomas Wouters (twouters)
Date: 2006-07-12 15:11

Message:
Logged In: YES 
user_id=34209

Unfortunately, it isn't quite fixed. It's fixed for code in
the global scope, but not for functions:

>>> s255 = "def foo():\n " + "".join(["\n "] * 254 + ["
spam\n"])
>>> exec s255
>>> dis.dis(foo)
.256           0 LOAD_GLOBAL              0 (spam)
.              3 POP_TOP             
.              4 LOAD_CONST               0 (None)
.              7 RETURN_VALUE        

>>> s256 = "def foo():\n " + "".join(["\n "] * 255 + ["
spam\n"])
>>> exec s256
>>> dis.dis(foo)
.  1           0 LOAD_GLOBAL              0 (spam)
.              3 POP_TOP             
.              4 LOAD_CONST               0 (None)
.              7 RETURN_VALUE        

I haven't tried figuring out for what else it's broken like
this, sorry :)


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-10 02:04

Message:
Logged In: YES 
user_id=33168

Committed revision 50500.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512814&group_id=5470

From noreply at sourceforge.net  Wed Jul 12 20:22:16 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 12 Jul 2006 11:22:16 -0700
Subject: [ python-Bugs-1521375 ] ctypes test overwrites /dev/null
Message-ID: <E1G0jLk-0007j7-B8@sc8-sf-web3.sourceforge.net>

Bugs item #1521375, was opened at 2006-07-12 13: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=1521375&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Scot Doyle (scotdoyle)
Assigned to: Nobody/Anonymous (nobody)
Summary: ctypes test overwrites /dev/null

Initial Comment:
Steps to reproduce on Debian Sarge:
1. ls -l /dev/null
2. wget
http://www.python.org/ftp/python/2.5/Python-2.5b2.tgz
3. tar xvzf Pyth*
4. cd Pyth*
5. ./configure
6. make
7. su
8. make test
9. ls -l /dev/null

/dev/null goes from being a special character device to
a normal file of length zero.

The following command can be used instead of step 8
above to delete /dev/null
./python -c 'import ctypes.test.test_find'


To recreate /dev/null:
1. su
2. rm /dev/null
3. mknod -m 666 /dev/null c 1 3
4. chown root:root /dev/null

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521375&group_id=5470

From noreply at sourceforge.net  Wed Jul 12 20:53:43 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 12 Jul 2006 11:53:43 -0700
Subject: [ python-Bugs-1521375 ] ctypes test overwrites /dev/null
Message-ID: <E1G0jqB-0003aY-Hf@sc8-sf-web3.sourceforge.net>

Bugs item #1521375, was opened at 2006-07-12 20:22
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521375&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Scot Doyle (scotdoyle)
>Assigned to: Thomas Heller (theller)
Summary: ctypes test overwrites /dev/null

Initial Comment:
Steps to reproduce on Debian Sarge:
1. ls -l /dev/null
2. wget
http://www.python.org/ftp/python/2.5/Python-2.5b2.tgz
3. tar xvzf Pyth*
4. cd Pyth*
5. ./configure
6. make
7. su
8. make test
9. ls -l /dev/null

/dev/null goes from being a special character device to
a normal file of length zero.

The following command can be used instead of step 8
above to delete /dev/null
./python -c 'import ctypes.test.test_find'


To recreate /dev/null:
1. su
2. rm /dev/null
3. mknod -m 666 /dev/null c 1 3
4. chown root:root /dev/null

----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2006-07-12 20:53

Message:
Logged In: YES 
user_id=11105

Now, that is an 'interesting' bug.  ctypes.util.find_library
does execute shell commands that happen to have '/dev/null'
in them, but it is completely unclear to me how one can
overwrite /dev/null (even if root).  Can you see anything
that's wrong there (That code is not from me, and I'm not at
all an expert in linux programming)?

BTW, I cannot reproduce this on ubuntu with 'sudo ./python
-c "import ctypes.test.test_find"'.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521375&group_id=5470

From noreply at sourceforge.net  Thu Jul 13 00:04:18 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 12 Jul 2006 15:04:18 -0700
Subject: [ python-Bugs-1521491 ] file.seek() influelce write() when opened
	with a+ mode
Message-ID: <E1G0moc-0004G0-Uf@sc8-sf-web5.sourceforge.net>

Bugs item #1521491, was opened at 2006-07-12 22: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=1521491&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Lior (rudnik_lior)
Assigned to: Nobody/Anonymous (nobody)
Summary: file.seek() influelce write() when opened with a+ mode

Initial Comment:
Python 2.5b1 (r25b1:47027, Jun 20 2006, 09:31:33)

Assuming documentation is correct: (from seek() help
"Note that if the file is opened for appending (mode
'a' or 'a+'), any seek() operations will be undone at
the next write"

Doing the following is __not__ undoing the seek
operation after calling this a few times (Simplified
code snippet):

from __future__ import with_statement
with open(path,'a+') as f:
    f.seek(0,2) # go to end
    pos = f.tell() 
    f.seek(0,0)
    line = f.readline().strip()
    f.seek(0,2) # go to end, not effective if opened
with mode a/a+ (currently bug?)
    f.write("something")

Calling the above code repeatedly didnt increase the
file size beyond 166 bytes (in my code)



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521491&group_id=5470

From noreply at sourceforge.net  Thu Jul 13 00:09:04 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 12 Jul 2006 15:09:04 -0700
Subject: [ python-Bugs-1521491 ] file.seek() influelce write() when opened
	with a+ mode
Message-ID: <E1G0mtE-0002mD-0F@sc8-sf-web6.sourceforge.net>

Bugs item #1521491, was opened at 2006-07-12 22:04
Message generated for change (Comment added) made by rudnik_lior
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521491&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Lior (rudnik_lior)
Assigned to: Nobody/Anonymous (nobody)
Summary: file.seek() influelce write() when opened with a+ mode

Initial Comment:
Python 2.5b1 (r25b1:47027, Jun 20 2006, 09:31:33)

Assuming documentation is correct: (from seek() help
"Note that if the file is opened for appending (mode
'a' or 'a+'), any seek() operations will be undone at
the next write"

Doing the following is __not__ undoing the seek
operation after calling this a few times (Simplified
code snippet):

from __future__ import with_statement
with open(path,'a+') as f:
    f.seek(0,2) # go to end
    pos = f.tell() 
    f.seek(0,0)
    line = f.readline().strip()
    f.seek(0,2) # go to end, not effective if opened
with mode a/a+ (currently bug?)
    f.write("something")

Calling the above code repeatedly didnt increase the
file size beyond 166 bytes (in my code)



----------------------------------------------------------------------

>Comment By: Lior (rudnik_lior)
Date: 2006-07-12 22:09

Message:
Logged In: YES 
user_id=1364480

Re-tried the code with empty file - it doesnt grow beyond
creating and writting at position 0 so it seems the seek
does influence the write position.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521491&group_id=5470

From noreply at sourceforge.net  Thu Jul 13 00:17:40 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 12 Jul 2006 15:17:40 -0700
Subject: [ python-Bugs-1521375 ] ctypes test overwrites /dev/null
Message-ID: <E1G0n1Y-0002PP-Nx@sc8-sf-web5.sourceforge.net>

Bugs item #1521375, was opened at 2006-07-12 13:22
Message generated for change (Comment added) made by scotdoyle
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521375&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Scot Doyle (scotdoyle)
Assigned to: Thomas Heller (theller)
Summary: ctypes test overwrites /dev/null

Initial Comment:
Steps to reproduce on Debian Sarge:
1. ls -l /dev/null
2. wget
http://www.python.org/ftp/python/2.5/Python-2.5b2.tgz
3. tar xvzf Pyth*
4. cd Pyth*
5. ./configure
6. make
7. su
8. make test
9. ls -l /dev/null

/dev/null goes from being a special character device to
a normal file of length zero.

The following command can be used instead of step 8
above to delete /dev/null
./python -c 'import ctypes.test.test_find'


To recreate /dev/null:
1. su
2. rm /dev/null
3. mknod -m 666 /dev/null c 1 3
4. chown root:root /dev/null

----------------------------------------------------------------------

>Comment By: Scot Doyle (scotdoyle)
Date: 2006-07-12 17:17

Message:
Logged In: YES 
user_id=1554504

Hey Thomas, that pointer is just what I needed :-)

/dev/null was being deleted by gcc. Discussion at
http://www.cs.helsinki.fi/linux/linux-kernel/2001-38/1503.html 

The attached patch fixed the problem on Debian Sarge and
Ubuntu 6.06.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2006-07-12 13:53

Message:
Logged In: YES 
user_id=11105

Now, that is an 'interesting' bug.  ctypes.util.find_library
does execute shell commands that happen to have '/dev/null'
in them, but it is completely unclear to me how one can
overwrite /dev/null (even if root).  Can you see anything
that's wrong there (That code is not from me, and I'm not at
all an expert in linux programming)?

BTW, I cannot reproduce this on ubuntu with 'sudo ./python
-c "import ctypes.test.test_find"'.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521375&group_id=5470

From noreply at sourceforge.net  Thu Jul 13 07:59:11 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 12 Jul 2006 22:59:11 -0700
Subject: [ python-Bugs-1512814 ] Incorrect lineno's in code objects
Message-ID: <E1G0uEB-00008u-5i@sc8-sf-web6.sourceforge.net>

Bugs item #1512814, was opened at 2006-06-26 09:01
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512814&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.5
Status: Open
Resolution: None
Priority: 7
Submitted By: Thomas Wouters (twouters)
>Assigned to: Thomas Wouters (twouters)
Summary: Incorrect lineno's in code objects

Initial Comment:
The 2.5 compiler forgets how to count linenumbers in
certain situations:

>>> s255 = "".join(["\n"] * 255 + ["spam"])
>>> s256 = "".join(["\n"] * 256 + ["spam"])

>>> exec s255
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 256, in <module>
NameError: name 'spam' is not defined

>>> exec s256
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 1, in <module>
NameError: name 'spam' is not defined

Notice the 'line 1' linenumber in the case of 256 blank
lines. The same happens for 'pass' statements or 'if 0'
blocks instead of blank lines. The problem is in the
actual code objects created:

>>> dis.disco(compile(s255, "", "exec"))
256           0 LOAD_NAME                0 (spam)
              3 POP_TOP             
              4 LOAD_CONST               0 (None)
              7 RETURN_VALUE        
>>> dis.disco(compile(s256, "", "exec"))
  1           0 LOAD_NAME                0 (spam)
              3 POP_TOP             
              4 LOAD_CONST               0 (None)
              7 RETURN_VALUE        



----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-12 22:59

Message:
Logged In: YES 
user_id=33168

Try the attached patch on for size.  Let me know if you can
find any other holes.

----------------------------------------------------------------------

Comment By: Thomas Wouters (twouters)
Date: 2006-07-12 06:11

Message:
Logged In: YES 
user_id=34209

Unfortunately, it isn't quite fixed. It's fixed for code in
the global scope, but not for functions:

>>> s255 = "def foo():\n " + "".join(["\n "] * 254 + ["
spam\n"])
>>> exec s255
>>> dis.dis(foo)
.256           0 LOAD_GLOBAL              0 (spam)
.              3 POP_TOP             
.              4 LOAD_CONST               0 (None)
.              7 RETURN_VALUE        

>>> s256 = "def foo():\n " + "".join(["\n "] * 255 + ["
spam\n"])
>>> exec s256
>>> dis.dis(foo)
.  1           0 LOAD_GLOBAL              0 (spam)
.              3 POP_TOP             
.              4 LOAD_CONST               0 (None)
.              7 RETURN_VALUE        

I haven't tried figuring out for what else it's broken like
this, sorry :)


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-09 17:04

Message:
Logged In: YES 
user_id=33168

Committed revision 50500.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512814&group_id=5470

From noreply at sourceforge.net  Thu Jul 13 08:29:53 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 12 Jul 2006 23:29:53 -0700
Subject: [ python-Bugs-1521491 ] file.seek() influelce write() when opened
	with a+ mode
Message-ID: <E1G0uht-0003Aj-Qz@sc8-sf-web5.sourceforge.net>

Bugs item #1521491, was opened at 2006-07-12 15:04
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521491&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Lior (rudnik_lior)
Assigned to: Nobody/Anonymous (nobody)
Summary: file.seek() influelce write() when opened with a+ mode

Initial Comment:
Python 2.5b1 (r25b1:47027, Jun 20 2006, 09:31:33)

Assuming documentation is correct: (from seek() help
"Note that if the file is opened for appending (mode
'a' or 'a+'), any seek() operations will be undone at
the next write"

Doing the following is __not__ undoing the seek
operation after calling this a few times (Simplified
code snippet):

from __future__ import with_statement
with open(path,'a+') as f:
    f.seek(0,2) # go to end
    pos = f.tell() 
    f.seek(0,0)
    line = f.readline().strip()
    f.seek(0,2) # go to end, not effective if opened
with mode a/a+ (currently bug?)
    f.write("something")

Calling the above code repeatedly didnt increase the
file size beyond 166 bytes (in my code)



----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-12 23:29

Message:
Logged In: YES 
user_id=33168

This seems to work for me on Linux.  Maybe we are testing
differently.  What o/s and version are you using?  Does this
work with Python 2.4?  Can you attach a complete test case
that demonstrates this problem?

Thanks.

----------------------------------------------------------------------

Comment By: Lior (rudnik_lior)
Date: 2006-07-12 15:09

Message:
Logged In: YES 
user_id=1364480

Re-tried the code with empty file - it doesnt grow beyond
creating and writting at position 0 so it seems the seek
does influence the write position.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521491&group_id=5470

From noreply at sourceforge.net  Thu Jul 13 09:43:50 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 13 Jul 2006 00:43:50 -0700
Subject: [ python-Bugs-1521491 ] file.seek() influelce write() when opened
	with a+ mode
Message-ID: <E1G0vrS-00018k-U2@sc8-sf-web3.sourceforge.net>

Bugs item #1521491, was opened at 2006-07-12 22:04
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521491&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Lior (rudnik_lior)
Assigned to: Nobody/Anonymous (nobody)
Summary: file.seek() influelce write() when opened with a+ mode

Initial Comment:
Python 2.5b1 (r25b1:47027, Jun 20 2006, 09:31:33)

Assuming documentation is correct: (from seek() help
"Note that if the file is opened for appending (mode
'a' or 'a+'), any seek() operations will be undone at
the next write"

Doing the following is __not__ undoing the seek
operation after calling this a few times (Simplified
code snippet):

from __future__ import with_statement
with open(path,'a+') as f:
    f.seek(0,2) # go to end
    pos = f.tell() 
    f.seek(0,0)
    line = f.readline().strip()
    f.seek(0,2) # go to end, not effective if opened
with mode a/a+ (currently bug?)
    f.write("something")

Calling the above code repeatedly didnt increase the
file size beyond 166 bytes (in my code)



----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-13 07:43

Message:
Logged In: YES 
user_id=849994

I also cannot see any problem with the above code and can
append to a file indefinitely. What exactly are you
expecting the code to do, and what do you get? Which OS is this?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-13 06:29

Message:
Logged In: YES 
user_id=33168

This seems to work for me on Linux.  Maybe we are testing
differently.  What o/s and version are you using?  Does this
work with Python 2.4?  Can you attach a complete test case
that demonstrates this problem?

Thanks.

----------------------------------------------------------------------

Comment By: Lior (rudnik_lior)
Date: 2006-07-12 22:09

Message:
Logged In: YES 
user_id=1364480

Re-tried the code with empty file - it doesnt grow beyond
creating and writting at position 0 so it seems the seek
does influence the write position.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521491&group_id=5470

From noreply at sourceforge.net  Thu Jul 13 09:47:10 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 13 Jul 2006 00:47:10 -0700
Subject: [ python-Bugs-1519452 ] zipfile -- too many files?
Message-ID: <E1G0vug-0003PT-2w@sc8-sf-web4.sourceforge.net>

Bugs item #1519452, was opened at 2006-07-09 07:57
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519452&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Joe Brown (shmengie)
Assigned to: Nobody/Anonymous (nobody)
Summary: zipfile -- too many files?

Initial Comment:
While creating a huge zipfile (probably too big) the
following error appeared.

Exception exceptions.OverflowError: 'long int too large
to convert to int' in <bound method ZipFile.__del__ of
<zipfile.ZipFile instance at 0x009BD198>> ignored

I assume this is during the closing of the zipfile,
further assuming too many files were added to the archive.

----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-13 09:47

Message:
Logged In: YES 
user_id=580910

The problem with zipfile is not the number of files, but the size of the archive. 
The basic zip file format stores file sizes as 32 bit (signed) integers, there is an 
extension for using 64 bit integers, but that isn't supported in python 2.4.

----------------------------------------------------------------------

Comment By: Joe Brown (shmengie)
Date: 2006-07-12 04:17

Message:
Logged In: YES 
user_id=729883

Windows 2.5 beta 2 responded like this:

Traceback (most recent call last):
  File "C:\python_scripts\archive.py", line 27, in <module>
    main()
  File "C:\python_scripts\archive.py", line 23, in main
    zipper(zip, folder)
  File "C:\python_scripts\archive.py", line 15, in zipper
    zip.write(os.path.join(root, item))
  File "C:\Python25\lib\zipfile.py", line 561, in write
    self._writecheck(zinfo)
  File "C:\Python25\lib\zipfile.py", line 536, in _writecheck
    raise LargeZipFile("Zipfile size would require ZIP64
extensions")
zipfile.LargeZipFile: Zipfile size would require ZIP64
extensions
C:\Python25\lib\struct.py:63: DeprecationWarning: struct
integer overflow maskin
g is deprecated
  return o.pack(*args)

----------------------------------------------------------------------

Comment By: Joe Brown (shmengie)
Date: 2006-07-11 22:08

Message:
Logged In: YES 
user_id=729883

The zip file was on order of 6-9 GBs, surely over 32000
files.  I will give Python2.5 a shot and see how that works.

I've stumbled on another bug with tarfile.  It's not
reporting an error, but I only find 350 files when I
unarchive.  That's entirely different bug tho :-o

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-11 19:47

Message:
Logged In: YES 
user_id=580910

How large is the resulting file? Zipfile in python2.4 cannot handle zipfiles that 
require the zip64 extensions and fails misserably when you do cross that limit.

This was fixed in python 2.5.

----------------------------------------------------------------------

Comment By: Joe Brown (shmengie)
Date: 2006-07-09 08:01

Message:
Logged In: YES 
user_id=729883

Platform: Windows SBS 2003
Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit
(Intel)] on win32

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519452&group_id=5470

From noreply at sourceforge.net  Thu Jul 13 10:17:28 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 13 Jul 2006 01:17:28 -0700
Subject: [ python-Bugs-1519452 ] zipfile -- too many files?
Message-ID: <E1G0wO0-0007XY-5u@sc8-sf-web3.sourceforge.net>

Bugs item #1519452, was opened at 2006-07-09 07:57
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519452&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Joe Brown (shmengie)
Assigned to: Nobody/Anonymous (nobody)
Summary: zipfile -- too many files?

Initial Comment:
While creating a huge zipfile (probably too big) the
following error appeared.

Exception exceptions.OverflowError: 'long int too large
to convert to int' in <bound method ZipFile.__del__ of
<zipfile.ZipFile instance at 0x009BD198>> ignored

I assume this is during the closing of the zipfile,
further assuming too many files were added to the archive.

----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-13 10:17

Message:
Logged In: YES 
user_id=580910

hmm, I should read all new comments before responding :-(

To use the ZIP64 extensions with python2.5 you must add 'allowZip64=True' to 
arguments of the zipfile constructor. ZIP64 is disabled by default because the 
unix zip tools don't support zip64.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-13 09:47

Message:
Logged In: YES 
user_id=580910

The problem with zipfile is not the number of files, but the size of the archive. 
The basic zip file format stores file sizes as 32 bit (signed) integers, there is an 
extension for using 64 bit integers, but that isn't supported in python 2.4.

----------------------------------------------------------------------

Comment By: Joe Brown (shmengie)
Date: 2006-07-12 04:17

Message:
Logged In: YES 
user_id=729883

Windows 2.5 beta 2 responded like this:

Traceback (most recent call last):
  File "C:\python_scripts\archive.py", line 27, in <module>
    main()
  File "C:\python_scripts\archive.py", line 23, in main
    zipper(zip, folder)
  File "C:\python_scripts\archive.py", line 15, in zipper
    zip.write(os.path.join(root, item))
  File "C:\Python25\lib\zipfile.py", line 561, in write
    self._writecheck(zinfo)
  File "C:\Python25\lib\zipfile.py", line 536, in _writecheck
    raise LargeZipFile("Zipfile size would require ZIP64
extensions")
zipfile.LargeZipFile: Zipfile size would require ZIP64
extensions
C:\Python25\lib\struct.py:63: DeprecationWarning: struct
integer overflow maskin
g is deprecated
  return o.pack(*args)

----------------------------------------------------------------------

Comment By: Joe Brown (shmengie)
Date: 2006-07-11 22:08

Message:
Logged In: YES 
user_id=729883

The zip file was on order of 6-9 GBs, surely over 32000
files.  I will give Python2.5 a shot and see how that works.

I've stumbled on another bug with tarfile.  It's not
reporting an error, but I only find 350 files when I
unarchive.  That's entirely different bug tho :-o

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-11 19:47

Message:
Logged In: YES 
user_id=580910

How large is the resulting file? Zipfile in python2.4 cannot handle zipfiles that 
require the zip64 extensions and fails misserably when you do cross that limit.

This was fixed in python 2.5.

----------------------------------------------------------------------

Comment By: Joe Brown (shmengie)
Date: 2006-07-09 08:01

Message:
Logged In: YES 
user_id=729883

Platform: Windows SBS 2003
Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit
(Intel)] on win32

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519452&group_id=5470

From noreply at sourceforge.net  Thu Jul 13 10:28:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 13 Jul 2006 01:28:46 -0700
Subject: [ python-Bugs-1521375 ] ctypes test overwrites /dev/null
Message-ID: <E1G0wYw-0001kC-D8@sc8-sf-web6.sourceforge.net>

Bugs item #1521375, was opened at 2006-07-12 20:22
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521375&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Scot Doyle (scotdoyle)
Assigned to: Thomas Heller (theller)
Summary: ctypes test overwrites /dev/null

Initial Comment:
Steps to reproduce on Debian Sarge:
1. ls -l /dev/null
2. wget
http://www.python.org/ftp/python/2.5/Python-2.5b2.tgz
3. tar xvzf Pyth*
4. cd Pyth*
5. ./configure
6. make
7. su
8. make test
9. ls -l /dev/null

/dev/null goes from being a special character device to
a normal file of length zero.

The following command can be used instead of step 8
above to delete /dev/null
./python -c 'import ctypes.test.test_find'


To recreate /dev/null:
1. su
2. rm /dev/null
3. mknod -m 666 /dev/null c 1 3
4. chown root:root /dev/null

----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2006-07-13 10:28

Message:
Logged In: YES 
user_id=11105

Scot, your patch is not correct because 'cmd' is never
executed.  However, I was able to reproduce the overwriting
of /dev/null by calling 'ctypes.util.find_library' for a
shared lib that does not exist.  Attached is a new patch
'util.diff' which fixes the problem for me.  Can you please
verify that it also works for you?

Thanks for finding the bug and locating the problem!

----------------------------------------------------------------------

Comment By: Scot Doyle (scotdoyle)
Date: 2006-07-13 00:17

Message:
Logged In: YES 
user_id=1554504

Hey Thomas, that pointer is just what I needed :-)

/dev/null was being deleted by gcc. Discussion at
http://www.cs.helsinki.fi/linux/linux-kernel/2001-38/1503.html 

The attached patch fixed the problem on Debian Sarge and
Ubuntu 6.06.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2006-07-12 20:53

Message:
Logged In: YES 
user_id=11105

Now, that is an 'interesting' bug.  ctypes.util.find_library
does execute shell commands that happen to have '/dev/null'
in them, but it is completely unclear to me how one can
overwrite /dev/null (even if root).  Can you see anything
that's wrong there (That code is not from me, and I'm not at
all an expert in linux programming)?

BTW, I cannot reproduce this on ubuntu with 'sudo ./python
-c "import ctypes.test.test_find"'.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521375&group_id=5470

From noreply at sourceforge.net  Thu Jul 13 11:58:52 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 13 Jul 2006 02:58:52 -0700
Subject: [ python-Bugs-1512814 ] Incorrect lineno's in code objects
Message-ID: <E1G0xy8-0003E5-Jx@sc8-sf-web5.sourceforge.net>

Bugs item #1512814, was opened at 2006-06-26 18:01
Message generated for change (Comment added) made by twouters
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512814&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.5
Status: Open
Resolution: None
Priority: 7
Submitted By: Thomas Wouters (twouters)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: Incorrect lineno's in code objects

Initial Comment:
The 2.5 compiler forgets how to count linenumbers in
certain situations:

>>> s255 = "".join(["\n"] * 255 + ["spam"])
>>> s256 = "".join(["\n"] * 256 + ["spam"])

>>> exec s255
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 256, in <module>
NameError: name 'spam' is not defined

>>> exec s256
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 1, in <module>
NameError: name 'spam' is not defined

Notice the 'line 1' linenumber in the case of 256 blank
lines. The same happens for 'pass' statements or 'if 0'
blocks instead of blank lines. The problem is in the
actual code objects created:

>>> dis.disco(compile(s255, "", "exec"))
256           0 LOAD_NAME                0 (spam)
              3 POP_TOP             
              4 LOAD_CONST               0 (None)
              7 RETURN_VALUE        
>>> dis.disco(compile(s256, "", "exec"))
  1           0 LOAD_NAME                0 (spam)
              3 POP_TOP             
              4 LOAD_CONST               0 (None)
              7 RETURN_VALUE        



----------------------------------------------------------------------

>Comment By: Thomas Wouters (twouters)
Date: 2006-07-13 11:58

Message:
Logged In: YES 
user_id=34209

Yep, the patch seems to work, also for the other case
someone pointed out to me, that was still broken after the
last fix:

>>> exec "import os\ns='''" + "\n"*256 + "'''\n1/0\n"
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 1, in <module>
ZeroDivisionError: integer division or modulo by zero

I tried a couple of other ways to get large linenumbers and
complex(er) parsing structures, and they all seem to work right.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-13 07:59

Message:
Logged In: YES 
user_id=33168

Try the attached patch on for size.  Let me know if you can
find any other holes.

----------------------------------------------------------------------

Comment By: Thomas Wouters (twouters)
Date: 2006-07-12 15:11

Message:
Logged In: YES 
user_id=34209

Unfortunately, it isn't quite fixed. It's fixed for code in
the global scope, but not for functions:

>>> s255 = "def foo():\n " + "".join(["\n "] * 254 + ["
spam\n"])
>>> exec s255
>>> dis.dis(foo)
.256           0 LOAD_GLOBAL              0 (spam)
.              3 POP_TOP             
.              4 LOAD_CONST               0 (None)
.              7 RETURN_VALUE        

>>> s256 = "def foo():\n " + "".join(["\n "] * 255 + ["
spam\n"])
>>> exec s256
>>> dis.dis(foo)
.  1           0 LOAD_GLOBAL              0 (spam)
.              3 POP_TOP             
.              4 LOAD_CONST               0 (None)
.              7 RETURN_VALUE        

I haven't tried figuring out for what else it's broken like
this, sorry :)


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-10 02:04

Message:
Logged In: YES 
user_id=33168

Committed revision 50500.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512814&group_id=5470

From noreply at sourceforge.net  Thu Jul 13 12:09:18 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 13 Jul 2006 03:09:18 -0700
Subject: [ python-Bugs-1519816 ] urllib2 proxy does not work in 2.4.3 and 2.5b
Message-ID: <E1G0y8E-0004S8-Qz@sc8-sf-web3.sourceforge.net>

Bugs item #1519816, was opened at 2006-07-10 10:29
Message generated for change (Comment added) made by mniklas
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519816&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
>Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Michal Niklas (mniklas)
Assigned to: Nobody/Anonymous (nobody)
>Summary: urllib2 proxy does not work in 2.4.3 and 2.5b

Initial Comment:
My python app had to retrieve some web pages and while 
our network environment requires proxy it uses urllib2 
opener (source is in attachment). It worked very well 
on older Python interpreters:
ActivePython 2.4.2 Build 248 (ActiveState Corp.) based 
on
Python 2.4.2 (#67, Oct 30 2005, 16:11:18) [MSC v.1310 
32 bit (Intel)] on win32

It works on linux with 2.3 and 2.4.1:
Python 2.4.1 (#2, May 5 2005, 11:32:06)
[GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2

But it does not work with newest 2.4.3 on Linux:
Python 2.4.3 (#1, Jul 10 2006, 09:57:52)
[GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2

Desired result:
isof-mark:~# python2.3 proxy_bug.py
trying http://www.python.org ...
OK.  We have reply from http://www.python.org.
Size: 13757 [b]
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 
Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/
xhtml1-transitional.dtd">
<html lang="en" xml:lang="en" xmlns="http://www.w3.org/
1999/xhtml">
<head>
<me
...
 Yorkshire">design by pollenation</a>
</div>
Copyright ???? 1990-2006, <a href="psf">Python Software 
Foundation</a><br />
<a href="about/legal">Legal Statements</a>
</div>
</div>
</div>
</body>
</html>


isof-mark:~# /usr/local/bin/python proxy_bug.py
trying http://www.python.org ...
Traceback (most recent call last):
  File "proxy_bug.py", line 37, in ?
    get_page()
  File "proxy_bug.py", line 27, in get_page
    f = urllib2.urlopen(request)
  File "/usr/local/lib/python2.4/urllib2.py", line 
130, in urlopen
    return _opener.open(url, data)
  File "/usr/local/lib/python2.4/urllib2.py", line 
364, in open
    response = meth(req, response)
  File "/usr/local/lib/python2.4/urllib2.py", line 
471, in http_response
    response = self.parent.error(
  File "/usr/local/lib/python2.4/urllib2.py", line 
402, in error
    return self._call_chain(*args)
  File "/usr/local/lib/python2.4/urllib2.py", line 
337, in _call_chain
    result = func(*args)
  File "/usr/local/lib/python2.4/urllib2.py", line 
480, in http_error_default
    raise HTTPError(req.get_full_url(), code, msg, 
hdrs, fp)
urllib2.HTTPError: HTTP Error 407: Proxy 
Authentication Required

I have raported it on ActiveState bug list (http://
bugs.activestate.com/show_bug.cgi?id=47018) while I 
first spot this bug on their destribution but it seems 
that bug is in others distributions too.

Regards,
Michal Niklas


----------------------------------------------------------------------

>Comment By: Michal Niklas (mniklas)
Date: 2006-07-13 12:09

Message:
Logged In: YES 
user_id=226518

2.5b2 does not work any better:
Python 2.5b2 (r25b2:50512, Jul 11 2006, 10:16:14) [MSC 
v.1310 32 bit (Intel)] on win32

Result is the same as in 2.5b1 :(


----------------------------------------------------------------------

Comment By: Michal Niklas (mniklas)
Date: 2006-07-11 08:27

Message:
Logged In: YES 
user_id=226518

Tried it with 2.5 beta 1 and it is not better :(

c:\tools\pyscripts\scripts>c:\python25\python2.5
Python 2.5b1 (r25b1:47027, Jun 20 2006, 09:31:33) [MSC 
v.1310 32 bit (Intel)] on win32


c:\tools\pyscripts\scripts>c:\python25\python2.5 
proxy_bug.py
trying http://www.python.org ...
Traceback (most recent call last):
  File "proxy_bug.py", line 37, in <module>
    get_page()
  File "proxy_bug.py", line 27, in get_page
    f = urllib2.urlopen(request)
  File "c:\python25\lib\urllib2.py", line 121, in urlopen
    return _opener.open(url, data)
  File "c:\python25\lib\urllib2.py", line 380, in open
    response = meth(req, response)
  File "c:\python25\lib\urllib2.py", line 491, in 
http_response
    'http', request, response, code, msg, hdrs)
  File "c:\python25\lib\urllib2.py", line 412, in error
    result = self._call_chain(*args)
  File "c:\python25\lib\urllib2.py", line 353, in 
_call_chain
    result = func(*args)
  File "c:\python25\lib\urllib2.py", line 831, in 
http_error_407
    authority, req, headers)
  File "c:\python25\lib\urllib2.py", line 795, in 
http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "c:\python25\lib\urllib2.py", line 805, in 
retry_http_basic_auth
    return self.parent.open(req)
  File "c:\python25\lib\urllib2.py", line 380, in open
    response = meth(req, response)
  File "c:\python25\lib\urllib2.py", line 491, in 
http_response
    'http', request, response, code, msg, hdrs)
  File "c:\python25\lib\urllib2.py", line 418, in error
    return self._call_chain(*args)
  File "c:\python25\lib\urllib2.py", line 353, in 
_call_chain
    result = func(*args)
  File "c:\python25\lib\urllib2.py", line 499, in 
http_error_default
    raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
urllib2.HTTPError: HTTP Error 407: Proxy Authentication 
Required

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-07-10 14:49

Message:
Logged In: YES 
user_id=849994

Can you please try with 2.5b1? A lot of urllib2 related bugs
have been fixed before this release.

----------------------------------------------------------------------

Comment By: Michal Niklas (mniklas)
Date: 2006-07-10 10:41

Message:
Logged In: YES 
user_id=226518

Cannot add attachment via upload so I put it here:
#!/usr/bin/python
# -*- coding: cp1250 -*-

import urllib
import urllib2

def get_page():
	url = 'http://www.python.org'
	print "trying %s ..." % (url)

	# Setup proxy & authentication
	proxy = "poczta.heuthes:8080"
	usr1 = "USER"
	pass1 = "PASSWD"
	proxy_handler = urllib2.ProxyHandler({"http" : "http:/
/" + proxy})
	pass_mgr = urllib2.HTTPPasswordMgrWithDefaultRealm()
	pass_mgr.add_password(None, "http://" + proxy, usr1, 
pass1)
	pass_mgr.add_password(None, proxy, usr1, pass1)
	auth_handler = urllib2.HTTPBasicAuthHandler(pass_mgr)
	proxy_auth_handler = 
urllib2.ProxyBasicAuthHandler(pass_mgr)

	# Now build a new URL opener and install it
	opener = urllib2.build_opener(proxy_handler, 
proxy_auth_handler, auth_handler, urllib2.HTTPHandler)
	urllib2.install_opener(opener)

	request = urllib2.Request(url)
	f = urllib2.urlopen(request)
	data = f.read()
	print "OK.  We have reply from %s.\nSize: %d [b]" % 
(url, len(data))
	if len(data) < 400:
		print data
	else:
		print data[:200]
		print "..."
		print data[-200:]

get_page()


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519816&group_id=5470

From noreply at sourceforge.net  Thu Jul 13 12:35:39 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 13 Jul 2006 03:35:39 -0700
Subject: [ python-Bugs-1514428 ] NaN comparison in Decimal broken
Message-ID: <E1G0yXj-0000A4-4b@sc8-sf-web4.sourceforge.net>

Bugs item #1514428, was opened at 2006-06-29 16:19
Message generated for change (Comment added) made by nmm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514428&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Nick Maclaren (nmm)
Assigned to: Raymond Hettinger (rhettinger)
Summary: NaN comparison in Decimal broken

Initial Comment:
Methinks this is a bit off :-)  True should be False.


Python 2.5b1 (trunk:47059, Jun 29 2006, 14:26:46)
[GCC 4.1.0 (SUSE Linux)] on linux2
>>> import decimal
>>> d = decimal.Decimal
>>> inf = d("inf")
>>> nan = d("nan")
>>> nan > inf
True
>>> nan < inf
False
>>> inf > nan
True
>>> inf < nan
False
b

----------------------------------------------------------------------

>Comment By: Nick Maclaren (nmm)
Date: 2006-07-13 10:35

Message:
Logged In: YES 
user_id=42444

It's still there in Beta 2.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514428&group_id=5470

From noreply at sourceforge.net  Thu Jul 13 12:56:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 13 Jul 2006 03:56:23 -0700
Subject: [ python-Bugs-1521726 ] isinstance failure in 2.6 Beta 2
Message-ID: <E1G0yrn-00010n-5O@sc8-sf-web4.sourceforge.net>

Bugs item #1521726, was opened at 2006-07-13 10: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=1521726&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Submitted By: Nick Maclaren (nmm)
Assigned to: Nobody/Anonymous (nobody)
Summary: isinstance failure in 2.6 Beta 2

Initial Comment:
Linux gosset 2.6.16.13-4-smp #1 SMP Wed May 3 04:53:23
UTC 2006 x86_64 x86_64 x86_64 GNU/Linux
./python Lib/test/test_compile.py

  File "Lib/test/test_compile.py", line 6, in <module>
    class TestSpecifics(unittest.TestCase):
  File "Lib/test/test_compile.py", line 399, in test_main
    test_support.run_unittest(TestSpecifics)
  File
"/home/nmm/Python-2.5b2/Lib/test/test_support.py", line
422, in run_unittest
    run_suite(suite, testclass)
  File
"/home/nmm/Python-2.5b2/Lib/test/test_support.py", line
407, in run_suite    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent
call last):
  File "Lib/test/test_compile.py", line 226, in
test_unary_minus
    self.assertTrue(isinstance(eval("%s" % (-sys.maxint
- 1)), int))

./python
Python 2.5b2 (r25b2:50512, Jul 13 2006, 11:33:15)
>>> import sys
>>> print sys.maxint
9223372036854775807
>>> print "%s" % (-sys.maxint - 1)
-9223372036854775808
>>> print isinstance(eval("%s" % (-sys.maxint - 1)), int)
False
>>> print isinstance(eval("%s" % (-sys.maxint)), int)
True


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521726&group_id=5470

From noreply at sourceforge.net  Thu Jul 13 13:54:26 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 13 Jul 2006 04:54:26 -0700
Subject: [ python-Bugs-1469557 ] FTP modue functions are not re-entrant,
	give odd exceptions
Message-ID: <E1G0zly-0000GQ-JC@sc8-sf-web3.sourceforge.net>

Bugs item #1469557, was opened at 2006-04-13 02:13
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469557&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
>Resolution: Invalid
Priority: 5
Submitted By: Bruce (brucepeterson)
Assigned to: Nobody/Anonymous (nobody)
Summary: FTP modue functions are not re-entrant,give odd exceptions

Initial Comment:
 If I define a class using the Thread and FTP moudles, 
start a process which gathers FTP responses, 
additional calls to the class may have the responses 
of the thread instead of the main loop (or vice versa)
  This causes weird and unexpected exceptions from the 
ftplib.

  For instance I get the following error when the 
thread process does a pwd() function
error_reply: 213 34603008  

  The "213" reply is a response from the main process 
size() function

---------
Code
---------
from time import sleep
from threading import Thread

class ftpMachine(Thread, ftplib.FTP):
    def __init__(self, svr, user, passwd):
        Thread.__init__(self)
        ftplib.FTP.__init__(self, svr, user, passwd)
        
    def run(self):
        for x in xrange(20):
            output="Thread -"+str(self.nlst())[:30]
            print output
            sleep (0.0100)

def main():
    aCon = ftpMachine("LocalFTP", "user", "")
    aCon.start()
    for x in xrange(20):
        output = "Main -- " + str(aCon.size("File"))
        print output  
        sleep (0.010)

Workround:
  Rewrite code to create a third worker thread for 
response isolation?  Don't know that this would solve 
the problem.


---------------
Exception example
---------------

Exception in thread Thread-1:
Traceback (most recent call last):
  File "C:\Python24\lib\threading.py", line 442, in 
__bootstrap
    self.run()
  File "dualFTPIssue.py", line 17, in run
    output  = "Thread output " + str(self.nlst())[:30]
+" ..."
  File "C:\Python24\lib\ftplib.py", line 448, in nlst
    self.retrlines(cmd, files.append)
  File "C:\Python24\lib\ftplib.py", line 396, in 
retrlines
    conn = self.transfercmd(cmd)
  File "C:\Python24\lib\ftplib.py", line 345, in 
transfercmd
    return self.ntransfercmd(cmd, rest)[0]
  File "C:\Python24\lib\ftplib.py", line 321, in 
ntransfercmd
    host, port = self.makepasv()
  File "C:\Python24\lib\ftplib.py", line 299, in 
makepasv
    host, port = parse227(self.sendcmd('PASV'))
  File "C:\Python24\lib\ftplib.py", line 566, in 
parse227
    raise error_reply, resp
error_reply: 213 34603008

----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-13 13:54

Message:
Logged In: YES 
user_id=580910

IMHO this isn't a bug, your accessing a shared resource (the FTP connection) 
from two threads without locking. Most of python's libraries aren't safe for this 
kind of use.

BTW. The fact that you subclass form thread and ftplib.FTP is immaterial, you 
will get the same effect if you create an ftplib.FTP and then use it in two threads.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469557&group_id=5470

From noreply at sourceforge.net  Thu Jul 13 14:04:55 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 13 Jul 2006 05:04:55 -0700
Subject: [ python-Bugs-1514420 ] Missing module code does spurious file search
Message-ID: <E1G0zw7-0005rp-Oi@sc8-sf-web4.sourceforge.net>

Bugs item #1514420, was opened at 2006-06-29 18:13
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514420&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Nick Maclaren (nmm)
Assigned to: Nobody/Anonymous (nobody)
Summary: Missing module code does spurious file search

Initial Comment:
Now, exactly WHY is it looking for a file called
<stdin>? :-)

This bug has been present since at least 2.3.3 - I
can't be bothered to
check back further.  Not surprisingly, it causes
misbehaviour if there
is a file called <stdin> in any of the places searched,
but it doesn't
strike me as the world's most catastrophic bug.



strace -e open python
Python 2.5b1 (trunk:47059, Jun 29 2006, 14:26:46)
[GCC 4.1.0 (SUSE Linux)] on linux2
>>> import dismal
open("dismal.so", O_RDONLY)             = -1 ENOENT (No
such file or directory)open("dismalmodule.so",
O_RDONLY)       = -1 ENOENT (No such file or directory)
open("dismal.py", O_RDONLY)             = -1 ENOENT (No
such file or directory)
open("dismal.pyc", O_RDONLY)            = -1 ENOENT (No
such file or directory)
open("/home/nmm/Python_2.5/lib/python2.5/dismal.so",
O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/nmm/Python_2.5/lib/python2.5/<stdin>",
O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/nmm/Python_2.5/lib/python2.5/plat-linux2/<stdin>",
O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/nmm/Python_2.5/lib/python2.5/lib-tk/<stdin>",
O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/nmm/Python_2.5/lib/python2.5/lib-dynload/<stdin>",
O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/nmm/Python_2.5/lib/python2.5/site-packages/<stdin>",
O_RDONLY) = -1 ENOENT (No such file or directory)
  File "<stdin>", line 1, in <module>
ImportError: No module named dismal
>>>


----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-13 14:04

Message:
Logged In: YES 
user_id=580910

It's probably looking for a file named <stdin> because the co_filename 
attribute for code that's executed from the interactive prompt has that value:

>>> import sys
>>> f = sys._getframe(0)
>>> f.f_code.co_filename
'<stdin>'

I agree that looking for that file is rather pointless and a bug.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514420&group_id=5470

From noreply at sourceforge.net  Thu Jul 13 15:56:59 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 13 Jul 2006 06:56:59 -0700
Subject: [ python-Bugs-1521375 ] ctypes test overwrites /dev/null
Message-ID: <E1G11gZ-00028y-A5@sc8-sf-web5.sourceforge.net>

Bugs item #1521375, was opened at 2006-07-12 13:22
Message generated for change (Comment added) made by scotdoyle
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521375&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Scot Doyle (scotdoyle)
Assigned to: Thomas Heller (theller)
Summary: ctypes test overwrites /dev/null

Initial Comment:
Steps to reproduce on Debian Sarge:
1. ls -l /dev/null
2. wget
http://www.python.org/ftp/python/2.5/Python-2.5b2.tgz
3. tar xvzf Pyth*
4. cd Pyth*
5. ./configure
6. make
7. su
8. make test
9. ls -l /dev/null

/dev/null goes from being a special character device to
a normal file of length zero.

The following command can be used instead of step 8
above to delete /dev/null
./python -c 'import ctypes.test.test_find'


To recreate /dev/null:
1. su
2. rm /dev/null
3. mknod -m 666 /dev/null c 1 3
4. chown root:root /dev/null

----------------------------------------------------------------------

>Comment By: Scot Doyle (scotdoyle)
Date: 2006-07-13 08:56

Message:
Logged In: YES 
user_id=1554504

Yes, not executing the command was one way to fix the bug :-)

Thanks for catching that. I verified the new patch to work.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2006-07-13 03:28

Message:
Logged In: YES 
user_id=11105

Scot, your patch is not correct because 'cmd' is never
executed.  However, I was able to reproduce the overwriting
of /dev/null by calling 'ctypes.util.find_library' for a
shared lib that does not exist.  Attached is a new patch
'util.diff' which fixes the problem for me.  Can you please
verify that it also works for you?

Thanks for finding the bug and locating the problem!

----------------------------------------------------------------------

Comment By: Scot Doyle (scotdoyle)
Date: 2006-07-12 17:17

Message:
Logged In: YES 
user_id=1554504

Hey Thomas, that pointer is just what I needed :-)

/dev/null was being deleted by gcc. Discussion at
http://www.cs.helsinki.fi/linux/linux-kernel/2001-38/1503.html 

The attached patch fixed the problem on Debian Sarge and
Ubuntu 6.06.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2006-07-12 13:53

Message:
Logged In: YES 
user_id=11105

Now, that is an 'interesting' bug.  ctypes.util.find_library
does execute shell commands that happen to have '/dev/null'
in them, but it is completely unclear to me how one can
overwrite /dev/null (even if root).  Can you see anything
that's wrong there (That code is not from me, and I'm not at
all an expert in linux programming)?

BTW, I cannot reproduce this on ubuntu with 'sudo ./python
-c "import ctypes.test.test_find"'.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521375&group_id=5470

From noreply at sourceforge.net  Thu Jul 13 19:39:52 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 13 Jul 2006 10:39:52 -0700
Subject: [ python-Bugs-1521947 ] possible bug in mystrtol.c with recent gcc
Message-ID: <E1G15AG-0004Tj-Jm@sc8-sf-web3.sourceforge.net>

Bugs item #1521947, was opened at 2006-07-13 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=1521947&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Marien Zwart (marienz)
Assigned to: Nobody/Anonymous (nobody)
Summary: possible bug in mystrtol.c with recent gcc

Initial Comment:
python 2.5b2 compiled with gentoo's gcc 4.1.1 and -O2
fails test_unary_minus in test_compile.py. Some
investigating showed that the -ftree-vrp pass of that
gcc (implied by -O2) optimizes out the "result ==
-result" test on line 215 of PyOS_strtol, meaning
PyOS_strtol of the most negative long will incorrectly
overflow. 

Python deals with this in this case by constructing a
python long object instead of a python int object, so
at least in this case the problem is not serious. I
have no idea if there is a case where this is a "real"
problem.

At first I reported this as a gentoo compiler bug, but
got the reply that:

"""
I'm pretty sure it's broken. -LONG_MIN overflows when
LONG_MIN < -LONG_MAX, and in standard C as well as "GNU
C", behaviour after overflow on signed integer
operations is undefined.
"""

(see https://bugs.gentoo.org/show_bug.cgi?id=140133)

So now I'm reporting this here. There seems to be a
LONG_MIN constant in limits.h here that could checked
against instead, but I have absolutely no idea how
standard that is. Or this could be a compiler bug after
all, in which case I would appreciate information I Can
use to back that up :)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521947&group_id=5470

From noreply at sourceforge.net  Thu Jul 13 19:44:33 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 13 Jul 2006 10:44:33 -0700
Subject: [ python-Bugs-1521950 ] shlex.split() does not tokenize like the shell
Message-ID: <E1G15En-0000ug-8n@sc8-sf-web5.sourceforge.net>

Bugs item #1521950, was opened at 2006-07-13 10: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=1521950&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Dan Christian (robodan)
Assigned to: Nobody/Anonymous (nobody)
Summary: shlex.split() does not tokenize like the shell

Initial Comment:
When shlex.split defines tokens, it doesn't properly
interpret ';', '&', and '&&'.  These should always be
place in a separate token (unless inside a string).

The shell treats the following as identical cases, but
shlex.split doesn't:

echo hi&&echo bye
echo hi && echo bye

echo hi;echo bye
echo hi ; echo bye

echo hi&echo bye
echo hi & echo bye

shlex.split makes these cases ambiguous:

echo 'foo&'
echo foo&

echo '&&exit'
echo &&exit


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521950&group_id=5470

From noreply at sourceforge.net  Thu Jul 13 19:44:49 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 13 Jul 2006 10:44:49 -0700
Subject: [ python-Bugs-1521375 ] ctypes test overwrites /dev/null
Message-ID: <E1G15F3-0005Rt-1c@sc8-sf-web6.sourceforge.net>

Bugs item #1521375, was opened at 2006-07-12 20:22
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521375&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Scot Doyle (scotdoyle)
Assigned to: Thomas Heller (theller)
Summary: ctypes test overwrites /dev/null

Initial Comment:
Steps to reproduce on Debian Sarge:
1. ls -l /dev/null
2. wget
http://www.python.org/ftp/python/2.5/Python-2.5b2.tgz
3. tar xvzf Pyth*
4. cd Pyth*
5. ./configure
6. make
7. su
8. make test
9. ls -l /dev/null

/dev/null goes from being a special character device to
a normal file of length zero.

The following command can be used instead of step 8
above to delete /dev/null
./python -c 'import ctypes.test.test_find'


To recreate /dev/null:
1. su
2. rm /dev/null
3. mknod -m 666 /dev/null c 1 3
4. chown root:root /dev/null

----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2006-07-13 19:44

Message:
Logged In: YES 
user_id=11105

Thanks.  Commited as r50619.

----------------------------------------------------------------------

Comment By: Scot Doyle (scotdoyle)
Date: 2006-07-13 15:56

Message:
Logged In: YES 
user_id=1554504

Yes, not executing the command was one way to fix the bug :-)

Thanks for catching that. I verified the new patch to work.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2006-07-13 10:28

Message:
Logged In: YES 
user_id=11105

Scot, your patch is not correct because 'cmd' is never
executed.  However, I was able to reproduce the overwriting
of /dev/null by calling 'ctypes.util.find_library' for a
shared lib that does not exist.  Attached is a new patch
'util.diff' which fixes the problem for me.  Can you please
verify that it also works for you?

Thanks for finding the bug and locating the problem!

----------------------------------------------------------------------

Comment By: Scot Doyle (scotdoyle)
Date: 2006-07-13 00:17

Message:
Logged In: YES 
user_id=1554504

Hey Thomas, that pointer is just what I needed :-)

/dev/null was being deleted by gcc. Discussion at
http://www.cs.helsinki.fi/linux/linux-kernel/2001-38/1503.html 

The attached patch fixed the problem on Debian Sarge and
Ubuntu 6.06.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2006-07-12 20:53

Message:
Logged In: YES 
user_id=11105

Now, that is an 'interesting' bug.  ctypes.util.find_library
does execute shell commands that happen to have '/dev/null'
in them, but it is completely unclear to me how one can
overwrite /dev/null (even if root).  Can you see anything
that's wrong there (That code is not from me, and I'm not at
all an expert in linux programming)?

BTW, I cannot reproduce this on ubuntu with 'sudo ./python
-c "import ctypes.test.test_find"'.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521375&group_id=5470

From noreply at sourceforge.net  Thu Jul 13 21:25:20 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 13 Jul 2006 12:25:20 -0700
Subject: [ python-Bugs-1522016 ] filter() doesn't use __len__ of
	str/unicode/tuple subclasses
Message-ID: <E1G16oK-0001q1-2A@sc8-sf-web4.sourceforge.net>

Bugs item #1522016, was opened at 2006-07-13 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=1522016&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Collin Winter (collinwinter)
Assigned to: Nobody/Anonymous (nobody)
Summary: filter() doesn't use __len__ of str/unicode/tuple subclasses

Initial Comment:
Consider the following code:

>>> class badstr(str):
...     def __len__(self):
...         return 6
...     def __getitem__(self, index):
...         return "a"
...
>>> filter(None, badstr("bbb"))
'aaa'

I would have expected the answer to be 'aaaaaa'.

The cause for this is that
Python/bltinmodule.c:filter{string,unicode,tuple} all
call PyString_Size (or the appropriate equivalent),
even if the sequence is a subclass of one of these
types. This bypasses any overloading of __len__ done by
the subclass, as demonstrated above.

If filter() is going to respect the subclass's
__getitem__ overload, it should also respect
overloading of __len__. The attached patch corrects this.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1522016&group_id=5470

From noreply at sourceforge.net  Thu Jul 13 21:26:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 13 Jul 2006 12:26:24 -0700
Subject: [ python-Bugs-1517509 ] filter() implementation does not match docs
Message-ID: <E1G16pM-0002J7-VL@sc8-sf-web4.sourceforge.net>

Bugs item #1517509, was opened at 2006-07-05 09:09
Message generated for change (Comment added) made by collinwinter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517509&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Collin Winter (collinwinter)
Assigned to: Nobody/Anonymous (nobody)
Summary: filter() implementation does not match docs

Initial Comment:
The docs for the built-in function filter() claim that
"filter(function, list) is equivalent to [item for item
in list if function(item)] if function is not None and
[item for item in list if item] if function is None".

>>> class infinite_str(str):
...     def __getitem__(self, index):
...         return "a"
...
>>> filter(None, infinite_str("1234"))
'aaaa'


Now, if we translate this to a listcomp according to
the docs:

>>> [x for x in infinite_str("1234") if x]

The listcomp version proceeds to chew up memory until
it exhausts the system resources or is killed by the user.

If the docs are to be believed, the filter() version
should do the same thing. 

----------------------------------------------------------------------

>Comment By: Collin Winter (collinwinter)
Date: 2006-07-13 15:26

Message:
Logged In: YES 
user_id=1344176

I've posted a patch for the __len__ issue; it's SF #1522016.

----------------------------------------------------------------------

Comment By: Collin Winter (collinwinter)
Date: 2006-07-05 11:16

Message:
Logged In: YES 
user_id=1344176

I wasn't just reviewing the docs; I came upon this while
re-implementing filter() in pure Python for a compatibility
module I'm working on. I discovered this particular
implementation detail when my naive implementation (as a
listcomp) didn't pass test_builtin.

My question is why filter() even cares about __len__, ie,
why it doesn't simply use the iterator protocol. This is
especially curious since filter() actively ignores the
iterator protocol when dealing with subclasses of str,
unicode and tuple:

>>> class badstr(str):
...     def __len__(self):
...         return 4
...     def __getitem__(self, index):
...         return "a"
...     def __iter__(self):
...         for i in range(5):
...             yield "b"
...
>>> filter(None, badseq("cccc"))
aaaa
>>> [x for x in badseq("cccc") if x]
['b', 'b', 'b', 'b', 'b']

Ignore the difference in return types (which is expected),
these two do not do the same thing; filter() uses a
combination of __len__ and __getitem__ while the listcomp
version uses the iterator protocol.

Clearly, in this case, "is equivalent to" means "bears only
a superficial relationship to".

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-07-05 10:58

Message:
Logged In: YES 
user_id=80475

Please take a larger view when reviewing the docs. 
The listcomp analogy is very helpful in explaining what 
filter() does and readers would not benefit by its removal.

Throughtout the docs, the phrase "is equivalent to" does 
not mean "is identical to" or "exactly the same as".   In 
this case, you have isolated a non-guaranteed 
implementation detail that is almost always irrelevant.  
When an object such as infinite_str lies about its length, 
the consequent behavior is undefined.  It is not hard to 
produce weird results when objects violate basic 
invariants such as len(istr)!=len(list(istr)) or the 
expected relation between __eq__ and __hash__.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517509&group_id=5470

From noreply at sourceforge.net  Thu Jul 13 21:55:32 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 13 Jul 2006 12:55:32 -0700
Subject: [ python-Bugs-1522046 ] RPM build fails for Py2.5b2
Message-ID: <E1G17HY-0006OQ-RU@sc8-sf-web5.sourceforge.net>

Bugs item #1522046, was opened at 2006-07-13 21: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=1522046&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Stefan Behnel (scoder)
Assigned to: Nobody/Anonymous (nobody)
Summary: RPM build fails for Py2.5b2

Initial Comment:
Using Misc/RPM/python-2.5.spec, Python 2.5b2 fails to
compile into an RPM on my machine (SuSE 10.1, AMD64,
gcc 4.1). Unlike with b1, I get loads of errors saying:

"ld: cannot find -lpython2.5"

The funny thing is that it continues to build and only
fails at the end when collecting the files for the RPM.

I use

configure --enable-shared --enable-unicode=ucs4 \
   --enable-ipv6 --with-pymalloc --prefix=/usr  \
   --libdir=/usr/lib64

The shared library is correctly built before these
errors come up. The error appear on the "sharedmods"
target. I also tried setting LD_LIBRARY_PATH by hand,
although the build script sets it before starting to
build the modules - no help.

What *does* help is adding "-L." to the LDFLAGS in
Makefile.pre.in:

sed -e '/DIR=.*lib$/ s|/lib$|/%{libdirname}| ;  \
        /LDFLAGS/ s|LDFLAGS=|LDFLAGS= -L. |'    \
    ./Makefile.pre.in.old >Makefile.pre.in

The "DIR=" is for an x86_64 bug that installs Python to
the wrong directory (/usr/lib instead of /usr/lib64).

I tried building Py2.5 by hand (configure/make) and
that also works nicely.

I attached a patch that fixes the problems I encountered.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1522046&group_id=5470

From noreply at sourceforge.net  Fri Jul 14 00:35:30 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 13 Jul 2006 15:35:30 -0700
Subject: [ python-Bugs-1517509 ] filter() implementation does not match docs
Message-ID: <E1G19mM-0002sa-0k@sc8-sf-web3.sourceforge.net>

Bugs item #1517509, was opened at 2006-07-05 08:09
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517509&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Collin Winter (collinwinter)
Assigned to: Nobody/Anonymous (nobody)
Summary: filter() implementation does not match docs

Initial Comment:
The docs for the built-in function filter() claim that
"filter(function, list) is equivalent to [item for item
in list if function(item)] if function is not None and
[item for item in list if item] if function is None".

>>> class infinite_str(str):
...     def __getitem__(self, index):
...         return "a"
...
>>> filter(None, infinite_str("1234"))
'aaaa'


Now, if we translate this to a listcomp according to
the docs:

>>> [x for x in infinite_str("1234") if x]

The listcomp version proceeds to chew up memory until
it exhausts the system resources or is killed by the user.

If the docs are to be believed, the filter() version
should do the same thing. 

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2006-07-13 17:35

Message:
Logged In: YES 
user_id=80475

It's a speed hack.  The result list for filter() is
pre-allocated to the input length and then resized downward
to the actual length.

Stop posting patches for non-bugs.


----------------------------------------------------------------------

Comment By: Collin Winter (collinwinter)
Date: 2006-07-13 14:26

Message:
Logged In: YES 
user_id=1344176

I've posted a patch for the __len__ issue; it's SF #1522016.

----------------------------------------------------------------------

Comment By: Collin Winter (collinwinter)
Date: 2006-07-05 10:16

Message:
Logged In: YES 
user_id=1344176

I wasn't just reviewing the docs; I came upon this while
re-implementing filter() in pure Python for a compatibility
module I'm working on. I discovered this particular
implementation detail when my naive implementation (as a
listcomp) didn't pass test_builtin.

My question is why filter() even cares about __len__, ie,
why it doesn't simply use the iterator protocol. This is
especially curious since filter() actively ignores the
iterator protocol when dealing with subclasses of str,
unicode and tuple:

>>> class badstr(str):
...     def __len__(self):
...         return 4
...     def __getitem__(self, index):
...         return "a"
...     def __iter__(self):
...         for i in range(5):
...             yield "b"
...
>>> filter(None, badseq("cccc"))
aaaa
>>> [x for x in badseq("cccc") if x]
['b', 'b', 'b', 'b', 'b']

Ignore the difference in return types (which is expected),
these two do not do the same thing; filter() uses a
combination of __len__ and __getitem__ while the listcomp
version uses the iterator protocol.

Clearly, in this case, "is equivalent to" means "bears only
a superficial relationship to".

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-07-05 09:58

Message:
Logged In: YES 
user_id=80475

Please take a larger view when reviewing the docs. 
The listcomp analogy is very helpful in explaining what 
filter() does and readers would not benefit by its removal.

Throughtout the docs, the phrase "is equivalent to" does 
not mean "is identical to" or "exactly the same as".   In 
this case, you have isolated a non-guaranteed 
implementation detail that is almost always irrelevant.  
When an object such as infinite_str lies about its length, 
the consequent behavior is undefined.  It is not hard to 
produce weird results when objects violate basic 
invariants such as len(istr)!=len(list(istr)) or the 
expected relation between __eq__ and __hash__.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517509&group_id=5470

From noreply at sourceforge.net  Fri Jul 14 00:43:13 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 13 Jul 2006 15:43:13 -0700
Subject: [ python-Bugs-1522016 ] filter() doesn't use __len__ of
	str/unicode/tuple subclasses
Message-ID: <E1G19tp-0000XU-4a@sc8-sf-web1.sourceforge.net>

Bugs item #1522016, was opened at 2006-07-13 14:25
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1522016&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Collin Winter (collinwinter)
Assigned to: Nobody/Anonymous (nobody)
Summary: filter() doesn't use __len__ of str/unicode/tuple subclasses

Initial Comment:
Consider the following code:

>>> class badstr(str):
...     def __len__(self):
...         return 6
...     def __getitem__(self, index):
...         return "a"
...
>>> filter(None, badstr("bbb"))
'aaa'

I would have expected the answer to be 'aaaaaa'.

The cause for this is that
Python/bltinmodule.c:filter{string,unicode,tuple} all
call PyString_Size (or the appropriate equivalent),
even if the sequence is a subclass of one of these
types. This bypasses any overloading of __len__ done by
the subclass, as demonstrated above.

If filter() is going to respect the subclass's
__getitem__ overload, it should also respect
overloading of __len__. The attached patch corrects this.


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2006-07-13 17:43

Message:
Logged In: YES 
user_id=80475

This isn't a bug.  You're making assumptions about
undocumented implementation details.  The is no shortage of
cases where the C code makes optimized direct internal calls
that bypass method overrides on subclasses of builtin types.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1522016&group_id=5470

From noreply at sourceforge.net  Fri Jul 14 02:52:54 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 13 Jul 2006 17:52:54 -0700
Subject: [ python-Bugs-1522237 ] _threading_local.py logic error in _localbase
	__new__
Message-ID: <E1G1BvK-0003HB-Kn@sc8-sf-web3.sourceforge.net>

Bugs item #1522237, was opened at 2006-07-13 20: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=1522237&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Tony Nelson (tony_nelson)
Assigned to: Nobody/Anonymous (nobody)
Summary: _threading_local.py logic error in _localbase __new__

Initial Comment:
I don't understand _threading_local.py, but I think
that parens are needed below in class _localbase __new__().

    if args or kw and (cls.__init__ is object.__init__):
        raise TypeError...

should be "(args or kw)", I think, looking at the
related test in _patch().

I'm not quite sure if this is python 2.5, but it is in
trunk.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1522237&group_id=5470

From noreply at sourceforge.net  Fri Jul 14 05:48:59 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 13 Jul 2006 20:48:59 -0700
Subject: [ python-Bugs-1223937 ] subprocess.py abuse of errno
Message-ID: <E1G1Efj-0004xR-9K@sc8-sf-web3.sourceforge.net>

Bugs item #1223937, was opened at 2005-06-20 16:56
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223937&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Oren Tirosh (orenti)
Assigned to: Peter ?
strand (astrand)
Summary: subprocess.py abuse of errno

Initial Comment:
The CalledProcessError exception's .errno attribute is
set to a child process return code which is not an
errno. Any attempt to look up this number with
os.strerror() or errno.errorcode[] will result in
meaningless output. This can break existing code that
catches OSError and does not expect CalledProcessError.

Possible resolutions:

1. Don't make CalledProcessError a subclass of OSError
2. If CalledProcessError stays a subclass of OSError
.errno should be set to some specific meaningful value
(which one? add new value to errnomodule.c?) and use a
separate attribute for the child process return code.


----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-07-14 13:48

Message:
Logged In: YES 
user_id=29957

Sounds fine. Please make sure to add a NEWS entry!


----------------------------------------------------------------------

Comment By: Michael Hoffman (hoffmanm)
Date: 2006-07-11 18:16

Message:
Logged In: YES 
user_id=987664

+1 from me. Thanks.

----------------------------------------------------------------------

Comment By: Peter ?
strand (astrand)
Date: 2006-07-11 08:53

Message:
Logged In: YES 
user_id=344921

If we fix this before Python 2.5, I guess we don't need to
think about backwards compatibility. See the attached patch
for a suggested solution. 

----------------------------------------------------------------------

Comment By: Peter ?
strand (astrand)
Date: 2006-07-11 06:34

Message:
Logged In: YES 
user_id=344921

Bug 1376309 has been marked as a duplicate of this bug. 

----------------------------------------------------------------------

Comment By: Peter ?
strand (astrand)
Date: 2005-06-22 06:13

Message:
Logged In: YES 
user_id=344921

I've changed my mind, since CalledProcessError is only in
the development version of Python. Perhaps it's acceptable
to change the API after all, then. Re-opening. 

----------------------------------------------------------------------

Comment By: Peter ?
strand (astrand)
Date: 2005-06-22 01:52

Message:
Logged In: YES 
user_id=344921

In hindsight, CalledProcessError should perhaps have been
designed some other way. But now when we have it, it's not
easy to change it. 

It all comes down to what is the documented behaviour and
not. As far as I understand, there's no requirement that the
errno number or an OSError should be possible to look up
with os.strerror(). I cannot find anything about this at
http://docs.python.org/lib/module-exceptions.html, at least.
All it says is "[errno is] assumed to be an error number". 

In my opinion, code should be prepared for "unknown" error
numbers. So currently, I'm not prepared to make any changes
to CalledProcessError. (If you disagree with me, post to
python-dev and see what others think.)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223937&group_id=5470

From noreply at sourceforge.net  Fri Jul 14 06:56:31 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 13 Jul 2006 21:56:31 -0700
Subject: [ python-Bugs-1508010 ] msvccompiler.py using VC6 with Python 2.5a2
Message-ID: <E1G1Fj5-0005Ah-KQ@sc8-sf-web3.sourceforge.net>

Bugs item #1508010, was opened at 2006-06-18 09:11
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508010&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils
Group: Python 2.5
>Status: Closed
Resolution: Accepted
Priority: 7
Submitted By: Jimmy Retzlaff (jretz)
Assigned to: Martin v. L??wis (loewis)
Summary: msvccompiler.py using VC6 with Python 2.5a2

Initial Comment:
The change in revision 42515 checks if MSSdk is
defined, and if so it will "Assume that the SDK set up
everything alright." The problem is that the SDK may be
set up for a different version of cl.exe than is
expected. In my case I have VC6 and VC7.1 installed and
the SDK is set up for VC6. When building extensions for
Python 2.5a2, distutils tries to use VC6 in my case.

----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-07-14 06:56

Message:
Logged In: YES 
user_id=21627

Committed as r50509

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-09 19:20

Message:
Logged In: YES 
user_id=33168

Martin, this looks fine if you think it's important.  Don't
forget to add a Misc/NEWS entry.

There are some typos in the doc:

chose -> choose

"most be both set" -> "must both be set"

Should the last distutils in the doc be:  \module{distutils}?

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-07-09 11:41

Message:
Logged In: YES 
user_id=21627

Here is a proposed patch: in addition to requiring MSSdk to
be set, distutils would also require DISTUTILS_USE_SDK to be
set.

Neal, can you please approve this new feature before beta 2?

----------------------------------------------------------------------

Comment By: Jimmy Retzlaff (jretz)
Date: 2006-06-25 01:01

Message:
Logged In: YES 
user_id=101588

There is an option when installing VC (or at least there
used to be, I haven't checked lately) to set the environment
variables to take effect system wide. This is useful in that
the build environment is always available at any command
line (and they are also set when I build from my editor
which is not VS). I've left mine pointed at VC6 as I
typically do standalone DLLs using VC6 so they are easier to
redistribute. Distutils has always selected the right
version so it hasn't been an issue for me when working on
Python things before.

The issue wouldn't be as difficult if the resulting behavior
were more obvious. Unfortunately the initial errors in my
case were syntax errors arising from macro definitions that
changed between VC6 and VC7.1. Most of the time I spent
updating py2exe to work with 2.5 was spent on diagnosing
this. It wasn???t helped by the fact that I had a blind spot
regarding the compiler version. I use a batch file to build
py2exe for 2.3, then 2.4, and finally 2.5. Since 2.3 and 2.4
were building fine I didn???t even consider the idea of the
wrong compiler version being used for quite a while.

For now I just do "set MSSDK=" before building and then
everything works just fine.


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-06-24 12:30

Message:
Logged In: YES 
user_id=21627

I don't understand the problem. MSSdk gets defined by
opening a specific SDK build environment. Just don't open
that build environment, but open a regular cmd.exe window,
and it should work fine.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508010&group_id=5470

From noreply at sourceforge.net  Fri Jul 14 06:57:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 13 Jul 2006 21:57:46 -0700
Subject: [ python-Bugs-1521726 ] isinstance failure in 2.5 Beta 2
Message-ID: <E1G1FkI-0007Fv-4E@sc8-sf-web6.sourceforge.net>

Bugs item #1521726, was opened at 2006-07-13 12:56
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521726&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Submitted By: Nick Maclaren (nmm)
Assigned to: Nobody/Anonymous (nobody)
>Summary: isinstance failure in 2.5 Beta 2

Initial Comment:
Linux gosset 2.6.16.13-4-smp #1 SMP Wed May 3 04:53:23
UTC 2006 x86_64 x86_64 x86_64 GNU/Linux
./python Lib/test/test_compile.py

  File "Lib/test/test_compile.py", line 6, in <module>
    class TestSpecifics(unittest.TestCase):
  File "Lib/test/test_compile.py", line 399, in test_main
    test_support.run_unittest(TestSpecifics)
  File
"/home/nmm/Python-2.5b2/Lib/test/test_support.py", line
422, in run_unittest
    run_suite(suite, testclass)
  File
"/home/nmm/Python-2.5b2/Lib/test/test_support.py", line
407, in run_suite    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent
call last):
  File "Lib/test/test_compile.py", line 226, in
test_unary_minus
    self.assertTrue(isinstance(eval("%s" % (-sys.maxint
- 1)), int))

./python
Python 2.5b2 (r25b2:50512, Jul 13 2006, 11:33:15)
>>> import sys
>>> print sys.maxint
9223372036854775807
>>> print "%s" % (-sys.maxint - 1)
-9223372036854775808
>>> print isinstance(eval("%s" % (-sys.maxint - 1)), int)
False
>>> print isinstance(eval("%s" % (-sys.maxint)), int)
True


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521726&group_id=5470

From noreply at sourceforge.net  Fri Jul 14 16:05:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 14 Jul 2006 07:05:05 -0700
Subject: [ python-Bugs-1223937 ] subprocess.py abuse of errno
Message-ID: <E1G1OHx-0002h2-31@sc8-sf-web5.sourceforge.net>

Bugs item #1223937, was opened at 2005-06-20 08:56
Message generated for change (Comment added) made by astrand
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223937&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Oren Tirosh (orenti)
Assigned to: Peter ?
strand (astrand)
Summary: subprocess.py abuse of errno

Initial Comment:
The CalledProcessError exception's .errno attribute is
set to a child process return code which is not an
errno. Any attempt to look up this number with
os.strerror() or errno.errorcode[] will result in
meaningless output. This can break existing code that
catches OSError and does not expect CalledProcessError.

Possible resolutions:

1. Don't make CalledProcessError a subclass of OSError
2. If CalledProcessError stays a subclass of OSError
.errno should be set to some specific meaningful value
(which one? add new value to errnomodule.c?) and use a
separate attribute for the child process return code.


----------------------------------------------------------------------

>Comment By: Peter ?
strand (astrand)
Date: 2006-07-14 16:05

Message:
Logged In: YES 
user_id=344921

Fixed in revision 50638.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-07-14 05:48

Message:
Logged In: YES 
user_id=29957

Sounds fine. Please make sure to add a NEWS entry!


----------------------------------------------------------------------

Comment By: Michael Hoffman (hoffmanm)
Date: 2006-07-11 10:16

Message:
Logged In: YES 
user_id=987664

+1 from me. Thanks.

----------------------------------------------------------------------

Comment By: Peter ?
strand (astrand)
Date: 2006-07-11 00:53

Message:
Logged In: YES 
user_id=344921

If we fix this before Python 2.5, I guess we don't need to
think about backwards compatibility. See the attached patch
for a suggested solution. 

----------------------------------------------------------------------

Comment By: Peter ?
strand (astrand)
Date: 2006-07-10 22:34

Message:
Logged In: YES 
user_id=344921

Bug 1376309 has been marked as a duplicate of this bug. 

----------------------------------------------------------------------

Comment By: Peter ?
strand (astrand)
Date: 2005-06-21 22:13

Message:
Logged In: YES 
user_id=344921

I've changed my mind, since CalledProcessError is only in
the development version of Python. Perhaps it's acceptable
to change the API after all, then. Re-opening. 

----------------------------------------------------------------------

Comment By: Peter ?
strand (astrand)
Date: 2005-06-21 17:52

Message:
Logged In: YES 
user_id=344921

In hindsight, CalledProcessError should perhaps have been
designed some other way. But now when we have it, it's not
easy to change it. 

It all comes down to what is the documented behaviour and
not. As far as I understand, there's no requirement that the
errno number or an OSError should be possible to look up
with os.strerror(). I cannot find anything about this at
http://docs.python.org/lib/module-exceptions.html, at least.
All it says is "[errno is] assumed to be an error number". 

In my opinion, code should be prepared for "unknown" error
numbers. So currently, I'm not prepared to make any changes
to CalledProcessError. (If you disagree with me, post to
python-dev and see what others think.)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223937&group_id=5470

From noreply at sourceforge.net  Fri Jul 14 17:55:18 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 14 Jul 2006 08:55:18 -0700
Subject: [ python-Bugs-1519069 ] incorrect locale.strcoll() return in Windows
Message-ID: <E1G1Q0c-0003UT-Op@sc8-sf-web6.sourceforge.net>

Bugs item #1519069, was opened at 2006-07-08 05:04
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519069&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Brian Matherly (pez4brian)
Assigned to: Nobody/Anonymous (nobody)
Summary: incorrect locale.strcoll() return in Windows

Initial Comment:
Python 2.4.2 in Windows (English locale):

>>> import locale
>>> locale.setlocale(locale.LC_ALL,'C')
'C'
>>> locale.setlocale(locale.LC_ALL,'')
'English_United States.1252'
>>> locale.strcoll("M","m")
1
>>> locale.strcoll("Ma","mz")
-1

It appears that when a string has one character, "M" is
greater than "m", but when it has more than one string,
"M" is equal to "m"

----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-07-14 17:55

Message:
Logged In: YES 
user_id=21627

Why do you think this is a bug? We pass the string as-is to
the C library, which passes it nearly as-is to
CompareStringW. This function then decides how they collate;
in Microsoft's definition of the English_United States
locale, these strings do have the order you get.

In case you wonder how the order is computed: essentially,
the strings are compared case insensitive, without
diacritics. If they then compare equal, the diacritics are
considered. If this still compares equal, Case weights are
considered. If this still compares equal, Special weights
are considered.

(Note: I obtained this indirectly by looking at the
LCMapString documentation, assuming that CompareString uses
LCMapString with LCMAP_SORTKEY|SORT_STRINGSORT).

----------------------------------------------------------------------

Comment By: Brian Matherly (pez4brian)
Date: 2006-07-08 05:35

Message:
Logged In: YES 
user_id=726294

I see the same problem in python 2.4.3

----------------------------------------------------------------------

Comment By: Brian Matherly (pez4brian)
Date: 2006-07-08 05:08

Message:
Logged In: YES 
user_id=726294

Correction:

It appears that when a string has one character, "M" is
greater than "m", but when it has more than one character,
"M" is equal to "m"

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519069&group_id=5470

From noreply at sourceforge.net  Fri Jul 14 22:09:44 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 14 Jul 2006 13:09:44 -0700
Subject: [ python-Bugs-1522771 ] Patch #1388073 is not mentioned in NEWS
Message-ID: <E1G1Tyq-0000Dd-M0@sc8-sf-web2.sourceforge.net>

Bugs item #1522771, was opened at 2006-07-14 16: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=1522771&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Collin Winter (collinwinter)
Assigned to: Nobody/Anonymous (nobody)
Summary: Patch #1388073 is not mentioned in NEWS

Initial Comment:
This patch adds a mention of patch #1388073 (which
changed the names of several attributes on
unittest.TestCase) to the "Library" subsection of
Misc/NEWS for Python 2.5 alpha 1 (since the patch was
applied before 2.5a1 was released).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1522771&group_id=5470

From noreply at sourceforge.net  Sat Jul 15 05:14:49 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 14 Jul 2006 20:14:49 -0700
Subject: [ python-Bugs-1519069 ] incorrect locale.strcoll() return in Windows
Message-ID: <E1G1acD-0008DC-BB@sc8-sf-web2.sourceforge.net>

Bugs item #1519069, was opened at 2006-07-07 22:04
Message generated for change (Comment added) made by pez4brian
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519069&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Brian Matherly (pez4brian)
Assigned to: Nobody/Anonymous (nobody)
Summary: incorrect locale.strcoll() return in Windows

Initial Comment:
Python 2.4.2 in Windows (English locale):

>>> import locale
>>> locale.setlocale(locale.LC_ALL,'C')
'C'
>>> locale.setlocale(locale.LC_ALL,'')
'English_United States.1252'
>>> locale.strcoll("M","m")
1
>>> locale.strcoll("Ma","mz")
-1

It appears that when a string has one character, "M" is
greater than "m", but when it has more than one string,
"M" is equal to "m"

----------------------------------------------------------------------

>Comment By: Brian Matherly (pez4brian)
Date: 2006-07-14 22:14

Message:
Logged In: YES 
user_id=726294

Thanks for your response. That is simply unacceptable. Who
at Microsoft needs to be flogged? More likely, this shows my
lack of understanding of strings and locale in general.

Your explanation does explain the results I get, but
wouldn't you admit that the results *seem* wrong?

By the definition given, the strings "Ma", "mb", "Mc", "md"
would actually sort in that order! So the list of sorted
strings would have alternating capitalization!

However, the list of strings "M", "m", "M", "m" would sort
as "M", "M", "m", "m" - no alternating capitalization - as I
would expect.

Would there happen to be some way to sort the strings using
the locale, but also using the case earlier in the
computation order? Basically, I want the sort to be case
sensitive.

Thanks again for your response. If you have any suggestions
that might help me achieve what I want, it would be greatly
appreciated.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-07-14 10:55

Message:
Logged In: YES 
user_id=21627

Why do you think this is a bug? We pass the string as-is to
the C library, which passes it nearly as-is to
CompareStringW. This function then decides how they collate;
in Microsoft's definition of the English_United States
locale, these strings do have the order you get.

In case you wonder how the order is computed: essentially,
the strings are compared case insensitive, without
diacritics. If they then compare equal, the diacritics are
considered. If this still compares equal, Case weights are
considered. If this still compares equal, Special weights
are considered.

(Note: I obtained this indirectly by looking at the
LCMapString documentation, assuming that CompareString uses
LCMapString with LCMAP_SORTKEY|SORT_STRINGSORT).

----------------------------------------------------------------------

Comment By: Brian Matherly (pez4brian)
Date: 2006-07-07 22:35

Message:
Logged In: YES 
user_id=726294

I see the same problem in python 2.4.3

----------------------------------------------------------------------

Comment By: Brian Matherly (pez4brian)
Date: 2006-07-07 22:08

Message:
Logged In: YES 
user_id=726294

Correction:

It appears that when a string has one character, "M" is
greater than "m", but when it has more than one character,
"M" is equal to "m"

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519069&group_id=5470

From noreply at sourceforge.net  Sat Jul 15 09:37:09 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 15 Jul 2006 00:37:09 -0700
Subject: [ python-Bugs-1519069 ] incorrect locale.strcoll() return in Windows
Message-ID: <E1G1ei5-0000SY-O9@sc8-sf-web6.sourceforge.net>

Bugs item #1519069, was opened at 2006-07-08 05:04
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519069&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Brian Matherly (pez4brian)
Assigned to: Nobody/Anonymous (nobody)
Summary: incorrect locale.strcoll() return in Windows

Initial Comment:
Python 2.4.2 in Windows (English locale):

>>> import locale
>>> locale.setlocale(locale.LC_ALL,'C')
'C'
>>> locale.setlocale(locale.LC_ALL,'')
'English_United States.1252'
>>> locale.strcoll("M","m")
1
>>> locale.strcoll("Ma","mz")
-1

It appears that when a string has one character, "M" is
greater than "m", but when it has more than one string,
"M" is equal to "m"

----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-07-15 09:37

Message:
Logged In: YES 
user_id=21627

You should ask these questions in some Win32 programmer
newsgroup. I don't know whether this sorting is correct or
not, I'm not a native English speaker.

----------------------------------------------------------------------

Comment By: Brian Matherly (pez4brian)
Date: 2006-07-15 05:14

Message:
Logged In: YES 
user_id=726294

Thanks for your response. That is simply unacceptable. Who
at Microsoft needs to be flogged? More likely, this shows my
lack of understanding of strings and locale in general.

Your explanation does explain the results I get, but
wouldn't you admit that the results *seem* wrong?

By the definition given, the strings "Ma", "mb", "Mc", "md"
would actually sort in that order! So the list of sorted
strings would have alternating capitalization!

However, the list of strings "M", "m", "M", "m" would sort
as "M", "M", "m", "m" - no alternating capitalization - as I
would expect.

Would there happen to be some way to sort the strings using
the locale, but also using the case earlier in the
computation order? Basically, I want the sort to be case
sensitive.

Thanks again for your response. If you have any suggestions
that might help me achieve what I want, it would be greatly
appreciated.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-07-14 17:55

Message:
Logged In: YES 
user_id=21627

Why do you think this is a bug? We pass the string as-is to
the C library, which passes it nearly as-is to
CompareStringW. This function then decides how they collate;
in Microsoft's definition of the English_United States
locale, these strings do have the order you get.

In case you wonder how the order is computed: essentially,
the strings are compared case insensitive, without
diacritics. If they then compare equal, the diacritics are
considered. If this still compares equal, Case weights are
considered. If this still compares equal, Special weights
are considered.

(Note: I obtained this indirectly by looking at the
LCMapString documentation, assuming that CompareString uses
LCMapString with LCMAP_SORTKEY|SORT_STRINGSORT).

----------------------------------------------------------------------

Comment By: Brian Matherly (pez4brian)
Date: 2006-07-08 05:35

Message:
Logged In: YES 
user_id=726294

I see the same problem in python 2.4.3

----------------------------------------------------------------------

Comment By: Brian Matherly (pez4brian)
Date: 2006-07-08 05:08

Message:
Logged In: YES 
user_id=726294

Correction:

It appears that when a string has one character, "M" is
greater than "m", but when it has more than one character,
"M" is equal to "m"

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519069&group_id=5470

From noreply at sourceforge.net  Sat Jul 15 17:18:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 15 Jul 2006 08:18:25 -0700
Subject: [ python-Bugs-1513617 ] IDLE fails to launch after 46272
Message-ID: <E1G1luT-0007MM-Or@sc8-sf-web1.sourceforge.net>

Bugs item #1513617, was opened at 2006-06-27 17:18
Message generated for change (Settings changed) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513617&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: None
Status: Open
Resolution: None
>Priority: 7
Submitted By: John Bollinger (bbands)
>Assigned to: Kurt B. Kaiser (kbk)
Summary: IDLE fails to launch after 46272

Initial Comment:
As of revision 46805 IDLE fails silently on launch. If
launched from a command prompt the following output is
seen.

D:\Python24\Lib\idlelib>python idle.py
Traceback (most recent call last):
  File "idle.py", line 2, in ?
    import idlelib.PyShell
  File "D:\Python24\lib\idlelib\PyShell.py", line 27, in ?
    from EditorWindow import EditorWindow, fixwordbreaks
  File "D:\Python24\lib\idlelib\EditorWindow.py", line
42, in ?
    class EditorWindow(object):
  File "D:\Python24\lib\idlelib\EditorWindow.py", line
47, in EditorWindow
    import Bindings
  File "D:\Python24\lib\idlelib\Bindings.py", line 109,
in ?
    default_keydefs = idleConf.GetCurrentKeySet()
  File "D:\Python24\lib\idlelib\configHandler.py", line
499, in GetCurrentKeySet

    result = self.GetKeySet(self.CurrentKeys())
  File "D:\Python24\lib\idlelib\configHandler.py", line
519, in GetKeySet
    activeExtns=self.GetExtensions(active_only=1)
  File "D:\Python24\lib\idlelib\configHandler.py", line
377, in GetExtensions
    extns=self.RemoveKeyBindNames(
  File "D:\Python24\lib\idlelib\configHandler.py", line
410, in RemoveKeyBindNames
    if name.endswith(('_bindings', '_cfgBindings')):
TypeError: expected a character buffer object


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513617&group_id=5470

From noreply at sourceforge.net  Sat Jul 15 18:21:21 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 15 Jul 2006 09:21:21 -0700
Subject: [ python-Bugs-1518772 ] ext/win-cookbook.html has a broken link to
	distutils
Message-ID: <E1G1mtN-0002ak-SY@sc8-sf-web5.sourceforge.net>

Bugs item #1518772, was opened at 2006-07-07 23:02
Message generated for change (Comment added) made by quiver
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1518772&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Johannes Gijsbers (jlgijsbers)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: ext/win-cookbook.html has a broken link to distutils

Initial Comment:
http://docs.python.org/ext/win-cookbook.html has a link
to distutils which points to
http://docs.python.org/ext/module-distutils.html. It
should point to
http://docs.python.org/lib/module-distutils.html.

----------------------------------------------------------------------

>Comment By: George Yoshida (quiver)
Date: 2006-07-16 01:21

Message:
Logged In: YES 
user_id=671362

Fixed in revision 50664 & 50664.

Thanks for the report.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1518772&group_id=5470

From noreply at sourceforge.net  Sat Jul 15 18:56:02 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 15 Jul 2006 09:56:02 -0700
Subject: [ python-Feature Requests-592047 ] Add syntax coloring to Mac IDE
Message-ID: <E1G1nQw-0004E2-Jd@sc8-sf-web6.sourceforge.net>

Feature Requests item #592047, was opened at 2002-08-07 09:14
Message generated for change (Comment added) made by etrepum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=592047&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Dan Grassi (dgrassi)
Assigned to: Just van Rossum (jvr)
Summary: Add syntax coloring to Mac IDE

Initial Comment:
I suggest including syntax coloring (AdvancedEditor.py) into the Mac IDE.  Syntax coloring is now expected and it can be disabled easily.  I would be willing to do the work.

Also the default font need to change or be installed.  Not all fonts handle bold-ing and with the default missing a font that does not work ends up as default.

Dan

----------------------------------------------------------------------

>Comment By: Bob Ippolito (etrepum)
Date: 2006-07-15 12:56

Message:
Logged In: YES 
user_id=139309

The Mac IDE is deprecated in preference of IDLE.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-08-07 09:58

Message:
Logged In: YES 
user_id=45365

This is a request for the Mac IDE, not for tkinter-based IDLE. Also, assigning it to Just.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=592047&group_id=5470

From noreply at sourceforge.net  Sat Jul 15 18:57:37 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 15 Jul 2006 09:57:37 -0700
Subject: [ python-Feature Requests-779160 ] Enhance PackageManager
	functionality
Message-ID: <E1G1nST-0003WT-6Z@sc8-sf-web2.sourceforge.net>

Feature Requests item #779160, was opened at 2003-07-28 16:52
Message generated for change (Comment added) made by etrepum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=779160&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Bob Ippolito (etrepum)
Assigned to: Jack Jansen (jackjansen)
Summary: Enhance PackageManager functionality

Initial Comment:
PackageManager should probably let you choose a tarball/ 
 zip/folder on disk (or drag + drop) and look for a setup.py  
 that it would do the Usual Thing with.  Perhaps also let you  
 choose an arbitrary .py file and scan for 'distutils' -- but I've  
 only seen a called-something-other-than-setup.py distutils  
 installer in one package (it had multiple setup-prefixed  
 installers that installed different related modules, and an  
 annoying no-op setup.py.. so I would say this is a bug on 
his  
 part). 
  
 PackageManager should be refactored to be responsive and  
 non-blocking (i.e. threaded or forking).    

----------------------------------------------------------------------

>Comment By: Bob Ippolito (etrepum)
Date: 2006-07-15 12:57

Message:
Logged In: YES 
user_id=139309

PackageManager is deprecated in favor of Cheese Shop + easy_install and 
bdist_mpkg + pythonmac.org/packages

----------------------------------------------------------------------

Comment By: has (hhas)
Date: 2004-06-04 14:26

Message:
Logged In: YES 
user_id=996627

"PackageManager should probably let you choose a tarball/ 
zip/folder on disk (or drag + drop) and look for a setup.py 
that it would do the Usual Thing with."

See my PyMod application for a simple standalone solution that fulfills 
this requirement:

http://freespace.virgin.net/hamish.sanderson/PyMod.app.sit

Supports building and installing distutils packages, and PyPI 
registration through a simple GUI. 

Could use a better name and icon, and needs a bit more user testing 
(only tested on 10.2.6 so far), but is otherwise ready to roll, and 
you're welcome to include in the MacPython 2.4 distribution.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=779160&group_id=5470

From noreply at sourceforge.net  Sat Jul 15 19:04:59 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 15 Jul 2006 10:04:59 -0700
Subject: [ python-Bugs-1149804 ] macostools.mkdirs: not thread-safe
Message-ID: <E1G1nZb-0003u5-DZ@sc8-sf-web1.sourceforge.net>

Bugs item #1149804, was opened at 2005-02-23 08:26
Message generated for change (Comment added) made by etrepum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1149804&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jurjen N.E. Bos (jneb)
Assigned to: Jack Jansen (jackjansen)
Summary: macostools.mkdirs: not thread-safe

Initial Comment:
Here is an easily fixable semi-bug in macostools:
When two threads are creating the same directory structure, one 
of them will fail as soon as the other thread made a directory.
This is trivially fixable by ignoring the error, but I'm not sure if it is 
worth it, like this:

def mkdirs(dst):
    """Make directories leading to 'dst' if they don't exist yet"""
    if dst == '' or os.path.exists(dst):
        return
    head, tail = os.path.split(dst)
    if os.sep == ':' and not ':' in head:
        head = head + ':'
    mkdirs(head)
    try: os.mkdir(dst, 0777)
    except OSError, err:
	if err.errno==17: #file exists
		#someone else has created the directory in the 
meantime. That's fine with me!
		pass
	else: raise
- Jurjen

----------------------------------------------------------------------

>Comment By: Bob Ippolito (etrepum)
Date: 2006-07-15 13:04

Message:
Logged In: YES 
user_id=139309

Most Python functions aren't intended to be thread-safe, this is what locks are 
for. I don't think this should be fixed, not even in os.makedirs.

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2005-03-01 03:49

Message:
Logged In: YES 
user_id=92689

Oops, disregard that portability remark, it does work correctly in non-OS9 
Python as well. I _think_ macostools.mkdirs() predates os.makedirs(), it's 
probably best considered deprecated.

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2005-03-01 03:40

Message:
Logged In: YES 
user_id=92689

Hm, macostools.mkdirs() also isn't portable: it only works on OS9 
MacPython. Why don't you use os.makedirs() instead? (Which appears to 
have the same threads issue, though.)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1149804&group_id=5470

From noreply at sourceforge.net  Sat Jul 15 19:07:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 15 Jul 2006 10:07:42 -0700
Subject: [ python-Bugs-776600 ] PIL binary package missing jpeg support (pimp)
Message-ID: <E1G1ncE-0007xV-3o@sc8-sf-web2.sourceforge.net>

Bugs item #776600, was opened at 2003-07-23 19:54
Message generated for change (Comment added) made by etrepum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776600&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: Python 2.3
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Bob Ippolito (etrepum)
Assigned to: Jack Jansen (jackjansen)
Summary: PIL binary package missing jpeg support (pimp)

Initial Comment:
Binary installation of PIL should be compiled with a static 
libjpeg.

----------------------------------------------------------------------

>Comment By: Bob Ippolito (etrepum)
Date: 2006-07-15 13:07

Message:
Logged In: YES 
user_id=139309

Repository no longer maintained, irrelevant.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776600&group_id=5470

From noreply at sourceforge.net  Sat Jul 15 19:09:15 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 15 Jul 2006 10:09:15 -0700
Subject: [ python-Bugs-735110 ] Mach-O gcc optimisation flag can boost
	performance up to 10%
Message-ID: <E1G1ndj-0006fQ-VG@sc8-sf-web5.sourceforge.net>

Bugs item #735110, was opened at 2003-05-09 05:02
Message generated for change (Comment added) made by etrepum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735110&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Just van Rossum (jvr)
Assigned to: Jack Jansen (jackjansen)
Summary: Mach-O gcc optimisation flag can boost performance up to 10%

Initial Comment:
This article:
  http://www.unsanity.org/archives/000044.php
says that the -mdynamic-no-pic gcc flag can boost performance of 
statically linked apps around 10%. Testing this with a non-framework 
build of Python shows this is indeed the case.

----------------------------------------------------------------------

>Comment By: Bob Ippolito (etrepum)
Date: 2006-07-15 13:09

Message:
Logged In: YES 
user_id=139309

This isn't really relevant, Mac OS X builds of Python are built as a shared library 
or framework (same thing, basically). Both cases require PIC.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735110&group_id=5470

From noreply at sourceforge.net  Sat Jul 15 19:09:49 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 15 Jul 2006 10:09:49 -0700
Subject: [ python-Bugs-711991 ] IDE needs easy access to builtin help()
Message-ID: <E1G1neH-0000Sm-4R@sc8-sf-web2.sourceforge.net>

Bugs item #711991, was opened at 2003-03-29 18:33
Message generated for change (Comment added) made by etrepum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711991&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Just van Rossum (jvr)
Summary: IDE needs easy access to builtin help()

Initial Comment:
Just, I'm assigning this to you for feedback. Feel free to assign back after providing it.

I think we need access to the help()-style documentation in the IDE, especially when browsing objects and such it would be very helpful.

What I'm thinking of at the moment is a window called &quot;Help for Selection&quot; (any better ideas?), and if that window is opened it will display the help() text for the current selection. It would follow focus, i.e. when you select a different window or a different object in the same window it would change.

An alternative design would be that you would have to use a command &quot;Show Help for Selection&quot; which would bring up a static window with the help() contents.

A third possibility (best of both worlds?) would be a window that has a checkbox &quot;Follow Selection&quot;, initially true. If you deselect it the window would stay open statically, and a subsequent &quot;Show Help for Selection&quot; command would bring up a new window with the checkbox checked.

----------------------------------------------------------------------

>Comment By: Bob Ippolito (etrepum)
Date: 2006-07-15 13:09

Message:
Logged In: YES 
user_id=139309

IDE is deprecated in favor of IDLE.

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2003-04-11 04:56

Message:
Logged In: YES 
user_id=92689

I would just go for &quot;Show Help for Selection&quot;. I'm not so sure how useful following the selection would be (thinking of a scenenario where you lookup some info based on the selection, then continue editing, following the help. It would be irritating if the help would disappear or change then.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711991&group_id=5470

From noreply at sourceforge.net  Sat Jul 15 19:10:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 15 Jul 2006 10:10:05 -0700
Subject: [ python-Bugs-710374 ] Raise IDE output window over splash screen on
	early crash
Message-ID: <E1G1neX-00072U-3C@sc8-sf-web5.sourceforge.net>

Bugs item #710374, was opened at 2003-03-26 17:33
Message generated for change (Comment added) made by etrepum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=710374&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Just van Rossum (jvr)
Summary: Raise IDE output window over splash screen on early crash

Initial Comment:
This one was also submitted by macrulezatsofthomedotnet, but I'm not so sure about it. What do you think, would changing the DLOG resource for the splash screen have other, unforeseen side effects?
The effect of the change I would dearly like: how often have I cursed the %#$ spalsh screen being in front of the error message I would really love to see...

Sometimes the script short-circuits while Python IDE is starting
	actually, I haven't fixed that yet, but I did get around the problem of it preventing Python from starting (which is a problem because the user then cannot quit). I ResEdited the Python IDE and changed the 'DLOG' resource, such that the 'About' dialogue (the splash screen) is a window, rather than an actual dialogue. thus, when the &lt;interrupted&gt; window appears (showing a traceback), it moves to the frontmost instead of remaining behind the splash where it can't be read.

----------------------------------------------------------------------

>Comment By: Bob Ippolito (etrepum)
Date: 2006-07-15 13:10

Message:
Logged In: YES 
user_id=139309

IDE is deprecated in favor of IDLE.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-03-27 15:55

Message:
Logged In: YES 
user_id=45365

Much better idea!

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2003-03-27 04:20

Message:
Logged In: YES 
user_id=92689

Perhaps the splash screen stuff should be in a try/finally so it's guaranteed to get closed?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=710374&group_id=5470

From noreply at sourceforge.net  Sat Jul 15 19:10:26 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 15 Jul 2006 10:10:26 -0700
Subject: [ python-Bugs-710373 ] IDE stdin doesn't have readlines
Message-ID: <E1G1nes-0000kS-MC@sc8-sf-web2.sourceforge.net>

Bugs item #710373, was opened at 2003-03-26 17:30
Message generated for change (Comment added) made by etrepum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=710373&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Just van Rossum (jvr)
Summary: IDE stdin doesn't have readlines

Initial Comment:
This was submitted by email by macrulezatsofthomedotnet. It looks reasonable, but please have a look too.

SimpleStdin doesn't provide a readlines method
	some scripts call sys.stdin.readlines(). the default stdin does not support this behaviour. I added it by copying and pasting the readlines method from StringIO, and adapting the indentation to fit. works beautifully: it asks the user for a line of input repeatedly until the user clicks 'Cancel'. not perfect UI, but it's something.

----------------------------------------------------------------------

>Comment By: Bob Ippolito (etrepum)
Date: 2006-07-15 13:10

Message:
Logged In: YES 
user_id=139309

IDE is deprecated in favor of IDLE.

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2003-03-27 04:18

Message:
Logged In: YES 
user_id=92689

Hm, I find the stdin.readline() emulation already a big pain, and I'm hesitant to add an even uglier kludge to support readlines(). The IDE is simply not well suited for stdin-based scripts, they are _much_ better run from the command line. But: an actual patch might still make it in...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=710373&group_id=5470

From noreply at sourceforge.net  Sat Jul 15 19:10:43 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 15 Jul 2006 10:10:43 -0700
Subject: [ python-Bugs-573174 ] Mac IDE behaviour (output to console)
Message-ID: <E1G1nf9-0000sZ-PF@sc8-sf-web2.sourceforge.net>

Bugs item #573174, was opened at 2002-06-24 11:40
Message generated for change (Comment added) made by etrepum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=573174&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: Platform-specific
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Carl Hagelberg (chagel)
Assigned to: Just van Rossum (jvr)
Summary: Mac IDE behaviour (output to console)

Initial Comment:

On woensdag, juni 5, 2002, at 05:15 , Carl Hagelberg wrote:

&gt; Hi Jack,
&gt;
&gt; There's a difference between the result of the following 
&gt; example when using
&gt; the interactive window and a 'program window' using
the &quot;Run 
&gt; all&quot; button
&gt; (OSX):
&gt;
&gt; a, b = 0, 1
&gt; while b &lt; 1000:
&gt;     print b,
&gt;     a, b = b, a+b
&gt;
&gt;
&gt; With out the &quot;,&quot; after 'print b' they both work the
same. With 
&gt; the comma
&gt; only the interactive window works. Is there a syntax
issue in 
&gt; the program
&gt; window?

Carl,
this is a &quot;known issue&quot;, but unfortunately one that is
difficult 
to fix. The IDE flushes output to the console window on 
end-of-line only. It has no knowledge of the print
statement, it 
just sees a stream of characters, and it can flush
either (a) at 
ever character or (b) at every end-of-line. The first
would make 
it horrendously inefficient, so it does the latter. Put
one 
&quot;print&quot; without the comma at the end and everything
will be 
printed.

But: this bug should be noted in the sourceforge bug
list. Could 
you please add it (category Macintosh, assign it to me
or Just 
(jvr))?
--
- Jack Jansen        &lt;Jack.Jansen at oratrix.com&gt;        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your
revolution -- 
Emma Goldman -



----------------------------------------------------------------------

>Comment By: Bob Ippolito (etrepum)
Date: 2006-07-15 13:10

Message:
Logged In: YES 
user_id=139309

IDE is deprecated in favor of IDLE.

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2002-07-24 14:22

Message:
Logged In: YES 
user_id=92689

I just looked at Idle's OutputWindow.py, and that doesn't do any buffering 
at all. So I wonder whether we should do that, too. Or maybe autoflush if 
the buffer is longer than X bytes.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-07-10 16:26

Message:
Logged In: YES 
user_id=45365

Just,
I'm assigning this to you (should have done so weeks ago:-).
It might be worthwhile to check out whether Idle has a workaround for this. Maybe something like doing a sys.stdout.flush() at a strategic point in the event loop is a solution (if it isn't too expensive), and otherwise at least such a flush when IDE goes idle (no pun intended).

And if it's too difficult just mark it &quot;won't fix&quot;:-)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=573174&group_id=5470

From noreply at sourceforge.net  Sat Jul 15 20:49:36 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 15 Jul 2006 11:49:36 -0700
Subject: [ python-Bugs-1523136 ] incorrect tcp checksum
Message-ID: <E1G1pCq-0006ou-76@sc8-sf-web6.sourceforge.net>

Bugs item #1523136, was opened at 2006-07-15 18: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=1523136&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: ecir hana (ecirhana)
Assigned to: Nobody/Anonymous (nobody)
Summary: incorrect tcp checksum

Initial Comment:
hi,

when using 'socket' library for a simple web server
'ethereal' reports incorrect checksum in transmission
control protocol.

on ubuntu dapper drake and firefox

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1523136&group_id=5470

From noreply at sourceforge.net  Sat Jul 15 21:51:44 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 15 Jul 2006 12:51:44 -0700
Subject: [ python-Bugs-1517996 ] IDLE (macosx): Class and Path browsers show
	Tk menu
Message-ID: <E1G1qAy-00067Q-6i@sc8-sf-web1.sourceforge.net>

Bugs item #1517996, was opened at 2006-07-06 04:34
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517996&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Nobody/Anonymous (nobody)
Summary: IDLE (macosx): Class and Path browsers show Tk menu

Initial Comment:
I've done some work on fixing the menus for IDLE before 2.5b1, but 
recently found more toplevel windows that don't have their own menu.

Both the Path Browser and Class Browser don't have a menubar of their 
own. The Tk implementation on MacOSX won't accept an empty menubar, 
but will replace that by a generic Tk menubar.

----------------------------------------------------------------------

>Comment By: Kurt B. Kaiser (kbk)
Date: 2006-07-15 15:51

Message:
Logged In: YES 
user_id=149084

I suppose this is also true for the debugger?

I'd consider this a bug in OSX Tk, it should be
reported there.

Without a specific need for a menubar, all it does
is take up valuable vertical space.  And continuing
to add OSX special casing clutters up the IDLE code;
IMO it should be limited to situations where
functionality is compromised.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517996&group_id=5470

From noreply at sourceforge.net  Sun Jul 16 03:51:30 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 15 Jul 2006 18:51:30 -0700
Subject: [ python-Bugs-1512814 ] Incorrect lineno's in code objects
Message-ID: <E1G1vn8-0001fW-J4@sc8-sf-web2.sourceforge.net>

Bugs item #1512814, was opened at 2006-06-26 09:01
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512814&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Thomas Wouters (twouters)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Incorrect lineno's in code objects

Initial Comment:
The 2.5 compiler forgets how to count linenumbers in
certain situations:

>>> s255 = "".join(["\n"] * 255 + ["spam"])
>>> s256 = "".join(["\n"] * 256 + ["spam"])

>>> exec s255
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 256, in <module>
NameError: name 'spam' is not defined

>>> exec s256
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 1, in <module>
NameError: name 'spam' is not defined

Notice the 'line 1' linenumber in the case of 256 blank
lines. The same happens for 'pass' statements or 'if 0'
blocks instead of blank lines. The problem is in the
actual code objects created:

>>> dis.disco(compile(s255, "", "exec"))
256           0 LOAD_NAME                0 (spam)
              3 POP_TOP             
              4 LOAD_CONST               0 (None)
              7 RETURN_VALUE        
>>> dis.disco(compile(s256, "", "exec"))
  1           0 LOAD_NAME                0 (spam)
              3 POP_TOP             
              4 LOAD_CONST               0 (None)
              7 RETURN_VALUE        



----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-15 18:51

Message:
Logged In: YES 
user_id=33168

Committed revision 50673.

Hopefully I'm really done this time. :-)

----------------------------------------------------------------------

Comment By: Thomas Wouters (twouters)
Date: 2006-07-13 02:58

Message:
Logged In: YES 
user_id=34209

Yep, the patch seems to work, also for the other case
someone pointed out to me, that was still broken after the
last fix:

>>> exec "import os\ns='''" + "\n"*256 + "'''\n1/0\n"
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 1, in <module>
ZeroDivisionError: integer division or modulo by zero

I tried a couple of other ways to get large linenumbers and
complex(er) parsing structures, and they all seem to work right.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-12 22:59

Message:
Logged In: YES 
user_id=33168

Try the attached patch on for size.  Let me know if you can
find any other holes.

----------------------------------------------------------------------

Comment By: Thomas Wouters (twouters)
Date: 2006-07-12 06:11

Message:
Logged In: YES 
user_id=34209

Unfortunately, it isn't quite fixed. It's fixed for code in
the global scope, but not for functions:

>>> s255 = "def foo():\n " + "".join(["\n "] * 254 + ["
spam\n"])
>>> exec s255
>>> dis.dis(foo)
.256           0 LOAD_GLOBAL              0 (spam)
.              3 POP_TOP             
.              4 LOAD_CONST               0 (None)
.              7 RETURN_VALUE        

>>> s256 = "def foo():\n " + "".join(["\n "] * 255 + ["
spam\n"])
>>> exec s256
>>> dis.dis(foo)
.  1           0 LOAD_GLOBAL              0 (spam)
.              3 POP_TOP             
.              4 LOAD_CONST               0 (None)
.              7 RETURN_VALUE        

I haven't tried figuring out for what else it's broken like
this, sorry :)


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-09 17:04

Message:
Logged In: YES 
user_id=33168

Committed revision 50500.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512814&group_id=5470

From noreply at sourceforge.net  Sun Jul 16 19:40:37 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 16 Jul 2006 10:40:37 -0700
Subject: [ python-Bugs-1523465 ] threading.Thread  Traceback
Message-ID: <E1G2Abd-0006e1-PK@sc8-sf-web5.sourceforge.net>

Bugs item #1523465, was opened at 2006-07-16 17: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=1523465&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Threads
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: roee88 (roee88)
Assigned to: Nobody/Anonymous (nobody)
Summary: threading.Thread  Traceback

Initial Comment:
I'm using the following line in my application:
Thread(target = open_new(dest)).start()

dest is file path set by user.
Got this traceback with python 2.5:
File "C:\python25\lib\threading.py", line 460, in 
__boostrap
self.run()
File "C:\python25\threading.py, line 440, in run
self.__target(*self.__args, **self.kwargs)
TypeError: 'bool' object is not callable

Worked well with python 2.4 .
OS: windows XP 32 bit.
Searched for a similar bug report but couldn't find 
one, sorry if it already been reported.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1523465&group_id=5470

From noreply at sourceforge.net  Sun Jul 16 20:55:12 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 16 Jul 2006 11:55:12 -0700
Subject: [ python-Feature Requests-1191699 ] make slices pickable
Message-ID: <E1G2Blo-0003ao-SU@sc8-sf-web1.sourceforge.net>

Feature Requests item #1191699, was opened at 2005-04-28 13:44
Message generated for change (Comment added) made by connelly
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1191699&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Sebastien de Menten (sdementen)
Assigned to: Raymond Hettinger (rhettinger)
Summary: make slices pickable

Initial Comment:
As suggested  by the summary, provide pickability of 
slices by default.
Currently one has to use copy_reg module to register 
slices as pickables.

----------------------------------------------------------------------

Comment By: Connelly (connelly)
Date: 2006-07-16 18:55

Message:
Logged In: YES 
user_id=1039782

Additional use case: I needed picklable slices when logging method calls to a 
database:  __setitem__(self, i, x) could not be logged because the database 
module attempted to pickle objects such as ('__setitem__', slice(1, 2, 3), []).

For other Python users who have run into this problem: the code needed to 
make slices picklable by copy_reg is available at:

  http://mail.python.org/pipermail/python-list/2004-November/
248988.html


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-03 00:50

Message:
Logged In: YES 
user_id=80475

Okay, sounds reasonable.  Will implement when I have time.

----------------------------------------------------------------------

Comment By: Sebastien de Menten (sdementen)
Date: 2005-04-30 18:02

Message:
Logged In: YES 
user_id=820079

Use case for pickable slices. 
Let A be a numeric array of size M x N. We want to consider 
sub-arrays in this array like A[:4, :] (the first 4 lines of the 
array). 
If we want to store both the array and the information of 
sub-arrays structures, we need to store slices (we can also 
store start/end indices of the array ... but this is call a slice 
so it would be better to have pickable slices). 
 
In fact, whenever one wants to write generic algorithm 
working on "sublist of lists" or "subarrays of arrays" or 
"sub-items of collection of items", it is nicer to use slice 
objects explicitly and so store them also explicitly. 
 

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-30 12:32

Message:
Logged In: YES 
user_id=80475

Use cases?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1191699&group_id=5470

From noreply at sourceforge.net  Sun Jul 16 20:55:47 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 16 Jul 2006 11:55:47 -0700
Subject: [ python-Bugs-1522771 ] Patch #1388073 is not mentioned in NEWS
Message-ID: <E1G2BmN-0002Kl-Sq@sc8-sf-web5.sourceforge.net>

Bugs item #1522771, was opened at 2006-07-14 16:09
Message generated for change (Comment added) made by collinwinter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1522771&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Collin Winter (collinwinter)
>Assigned to: Georg Brandl (gbrandl)
Summary: Patch #1388073 is not mentioned in NEWS

Initial Comment:
This patch adds a mention of patch #1388073 (which
changed the names of several attributes on
unittest.TestCase) to the "Library" subsection of
Misc/NEWS for Python 2.5 alpha 1 (since the patch was
applied before 2.5a1 was released).

----------------------------------------------------------------------

>Comment By: Collin Winter (collinwinter)
Date: 2006-07-16 14:55

Message:
Logged In: YES 
user_id=1344176

Assigned to gbrandl, since he committed the initial patch.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1522771&group_id=5470

From noreply at sourceforge.net  Sun Jul 16 21:01:15 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 16 Jul 2006 12:01:15 -0700
Subject: [ python-Bugs-1523465 ] threading.Thread  Traceback
Message-ID: <E1G2Brf-0005lE-Ml@sc8-sf-web6.sourceforge.net>

Bugs item #1523465, was opened at 2006-07-16 13:40
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1523465&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Threads
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: roee88 (roee88)
Assigned to: Nobody/Anonymous (nobody)
Summary: threading.Thread  Traceback

Initial Comment:
I'm using the following line in my application:
Thread(target = open_new(dest)).start()

dest is file path set by user.
Got this traceback with python 2.5:
File "C:\python25\lib\threading.py", line 460, in 
__boostrap
self.run()
File "C:\python25\threading.py, line 440, in run
self.__target(*self.__args, **self.kwargs)
TypeError: 'bool' object is not callable

Worked well with python 2.4 .
OS: windows XP 32 bit.
Searched for a similar bug report but couldn't find 
one, sorry if it already been reported.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-07-16 15:01

Message:
Logged In: YES 
user_id=31435

What does `open_new` return?  What does

print type(open_new(dest))

display in a failing case?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1523465&group_id=5470

From noreply at sourceforge.net  Sun Jul 16 21:18:15 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 16 Jul 2006 12:18:15 -0700
Subject: [ python-Bugs-1523465 ] threading.Thread  Traceback
Message-ID: <E1G2C87-000799-Ld@sc8-sf-web6.sourceforge.net>

Bugs item #1523465, was opened at 2006-07-16 17:40
Message generated for change (Comment added) made by roee88
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1523465&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Threads
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: roee88 (roee88)
Assigned to: Nobody/Anonymous (nobody)
Summary: threading.Thread  Traceback

Initial Comment:
I'm using the following line in my application:
Thread(target = open_new(dest)).start()

dest is file path set by user.
Got this traceback with python 2.5:
File "C:\python25\lib\threading.py", line 460, in 
__boostrap
self.run()
File "C:\python25\threading.py, line 440, in run
self.__target(*self.__args, **self.kwargs)
TypeError: 'bool' object is not callable

Worked well with python 2.4 .
OS: windows XP 32 bit.
Searched for a similar bug report but couldn't find 
one, sorry if it already been reported.

----------------------------------------------------------------------

>Comment By: roee88 (roee88)
Date: 2006-07-16 19:18

Message:
Logged In: YES 
user_id=1111143

open_new is imported from webbrowser and it returns a 
boolean (True in that case).

This shouldn't conflict with the Thread target.
Just as a note, except for the Traceback everything works 
well. The dest does open.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-16 19:01

Message:
Logged In: YES 
user_id=31435

What does `open_new` return?  What does

print type(open_new(dest))

display in a failing case?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1523465&group_id=5470

From noreply at sourceforge.net  Sun Jul 16 22:04:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 16 Jul 2006 13:04:23 -0700
Subject: [ python-Bugs-1523465 ] threading.Thread  Traceback
Message-ID: <E1G2Cql-0005to-E2@sc8-sf-web1.sourceforge.net>

Bugs item #1523465, was opened at 2006-07-16 13:40
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1523465&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Threads
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: roee88 (roee88)
Assigned to: Nobody/Anonymous (nobody)
Summary: threading.Thread  Traceback

Initial Comment:
I'm using the following line in my application:
Thread(target = open_new(dest)).start()

dest is file path set by user.
Got this traceback with python 2.5:
File "C:\python25\lib\threading.py", line 460, in 
__boostrap
self.run()
File "C:\python25\threading.py, line 440, in run
self.__target(*self.__args, **self.kwargs)
TypeError: 'bool' object is not callable

Worked well with python 2.4 .
OS: windows XP 32 bit.
Searched for a similar bug report but couldn't find 
one, sorry if it already been reported.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-07-16 16:04

Message:
Logged In: YES 
user_id=31435

Why do you imagine it makes sense to pass a boolean as the
target?  What do you think that should do?  As the message
said, a bool object is not callable, and, from the docs:

"""
`target` is the callable object to be invoked by the `run()`
method. Defaults to None, meaning nothing is called. 
"""

It doesn't make sense to pass True (or, e.g., an integer,
string, list, dict, or anything else that isn't callable).

Note that it's not true that Python 2.4 (or any other
version of Python) accepted a boolen here either; e.g.,

$ python
Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more
information.
>>> import threading
>>> threading.Thread(target=True).start()
>>> Exception in thread Thread-2:
Traceback (most recent call last):
  File "C:\Python24\lib\threading.py", line 442, in __bootstrap
    self.run()
  File "C:\Python24\lib\threading.py", line 422, in run
    self.__target(*self.__args, **self.__kwargs)
TypeError: 'bool' object is not callable


----------------------------------------------------------------------

Comment By: roee88 (roee88)
Date: 2006-07-16 15:18

Message:
Logged In: YES 
user_id=1111143

open_new is imported from webbrowser and it returns a 
boolean (True in that case).

This shouldn't conflict with the Thread target.
Just as a note, except for the Traceback everything works 
well. The dest does open.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-16 15:01

Message:
Logged In: YES 
user_id=31435

What does `open_new` return?  What does

print type(open_new(dest))

display in a failing case?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1523465&group_id=5470

From noreply at sourceforge.net  Sun Jul 16 22:47:44 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 16 Jul 2006 13:47:44 -0700
Subject: [ python-Bugs-1523465 ] threading.Thread  Traceback
Message-ID: <E1G2DWi-0002iY-GM@sc8-sf-web6.sourceforge.net>

Bugs item #1523465, was opened at 2006-07-16 17:40
Message generated for change (Comment added) made by roee88
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1523465&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Threads
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: roee88 (roee88)
Assigned to: Nobody/Anonymous (nobody)
Summary: threading.Thread  Traceback

Initial Comment:
I'm using the following line in my application:
Thread(target = open_new(dest)).start()

dest is file path set by user.
Got this traceback with python 2.5:
File "C:\python25\lib\threading.py", line 460, in 
__boostrap
self.run()
File "C:\python25\threading.py, line 440, in run
self.__target(*self.__args, **self.kwargs)
TypeError: 'bool' object is not callable

Worked well with python 2.4 .
OS: windows XP 32 bit.
Searched for a similar bug report but couldn't find 
one, sorry if it already been reported.

----------------------------------------------------------------------

>Comment By: roee88 (roee88)
Date: 2006-07-16 20:47

Message:
Logged In: YES 
user_id=1111143

I'm really sorry, I got confused because of a change 
between 2.4 and 2.5 in the return value of open_new.
Python 2.4 always returns None so there is no exception.

After reading the docs I saw I need to use:
Thread(target = open_new, args = [dest]).start()
Sorry again. Have a nice day :)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-16 20:04

Message:
Logged In: YES 
user_id=31435

Why do you imagine it makes sense to pass a boolean as the
target?  What do you think that should do?  As the message
said, a bool object is not callable, and, from the docs:

"""
`target` is the callable object to be invoked by the `run()`
method. Defaults to None, meaning nothing is called. 
"""

It doesn't make sense to pass True (or, e.g., an integer,
string, list, dict, or anything else that isn't callable).

Note that it's not true that Python 2.4 (or any other
version of Python) accepted a boolen here either; e.g.,

$ python
Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more
information.
>>> import threading
>>> threading.Thread(target=True).start()
>>> Exception in thread Thread-2:
Traceback (most recent call last):
  File "C:\Python24\lib\threading.py", line 442, in __bootstrap
    self.run()
  File "C:\Python24\lib\threading.py", line 422, in run
    self.__target(*self.__args, **self.__kwargs)
TypeError: 'bool' object is not callable


----------------------------------------------------------------------

Comment By: roee88 (roee88)
Date: 2006-07-16 19:18

Message:
Logged In: YES 
user_id=1111143

open_new is imported from webbrowser and it returns a 
boolean (True in that case).

This shouldn't conflict with the Thread target.
Just as a note, except for the Traceback everything works 
well. The dest does open.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-16 19:01

Message:
Logged In: YES 
user_id=31435

What does `open_new` return?  What does

print type(open_new(dest))

display in a failing case?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1523465&group_id=5470

From noreply at sourceforge.net  Mon Jul 17 00:20:38 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 16 Jul 2006 15:20:38 -0700
Subject: [ python-Bugs-1523465 ] threading.Thread  Traceback
Message-ID: <E1G2Eyc-0006M0-BG@sc8-sf-web2.sourceforge.net>

Bugs item #1523465, was opened at 2006-07-16 13:40
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1523465&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Threads
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: roee88 (roee88)
Assigned to: Nobody/Anonymous (nobody)
Summary: threading.Thread  Traceback

Initial Comment:
I'm using the following line in my application:
Thread(target = open_new(dest)).start()

dest is file path set by user.
Got this traceback with python 2.5:
File "C:\python25\lib\threading.py", line 460, in 
__boostrap
self.run()
File "C:\python25\threading.py, line 440, in run
self.__target(*self.__args, **self.kwargs)
TypeError: 'bool' object is not callable

Worked well with python 2.4 .
OS: windows XP 32 bit.
Searched for a similar bug report but couldn't find 
one, sorry if it already been reported.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-07-16 18:20

Message:
Logged In: YES 
user_id=31435

That's OK -- I'm glad you're unstuck now!  Closing as Not-a-Bug.

----------------------------------------------------------------------

Comment By: roee88 (roee88)
Date: 2006-07-16 16:47

Message:
Logged In: YES 
user_id=1111143

I'm really sorry, I got confused because of a change 
between 2.4 and 2.5 in the return value of open_new.
Python 2.4 always returns None so there is no exception.

After reading the docs I saw I need to use:
Thread(target = open_new, args = [dest]).start()
Sorry again. Have a nice day :)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-16 16:04

Message:
Logged In: YES 
user_id=31435

Why do you imagine it makes sense to pass a boolean as the
target?  What do you think that should do?  As the message
said, a bool object is not callable, and, from the docs:

"""
`target` is the callable object to be invoked by the `run()`
method. Defaults to None, meaning nothing is called. 
"""

It doesn't make sense to pass True (or, e.g., an integer,
string, list, dict, or anything else that isn't callable).

Note that it's not true that Python 2.4 (or any other
version of Python) accepted a boolen here either; e.g.,

$ python
Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more
information.
>>> import threading
>>> threading.Thread(target=True).start()
>>> Exception in thread Thread-2:
Traceback (most recent call last):
  File "C:\Python24\lib\threading.py", line 442, in __bootstrap
    self.run()
  File "C:\Python24\lib\threading.py", line 422, in run
    self.__target(*self.__args, **self.__kwargs)
TypeError: 'bool' object is not callable


----------------------------------------------------------------------

Comment By: roee88 (roee88)
Date: 2006-07-16 15:18

Message:
Logged In: YES 
user_id=1111143

open_new is imported from webbrowser and it returns a 
boolean (True in that case).

This shouldn't conflict with the Thread target.
Just as a note, except for the Traceback everything works 
well. The dest does open.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-16 15:01

Message:
Logged In: YES 
user_id=31435

What does `open_new` return?  What does

print type(open_new(dest))

display in a failing case?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1523465&group_id=5470

From noreply at sourceforge.net  Mon Jul 17 03:13:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 16 Jul 2006 18:13:23 -0700
Subject: [ python-Bugs-1521726 ] isinstance failure in 2.5 Beta 2
Message-ID: <E1G2Hfn-00019R-1M@sc8-sf-web1.sourceforge.net>

Bugs item #1521726, was opened at 2006-07-13 03:56
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521726&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
>Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Nick Maclaren (nmm)
Assigned to: Nobody/Anonymous (nobody)
Summary: isinstance failure in 2.5 Beta 2

Initial Comment:
Linux gosset 2.6.16.13-4-smp #1 SMP Wed May 3 04:53:23
UTC 2006 x86_64 x86_64 x86_64 GNU/Linux
./python Lib/test/test_compile.py

  File "Lib/test/test_compile.py", line 6, in <module>
    class TestSpecifics(unittest.TestCase):
  File "Lib/test/test_compile.py", line 399, in test_main
    test_support.run_unittest(TestSpecifics)
  File
"/home/nmm/Python-2.5b2/Lib/test/test_support.py", line
422, in run_unittest
    run_suite(suite, testclass)
  File
"/home/nmm/Python-2.5b2/Lib/test/test_support.py", line
407, in run_suite    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent
call last):
  File "Lib/test/test_compile.py", line 226, in
test_unary_minus
    self.assertTrue(isinstance(eval("%s" % (-sys.maxint
- 1)), int))

./python
Python 2.5b2 (r25b2:50512, Jul 13 2006, 11:33:15)
>>> import sys
>>> print sys.maxint
9223372036854775807
>>> print "%s" % (-sys.maxint - 1)
-9223372036854775808
>>> print isinstance(eval("%s" % (-sys.maxint - 1)), int)
False
>>> print isinstance(eval("%s" % (-sys.maxint)), int)
True


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-16 18:13

Message:
Logged In: YES 
user_id=33168

What version of gcc?  Is this a duplicate of 1521947.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521726&group_id=5470

From noreply at sourceforge.net  Mon Jul 17 03:13:36 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 16 Jul 2006 18:13:36 -0700
Subject: [ python-Bugs-1521947 ] possible bug in mystrtol.c with recent gcc
Message-ID: <E1G2Hg0-0001G1-Nk@sc8-sf-web1.sourceforge.net>

Bugs item #1521947, was opened at 2006-07-13 10:39
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521947&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Marien Zwart (marienz)
Assigned to: Nobody/Anonymous (nobody)
Summary: possible bug in mystrtol.c with recent gcc

Initial Comment:
python 2.5b2 compiled with gentoo's gcc 4.1.1 and -O2
fails test_unary_minus in test_compile.py. Some
investigating showed that the -ftree-vrp pass of that
gcc (implied by -O2) optimizes out the "result ==
-result" test on line 215 of PyOS_strtol, meaning
PyOS_strtol of the most negative long will incorrectly
overflow. 

Python deals with this in this case by constructing a
python long object instead of a python int object, so
at least in this case the problem is not serious. I
have no idea if there is a case where this is a "real"
problem.

At first I reported this as a gentoo compiler bug, but
got the reply that:

"""
I'm pretty sure it's broken. -LONG_MIN overflows when
LONG_MIN < -LONG_MAX, and in standard C as well as "GNU
C", behaviour after overflow on signed integer
operations is undefined.
"""

(see https://bugs.gentoo.org/show_bug.cgi?id=140133)

So now I'm reporting this here. There seems to be a
LONG_MIN constant in limits.h here that could checked
against instead, but I have absolutely no idea how
standard that is. Or this could be a compiler bug after
all, in which case I would appreciate information I Can
use to back that up :)

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-16 18:13

Message:
Logged In: YES 
user_id=33168

Is this a duplicate of 1521726?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521947&group_id=5470

From noreply at sourceforge.net  Mon Jul 17 04:23:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 16 Jul 2006 19:23:25 -0700
Subject: [ python-Bugs-1523610 ] PyArg_ParseTupleAndKeywords potential core
	dump
Message-ID: <E1G2IlZ-0000Td-PO@sc8-sf-web1.sourceforge.net>

Bugs item #1523610, was opened at 2006-07-16 19: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=1523610&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Eric Huss (ehuss)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyArg_ParseTupleAndKeywords potential core dump

Initial Comment:
After getting bit by bug 893549, I was noticing that
sometimes I was getting a core dump instead of a
TypeError when PyArg_ParseTupleAndKeywords was skipping
over a type the "skipitem" code does not understand.

There are about 4 problems I will describe (though they
are related, so it's probably not worth filing seperate
bugs).

The problem is that the "levels" variable is passed to
the seterror function uninitialized.  If levels does
not happen to contain any 0 elements, then the
iteration code in seterror will go crazy (I will get to
this in a moment).

In the one place where "skipitem" is called, you will
notice it immediately calls seterror() if it returned
an error message.  However, "levels" is not set by the
skipitem function, and thus seterror iterates over an
uninitialized value.  I suggest setting levels[0] = 0
somewhere in the beginning of the code, since the
expectations of setting the "levels" seems awefully
delicate.

(As a side note, there's no bounds checking on the
levels variable, either.  It seems unlikely that
someone will have 32 levels of nested variables, but I
think it points to a general problem with how the
variable is passed around.)

A second fix is to set levels[0] = 0 if setitem fails
before calling seterror().

Now, returning to the "seterror goes crazy" problem I
mentioned earlier, the following code in the seterror
function:

while (levels[i] > 0 && (int)(p-buf) < 220) {

should be:

while (levels[i] > 0 && (int)(p-buf) > 220) {

At least, that's what I'm assuming it is supposed to
be.  I think it should be clear why this is bad.

But wait, there's more!  The snprintf in seterror call
uses the incorrect size of buf.  The following line:

PyOS_snprintf(p, sizeof(buf) - (buf - p),

should be:

PyOS_snprintf(p, sizeof(buf) - (p - buf),

My particular platform (FreeBSD) puts a NUL character
at the end of the buffer.  However, since the size of
the buffer is computed incorrectly, this line of code
stomps on the stack (overwritting the levels value in
my case).

Let me know if you have any questions, or want any
sample code.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1523610&group_id=5470

From noreply at sourceforge.net  Mon Jul 17 04:28:16 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 16 Jul 2006 19:28:16 -0700
Subject: [ python-Bugs-1523610 ] PyArg_ParseTupleAndKeywords potential core
	dump
Message-ID: <E1G2IqG-0002js-O1@sc8-sf-web1.sourceforge.net>

Bugs item #1523610, was opened at 2006-07-16 19:23
Message generated for change (Comment added) made by ehuss
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1523610&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Eric Huss (ehuss)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyArg_ParseTupleAndKeywords potential core dump

Initial Comment:
After getting bit by bug 893549, I was noticing that
sometimes I was getting a core dump instead of a
TypeError when PyArg_ParseTupleAndKeywords was skipping
over a type the "skipitem" code does not understand.

There are about 4 problems I will describe (though they
are related, so it's probably not worth filing seperate
bugs).

The problem is that the "levels" variable is passed to
the seterror function uninitialized.  If levels does
not happen to contain any 0 elements, then the
iteration code in seterror will go crazy (I will get to
this in a moment).

In the one place where "skipitem" is called, you will
notice it immediately calls seterror() if it returned
an error message.  However, "levels" is not set by the
skipitem function, and thus seterror iterates over an
uninitialized value.  I suggest setting levels[0] = 0
somewhere in the beginning of the code, since the
expectations of setting the "levels" seems awefully
delicate.

(As a side note, there's no bounds checking on the
levels variable, either.  It seems unlikely that
someone will have 32 levels of nested variables, but I
think it points to a general problem with how the
variable is passed around.)

A second fix is to set levels[0] = 0 if setitem fails
before calling seterror().

Now, returning to the "seterror goes crazy" problem I
mentioned earlier, the following code in the seterror
function:

while (levels[i] > 0 && (int)(p-buf) < 220) {

should be:

while (levels[i] > 0 && (int)(p-buf) > 220) {

At least, that's what I'm assuming it is supposed to
be.  I think it should be clear why this is bad.

But wait, there's more!  The snprintf in seterror call
uses the incorrect size of buf.  The following line:

PyOS_snprintf(p, sizeof(buf) - (buf - p),

should be:

PyOS_snprintf(p, sizeof(buf) - (p - buf),

My particular platform (FreeBSD) puts a NUL character
at the end of the buffer.  However, since the size of
the buffer is computed incorrectly, this line of code
stomps on the stack (overwritting the levels value in
my case).

Let me know if you have any questions, or want any
sample code.


----------------------------------------------------------------------

>Comment By: Eric Huss (ehuss)
Date: 2006-07-16 19:28

Message:
Logged In: YES 
user_id=393416

Oops, skip the section about <220 being >220.  I've been
staring at it too long.  The rest of the issues should be
valid, though.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1523610&group_id=5470

From noreply at sourceforge.net  Mon Jul 17 04:34:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 16 Jul 2006 19:34:23 -0700
Subject: [ python-Bugs-957381 ] bdist_rpm fails on redhat9, fc1, fc2
Message-ID: <E1G2IwB-0000LG-IG@sc8-sf-web2.sourceforge.net>

Bugs item #957381, was opened at 2004-05-20 09:05
Message generated for change (Comment added) made by misa
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=957381&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Epler (jepler)
Assigned to: Anthony Baxter (anthonybaxter)
Summary: bdist_rpm fails on redhat9, fc1, fc2

Initial Comment:
distutils bdist_rpm has long been broken for recent
versions of RPM (RedHat 9, Fedora Core 1 and 2)
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=88616
 
When an RPM contains an executable or shared library, a
"-debuginfo" rpm is generated.  For instance, the
following two packages would be generated:
    foo-1.0.0-1.i386.rpm
    foo-debuginfo-1.0.0.1-i386.rpm
 
When distutils is faced with this problem, it prints an
error like
    AssertionError: unexpected number of RPM files
found:
['build/bdist.linux-i686/rpm/RPMS/i386/foo-1.0.0-1.i386.rpm',
build/bdist.linux-i686/rpm/RPMS/i386/foo-debuginfo-1.0.0-1.i386.rpm']

The bugzilla bug contains a proposed patch, but
redhat/fedora developers chose not to accept it for
their own build of Python.

----------------------------------------------------------------------

Comment By: Mihai Ibanescu (misa)
Date: 2006-07-16 22:34

Message:
Logged In: YES 
user_id=205865

Please see patch 1060577  for a more general approach that
should let people build multiple rpms out of a spec file.

https://sourceforge.net/tracker/?func=detail&aid=1060577&group_id=5470&atid=305470

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-06-11 13:18

Message:
Logged In: YES 
user_id=29957

Applied to trunk. Will backport to the 2.3 branch.


----------------------------------------------------------------------

Comment By: Jeff Epler (jepler)
Date: 2004-05-21 07:46

Message:
Logged In: YES 
user_id=2772

the "WONTFIX" closure of bugzilla 88616 was already from
Fedora days (2004-04-05), so opening a new bug report is
unlikely to do much on its own.  (in fact, I don't know if
it's likely to do more than get closed as a duplicate)  Of
course, I don't speak for Fedora.

If a fix for this new RPM feature is included in Python (for
2.3.5 and 2.4) then I'd guess it's more likely to be added
as a patch for a subsequent 2.3.3 or 2.3.4-based Python
package, but again I don't speak for the Fedora developers.

----------------------------------------------------------------------

Comment By: Jeremy Sanders (jeremysanders)
Date: 2004-05-21 04:46

Message:
Logged In: YES 
user_id=8953

I've opened a bugzilla report for fedora 2 

See
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=123598

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=957381&group_id=5470

From noreply at sourceforge.net  Mon Jul 17 07:48:56 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 16 Jul 2006 22:48:56 -0700
Subject: [ python-Bugs-1504456 ] xmlcore needs to be documented
Message-ID: <E1G2LyS-0004FV-6z@sc8-sf-web1.sourceforge.net>

Bugs item #1504456, was opened at 2006-06-11 15:50
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504456&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 6
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: xmlcore needs to be documented

Initial Comment:
The change from the "xml" package to the "xmlcore"
package needs to be documented for Python 2.5.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-17 01:48

Message:
Logged In: YES 
user_id=3066

I've added a brief mention of the xmlcore package in the
chapter intro.  Each module reference section needs to have
something added still.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-06-20 09:20

Message:
Logged In: YES 
user_id=11375

I've added this to rev. 47044 of the "What's New".

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504456&group_id=5470

From noreply at sourceforge.net  Mon Jul 17 11:20:49 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 17 Jul 2006 02:20:49 -0700
Subject: [ python-Bugs-1521947 ] possible bug in mystrtol.c with recent gcc
Message-ID: <E1G2PHV-0001Cb-AQ@sc8-sf-web5.sourceforge.net>

Bugs item #1521947, was opened at 2006-07-13 17:39
Message generated for change (Comment added) made by nmm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521947&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Marien Zwart (marienz)
Assigned to: Nobody/Anonymous (nobody)
Summary: possible bug in mystrtol.c with recent gcc

Initial Comment:
python 2.5b2 compiled with gentoo's gcc 4.1.1 and -O2
fails test_unary_minus in test_compile.py. Some
investigating showed that the -ftree-vrp pass of that
gcc (implied by -O2) optimizes out the "result ==
-result" test on line 215 of PyOS_strtol, meaning
PyOS_strtol of the most negative long will incorrectly
overflow. 

Python deals with this in this case by constructing a
python long object instead of a python int object, so
at least in this case the problem is not serious. I
have no idea if there is a case where this is a "real"
problem.

At first I reported this as a gentoo compiler bug, but
got the reply that:

"""
I'm pretty sure it's broken. -LONG_MIN overflows when
LONG_MIN < -LONG_MAX, and in standard C as well as "GNU
C", behaviour after overflow on signed integer
operations is undefined.
"""

(see https://bugs.gentoo.org/show_bug.cgi?id=140133)

So now I'm reporting this here. There seems to be a
LONG_MIN constant in limits.h here that could checked
against instead, but I have absolutely no idea how
standard that is. Or this could be a compiler bug after
all, in which case I would appreciate information I Can
use to back that up :)

----------------------------------------------------------------------

Comment By: Nick Maclaren (nmm)
Date: 2006-07-17 09:20

Message:
Logged In: YES 
user_id=42444

Yes, this is a duplicate of 1521726.

The compiler people's answer is correct, and mystrtoul.c is
incorrect. LONG_MIN has been in C since C90, so should be
safe, but its value may not always be what you expect.

However, the code breakage is worse that just that test, and
there are the following 3 cases of undefined behaviour:

    1) Casting and unsigned long to long above LONG_MAX.
    2) That test.
    3) result = -result.

The fix should be to make result unsigned long, and check
the range BEFORE any conversion.  Nothing else is safe.

It is a matter of taste whether to include a fiddle for the
number that can be held only when negated - I wouldn't, and
would let that number be converted to a Python long, but
others might disagree.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-17 01:13

Message:
Logged In: YES 
user_id=33168

Is this a duplicate of 1521726?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521947&group_id=5470

From noreply at sourceforge.net  Mon Jul 17 11:22:28 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 17 Jul 2006 02:22:28 -0700
Subject: [ python-Bugs-1521726 ] isinstance failure in 2.5 Beta 2
Message-ID: <E1G2PJ6-0005Dc-1y@sc8-sf-web2.sourceforge.net>

Bugs item #1521726, was opened at 2006-07-13 10:56
Message generated for change (Comment added) made by nmm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521726&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Nick Maclaren (nmm)
Assigned to: Nobody/Anonymous (nobody)
Summary: isinstance failure in 2.5 Beta 2

Initial Comment:
Linux gosset 2.6.16.13-4-smp #1 SMP Wed May 3 04:53:23
UTC 2006 x86_64 x86_64 x86_64 GNU/Linux
./python Lib/test/test_compile.py

  File "Lib/test/test_compile.py", line 6, in <module>
    class TestSpecifics(unittest.TestCase):
  File "Lib/test/test_compile.py", line 399, in test_main
    test_support.run_unittest(TestSpecifics)
  File
"/home/nmm/Python-2.5b2/Lib/test/test_support.py", line
422, in run_unittest
    run_suite(suite, testclass)
  File
"/home/nmm/Python-2.5b2/Lib/test/test_support.py", line
407, in run_suite    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent
call last):
  File "Lib/test/test_compile.py", line 226, in
test_unary_minus
    self.assertTrue(isinstance(eval("%s" % (-sys.maxint
- 1)), int))

./python
Python 2.5b2 (r25b2:50512, Jul 13 2006, 11:33:15)
>>> import sys
>>> print sys.maxint
9223372036854775807
>>> print "%s" % (-sys.maxint - 1)
-9223372036854775808
>>> print isinstance(eval("%s" % (-sys.maxint - 1)), int)
False
>>> print isinstance(eval("%s" % (-sys.maxint)), int)
True


----------------------------------------------------------------------

>Comment By: Nick Maclaren (nmm)
Date: 2006-07-17 09:22

Message:
Logged In: YES 
user_id=42444

Yes, it is a duplicate of 1521947.  4.1.0, for what it is
worth, but I have added comments to 1521947.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-17 01:13

Message:
Logged In: YES 
user_id=33168

What version of gcc?  Is this a duplicate of 1521947.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521726&group_id=5470

From noreply at sourceforge.net  Mon Jul 17 14:13:47 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 17 Jul 2006 05:13:47 -0700
Subject: [ python-Bugs-1523136 ] incorrect tcp checksum
Message-ID: <E1G2Ryt-0002Ig-0G@sc8-sf-web1.sourceforge.net>

Bugs item #1523136, was opened at 2006-07-15 20:49
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1523136&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
>Group: 3rd Party
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: ecir hana (ecirhana)
Assigned to: Nobody/Anonymous (nobody)
Summary: incorrect tcp checksum

Initial Comment:
hi,

when using 'socket' library for a simple web server
'ethereal' reports incorrect checksum in transmission
control protocol.

on ubuntu dapper drake and firefox

----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-07-17 14:13

Message:
Logged In: YES 
user_id=21627

This can hardly be a problem in Python. Python uses the TCP
implementation of the operating system, and the TCP stack
computes the checksum.

Closing as third-party bug.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1523136&group_id=5470

From noreply at sourceforge.net  Mon Jul 17 15:26:41 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 17 Jul 2006 06:26:41 -0700
Subject: [ python-Bugs-1522771 ] Patch #1388073 is not mentioned in NEWS
Message-ID: <E1G2T7R-0005Gl-W6@sc8-sf-web5.sourceforge.net>

Bugs item #1522771, was opened at 2006-07-14 20:09
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1522771&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Collin Winter (collinwinter)
Assigned to: Georg Brandl (gbrandl)
Summary: Patch #1388073 is not mentioned in NEWS

Initial Comment:
This patch adds a mention of patch #1388073 (which
changed the names of several attributes on
unittest.TestCase) to the "Library" subsection of
Misc/NEWS for Python 2.5 alpha 1 (since the patch was
applied before 2.5a1 was released).

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-17 13:26

Message:
Logged In: YES 
user_id=849994

Committed rev. 50689.

----------------------------------------------------------------------

Comment By: Collin Winter (collinwinter)
Date: 2006-07-16 18:55

Message:
Logged In: YES 
user_id=1344176

Assigned to gbrandl, since he committed the initial patch.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1522771&group_id=5470

From noreply at sourceforge.net  Mon Jul 17 15:49:37 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 17 Jul 2006 06:49:37 -0700
Subject: [ python-Bugs-1523853 ] 2.4.2 file.read caches EOF state
Message-ID: <E1G2TTd-0006ep-RZ@sc8-sf-web1.sourceforge.net>

Bugs item #1523853, was opened at 2006-07-17 13: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=1523853&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jarkko Torppa (beeki)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.4.2 file.read caches EOF state

Initial Comment:
It seems that python 2.4.2 file reading stuff (for l in
f) and (f.read()) cache EOF state. For f.next
documtation hints that there is internal buffer so I
guess that this is somewhat acceptable there. But for
f.read() there is no hint about internal buffering of
the state.

This is somewhat unfortunate as tail -f like
functionality is impossible to implement without doing
lowlevel io (os.read) (as traddional unix has no
select-like functionality on files).

Tested on solaris8. This is either library or
documentation bug.

Code below

def iterline(f):
    """ Own function because the internal seems to
buffer EOF
    """
    b=[]
    while 1:
        data=os.read()
        print `data`,`b`,f.tell(), \
               os.fstat(f.fileno()).st_size
        if len(data) == 0:
            time.sleep(1)
            continue
        idx=data.find('\n')
        while idx > 0:
            line=data[:idx]
            if b:
                yield ''.join(b) + line
                b = []
            else:
                yield line
            data=data[idx+1:]
            idx=data.find('\n')
        b.append(data)
    raise StopIteration

Output
'' [''] 1699424 1699424
(log lines appended here)
'' [''] 1699424 1699647



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1523853&group_id=5470

From noreply at sourceforge.net  Mon Jul 17 19:40:40 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 17 Jul 2006 10:40:40 -0700
Subject: [ python-Bugs-1513617 ] IDLE fails to launch after 46272 (2.4 with
	2.5 IDLE)
Message-ID: <E1G2X5E-0003yk-3r@sc8-sf-web1.sourceforge.net>

Bugs item #1513617, was opened at 2006-06-27 17:18
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513617&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
>Group: Python 2.4
>Status: Closed
>Resolution: Invalid
>Priority: 5
Submitted By: John Bollinger (bbands)
Assigned to: Kurt B. Kaiser (kbk)
>Summary: IDLE fails to launch after 46272 (2.4 with 2.5 IDLE)

Initial Comment:
As of revision 46805 IDLE fails silently on launch. If
launched from a command prompt the following output is
seen.

D:\Python24\Lib\idlelib>python idle.py
Traceback (most recent call last):
  File "idle.py", line 2, in ?
    import idlelib.PyShell
  File "D:\Python24\lib\idlelib\PyShell.py", line 27, in ?
    from EditorWindow import EditorWindow, fixwordbreaks
  File "D:\Python24\lib\idlelib\EditorWindow.py", line
42, in ?
    class EditorWindow(object):
  File "D:\Python24\lib\idlelib\EditorWindow.py", line
47, in EditorWindow
    import Bindings
  File "D:\Python24\lib\idlelib\Bindings.py", line 109,
in ?
    default_keydefs = idleConf.GetCurrentKeySet()
  File "D:\Python24\lib\idlelib\configHandler.py", line
499, in GetCurrentKeySet

    result = self.GetKeySet(self.CurrentKeys())
  File "D:\Python24\lib\idlelib\configHandler.py", line
519, in GetKeySet
    activeExtns=self.GetExtensions(active_only=1)
  File "D:\Python24\lib\idlelib\configHandler.py", line
377, in GetExtensions
    extns=self.RemoveKeyBindNames(
  File "D:\Python24\lib\idlelib\configHandler.py", line
410, in RemoveKeyBindNames
    if name.endswith(('_bindings', '_cfgBindings')):
TypeError: expected a character buffer object


----------------------------------------------------------------------

>Comment By: Kurt B. Kaiser (kbk)
Date: 2006-07-17 13:40

Message:
Logged In: YES 
user_id=149084

It appears that you are running a mixed system
on XP: Python 2.4 and IDLE from the repository.

At 46805 IDLE was modified to reflect new syntax:

"Make use of new str.startswith/endswith semantics.
Occurences in email and compiler were ignored due to 
backwards compat requirements."

The change is:

http://svn.python.org/view/python/trunk/Lib/idlelib/
configHandler.py?rev=46805&r1=38395&r2=46805

My suggestion would be to move to 2.5b2, now
available.  Otherwise, modify your configHandler.py
source to revert this change locally.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513617&group_id=5470

From noreply at sourceforge.net  Mon Jul 17 19:55:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 17 Jul 2006 10:55:46 -0700
Subject: [ python-Bugs-1521726 ] isinstance failure in 2.5 Beta 2
Message-ID: <E1G2XJq-00011J-TT@sc8-sf-web1.sourceforge.net>

Bugs item #1521726, was opened at 2006-07-13 10:56
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521726&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Nick Maclaren (nmm)
Assigned to: Nobody/Anonymous (nobody)
Summary: isinstance failure in 2.5 Beta 2

Initial Comment:
Linux gosset 2.6.16.13-4-smp #1 SMP Wed May 3 04:53:23
UTC 2006 x86_64 x86_64 x86_64 GNU/Linux
./python Lib/test/test_compile.py

  File "Lib/test/test_compile.py", line 6, in <module>
    class TestSpecifics(unittest.TestCase):
  File "Lib/test/test_compile.py", line 399, in test_main
    test_support.run_unittest(TestSpecifics)
  File
"/home/nmm/Python-2.5b2/Lib/test/test_support.py", line
422, in run_unittest
    run_suite(suite, testclass)
  File
"/home/nmm/Python-2.5b2/Lib/test/test_support.py", line
407, in run_suite    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent
call last):
  File "Lib/test/test_compile.py", line 226, in
test_unary_minus
    self.assertTrue(isinstance(eval("%s" % (-sys.maxint
- 1)), int))

./python
Python 2.5b2 (r25b2:50512, Jul 13 2006, 11:33:15)
>>> import sys
>>> print sys.maxint
9223372036854775807
>>> print "%s" % (-sys.maxint - 1)
-9223372036854775808
>>> print isinstance(eval("%s" % (-sys.maxint - 1)), int)
False
>>> print isinstance(eval("%s" % (-sys.maxint)), int)
True


----------------------------------------------------------------------

Comment By: Nick Maclaren (nmm)
Date: 2006-07-17 09:22

Message:
Logged In: YES 
user_id=42444

Yes, it is a duplicate of 1521947.  4.1.0, for what it is
worth, but I have added comments to 1521947.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-17 01:13

Message:
Logged In: YES 
user_id=33168

What version of gcc?  Is this a duplicate of 1521947.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521726&group_id=5470

From noreply at sourceforge.net  Mon Jul 17 20:06:57 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 17 Jul 2006 11:06:57 -0700
Subject: [ python-Bugs-1517990 ] IDLE on macosx keybindings need work
Message-ID: <E1G2XUf-000538-9z@sc8-sf-web1.sourceforge.net>

Bugs item #1517990, was opened at 2006-07-06 04:26
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517990&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.5
Status: Open
Resolution: None
Priority: 7
Submitted By: Ronald Oussoren (ronaldoussoren)
>Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: IDLE on macosx keybindings need work

Initial Comment:
There is a serious issue with the keybindings for IDLE on OSX: a lot of 
them don't work correctly. One example of a not-working key-binding is 
'CMD-W', this should close the current window but doesn't.  'CMD-N' does 
create a new window though, so at least some keybindings work.


----------------------------------------------------------------------

>Comment By: Kurt B. Kaiser (kbk)
Date: 2006-07-17 14:06

Message:
Logged In: YES 
user_id=149084

Unfortunately, I don't have a Mac to work with.

The current Mac keybindings were devised by Tony
Lownds (tonylownds) during the transition to OSX.

Would you like to create a new section in 
config-keys.def named OSX and work up some new
bindings?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517990&group_id=5470

From noreply at sourceforge.net  Mon Jul 17 20:46:27 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 17 Jul 2006 11:46:27 -0700
Subject: [ python-Bugs-1517993 ] IDLE: config-main.def contains
	windows-specific settings
Message-ID: <E1G2Y6t-0001oT-C9@sc8-sf-web2.sourceforge.net>

Bugs item #1517993, was opened at 2006-07-06 04:29
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517993&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Nobody/Anonymous (nobody)
Summary: IDLE: config-main.def contains windows-specific settings

Initial Comment:
The default values in config-main.def contain values that are specific for 
Windows. This means that the key-bindings for other platforms, such as 
OSX will be wrong (because config-main selects the windows keybindings 
as the default keybindings).

I've worked around this by copying a mac version of config-main.def over 
the installed version of config-main.def from Mac/IDLE/Makefile.in. That 
is obviously a crude hack, but I know of no better solution.

----------------------------------------------------------------------

>Comment By: Kurt B. Kaiser (kbk)
Date: 2006-07-17 14:46

Message:
Logged In: YES 
user_id=149084

Not so crude, since there is a Mac/IDLE/ dir? I
gather this works ok for 2.5 installs on OSX?

Perhaps IDLE should be modified to try to detect
the platform and only use the entry in
config-main.def if detection fails.  The [keys]
section is necessary, I believe, to mirror the
[keys] section in the user's config-main.cfg if
he changes keybindings.

But you would still need Mac/IDLE/, would you not?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517993&group_id=5470

From noreply at sourceforge.net  Mon Jul 17 21:33:18 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 17 Jul 2006 12:33:18 -0700
Subject: [ python-Bugs-1524081 ] logging using the SysLog handler fails if
	locale is set
Message-ID: <E1G2YqE-0002L3-C4@sc8-sf-web5.sourceforge.net>

Bugs item #1524081, was opened at 2006-07-17 15: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=1524081&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Mihai Ibanescu (misa)
Assigned to: Nobody/Anonymous (nobody)
Summary: logging using the SysLog handler fails if locale is set

Initial Comment:
This affectes b2 and python 2.4 too.
Initially reported here:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=198971

Looking at logging/handlers.py:

Line 635:
self.encodePriority(self.facility,                    
            string.lower(record.levelname)), msg)

Line 611 in encodePriority:
priority = self.priority_names[priority]

priority_names is declared on line 527:
    priority_names = {
        "alert":    LOG_ALERT,
        "crit":     LOG_CRIT,
        ...
        "info":     LOG_INFO,
        ...

Now, if one initializes the locale (i.e. 
locale.setlocale(locale.LC_ALL, "")

and then tries to use the logging module, it will fail
with an exception looking kinda like:

  File "/usr/lib64/python2.4/logging/handlers.py", line
627, in encodePriority
    priority = self.priority_names[priority]
KeyError: 'Info'

if they choose LANG=tr_TR.UTF-8

This happens because in that particular locale,
"INFO".lower() != "info"

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1524081&group_id=5470

From noreply at sourceforge.net  Tue Jul 18 00:13:36 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 17 Jul 2006 15:13:36 -0700
Subject: [ python-Bugs-1325071 ] "as" keyword sometimes highlighted in strings
Message-ID: <E1G2bLM-0005DF-UP@sc8-sf-web2.sourceforge.net>

Bugs item #1325071, was opened at 2005-10-12 13:45
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1325071&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 3
Submitted By: Artur de Sousa Rocha (adsr)
Assigned to: Kurt B. Kaiser (kbk)
Summary: "as" keyword sometimes highlighted in strings

Initial Comment:
IDLE sometimes highlights the "as" keyword inside
strings. See the docstring to the get_redir() function
in the attached script.

IDLE 1.1.2, Python 2.4.2, but I've seen it in older
versions too.

----------------------------------------------------------------------

>Comment By: Kurt B. Kaiser (kbk)
Date: 2006-07-17 18:13

Message:
Logged In: YES 
user_id=149084

closed by patch 1479219, Tal Einat

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-10-14 03:20

Message:
Logged In: YES 
user_id=80475

It is better to have fast and simple syntax highlighting
which does not special-case literals.  IOW, I prefer the
status quo -- it would be a loss to have the highlighting
code get mired down with parser logic.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1325071&group_id=5470

From noreply at sourceforge.net  Tue Jul 18 01:08:38 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 17 Jul 2006 16:08:38 -0700
Subject: [ python-Bugs-1218081 ] email.Utils.py: "'" in RFC2231 header
Message-ID: <E1G2cCc-0004JV-JO@sc8-sf-web6.sourceforge.net>

Bugs item #1218081, was opened at 2005-06-10 06:07
Message generated for change (Comment added) made by bwarsaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1218081&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Tokio Kikuchi (tkikuchi)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email.Utils.py: "'" in RFC2231 header

Initial Comment:
A header like this one can cause ValueError in
attempting to decode the RFC2231 format:

Content-Disposition: inline;
        filename*0="Today's Headlines- C.I.A. Is
Reviewing Its Security Policy
        for R"; filename*1="ecruiting Translators.jpg"

Note that there is a ' in the filename.  MUA should
have escaped the ' by %27 but Python email library
should be robust for such a violation.

Here is the traceback:

>>> print p[4]['content-disposition']
inline;
        filename*0="Today's Headlines- C.I.A. Is
Reviewing Its Security Policy
        for R"; filename*1="ecruiting Translators.jpg"
>>> p[4].get_filename()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.4/email/Message.py",
line 707, in get_filename
    filename = self.get_param('filename', missing,
'content-disposition')
  File "/usr/local/lib/python2.4/email/Message.py",
line 590, in get_param
    for k, v in self._get_params_preserve(failobj, header):
  File "/usr/local/lib/python2.4/email/Message.py",
line 537, in _get_params_pre
serve
    params = Utils.decode_params(params)
  File "/usr/local/lib/python2.4/email/Utils.py", line
275, in decode_params
    charset, language, value =
decode_rfc2231(EMPTYSTRING.join(value))
  File "/usr/local/lib/python2.4/email/Utils.py", line
222, in decode_rfc2231
    charset, language, s = parts
ValueError: need more than 2 values to unpack
>>>


----------------------------------------------------------------------

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2006-07-17 19:08

Message:
Logged In: YES 
user_id=12800

Fixed in r50692 in the Python 2.5 trunk.  I will back port
these changes to email 3.0 and 2.5.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1218081&group_id=5470

From noreply at sourceforge.net  Tue Jul 18 01:09:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 17 Jul 2006 16:09:05 -0700
Subject: [ python-Bugs-1102973 ] Incorrect RFC 2231 decoding
Message-ID: <E1G2cD3-0005C4-9X@sc8-sf-web6.sourceforge.net>

Bugs item #1102973, was opened at 2005-01-15 11:13
Message generated for change (Settings changed) made by bwarsaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1102973&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Barry A. Warsaw (bwarsaw)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Incorrect RFC 2231 decoding

Initial Comment:
The following message

---snip snip---
Content-Transfer-Encoding: base64
Content-Type: application/msword; x-mac-type=42494E41;
x-unix-mode=0644;
    x-mac-creator=4D535744;
    name="miriam's file.doc"
Content-Disposition: attachment;
    filename*0="miriam's file"; filename*1=ths.doc
---snip snip---

Is incorrectly decoded according to RFC 2231.  The bug
is in Utils.py in the decode_params() and
decode_rfc2231() functions.  charset/lang encoding
should only be present on the first parameter, i.e.
filename*0 and even then, the quoted single quote
should not trip up the scanner.  The problem is two fold:

- first, the unquoting of filename*0 happens in
decode_param(), too early for decode_rfc2231() to know
about it.  Second, the logic in docode_rfc2231() is too
naive; it should take quoting into account to decide
whether a single quote is part of the file name or part
of the leading charset/lang encoding.

I've labeled this in the Group: Python 2.4, but it
really affects Python 2.3 as well, and the current head.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1102973&group_id=5470

From noreply at sourceforge.net  Tue Jul 18 04:21:04 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 17 Jul 2006 19:21:04 -0700
Subject: [ python-Bugs-1237697 ] link path probs on OSX re: Tcl,
	Tk & fink's /sw
Message-ID: <200607180221.k6I2L4YF020126@sc8-sf-db2-new-b.sourceforge.net>

Bugs item #1237697, was opened at 07/13/05 10:06
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1237697&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.4
>Status: Closed
Resolution: None
Priority: 5
Submitted By: OpenMacNews (blakers)
Assigned to: Nobody/Anonymous (nobody)
Summary: link path probs on OSX re: Tcl, Tk & fink's /sw

Initial Comment:
hi all,

i'm bldg Python 2.4.1 on OSX 10.4.1 ...

i've installed a late version of Tcl/Tk framework in:

   /Library/Frameworks/Tcl.framework
   /Library/Frameworks/Tk.framework

iiuc, these frameworks/libs are SUPPOSED to be searched PRIOR to /
System/Library/Frameworks ...

i've installed the Fink dev env in "/sw"

the Fink ev is 'disabled' o my box ... i.e., "/sw" is NOT in my path ...



that said, the Python build 'insists' on building against:

(1) the /System/... Tcl & Tk frameworks
(2) libs/includes in /sw/... (e.g., ndbm.h ...)

correcting the problem is INSENSITIVE to discreet inclusion of /Library/
Frameworks in LD_LIBRARY_PATH/DYLD_LIBRARY_PATH

only the build time spec'n of:

   setenv LDFLAGS "-L/Library/Frameworks -framework Tcl -framework 
Tk"

seems to do the trick ...

as for /sw, only a:

mv /sw /swTMP
( ... build ...)
mv /swTMP /sw

seems to work.

cheers,

richard


----------------------------------------------------------------------

>Comment By: SourceForge Robot (sf-robot)
Date: 07/17/06 19:21

Message:
Logged In: YES 
user_id=1312539

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 07/03/06 05:36

Message:
Logged In: YES 
user_id=21627

It's not clear to me what the problem is that is being
reported here; it looks like a messed-up setup on the build
machine to me. Lowering the priority to "normal".

blakers, if the problem persists, it would be good if you
could start all over:
1) close this report
2) create a new report, indicating
   a) what you did
   b) what happened (stop your report at the first error,
      later errors might be follow-up)
   c) what you expected to happen instead.

----------------------------------------------------------------------

Comment By: OpenMacNews (blakers)
Date: 07/13/05 11:32

Message:
Logged In: YES 
user_id=564069

1st, i "lied" earlier ... i'm building on OSX 10.4.2, not 10.4.1.

AND, apparently, i still have a problem ... the WRONG HEADERS.

even with:

	setenv CPPFLAGS "-I/Library/Frameworks/Tcl.framework/Headers -I/
Library/Frameworks/Tcl.framework/Versions/Current/PrivateHeaders -I/
Library/Frameworks/Tk.framework/Headers -I/Library/Frameworks/
Tk.framework/Versions/Current/PrivateHeaders"

set prior to configure, the build 'make' STILL complains abt:

building '_tkinter' extension
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fno-strict-aliasing -Wno-
long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -
DWITH_APPINIT=1 -I/System/Library/Frameworks/Tcl.framework/Headers -I/
System/Library/Frameworks/Tcl.framework/Versions/Current/PrivateHeaders -
I/System/Library/Frameworks/Tk.framework/Headers -I/System/Library/
Frameworks/Tk.framework/Versions/Current/PrivateHeaders -I/usr/X11R6/
include -I. -I/usr/ports/Python-2.4.1/./Include -I/usr/ports/Python-2.4.1/./Mac/
Include -I/usr/local/include -I/usr/ports/Python-2.4.1/Include -I/usr/ports/
Python-2.4.1 -c /usr/ports/Python-2.4.1/Modules/_tkinter.c -o build/
temp.darwin-8.2.0-Power_Macintosh-2.4/_tkinter.o -framework Tcl -
framework Tk
In file included from /System/Library/Frameworks/Tk.framework/Headers/tk.h:
96,
                 from /usr/ports/Python-2.4.1/Modules/_tkinter.c:67:
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:140: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:343: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:462: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:480: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:505: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:506: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:518: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:531: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:1065: 
warning: function declaration isn't a prototype
powerpc-apple-darwin8-gcc-4.0.0: -framework: linker input file unused 
because linking not done
powerpc-apple-darwin8-gcc-4.0.0: Tcl: linker input file unused because 
linking not done
powerpc-apple-darwin8-gcc-4.0.0: -framework: linker input file unused 
because linking not done
powerpc-apple-darwin8-gcc-4.0.0: Tk: linker input file unused because 
linking not done
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fno-strict-aliasing -Wno-
long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -
DWITH_APPINIT=1 -I/System/Library/Frameworks/Tcl.framework/Headers -I/
System/Library/Frameworks/Tcl.framework/Versions/Current/PrivateHeaders -
I/System/Library/Frameworks/Tk.framework/Headers -I/System/Library/
Frameworks/Tk.framework/Versions/Current/PrivateHeaders -I/usr/X11R6/
include -I. -I/usr/ports/Python-2.4.1/./Include -I/usr/ports/Python-2.4.1/./Mac/
Include -I/usr/local/include -I/usr/ports/Python-2.4.1/Include -I/usr/ports/
Python-2.4.1 -c /usr/ports/Python-2.4.1/Modules/tkappinit.c -o build/
temp.darwin-8.2.0-Power_Macintosh-2.4/tkappinit.o -framework Tcl -
framework Tk
In file included from /System/Library/Frameworks/Tk.framework/Headers/tk.h:
96,
                 from /usr/ports/Python-2.4.1/Modules/tkappinit.c:17:
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:140: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:343: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:462: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:480: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:505: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:506: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:518: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:531: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:1065: 
warning: function declaration isn't a prototype
powerpc-apple-darwin8-gcc-4.0.0: -framework: linker input file unused 
because linking not done
powerpc-apple-darwin8-gcc-4.0.0: Tcl: linker input file unused because 
linking not done
powerpc-apple-darwin8-gcc-4.0.0: -framework: linker input file unused 
because linking not done
powerpc-apple-darwin8-gcc-4.0.0: Tk: linker input file unused because 
linking not done
gcc -L/Library/Frameworks -framework Tcl -framework Tk -bundle -undefined 
dynamic_lookup -L/Library/Frameworks -framework Tcl -framework Tk -I. -I./
Include build/temp.darwin-8.2.0-Power_Macintosh-2.4/_tkinter.o build/
temp.darwin-8.2.0-Power_Macintosh-2.4/tkappinit.o -L/usr/local/lib -o build/
lib.darwin-8.2.0-Power_Macintosh-2.4/_tkinter.so -framework Tcl -framework 
Tk
running build_scripts
creating build/scripts-2.4
copying and adjusting /usr/ports/Python-2.4.1/Tools/scripts/pydoc -> build/
scripts-2.4
copying and adjusting /usr/ports/Python-2.4.1/Tools/scripts/idle -> build/
scripts-2.4
copying and adjusting /usr/ports/Python-2.4.1/Lib/smtpd.py -> build/scripts-2.4
changing mode of build/scripts-2.4/pydoc from 644 to 755
changing mode of build/scripts-2.4/idle from 644 to 755
changing mode of build/scripts-2.4/smtpd.py from 644 to 755

cheers,

richard



----------------------------------------------------------------------

Comment By: OpenMacNews (blakers)
Date: 07/13/05 10:56

Message:
Logged In: YES 
user_id=564069

1st, i "lied" earlier ... i'm building on OSX 10.4.2, not 10.4.1.

AND, apparently, i still have a problem ... the WRONG HEADERS.

even with:

	setenv CPPFLAGS "-I/Library/Frameworks/Tcl.framework/Headers -I/
Library/Frameworks/Tcl.framework/Versions/Current/PrivateHeaders -I/
Library/Frameworks/Tk.framework/Headers -I/Library/Frameworks/
Tk.framework/Versions/Current/PrivateHeaders"

set prior to configure, the build 'make' STILL complains abt:

building '_tkinter' extension
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fno-strict-aliasing -Wno-
long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -
DWITH_APPINIT=1 -I/System/Library/Frameworks/Tcl.framework/Headers -I/
System/Library/Frameworks/Tcl.framework/Versions/Current/PrivateHeaders -
I/System/Library/Frameworks/Tk.framework/Headers -I/System/Library/
Frameworks/Tk.framework/Versions/Current/PrivateHeaders -I/usr/X11R6/
include -I. -I/usr/ports/Python-2.4.1/./Include -I/usr/ports/Python-2.4.1/./Mac/
Include -I/usr/local/include -I/usr/ports/Python-2.4.1/Include -I/usr/ports/
Python-2.4.1 -c /usr/ports/Python-2.4.1/Modules/_tkinter.c -o build/
temp.darwin-8.2.0-Power_Macintosh-2.4/_tkinter.o -framework Tcl -
framework Tk
In file included from /System/Library/Frameworks/Tk.framework/Headers/tk.h:
96,
                 from /usr/ports/Python-2.4.1/Modules/_tkinter.c:67:
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:140: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:343: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:462: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:480: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:505: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:506: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:518: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:531: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:1065: 
warning: function declaration isn't a prototype
powerpc-apple-darwin8-gcc-4.0.0: -framework: linker input file unused 
because linking not done
powerpc-apple-darwin8-gcc-4.0.0: Tcl: linker input file unused because 
linking not done
powerpc-apple-darwin8-gcc-4.0.0: -framework: linker input file unused 
because linking not done
powerpc-apple-darwin8-gcc-4.0.0: Tk: linker input file unused because 
linking not done
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fno-strict-aliasing -Wno-
long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -
DWITH_APPINIT=1 -I/System/Library/Frameworks/Tcl.framework/Headers -I/
System/Library/Frameworks/Tcl.framework/Versions/Current/PrivateHeaders -
I/System/Library/Frameworks/Tk.framework/Headers -I/System/Library/
Frameworks/Tk.framework/Versions/Current/PrivateHeaders -I/usr/X11R6/
include -I. -I/usr/ports/Python-2.4.1/./Include -I/usr/ports/Python-2.4.1/./Mac/
Include -I/usr/local/include -I/usr/ports/Python-2.4.1/Include -I/usr/ports/
Python-2.4.1 -c /usr/ports/Python-2.4.1/Modules/tkappinit.c -o build/
temp.darwin-8.2.0-Power_Macintosh-2.4/tkappinit.o -framework Tcl -
framework Tk
In file included from /System/Library/Frameworks/Tk.framework/Headers/tk.h:
96,
                 from /usr/ports/Python-2.4.1/Modules/tkappinit.c:17:
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:140: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:343: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:462: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:480: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:505: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:506: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:518: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:531: warning: 
function declaration isn't a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:1065: 
warning: function declaration isn't a prototype
powerpc-apple-darwin8-gcc-4.0.0: -framework: linker input file unused 
because linking not done
powerpc-apple-darwin8-gcc-4.0.0: Tcl: linker input file unused because 
linking not done
powerpc-apple-darwin8-gcc-4.0.0: -framework: linker input file unused 
because linking not done
powerpc-apple-darwin8-gcc-4.0.0: Tk: linker input file unused because 
linking not done
gcc -L/Library/Frameworks -framework Tcl -framework Tk -bundle -undefined 
dynamic_lookup -L/Library/Frameworks -framework Tcl -framework Tk -I. -I./
Include build/temp.darwin-8.2.0-Power_Macintosh-2.4/_tkinter.o build/
temp.darwin-8.2.0-Power_Macintosh-2.4/tkappinit.o -L/usr/local/lib -o build/
lib.darwin-8.2.0-Power_Macintosh-2.4/_tkinter.so -framework Tcl -framework 
Tk
running build_scripts
creating build/scripts-2.4
copying and adjusting /usr/ports/Python-2.4.1/Tools/scripts/pydoc -> build/
scripts-2.4
copying and adjusting /usr/ports/Python-2.4.1/Tools/scripts/idle -> build/
scripts-2.4
copying and adjusting /usr/ports/Python-2.4.1/Lib/smtpd.py -> build/scripts-2.4
changing mode of build/scripts-2.4/pydoc from 644 to 755
changing mode of build/scripts-2.4/idle from 644 to 755
changing mode of build/scripts-2.4/smtpd.py from 644 to 755

cheers,

richard



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1237697&group_id=5470

From noreply at sourceforge.net  Tue Jul 18 04:21:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 17 Jul 2006 19:21:05 -0700
Subject: [ python-Bugs-1295179 ] termios.c in qnx4.25
Message-ID: <200607180221.k6I2L5Iv020136@sc8-sf-db2-new-b.sourceforge.net>

Bugs item #1295179, was opened at 09/19/05 02:28
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295179&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Platform-specific
>Status: Closed
Resolution: None
Priority: 5
Submitted By: kbob_ru (kbob_ru)
Assigned to: Nobody/Anonymous (nobody)
Summary: termios.c in qnx4.25

Initial Comment:
I compile python version 2.3.5 in QNX4.25.
But I found that #include <termios.h> don't work 
because in qnx4 we need to include <sys/termio.c> first 
in which #include <termios.h> already present.
Second, Module/termios.c needs flag IXANY, that not 
defined in qnx4 headers.

Include right header and write #ifdef IXANY \ #endif 
around helps to compile Module/termios.c.

----------------------------------------------------------------------

>Comment By: SourceForge Robot (sf-robot)
Date: 07/17/06 19:21

Message:
Logged In: YES 
user_id=1312539

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 07/03/06 06:40

Message:
Logged In: YES 
user_id=849994

Can you test this with Python 2.5b1?

----------------------------------------------------------------------

Comment By: kbob_ru (kbob_ru)
Date: 06/02/06 22:03

Message:
Logged In: YES 
user_id=1347065

I used next patch for Python versions 2.3.5 and 2.4.3.
It helps work properly termios module in QNX4.25 and
termios test pass.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295179&group_id=5470

From noreply at sourceforge.net  Tue Jul 18 04:52:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 17 Jul 2006 19:52:42 -0700
Subject: [ python-Bugs-1519069 ] incorrect locale.strcoll() return in Windows
Message-ID: <E1G2fhS-00048Z-NO@sc8-sf-web1.sourceforge.net>

Bugs item #1519069, was opened at 2006-07-07 22:04
Message generated for change (Comment added) made by pez4brian
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519069&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Brian Matherly (pez4brian)
Assigned to: Nobody/Anonymous (nobody)
Summary: incorrect locale.strcoll() return in Windows

Initial Comment:
Python 2.4.2 in Windows (English locale):

>>> import locale
>>> locale.setlocale(locale.LC_ALL,'C')
'C'
>>> locale.setlocale(locale.LC_ALL,'')
'English_United States.1252'
>>> locale.strcoll("M","m")
1
>>> locale.strcoll("Ma","mz")
-1

It appears that when a string has one character, "M" is
greater than "m", but when it has more than one string,
"M" is equal to "m"

----------------------------------------------------------------------

>Comment By: Brian Matherly (pez4brian)
Date: 2006-07-17 21:52

Message:
Logged In: YES 
user_id=726294

I think you are right - it's probably a Windows issue - if
it is an issue at all. I don't claim to be a lingual expert.
But I would prefer a case sensitive comparison. So I wrote a
function. It looks like this:

def strcoll_case_sensitive(string1,string2):
    """ This function was written because string comparisons
in Windows 
        seem to be case insensitive if the string is longer
than 
        one character. """
    # First, compare the first character
    diff = locale.strcoll(string1[0],string2[0])
    if diff == 0:
        # If the first character is the same, compare the rest
        diff = locale.strcoll(string1,string2)
    return diff

Thanks for your help. Feel free to close this bug.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-07-15 02:37

Message:
Logged In: YES 
user_id=21627

You should ask these questions in some Win32 programmer
newsgroup. I don't know whether this sorting is correct or
not, I'm not a native English speaker.

----------------------------------------------------------------------

Comment By: Brian Matherly (pez4brian)
Date: 2006-07-14 22:14

Message:
Logged In: YES 
user_id=726294

Thanks for your response. That is simply unacceptable. Who
at Microsoft needs to be flogged? More likely, this shows my
lack of understanding of strings and locale in general.

Your explanation does explain the results I get, but
wouldn't you admit that the results *seem* wrong?

By the definition given, the strings "Ma", "mb", "Mc", "md"
would actually sort in that order! So the list of sorted
strings would have alternating capitalization!

However, the list of strings "M", "m", "M", "m" would sort
as "M", "M", "m", "m" - no alternating capitalization - as I
would expect.

Would there happen to be some way to sort the strings using
the locale, but also using the case earlier in the
computation order? Basically, I want the sort to be case
sensitive.

Thanks again for your response. If you have any suggestions
that might help me achieve what I want, it would be greatly
appreciated.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-07-14 10:55

Message:
Logged In: YES 
user_id=21627

Why do you think this is a bug? We pass the string as-is to
the C library, which passes it nearly as-is to
CompareStringW. This function then decides how they collate;
in Microsoft's definition of the English_United States
locale, these strings do have the order you get.

In case you wonder how the order is computed: essentially,
the strings are compared case insensitive, without
diacritics. If they then compare equal, the diacritics are
considered. If this still compares equal, Case weights are
considered. If this still compares equal, Special weights
are considered.

(Note: I obtained this indirectly by looking at the
LCMapString documentation, assuming that CompareString uses
LCMapString with LCMAP_SORTKEY|SORT_STRINGSORT).

----------------------------------------------------------------------

Comment By: Brian Matherly (pez4brian)
Date: 2006-07-07 22:35

Message:
Logged In: YES 
user_id=726294

I see the same problem in python 2.4.3

----------------------------------------------------------------------

Comment By: Brian Matherly (pez4brian)
Date: 2006-07-07 22:08

Message:
Logged In: YES 
user_id=726294

Correction:

It appears that when a string has one character, "M" is
greater than "m", but when it has more than one character,
"M" is equal to "m"

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519069&group_id=5470

From noreply at sourceforge.net  Tue Jul 18 06:05:30 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 17 Jul 2006 21:05:30 -0700
Subject: [ python-Bugs-1179168 ] IDLE bug - changing shortcuts - Shift-Tab
	broken!
Message-ID: <E1G2gpu-00068Y-Je@sc8-sf-web5.sourceforge.net>

Bugs item #1179168, was opened at 2005-04-08 07:54
Message generated for change (Settings changed) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1179168&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 6
Submitted By: Przemys&#322;aw Gocy&#322;a (bld_d16)
Assigned to: Kurt B. Kaiser (kbk)
Summary: IDLE bug - changing shortcuts - Shift-Tab broken!

Initial Comment:
On Python 2.4.1 on WinXP I have changed keyboard 
shortcut settings for indent/unindent.
New shorcut was Tab/Shift+Tab.

When I did it IDLE hanged up and I could not to launch it 
again.

I have tried everything. Uninstall whole Python and then 
reinstall (tried both version 2.3 and 2.4).
It just looks like from the change of shortcuts IDLE don't 
works.

I tried to:
  import idlelib.PyShell
  idlelib.PyShell.main()
and result with bug are in attachment

Where is the information about IDLE shortcuts keeped ?
Why IDLE remember this even after reinstall ?
How to fix it up?

Best regards,
Przemek

----------------------------------------------------------------------

>Comment By: Kurt B. Kaiser (kbk)
Date: 2006-07-18 00:05

Message:
Logged In: YES 
user_id=149084

rev 50695

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2005-04-14 16:58

Message:
Logged In: YES 
user_id=149084

Your user keyset config file on Windows is at
Documents and Settings\<YourUserName>\.idlerc\config-keys.cfg
This file doesn't get removed when Python is uninstalled.

Open this file with a text editor and find the <Key-tab> entry.
Change it to <Key-Tab>

This is a bug in IDLE.  (normally people don't try to re-assign
the tab key, so it got missed)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1179168&group_id=5470

From noreply at sourceforge.net  Tue Jul 18 06:11:10 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 17 Jul 2006 21:11:10 -0700
Subject: [ python-Bugs-1296433 ] expat crash python
Message-ID: <E1G2gvO-0001Uj-TV@sc8-sf-web3.sourceforge.net>

Bugs item #1296433, was opened at 2005-09-20 07:10
Message generated for change (Settings changed) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1296433&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: XML
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 6
Submitted By: Mike Rozhnov (rozhnov)
Assigned to: Brett Cannon (bcannon)
Summary: expat crash python

Initial Comment:
This simple script crash python.
Parsing of commented xml string work good.
(i.e. raised exception not crash python)
Buffer overflow during convertion to unicode?

Tested on Win XP and linux with kernel 2.4 with same
results.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-01 09:33

Message:
Logged In: YES 
user_id=3066

This is now fixed in the Expat CVS with lib/xmlparse.c
revisions 1.154 and 1.155.  I've merged these into the Expat
bundled with Python in revision 47191 (on the trunk), and
moved the crasher test into the tests for xml.parsers.expat.

I don't know when the next Expat release will go out yet,
but this will keep us from being dependent on that schedule.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2006-06-30 11:06

Message:
Logged In: YES 
user_id=357491

The fault is with Expat and not us.  I have submitted a bug
report with a possible patch at
http://sourceforge.net/tracker/index.php?func=detail&aid=1515266&group_id=10127&atid=110127
 .  I don't know what their turn-around time will be with
this so I will email python-dev to see how long people want
to wait on the Expat developers before we just push our own
patch for this.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2006-06-29 18:33

Message:
Logged In: YES 
user_id=357491

Still seems to be failing even with the Expat 2.0 upgrade in
HEAD.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-11-12 12:53

Message:
Logged In: YES 
user_id=33168

I had recently upgraded to expat 1.95.8, so I was hopeful. 
But it still crashed for me on linux.  

I did get a better stack trace which allowed me to come up
with a patch that solves the problem and passes all the
tests.  The patch seems a bit odd and I think there might be
another problem going on here.  It would be great if someone
more familiar with xmlparse could take a look at the patch
and figure out if it's right or not.

----------------------------------------------------------------------

Comment By: Fredrik Lundh (effbot)
Date: 2005-11-12 03:05

Message:
Logged In: YES 
user_id=38376

Works for me under 2.3.2 (with expat 1.95.6) and 2.4.1 (with
expat 1.95.8).

Try upgrading your expat and see if the problem goes away.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-22 14:54

Message:
Logged In: YES 
user_id=33168

I can reproduce on Linux with current CVS and expat
1.95.5-2.  Note the size of the data only needs to be
greater than 1024.

xml = "<?xml version='1.0' encoding='iso8859'?><s>%s</s>" %
('a' * 1025)

I am not certain this problem is specific to Python.  It
might be down in expat only.  Need to investigate further.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1296433&group_id=5470

From noreply at sourceforge.net  Tue Jul 18 06:42:04 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 17 Jul 2006 21:42:04 -0700
Subject: [ python-Bugs-1520914 ] time.strftime breakage in 2.4/2.5
Message-ID: <E1G2hPI-0007Qe-ST@sc8-sf-web5.sourceforge.net>

Bugs item #1520914, was opened at 2006-07-11 18:52
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1520914&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Brett Cannon (bcannon)
Summary: time.strftime breakage in 2.4/2.5

Initial Comment:
Up to Python 2.3 this worked just fine:

    >>> import time
    >>> time.strftime("%Y-%m-%d", (2005, 6, 4) + (0,)*6)
    '2005-06-04'

Starting with 2.4 it broke:

    >>> import time
    >>> time.strftime("%Y-%m-%d", (2005, 6, 4) + (0,)*6)
    Traceback (most recent call last):
      File "<stdin>", line 1, in ?
    ValueError: day of year out of range

though if you change the unused fields to 1 it works:

    >>> time.strftime("%Y-%m-%d", (2005, 6, 4) + (1,)*6)
    '2005-06-04'

While this wasn't documented behavior, it was certainly behaviour that 
worked for a long time.  It should probably be allowed to continue 
working.

Skip


----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2006-07-17 21:42

Message:
Logged In: YES 
user_id=357491

Fixed in rev. 50696 .

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1520914&group_id=5470

From noreply at sourceforge.net  Tue Jul 18 07:26:56 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 17 Jul 2006 22:26:56 -0700
Subject: [ python-Bugs-1519069 ] incorrect locale.strcoll() return in Windows
Message-ID: <E1G2i6i-0004Ct-OH@sc8-sf-web5.sourceforge.net>

Bugs item #1519069, was opened at 2006-07-08 05:04
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519069&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
>Group: 3rd Party
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Brian Matherly (pez4brian)
Assigned to: Nobody/Anonymous (nobody)
Summary: incorrect locale.strcoll() return in Windows

Initial Comment:
Python 2.4.2 in Windows (English locale):

>>> import locale
>>> locale.setlocale(locale.LC_ALL,'C')
'C'
>>> locale.setlocale(locale.LC_ALL,'')
'English_United States.1252'
>>> locale.strcoll("M","m")
1
>>> locale.strcoll("Ma","mz")
-1

It appears that when a string has one character, "M" is
greater than "m", but when it has more than one string,
"M" is equal to "m"

----------------------------------------------------------------------

Comment By: Brian Matherly (pez4brian)
Date: 2006-07-18 04:52

Message:
Logged In: YES 
user_id=726294

I think you are right - it's probably a Windows issue - if
it is an issue at all. I don't claim to be a lingual expert.
But I would prefer a case sensitive comparison. So I wrote a
function. It looks like this:

def strcoll_case_sensitive(string1,string2):
    """ This function was written because string comparisons
in Windows 
        seem to be case insensitive if the string is longer
than 
        one character. """
    # First, compare the first character
    diff = locale.strcoll(string1[0],string2[0])
    if diff == 0:
        # If the first character is the same, compare the rest
        diff = locale.strcoll(string1,string2)
    return diff

Thanks for your help. Feel free to close this bug.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-07-15 09:37

Message:
Logged In: YES 
user_id=21627

You should ask these questions in some Win32 programmer
newsgroup. I don't know whether this sorting is correct or
not, I'm not a native English speaker.

----------------------------------------------------------------------

Comment By: Brian Matherly (pez4brian)
Date: 2006-07-15 05:14

Message:
Logged In: YES 
user_id=726294

Thanks for your response. That is simply unacceptable. Who
at Microsoft needs to be flogged? More likely, this shows my
lack of understanding of strings and locale in general.

Your explanation does explain the results I get, but
wouldn't you admit that the results *seem* wrong?

By the definition given, the strings "Ma", "mb", "Mc", "md"
would actually sort in that order! So the list of sorted
strings would have alternating capitalization!

However, the list of strings "M", "m", "M", "m" would sort
as "M", "M", "m", "m" - no alternating capitalization - as I
would expect.

Would there happen to be some way to sort the strings using
the locale, but also using the case earlier in the
computation order? Basically, I want the sort to be case
sensitive.

Thanks again for your response. If you have any suggestions
that might help me achieve what I want, it would be greatly
appreciated.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-07-14 17:55

Message:
Logged In: YES 
user_id=21627

Why do you think this is a bug? We pass the string as-is to
the C library, which passes it nearly as-is to
CompareStringW. This function then decides how they collate;
in Microsoft's definition of the English_United States
locale, these strings do have the order you get.

In case you wonder how the order is computed: essentially,
the strings are compared case insensitive, without
diacritics. If they then compare equal, the diacritics are
considered. If this still compares equal, Case weights are
considered. If this still compares equal, Special weights
are considered.

(Note: I obtained this indirectly by looking at the
LCMapString documentation, assuming that CompareString uses
LCMapString with LCMAP_SORTKEY|SORT_STRINGSORT).

----------------------------------------------------------------------

Comment By: Brian Matherly (pez4brian)
Date: 2006-07-08 05:35

Message:
Logged In: YES 
user_id=726294

I see the same problem in python 2.4.3

----------------------------------------------------------------------

Comment By: Brian Matherly (pez4brian)
Date: 2006-07-08 05:08

Message:
Logged In: YES 
user_id=726294

Correction:

It appears that when a string has one character, "M" is
greater than "m", but when it has more than one character,
"M" is equal to "m"

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519069&group_id=5470

From noreply at sourceforge.net  Tue Jul 18 09:35:41 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 18 Jul 2006 00:35:41 -0700
Subject: [ python-Bugs-1524310 ] os.listdir doesn't check error code from
	FindNextFile
Message-ID: <E1G2k7J-0004Gr-Bd@sc8-sf-web2.sourceforge.net>

Bugs item #1524310, was opened at 2006-07-18 02:35
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=1524310&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Roger Upole (rupole)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.listdir doesn't check error code from FindNextFile

Initial Comment:
The Windows implementation of listdir returns 
successfully as soon as FindNextFile returns False, 
without checking that GetLastError returns 
ERROR_NO_MORE_FILES.  If the operation is interrupted 
(eg removable media ejected, network connection to UNC 
path lost, and so on) an incomplete directory listing 
is returned instead of throwing an exception.
This behaviour exists in 2.4.3 and 2.5b2.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1524310&group_id=5470

From noreply at sourceforge.net  Tue Jul 18 09:44:59 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 18 Jul 2006 00:44:59 -0700
Subject: [ python-Bugs-1524317 ] configure --without-threads fails to build
Message-ID: <E1G2kGJ-0004XC-3X@sc8-sf-web6.sourceforge.net>

Bugs item #1524317, was opened at 2006-07-18 00: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=1524317&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Ram Bhamidipaty (rambham)
Assigned to: Nobody/Anonymous (nobody)
Summary: configure --without-threads fails to build

Initial Comment:
In Python-2.5b2 I tried to do this:

./configure --without-threads
gmake

The build will fail with an undefined
reference to _PyThread_CurrentFrames

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1524317&group_id=5470

From noreply at sourceforge.net  Tue Jul 18 13:29:56 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 18 Jul 2006 04:29:56 -0700
Subject: [ python-Bugs-1524317 ] configure --without-threads fails to build
Message-ID: <E1G2nm0-00034l-MD@sc8-sf-web5.sourceforge.net>

Bugs item #1524317, was opened at 2006-07-18 07:44
Message generated for change (Comment added) made by splitscreen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1524317&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Ram Bhamidipaty (rambham)
Assigned to: Nobody/Anonymous (nobody)
Summary: configure --without-threads fails to build

Initial Comment:
In Python-2.5b2 I tried to do this:

./configure --without-threads
gmake

The build will fail with an undefined
reference to _PyThread_CurrentFrames

----------------------------------------------------------------------

Comment By: Matt Fleming (splitscreen)
Date: 2006-07-18 11:29

Message:
Logged In: YES 
user_id=1126061

I can confirm this error on Linux, below is the output,

gcc  -Xlinker -export-dynamic -o python \
                Modules/python.o \
                libpython2.5.a -ldl  -lutil   -lm  
libpython2.5.a(posixmodule.o): In function `posix_tmpnam':
./Modules/posixmodule.c:6701: warning: the use of `tmpnam'
is dangerous, better 
use `mkstemp'
libpython2.5.a(posixmodule.o): In function `posix_tempnam':
./Modules/posixmodule.c:6654: warning: the use of `tempnam'
is dangerous, better
 use `mkstemp'
libpython2.5.a(sysmodule.o): In function `sys_current_frames':
Python/sysmodule.c:675: undefined reference to
`_PyThread_CurrentFrames'
collect2: ld returned 1 exit status
make: *** [python] Error 1


Thanks, Matt

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1524317&group_id=5470

From noreply at sourceforge.net  Tue Jul 18 14:09:34 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 18 Jul 2006 05:09:34 -0700
Subject: [ python-Bugs-1517990 ] IDLE on macosx keybindings need work
Message-ID: <E1G2oOM-0001FS-9Y@sc8-sf-web6.sourceforge.net>

Bugs item #1517990, was opened at 2006-07-06 10:26
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517990&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.5
Status: Open
Resolution: None
Priority: 7
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: IDLE on macosx keybindings need work

Initial Comment:
There is a serious issue with the keybindings for IDLE on OSX: a lot of 
them don't work correctly. One example of a not-working key-binding is 
'CMD-W', this should close the current window but doesn't.  'CMD-N' does 
create a new window though, so at least some keybindings work.


----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-18 14:09

Message:
Logged In: YES 
user_id=580910

The keybinding definition itself seems to be correct (although I haven't reviewed 
it completely yet). The problem at this point is that IDLE doesn't respond to 
some (or even most) of them. I suspect that AquaTk is at fault here, it is really 
lousy at times.

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2006-07-17 20:06

Message:
Logged In: YES 
user_id=149084

Unfortunately, I don't have a Mac to work with.

The current Mac keybindings were devised by Tony
Lownds (tonylownds) during the transition to OSX.

Would you like to create a new section in 
config-keys.def named OSX and work up some new
bindings?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517990&group_id=5470

From noreply at sourceforge.net  Tue Jul 18 14:20:44 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 18 Jul 2006 05:20:44 -0700
Subject: [ python-Bugs-1517996 ] IDLE (macosx): Class and Path browsers show
	Tk menu
Message-ID: <E1G2oZA-0000Je-27@sc8-sf-web6.sourceforge.net>

Bugs item #1517996, was opened at 2006-07-06 10:34
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517996&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Nobody/Anonymous (nobody)
Summary: IDLE (macosx): Class and Path browsers show Tk menu

Initial Comment:
I've done some work on fixing the menus for IDLE before 2.5b1, but 
recently found more toplevel windows that don't have their own menu.

Both the Path Browser and Class Browser don't have a menubar of their 
own. The Tk implementation on MacOSX won't accept an empty menubar, 
but will replace that by a generic Tk menubar.

----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-18 14:20

Message:
Logged In: YES 
user_id=580910

These menu problems are at the very root caused by differences in the way 
menus work on OSX (one application wide menu at the top of the screen) and 
most other systems (optional menus for every window).  Applications on OSX 
must have some kind of menu (or be full-screen, but we don't want that for 
IDLE), Tk uses the per-window menu for the currently selected window for 
that. If a window doesn't have a menu it makes up one and I haven't found a 
way yet to override that menu (which would solve that problem once and for 
all).

I do believe that my other changes really are good, they make IDLE perform 
more like a true OSX application. This is important because IDLE is the default 
IDE, and hence probably the first thing naive OSX users will see of python.

BTW. AquaTk really sucks, which makes it annoyingly hard to create a really 
good OSX citizen of IDLE and I have given up on getting there. If I understand 
the lazyweb correctly you're supposed to port your appliations to some other 
GUI library (Tile?) to get a native L&F for lots of widgets and standard dialogs.

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2006-07-15 21:51

Message:
Logged In: YES 
user_id=149084

I suppose this is also true for the debugger?

I'd consider this a bug in OSX Tk, it should be
reported there.

Without a specific need for a menubar, all it does
is take up valuable vertical space.  And continuing
to add OSX special casing clutters up the IDLE code;
IMO it should be limited to situations where
functionality is compromised.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517996&group_id=5470

From noreply at sourceforge.net  Tue Jul 18 14:34:09 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 18 Jul 2006 05:34:09 -0700
Subject: [ python-Bugs-1517993 ] IDLE: config-main.def contains
	windows-specific settings
Message-ID: <E1G2om9-0007DN-UK@sc8-sf-web2.sourceforge.net>

Bugs item #1517993, was opened at 2006-07-06 10:29
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517993&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.5
Status: Open
Resolution: None
>Priority: 2
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Nobody/Anonymous (nobody)
Summary: IDLE: config-main.def contains windows-specific settings

Initial Comment:
The default values in config-main.def contain values that are specific for 
Windows. This means that the key-bindings for other platforms, such as 
OSX will be wrong (because config-main selects the windows keybindings 
as the default keybindings).

I've worked around this by copying a mac version of config-main.def over 
the installed version of config-main.def from Mac/IDLE/Makefile.in. That 
is obviously a crude hack, but I know of no better solution.

----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-18 14:34

Message:
Logged In: YES 
user_id=580910

Mac/IDLE contains support code for building and installing an application 
bundle for IDLE, which gives us a nice icon to click on :-)

Detecting the platform and automaticly using platform-specific settings 
would be nice and would mostly solve my problem. "Mostly" because config-
extensions.def also contains key-binding definitions; which could well be 
platform-specific (AquaTk doesn't seem to support the ALT modifier).

IMHO the current workaround is crude because I maintain a seperate copy of 
several configuration files just to change a small number of settings.  I have 
lowered the priority of this issue because I don't think this is very important.

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2006-07-17 20:46

Message:
Logged In: YES 
user_id=149084

Not so crude, since there is a Mac/IDLE/ dir? I
gather this works ok for 2.5 installs on OSX?

Perhaps IDLE should be modified to try to detect
the platform and only use the entry in
config-main.def if detection fails.  The [keys]
section is necessary, I believe, to mirror the
[keys] section in the user's config-main.cfg if
he changes keybindings.

But you would still need Mac/IDLE/, would you not?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517993&group_id=5470

From noreply at sourceforge.net  Tue Jul 18 19:54:53 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 18 Jul 2006 10:54:53 -0700
Subject: [ python-Bugs-1524317 ] configure --without-threads fails to build
Message-ID: <E1G2tmX-0000s6-Mc@sc8-sf-web2.sourceforge.net>

Bugs item #1524317, was opened at 2006-07-18 07:44
Message generated for change (Comment added) made by splitscreen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1524317&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Ram Bhamidipaty (rambham)
Assigned to: Nobody/Anonymous (nobody)
Summary: configure --without-threads fails to build

Initial Comment:
In Python-2.5b2 I tried to do this:

./configure --without-threads
gmake

The build will fail with an undefined
reference to _PyThread_CurrentFrames

----------------------------------------------------------------------

Comment By: Matt Fleming (splitscreen)
Date: 2006-07-18 17:54

Message:
Logged In: YES 
user_id=1126061

Fix in patch #1524724. If someone gives it the thumbs up, I
can commit it.

Matt

----------------------------------------------------------------------

Comment By: Matt Fleming (splitscreen)
Date: 2006-07-18 11:29

Message:
Logged In: YES 
user_id=1126061

I can confirm this error on Linux, below is the output,

gcc  -Xlinker -export-dynamic -o python \
                Modules/python.o \
                libpython2.5.a -ldl  -lutil   -lm  
libpython2.5.a(posixmodule.o): In function `posix_tmpnam':
./Modules/posixmodule.c:6701: warning: the use of `tmpnam'
is dangerous, better 
use `mkstemp'
libpython2.5.a(posixmodule.o): In function `posix_tempnam':
./Modules/posixmodule.c:6654: warning: the use of `tempnam'
is dangerous, better
 use `mkstemp'
libpython2.5.a(sysmodule.o): In function `sys_current_frames':
Python/sysmodule.c:675: undefined reference to
`_PyThread_CurrentFrames'
collect2: ld returned 1 exit status
make: *** [python] Error 1


Thanks, Matt

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1524317&group_id=5470

From noreply at sourceforge.net  Wed Jul 19 02:05:55 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 18 Jul 2006 17:05:55 -0700
Subject: [ python-Bugs-1524317 ] configure --without-threads fails to build
Message-ID: <E1G2zZb-0003HA-8E@sc8-sf-web5.sourceforge.net>

Bugs item #1524317, was opened at 2006-07-18 03:44
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1524317&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Ram Bhamidipaty (rambham)
Assigned to: Nobody/Anonymous (nobody)
Summary: configure --without-threads fails to build

Initial Comment:
In Python-2.5b2 I tried to do this:

./configure --without-threads
gmake

The build will fail with an undefined
reference to _PyThread_CurrentFrames

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-07-18 20:05

Message:
Logged In: YES 
user_id=31435

Fixed in rev 50708.  That made _PyThread_CurrentFrames()
available in all builds, and fiddled test_sys so that the
test for sys._current_frames() passes with or without
threads.  test_sys still fails in a build without threads,
but for an unrelated reason.

----------------------------------------------------------------------

Comment By: Matt Fleming (splitscreen)
Date: 2006-07-18 13:54

Message:
Logged In: YES 
user_id=1126061

Fix in patch #1524724. If someone gives it the thumbs up, I
can commit it.

Matt

----------------------------------------------------------------------

Comment By: Matt Fleming (splitscreen)
Date: 2006-07-18 07:29

Message:
Logged In: YES 
user_id=1126061

I can confirm this error on Linux, below is the output,

gcc  -Xlinker -export-dynamic -o python \
                Modules/python.o \
                libpython2.5.a -ldl  -lutil   -lm  
libpython2.5.a(posixmodule.o): In function `posix_tmpnam':
./Modules/posixmodule.c:6701: warning: the use of `tmpnam'
is dangerous, better 
use `mkstemp'
libpython2.5.a(posixmodule.o): In function `posix_tempnam':
./Modules/posixmodule.c:6654: warning: the use of `tempnam'
is dangerous, better
 use `mkstemp'
libpython2.5.a(sysmodule.o): In function `sys_current_frames':
Python/sysmodule.c:675: undefined reference to
`_PyThread_CurrentFrames'
collect2: ld returned 1 exit status
make: *** [python] Error 1


Thanks, Matt

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1524317&group_id=5470

From noreply at sourceforge.net  Wed Jul 19 04:46:35 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 18 Jul 2006 19:46:35 -0700
Subject: [ python-Bugs-1524938 ] MemoryError with a lot of available memory -
	gc not called
Message-ID: <E1G3254-0008K9-WB@sc8-sf-web3.sourceforge.net>

Bugs item #1524938, was opened at 2006-07-19 05:46
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=1524938&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Matusevich (markmat)
Assigned to: Nobody/Anonymous (nobody)
Summary: MemoryError with a lot of available memory - gc not called

Initial Comment:
Also the gc behavior is consistent with the
documentation, I beleave it is wrong. I think, that Gc
should be called automatically before any memory
allocation is raised.

Example 1:
for i in range(700): 
   a = [range(5000000)]
   a.append(a)
   print i

This example will crash on any any PC with less then
20Gb RAM. On my PC (Windows 2000, 256Mb) it crashes at
i==7.
Also, this example can be fixed by addition of a call
to gc.collect() in the loop, in real cases it may be
unreasonable. 


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1524938&group_id=5470

From noreply at sourceforge.net  Wed Jul 19 13:12:14 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 19 Jul 2006 04:12:14 -0700
Subject: [ python-Bugs-1519816 ] urllib2 proxy does not work in 2.4.3
Message-ID: <E1G39yQ-0001Nu-TA@sc8-sf-web2.sourceforge.net>

Bugs item #1519816, was opened at 2006-07-10 10:29
Message generated for change (Comment added) made by mniklas
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519816&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Michal Niklas (mniklas)
Assigned to: Nobody/Anonymous (nobody)
>Summary: urllib2 proxy does not work in 2.4.3

Initial Comment:
My python app had to retrieve some web pages and while 
our network environment requires proxy it uses urllib2 
opener (source is in attachment). It worked very well 
on older Python interpreters:
ActivePython 2.4.2 Build 248 (ActiveState Corp.) based 
on
Python 2.4.2 (#67, Oct 30 2005, 16:11:18) [MSC v.1310 
32 bit (Intel)] on win32

It works on linux with 2.3 and 2.4.1:
Python 2.4.1 (#2, May 5 2005, 11:32:06)
[GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2

But it does not work with newest 2.4.3 on Linux:
Python 2.4.3 (#1, Jul 10 2006, 09:57:52)
[GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2

Desired result:
isof-mark:~# python2.3 proxy_bug.py
trying http://www.python.org ...
OK.  We have reply from http://www.python.org.
Size: 13757 [b]
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 
Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/
xhtml1-transitional.dtd">
<html lang="en" xml:lang="en" xmlns="http://www.w3.org/
1999/xhtml">
<head>
<me
...
 Yorkshire">design by pollenation</a>
</div>
Copyright ???? 1990-2006, <a href="psf">Python Software 
Foundation</a><br />
<a href="about/legal">Legal Statements</a>
</div>
</div>
</div>
</body>
</html>


isof-mark:~# /usr/local/bin/python proxy_bug.py
trying http://www.python.org ...
Traceback (most recent call last):
  File "proxy_bug.py", line 37, in ?
    get_page()
  File "proxy_bug.py", line 27, in get_page
    f = urllib2.urlopen(request)
  File "/usr/local/lib/python2.4/urllib2.py", line 
130, in urlopen
    return _opener.open(url, data)
  File "/usr/local/lib/python2.4/urllib2.py", line 
364, in open
    response = meth(req, response)
  File "/usr/local/lib/python2.4/urllib2.py", line 
471, in http_response
    response = self.parent.error(
  File "/usr/local/lib/python2.4/urllib2.py", line 
402, in error
    return self._call_chain(*args)
  File "/usr/local/lib/python2.4/urllib2.py", line 
337, in _call_chain
    result = func(*args)
  File "/usr/local/lib/python2.4/urllib2.py", line 
480, in http_error_default
    raise HTTPError(req.get_full_url(), code, msg, 
hdrs, fp)
urllib2.HTTPError: HTTP Error 407: Proxy 
Authentication Required

I have raported it on ActiveState bug list (http://
bugs.activestate.com/show_bug.cgi?id=47018) while I 
first spot this bug on their destribution but it seems 
that bug is in others distributions too.

Regards,
Michal Niklas


----------------------------------------------------------------------

>Comment By: Michal Niklas (mniklas)
Date: 2006-07-19 13:12

Message:
Logged In: YES 
user_id=226518

I have checked that the last wersion my script works with 
is 2.4.2 and copied that version urllib2.py to 2.4.3 Lib 
directory.  It works again.  The only change in urllib2.py 
is in retry_http_basic_auth(), line 723:
 2.4.2
  user,pw = self.passwd.find_user_password(realm, host)
 2.4.3
  user, pw = self.passwd.find_user_password(realm, 
req.get_full_url())

So "host" is replaced by "req.get_full_url()".

Checked again with 2.5b2 and it works!
Probably I destroyed my test environment and tested
it wrong way :(

So the problem is only with 2.4.3.
Previous versions and 2.5b works well.

Regards,
Michal Niklas


----------------------------------------------------------------------

Comment By: Michal Niklas (mniklas)
Date: 2006-07-13 12:09

Message:
Logged In: YES 
user_id=226518

2.5b2 does not work any better:
Python 2.5b2 (r25b2:50512, Jul 11 2006, 10:16:14) [MSC 
v.1310 32 bit (Intel)] on win32

Result is the same as in 2.5b1 :(


----------------------------------------------------------------------

Comment By: Michal Niklas (mniklas)
Date: 2006-07-11 08:27

Message:
Logged In: YES 
user_id=226518

Tried it with 2.5 beta 1 and it is not better :(

c:\tools\pyscripts\scripts>c:\python25\python2.5
Python 2.5b1 (r25b1:47027, Jun 20 2006, 09:31:33) [MSC 
v.1310 32 bit (Intel)] on win32


c:\tools\pyscripts\scripts>c:\python25\python2.5 
proxy_bug.py
trying http://www.python.org ...
Traceback (most recent call last):
  File "proxy_bug.py", line 37, in <module>
    get_page()
  File "proxy_bug.py", line 27, in get_page
    f = urllib2.urlopen(request)
  File "c:\python25\lib\urllib2.py", line 121, in urlopen
    return _opener.open(url, data)
  File "c:\python25\lib\urllib2.py", line 380, in open
    response = meth(req, response)
  File "c:\python25\lib\urllib2.py", line 491, in 
http_response
    'http', request, response, code, msg, hdrs)
  File "c:\python25\lib\urllib2.py", line 412, in error
    result = self._call_chain(*args)
  File "c:\python25\lib\urllib2.py", line 353, in 
_call_chain
    result = func(*args)
  File "c:\python25\lib\urllib2.py", line 831, in 
http_error_407
    authority, req, headers)
  File "c:\python25\lib\urllib2.py", line 795, in 
http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "c:\python25\lib\urllib2.py", line 805, in 
retry_http_basic_auth
    return self.parent.open(req)
  File "c:\python25\lib\urllib2.py", line 380, in open
    response = meth(req, response)
  File "c:\python25\lib\urllib2.py", line 491, in 
http_response
    'http', request, response, code, msg, hdrs)
  File "c:\python25\lib\urllib2.py", line 418, in error
    return self._call_chain(*args)
  File "c:\python25\lib\urllib2.py", line 353, in 
_call_chain
    result = func(*args)
  File "c:\python25\lib\urllib2.py", line 499, in 
http_error_default
    raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
urllib2.HTTPError: HTTP Error 407: Proxy Authentication 
Required

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-07-10 14:49

Message:
Logged In: YES 
user_id=849994

Can you please try with 2.5b1? A lot of urllib2 related bugs
have been fixed before this release.

----------------------------------------------------------------------

Comment By: Michal Niklas (mniklas)
Date: 2006-07-10 10:41

Message:
Logged In: YES 
user_id=226518

Cannot add attachment via upload so I put it here:
#!/usr/bin/python
# -*- coding: cp1250 -*-

import urllib
import urllib2

def get_page():
	url = 'http://www.python.org'
	print "trying %s ..." % (url)

	# Setup proxy & authentication
	proxy = "poczta.heuthes:8080"
	usr1 = "USER"
	pass1 = "PASSWD"
	proxy_handler = urllib2.ProxyHandler({"http" : "http:/
/" + proxy})
	pass_mgr = urllib2.HTTPPasswordMgrWithDefaultRealm()
	pass_mgr.add_password(None, "http://" + proxy, usr1, 
pass1)
	pass_mgr.add_password(None, proxy, usr1, pass1)
	auth_handler = urllib2.HTTPBasicAuthHandler(pass_mgr)
	proxy_auth_handler = 
urllib2.ProxyBasicAuthHandler(pass_mgr)

	# Now build a new URL opener and install it
	opener = urllib2.build_opener(proxy_handler, 
proxy_auth_handler, auth_handler, urllib2.HTTPHandler)
	urllib2.install_opener(opener)

	request = urllib2.Request(url)
	f = urllib2.urlopen(request)
	data = f.read()
	print "OK.  We have reply from %s.\nSize: %d [b]" % 
(url, len(data))
	if len(data) < 400:
		print data
	else:
		print data[:200]
		print "..."
		print data[-200:]

get_page()


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519816&group_id=5470

From noreply at sourceforge.net  Wed Jul 19 13:13:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 19 Jul 2006 04:13:05 -0700
Subject: [ python-Bugs-1519816 ] urllib2 proxy does not work in 2.4.3
Message-ID: <E1G39zF-0001jD-FU@sc8-sf-web2.sourceforge.net>

Bugs item #1519816, was opened at 2006-07-10 10:29
Message generated for change (Settings changed) made by mniklas
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519816&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
>Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Michal Niklas (mniklas)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 proxy does not work in 2.4.3

Initial Comment:
My python app had to retrieve some web pages and while 
our network environment requires proxy it uses urllib2 
opener (source is in attachment). It worked very well 
on older Python interpreters:
ActivePython 2.4.2 Build 248 (ActiveState Corp.) based 
on
Python 2.4.2 (#67, Oct 30 2005, 16:11:18) [MSC v.1310 
32 bit (Intel)] on win32

It works on linux with 2.3 and 2.4.1:
Python 2.4.1 (#2, May 5 2005, 11:32:06)
[GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2

But it does not work with newest 2.4.3 on Linux:
Python 2.4.3 (#1, Jul 10 2006, 09:57:52)
[GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2

Desired result:
isof-mark:~# python2.3 proxy_bug.py
trying http://www.python.org ...
OK.  We have reply from http://www.python.org.
Size: 13757 [b]
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 
Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/
xhtml1-transitional.dtd">
<html lang="en" xml:lang="en" xmlns="http://www.w3.org/
1999/xhtml">
<head>
<me
...
 Yorkshire">design by pollenation</a>
</div>
Copyright ???? 1990-2006, <a href="psf">Python Software 
Foundation</a><br />
<a href="about/legal">Legal Statements</a>
</div>
</div>
</div>
</body>
</html>


isof-mark:~# /usr/local/bin/python proxy_bug.py
trying http://www.python.org ...
Traceback (most recent call last):
  File "proxy_bug.py", line 37, in ?
    get_page()
  File "proxy_bug.py", line 27, in get_page
    f = urllib2.urlopen(request)
  File "/usr/local/lib/python2.4/urllib2.py", line 
130, in urlopen
    return _opener.open(url, data)
  File "/usr/local/lib/python2.4/urllib2.py", line 
364, in open
    response = meth(req, response)
  File "/usr/local/lib/python2.4/urllib2.py", line 
471, in http_response
    response = self.parent.error(
  File "/usr/local/lib/python2.4/urllib2.py", line 
402, in error
    return self._call_chain(*args)
  File "/usr/local/lib/python2.4/urllib2.py", line 
337, in _call_chain
    result = func(*args)
  File "/usr/local/lib/python2.4/urllib2.py", line 
480, in http_error_default
    raise HTTPError(req.get_full_url(), code, msg, 
hdrs, fp)
urllib2.HTTPError: HTTP Error 407: Proxy 
Authentication Required

I have raported it on ActiveState bug list (http://
bugs.activestate.com/show_bug.cgi?id=47018) while I 
first spot this bug on their destribution but it seems 
that bug is in others distributions too.

Regards,
Michal Niklas


----------------------------------------------------------------------

Comment By: Michal Niklas (mniklas)
Date: 2006-07-19 13:12

Message:
Logged In: YES 
user_id=226518

I have checked that the last wersion my script works with 
is 2.4.2 and copied that version urllib2.py to 2.4.3 Lib 
directory.  It works again.  The only change in urllib2.py 
is in retry_http_basic_auth(), line 723:
 2.4.2
  user,pw = self.passwd.find_user_password(realm, host)
 2.4.3
  user, pw = self.passwd.find_user_password(realm, 
req.get_full_url())

So "host" is replaced by "req.get_full_url()".

Checked again with 2.5b2 and it works!
Probably I destroyed my test environment and tested
it wrong way :(

So the problem is only with 2.4.3.
Previous versions and 2.5b works well.

Regards,
Michal Niklas


----------------------------------------------------------------------

Comment By: Michal Niklas (mniklas)
Date: 2006-07-13 12:09

Message:
Logged In: YES 
user_id=226518

2.5b2 does not work any better:
Python 2.5b2 (r25b2:50512, Jul 11 2006, 10:16:14) [MSC 
v.1310 32 bit (Intel)] on win32

Result is the same as in 2.5b1 :(


----------------------------------------------------------------------

Comment By: Michal Niklas (mniklas)
Date: 2006-07-11 08:27

Message:
Logged In: YES 
user_id=226518

Tried it with 2.5 beta 1 and it is not better :(

c:\tools\pyscripts\scripts>c:\python25\python2.5
Python 2.5b1 (r25b1:47027, Jun 20 2006, 09:31:33) [MSC 
v.1310 32 bit (Intel)] on win32


c:\tools\pyscripts\scripts>c:\python25\python2.5 
proxy_bug.py
trying http://www.python.org ...
Traceback (most recent call last):
  File "proxy_bug.py", line 37, in <module>
    get_page()
  File "proxy_bug.py", line 27, in get_page
    f = urllib2.urlopen(request)
  File "c:\python25\lib\urllib2.py", line 121, in urlopen
    return _opener.open(url, data)
  File "c:\python25\lib\urllib2.py", line 380, in open
    response = meth(req, response)
  File "c:\python25\lib\urllib2.py", line 491, in 
http_response
    'http', request, response, code, msg, hdrs)
  File "c:\python25\lib\urllib2.py", line 412, in error
    result = self._call_chain(*args)
  File "c:\python25\lib\urllib2.py", line 353, in 
_call_chain
    result = func(*args)
  File "c:\python25\lib\urllib2.py", line 831, in 
http_error_407
    authority, req, headers)
  File "c:\python25\lib\urllib2.py", line 795, in 
http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "c:\python25\lib\urllib2.py", line 805, in 
retry_http_basic_auth
    return self.parent.open(req)
  File "c:\python25\lib\urllib2.py", line 380, in open
    response = meth(req, response)
  File "c:\python25\lib\urllib2.py", line 491, in 
http_response
    'http', request, response, code, msg, hdrs)
  File "c:\python25\lib\urllib2.py", line 418, in error
    return self._call_chain(*args)
  File "c:\python25\lib\urllib2.py", line 353, in 
_call_chain
    result = func(*args)
  File "c:\python25\lib\urllib2.py", line 499, in 
http_error_default
    raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
urllib2.HTTPError: HTTP Error 407: Proxy Authentication 
Required

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-07-10 14:49

Message:
Logged In: YES 
user_id=849994

Can you please try with 2.5b1? A lot of urllib2 related bugs
have been fixed before this release.

----------------------------------------------------------------------

Comment By: Michal Niklas (mniklas)
Date: 2006-07-10 10:41

Message:
Logged In: YES 
user_id=226518

Cannot add attachment via upload so I put it here:
#!/usr/bin/python
# -*- coding: cp1250 -*-

import urllib
import urllib2

def get_page():
	url = 'http://www.python.org'
	print "trying %s ..." % (url)

	# Setup proxy & authentication
	proxy = "poczta.heuthes:8080"
	usr1 = "USER"
	pass1 = "PASSWD"
	proxy_handler = urllib2.ProxyHandler({"http" : "http:/
/" + proxy})
	pass_mgr = urllib2.HTTPPasswordMgrWithDefaultRealm()
	pass_mgr.add_password(None, "http://" + proxy, usr1, 
pass1)
	pass_mgr.add_password(None, proxy, usr1, pass1)
	auth_handler = urllib2.HTTPBasicAuthHandler(pass_mgr)
	proxy_auth_handler = 
urllib2.ProxyBasicAuthHandler(pass_mgr)

	# Now build a new URL opener and install it
	opener = urllib2.build_opener(proxy_handler, 
proxy_auth_handler, auth_handler, urllib2.HTTPHandler)
	urllib2.install_opener(opener)

	request = urllib2.Request(url)
	f = urllib2.urlopen(request)
	data = f.read()
	print "OK.  We have reply from %s.\nSize: %d [b]" % 
(url, len(data))
	if len(data) < 400:
		print data
	else:
		print data[:200]
		print "..."
		print data[-200:]

get_page()


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519816&group_id=5470

From noreply at sourceforge.net  Wed Jul 19 16:53:29 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 19 Jul 2006 07:53:29 -0700
Subject: [ python-Bugs-1525343 ] Webserver TypeError: expected read buffer,
	NoneType found
Message-ID: <E1G3DQX-0003v3-OC@sc8-sf-web5.sourceforge.net>

Bugs item #1525343, was opened at 2006-07-19 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=1525343&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: jbet (jbeisert)
Assigned to: Nobody/Anonymous (nobody)
Summary: Webserver TypeError: expected read buffer, NoneType found

Initial Comment:
When I'm using the python webserver I got the 
following message for every access by my client. 
Soryy, I have no experience in Python, so I cannot 
help. This is only a report. 
  
HTTPdaemon_v1.0.0 listening on port 8001 
---------------------------------------- 
Exception happened during processing of request from 
('192.168.1.9', 33917) 
Traceback (most recent call last): 
  File "/home/jb/bin/lib/python2.5/SocketServer.py", 
line 463, in  
process_request_thread 
    self.finish_request(request, client_address) 
  File "/home/jb/bin/lib/python2.5/SocketServer.py", 
line 254, in  
finish_request 
    self.RequestHandlerClass(request, client_address, 
self) 
  File "/home/jb/bin/lib/python2.5/SocketServer.py", 
line 521, in __init__ 
    self.handle() 
  File 
"/home/jb/bin/lib/python2.5/BaseHTTPServer.py", line 
316, in handle 
    self.handle_one_request() 
  File 
"/home/jb/bin/lib/python2.5/BaseHTTPServer.py", line 
310, in  
handle_one_request 
    method() 
  File 
"./src/Myghty-1.0/lib/myghty/http/HTTPServerHandler.py", 
line 53, in  
do_GET 
    self.handle_request() 
  File 
"./src/Myghty-1.0/lib/myghty/http/HTTPServerHandler.py", 
line 56, in  
handle_request 
    httpreq = HSHTTPRequest(self) 
  File 
"./src/Myghty-1.0/lib/myghty/http/HTTPServerHandler.py", 
line 254, in  
__init__ 
    keep_blank_values = True 
  File "/home/jb/bin/lib/python2.5/cgi.py", line 462, 
in __init__ 
    fp = StringIO(qs) 
TypeError: expected read buffer, NoneType found 
---------------------------------------- 
---------------------------------------- 
Exception happened during processing of request from 
('192.168.1.9', 33918) 
Traceback (most recent call last): 
  File "/home/jb/bin/lib/python2.5/SocketServer.py", 
line 463, in  
process_request_thread 
    self.finish_request(request, client_address) 
  File "/home/jb/bin/lib/python2.5/SocketServer.py", 
line 254, in  
finish_request 
    self.RequestHandlerClass(request, client_address, 
self) 
  File "/home/jb/bin/lib/python2.5/SocketServer.py", 
line 521, in __init__ 
    self.handle() 
  File 
"/home/jb/bin/lib/python2.5/BaseHTTPServer.py", line 
316, in handle 
    self.handle_one_request() 
  File 
"/home/jb/bin/lib/python2.5/BaseHTTPServer.py", line 
310, in  
handle_one_request 
    method() 
  File 
"./src/Myghty-1.0/lib/myghty/http/HTTPServerHandler.py", 
line 53, in  
do_GET 
    self.handle_request() 
  File 
"./src/Myghty-1.0/lib/myghty/http/HTTPServerHandler.py", 
line 56, in  
handle_request 
    httpreq = HSHTTPRequest(self) 
  File 
"./src/Myghty-1.0/lib/myghty/http/HTTPServerHandler.py", 
line 254, in  
__init__ 
    keep_blank_values = True 
  File "/home/jb/bin/lib/python2.5/cgi.py", line 462, 
in __init__ 
    fp = StringIO(qs) 
TypeError: expected read buffer, NoneType found 
---------------------------------------- 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525343&group_id=5470

From noreply at sourceforge.net  Wed Jul 19 19:24:48 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 19 Jul 2006 10:24:48 -0700
Subject: [ python-Bugs-1525447 ] Build fails on OS X with case sensitive fs
Message-ID: <E1G3Fmy-0005xb-H8@sc8-sf-web2.sourceforge.net>

Bugs item #1525447, was opened at 2006-07-19 19:24
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=1525447&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: gideon may (gdm)
Assigned to: Nobody/Anonymous (nobody)
Summary: Build fails on OS X with case sensitive fs

Initial Comment:
When compiling python from svn on a Mac OS X with a 
case sensitive file system I get the following build
error:

running build
running build_ext
db.h: found (4, 3) in /opt/local/include/db4
db lib: using (4, 3) db-4.3
sqlite: found /usr/include/sqlite3.h
/usr/include/sqlite3.h: version 3.1.3
Traceback (most recent call last):
  File "./setup.py", line 1507, in <module>
    main()
.
.
  File "./setup.py", line 1088, in addMacExtension
    raise RuntimeError("%s not found" % name)
RuntimeError: MacOS not found
make: *** [sharedmods] Error 1




It can be fixed by either renaming the file:
  Mac/Modules/macosmodule.c 
to
  Mac/Modules/MacOSmodule.c 

or applying the following patch :
Index: setup.py
===================================================================
--- setup.py    (revision 50687)
+++ setup.py    (working copy)
@@ -1101,7 +1101,7 @@
             carbon_kwds = {'extra_compile_args':
carbon_extra_compile_args,
                            'extra_link_args':
['-framework', 'Carbon'],
                           }
-            CARBON_EXTS = ['ColorPicker', 'gestalt',
'MacOS', 'Nav',
+            CARBON_EXTS = ['ColorPicker', 'gestalt',
'macos', 'Nav',
                            'OSATerminology', 'icglue',
                            # All these are in subdirs
                            '_AE', '_AH', '_App',
'_CarbonEvt', '_Cm', '_Ctl',


Cheers,

Gideon



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525447&group_id=5470

From noreply at sourceforge.net  Wed Jul 19 19:25:44 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 19 Jul 2006 10:25:44 -0700
Subject: [ python-Bugs-1525447 ] Build fails on OS X with case sensitive fs
Message-ID: <E1G3Fns-0006GW-8b@sc8-sf-web2.sourceforge.net>

Bugs item #1525447, was opened at 2006-07-19 19:24
Message generated for change (Settings changed) made by gdm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525447&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
>Priority: 6
Submitted By: gideon may (gdm)
Assigned to: Nobody/Anonymous (nobody)
Summary: Build fails on OS X with case sensitive fs

Initial Comment:
When compiling python from svn on a Mac OS X with a 
case sensitive file system I get the following build
error:

running build
running build_ext
db.h: found (4, 3) in /opt/local/include/db4
db lib: using (4, 3) db-4.3
sqlite: found /usr/include/sqlite3.h
/usr/include/sqlite3.h: version 3.1.3
Traceback (most recent call last):
  File "./setup.py", line 1507, in <module>
    main()
.
.
  File "./setup.py", line 1088, in addMacExtension
    raise RuntimeError("%s not found" % name)
RuntimeError: MacOS not found
make: *** [sharedmods] Error 1




It can be fixed by either renaming the file:
  Mac/Modules/macosmodule.c 
to
  Mac/Modules/MacOSmodule.c 

or applying the following patch :
Index: setup.py
===================================================================
--- setup.py    (revision 50687)
+++ setup.py    (working copy)
@@ -1101,7 +1101,7 @@
             carbon_kwds = {'extra_compile_args':
carbon_extra_compile_args,
                            'extra_link_args':
['-framework', 'Carbon'],
                           }
-            CARBON_EXTS = ['ColorPicker', 'gestalt',
'MacOS', 'Nav',
+            CARBON_EXTS = ['ColorPicker', 'gestalt',
'macos', 'Nav',
                            'OSATerminology', 'icglue',
                            # All these are in subdirs
                            '_AE', '_AH', '_App',
'_CarbonEvt', '_Cm', '_Ctl',


Cheers,

Gideon



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525447&group_id=5470

From noreply at sourceforge.net  Wed Jul 19 20:06:55 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 19 Jul 2006 11:06:55 -0700
Subject: [ python-Bugs-1525469 ] SimpleXMLRpcServer still uses sys.exc_value
	and sys.exc_type
Message-ID: <E1G3GRj-0003qd-V7@sc8-sf-web6.sourceforge.net>

Bugs item #1525469, was opened at 2006-07-19 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=1525469&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Russell Warren (qopit)
Assigned to: Nobody/Anonymous (nobody)
Summary: SimpleXMLRpcServer still uses sys.exc_value and sys.exc_type

Initial Comment:
Use of sys.exc_value and sys.exc_type is not thread
safe.  It should just use sys.exc_info.

Both exc_value and exc_type are used in two exceptiuon
trapping locations.

This goes back to at least 2.3, and I've checked 2.5
svn ver 50569 and it is still an issue.

Russ


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525469&group_id=5470

From noreply at sourceforge.net  Wed Jul 19 23:30:28 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 19 Jul 2006 14:30:28 -0700
Subject: [ python-Bugs-1525549 ] Document additions from PEP 302
Message-ID: <E1G3Jci-0000b2-5m@sc8-sf-web1.sourceforge.net>

Bugs item #1525549, was opened at 2006-07-19 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=105470&aid=1525549&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Brett Cannon (bcannon)
Assigned to: Nobody/Anonymous (nobody)
Summary: Document additions from PEP 302

Initial Comment:
meta_path, path_hooks, and path_importer_cache are not
in the documentation for sys.  These were all added by
PEP 302.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525549&group_id=5470

From noreply at sourceforge.net  Thu Jul 20 01:20:07 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 19 Jul 2006 16:20:07 -0700
Subject: [ python-Bugs-1524938 ] MemoryError with a lot of available memory -
	gc not called
Message-ID: <E1G3LKp-0006UK-Mj@sc8-sf-web2.sourceforge.net>

Bugs item #1524938, was opened at 2006-07-19 02:46
Message generated for change (Comment added) made by illume
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1524938&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Matusevich (markmat)
Assigned to: Nobody/Anonymous (nobody)
Summary: MemoryError with a lot of available memory - gc not called

Initial Comment:
Also the gc behavior is consistent with the
documentation, I beleave it is wrong. I think, that Gc
should be called automatically before any memory
allocation is raised.

Example 1:
for i in range(700): 
   a = [range(5000000)]
   a.append(a)
   print i

This example will crash on any any PC with less then
20Gb RAM. On my PC (Windows 2000, 256Mb) it crashes at
i==7.
Also, this example can be fixed by addition of a call
to gc.collect() in the loop, in real cases it may be
unreasonable. 


----------------------------------------------------------------------

Comment By: Rene Dudfield (illume)
Date: 2006-07-19 23:20

Message:
Logged In: YES 
user_id=2042

Perhaps better than checking before every memory allocation,
would be to check once a memory error happens in an allocation.

That way there is only the gc hit once there is low memory.

So...

res = malloc(...);
if(!res) {
    gc.collect();
}

res = malloc(...);
if(!res) {
    raise memory error.
}





----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1524938&group_id=5470

From noreply at sourceforge.net  Thu Jul 20 01:28:37 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 19 Jul 2006 16:28:37 -0700
Subject: [ python-Bugs-1525589 ] Malloc, memory error, failmalloc, low memory.
Message-ID: <E1G3LT3-00009t-Ay@sc8-sf-web3.sourceforge.net>

Bugs item #1525589, was opened at 2006-07-19 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=1525589&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Rene Dudfield (illume)
Assigned to: Nobody/Anonymous (nobody)
Summary: Malloc, memory error, failmalloc, low memory.

Initial Comment:
The failmalloc library can be used to simulate high
load, low memory conditions.

http://www.nongnu.org/failmalloc/

It reports that python segfaults under some conditions
when memory allocation fails.

"
$ LD_PRELOAD=libfailmalloc.so FAILMALLOC_INTERVAL=10 python
Fatal Python error: Can't initialize 'type'
Aborted
$ LD_PRELOAD=libfailmalloc.so FAILMALLOC_INTERVAL=100
python
Segmentation fault
"

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525589&group_id=5470

From noreply at sourceforge.net  Thu Jul 20 01:31:39 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 19 Jul 2006 16:31:39 -0700
Subject: [ python-Bugs-1525590 ] ldap get_option(0) causes segfault
Message-ID: <E1G3LVz-0003yg-21@sc8-sf-web2.sourceforge.net>

Bugs item #1525590, was opened at 2006-07-19 16: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=1525590&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Sean Burford (seanburford)
Assigned to: Nobody/Anonymous (nobody)
Summary: ldap get_option(0) causes segfault

Initial Comment:
$ /usr/bin/python2.4
Python 2.4.1 (#2, Mar 30 2005, 21:51:10) 
[GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import ldap
>>> l=ldap.open('abc')
>>> l.get_option(0)
Segmentation fault

$ /usr/bin/python2.3
Python 2.3.5 (#2, Aug 30 2005, 13:43:24) 
[GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import ldap
>>> l=ldap.open('abc')
>>> l.get_option(0)


Under GDB with 2.4.1:

>>> l.get_option(0)
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1209606016 (LWP 27694)]
0xb7ee4d8b in strlen () from /lib/tls/i686/cmov/libc.so.6
(gdb) bt
#0  0xb7ee4d8b in strlen () from
/lib/tls/i686/cmov/libc.so.6
#1  0x080dc668 in Py_InitModule4 ()
#2  0x080dce8e in PyModule_AddStringConstant ()
#3  0x080dc6ba in Py_InitModule4 ()
#4  0x080dc755 in Py_VaBuildValue ()
#5  0x080dc6d8 in Py_BuildValue ()
#6  0xb7fde111 in LDAP_get_option ()
   from /usr/lib/python2.4/site-packages/_ldap.so
#7  0xb7fd9127 in py_ldap_sasl_interaction ()
   from /usr/lib/python2.4/site-packages/_ldap.so
#8  0x081071fa in PyCFunction_Call ()
#9  0x0805c449 in PyObject_Call ()
#10 0x080afc34 in PyEval_CallObjectWithKeywords ()
#11 0x080add4c in PyEval_EvalFrame ()
#12 0x080ae42e in PyEval_EvalCodeEx ()
#13 0x080af849 in PyEval_CallObjectWithKeywords ()
#14 0x080af464 in PyEval_CallObjectWithKeywords ()
#15 0x080ad9b7 in PyEval_EvalFrame ()
#16 0x080af8cd in PyEval_CallObjectWithKeywords ()
#17 0x080af464 in PyEval_CallObjectWithKeywords ()
#18 0x080ad9b7 in PyEval_EvalFrame ()
#19 0x080ae42e in PyEval_EvalCodeEx ()
#20 0x080b11a9 in PyEval_EvalCode ()
#21 0x080df38b in PyRun_FileExFlags ()
#22 0x080de88e in PyRun_InteractiveOneFlags ()
#23 0x080de683 in PyRun_InteractiveLoopFlags ()
#24 0x080dfd32 in PyRun_AnyFileExFlags ()
#25 0x080554a4 in Py_Main ()
#26 0x08054f2b in main ()


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525590&group_id=5470

From noreply at sourceforge.net  Thu Jul 20 04:20:48 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 19 Jul 2006 19:20:48 -0700
Subject: [ python-Bugs-1517370 ] Getting an error message import site failed
	-v traceback.
Message-ID: <200607200220.k6K2Kmpo004019@sc8-sf-db2-new-b.sourceforge.net>

Bugs item #1517370, was opened at 07/05/06 00:22
Message generated for change (Settings changed) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517370&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
>Status: Closed
Resolution: None
Priority: 5
Submitted By: brijesh kumar (brijesh_04)
Assigned to: Nobody/Anonymous (nobody)
Summary: Getting an error message import site failed -v traceback.

Initial Comment:
we have not installed python on the machine and trying 
to use python24.dll in c++ code(by including header 
python.h).

At the time of py_initialize() we get an error import 
site failed -v traceback. But if python is installed 
on the machine no such error comes.

But we don't want to Install Python on my M/C.
Please tell us how to get rid of this error in our 
scenerio.



----------------------------------------------------------------------

>Comment By: SourceForge Robot (sf-robot)
Date: 07/19/06 19:20

Message:
Logged In: YES 
user_id=1312539

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 07/05/06 01:05

Message:
Logged In: YES 
user_id=849994

You'll have to set Py_NoSiteFlag prior to calling
Py_Initialize(). See Python/main.c which does this while
parsing command line args.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517370&group_id=5470

From noreply at sourceforge.net  Thu Jul 20 05:33:10 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 19 Jul 2006 20:33:10 -0700
Subject: [ python-Bugs-1525590 ] ldap get_option(0) causes segfault
Message-ID: <E1G3PHi-0007z2-OZ@sc8-sf-web3.sourceforge.net>

Bugs item #1525590, was opened at 2006-07-19 16:31
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525590&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
>Group: 3rd Party
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Sean Burford (seanburford)
Assigned to: Nobody/Anonymous (nobody)
Summary: ldap get_option(0) causes segfault

Initial Comment:
$ /usr/bin/python2.4
Python 2.4.1 (#2, Mar 30 2005, 21:51:10) 
[GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import ldap
>>> l=ldap.open('abc')
>>> l.get_option(0)
Segmentation fault

$ /usr/bin/python2.3
Python 2.3.5 (#2, Aug 30 2005, 13:43:24) 
[GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import ldap
>>> l=ldap.open('abc')
>>> l.get_option(0)


Under GDB with 2.4.1:

>>> l.get_option(0)
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1209606016 (LWP 27694)]
0xb7ee4d8b in strlen () from /lib/tls/i686/cmov/libc.so.6
(gdb) bt
#0  0xb7ee4d8b in strlen () from
/lib/tls/i686/cmov/libc.so.6
#1  0x080dc668 in Py_InitModule4 ()
#2  0x080dce8e in PyModule_AddStringConstant ()
#3  0x080dc6ba in Py_InitModule4 ()
#4  0x080dc755 in Py_VaBuildValue ()
#5  0x080dc6d8 in Py_BuildValue ()
#6  0xb7fde111 in LDAP_get_option ()
   from /usr/lib/python2.4/site-packages/_ldap.so
#7  0xb7fd9127 in py_ldap_sasl_interaction ()
   from /usr/lib/python2.4/site-packages/_ldap.so
#8  0x081071fa in PyCFunction_Call ()
#9  0x0805c449 in PyObject_Call ()
#10 0x080afc34 in PyEval_CallObjectWithKeywords ()
#11 0x080add4c in PyEval_EvalFrame ()
#12 0x080ae42e in PyEval_EvalCodeEx ()
#13 0x080af849 in PyEval_CallObjectWithKeywords ()
#14 0x080af464 in PyEval_CallObjectWithKeywords ()
#15 0x080ad9b7 in PyEval_EvalFrame ()
#16 0x080af8cd in PyEval_CallObjectWithKeywords ()
#17 0x080af464 in PyEval_CallObjectWithKeywords ()
#18 0x080ad9b7 in PyEval_EvalFrame ()
#19 0x080ae42e in PyEval_EvalCodeEx ()
#20 0x080b11a9 in PyEval_EvalCode ()
#21 0x080df38b in PyRun_FileExFlags ()
#22 0x080de88e in PyRun_InteractiveOneFlags ()
#23 0x080de683 in PyRun_InteractiveLoopFlags ()
#24 0x080dfd32 in PyRun_AnyFileExFlags ()
#25 0x080554a4 in Py_Main ()
#26 0x08054f2b in main ()


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-19 20:33

Message:
Logged In: YES 
user_id=33168

ldap is not part of the Python core.  You should file this
bug with the ldap maintainers or whoever provided the ldap
module.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525590&group_id=5470

From noreply at sourceforge.net  Thu Jul 20 05:57:53 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 19 Jul 2006 20:57:53 -0700
Subject: [ python-Bugs-1525678 ] exec and eval allocate lots of memory and do
	not free it
Message-ID: <E1G3Pfd-0001Fo-K2@sc8-sf-web3.sourceforge.net>

Bugs item #1525678, was opened at 2006-07-20 03:57
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=1525678&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Connelly (connelly)
Assigned to: Nobody/Anonymous (nobody)
Summary: exec and eval allocate lots of memory and do not free it

Initial Comment:
I'm not sure if this is a bug.  The "bug" is that if I start a new Python 
session, create a dict or list called d which takes around 2 MB of 
memory, and then I set d = eval(repr(d)), the Python process now is 
using ~38 MB of memory more than where it started at.  The high 
memory usage continues even after d is deleted.

Example 1:

% python
>>> # Memory use: 3216 KB
>>> d = dict.fromkeys(range(50000))
>>> # Memory use: 5400 KB
>>> d = eval('%r' % d)
>>> # Memory use: 41620 KB
>>> del d
>>> # Memory use: 40080 KB

I am using Python 2.4.1 (#65, Mar 30 2005) on Windows XP SP2 with 
512 MB RAM.

If we start with a larger initial dict -- say 
dict.fromkeys(range(1000**2)), then the line d = eval('%r' % d) can 
easily cause the process to start paging to disk, even though both the 
data structure and its string representation fit easily in memory.

Perhaps this behavior is due Python caching bytecodes.  One 
peculiarity about this "bug" is that if Example 1 is repeated with a 
second variable such as "d2", which is set to the value 
dict.fromkeys(range(50000,100000)), then the memory usage ends up 
exactly at 40080 KB after the second "del" statement.  If Python were 
caching the bytecodes, then one would expect the repetition of the 
example to put the memory usage at ~80000 KB.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525678&group_id=5470

From noreply at sourceforge.net  Thu Jul 20 08:40:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 19 Jul 2006 23:40:23 -0700
Subject: [ python-Bugs-1516184 ] inspect.py: still infinite recursion
	inspecting frames
Message-ID: <E1G3SCt-0003Mb-NR@sc8-sf-web5.sourceforge.net>

Bugs item #1516184, was opened at 2006-07-03 08:39
Message generated for change (Comment added) made by connelly
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1516184&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Don Quijote (dq_searchlores)
Assigned to: Phillip J. Eby (pje)
Summary: inspect.py: still infinite recursion inspecting frames

Initial Comment:
Using python 2.5 beta 1 on Windows XP, and py2exe 0.6.5.

After packing and compressing a project via py2exe,
there's still an infinite recursion involving functions
getsourcefile, getmodule and getabsfile in module
inspect.py.

I was able to fix this infinite recursion by

1) changing the declaration of getabsfile & getmodule to:
def getabsfile(object, filename=None):
def getmodule(object, filename=None):

2) including the "filename" parameter in all calls to
getabsfile inside of function getmodule.

3) having getabsfile return the absolute and normalized
filename if not null.

Perhaps this change helps to clean up the 'ugliness'
introduced in version 45822.

Kind regards,
Don Quijote 

----------------------------------------------------------------------

Comment By: Connelly (connelly)
Date: 2006-07-20 06:40

Message:
Logged In: YES 
user_id=1039782

I tried pje's Revision 50526 and this still causes infinite recursion with:

>>> inspect.getmodule(compile('a=10','','single'))


----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2006-07-10 19:05

Message:
Logged In: YES 
user_id=56214

Fixed in revision 50526.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-05 01:53

Message:
Logged In: YES 
user_id=33168

Phillip any comments?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1516184&group_id=5470

From noreply at sourceforge.net  Thu Jul 20 08:59:17 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 19 Jul 2006 23:59:17 -0700
Subject: [ python-Bugs-1516184 ] inspect.py: still infinite recursion
	inspecting frames
Message-ID: <E1G3SVB-0002ZW-IE@sc8-sf-web2.sourceforge.net>

Bugs item #1516184, was opened at 2006-07-03 01:39
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1516184&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
>Status: Open
>Resolution: None
Priority: 5
Submitted By: Don Quijote (dq_searchlores)
Assigned to: Phillip J. Eby (pje)
Summary: inspect.py: still infinite recursion inspecting frames

Initial Comment:
Using python 2.5 beta 1 on Windows XP, and py2exe 0.6.5.

After packing and compressing a project via py2exe,
there's still an infinite recursion involving functions
getsourcefile, getmodule and getabsfile in module
inspect.py.

I was able to fix this infinite recursion by

1) changing the declaration of getabsfile & getmodule to:
def getabsfile(object, filename=None):
def getmodule(object, filename=None):

2) including the "filename" parameter in all calls to
getabsfile inside of function getmodule.

3) having getabsfile return the absolute and normalized
filename if not null.

Perhaps this change helps to clean up the 'ugliness'
introduced in version 45822.

Kind regards,
Don Quijote 

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-19 23:59

Message:
Logged In: YES 
user_id=33168

Confirmed this is bad: 
inspect.getmodule(compile('a=10','','single'))

----------------------------------------------------------------------

Comment By: Connelly (connelly)
Date: 2006-07-19 23:40

Message:
Logged In: YES 
user_id=1039782

I tried pje's Revision 50526 and this still causes infinite recursion with:

>>> inspect.getmodule(compile('a=10','','single'))


----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2006-07-10 12:05

Message:
Logged In: YES 
user_id=56214

Fixed in revision 50526.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-04 18:53

Message:
Logged In: YES 
user_id=33168

Phillip any comments?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1516184&group_id=5470

From noreply at sourceforge.net  Thu Jul 20 14:36:44 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 20 Jul 2006 05:36:44 -0700
Subject: [ python-Bugs-1516184 ] inspect.py: still infinite recursion
	inspecting frames
Message-ID: <E1G3Xlk-0007xN-BS@sc8-sf-web5.sourceforge.net>

Bugs item #1516184, was opened at 2006-07-03 10:39
Message generated for change (Comment added) made by dq_searchlores
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1516184&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Don Quijote (dq_searchlores)
Assigned to: Phillip J. Eby (pje)
Summary: inspect.py: still infinite recursion inspecting frames

Initial Comment:
Using python 2.5 beta 1 on Windows XP, and py2exe 0.6.5.

After packing and compressing a project via py2exe,
there's still an infinite recursion involving functions
getsourcefile, getmodule and getabsfile in module
inspect.py.

I was able to fix this infinite recursion by

1) changing the declaration of getabsfile & getmodule to:
def getabsfile(object, filename=None):
def getmodule(object, filename=None):

2) including the "filename" parameter in all calls to
getabsfile inside of function getmodule.

3) having getabsfile return the absolute and normalized
filename if not null.

Perhaps this change helps to clean up the 'ugliness'
introduced in version 45822.

Kind regards,
Don Quijote 

----------------------------------------------------------------------

>Comment By: Don Quijote (dq_searchlores)
Date: 2006-07-20 14:36

Message:
Logged In: YES 
user_id=1118684

A possible simple fix:
In function getabsfile(), test _filename explicitly with:
...abspath(_filename is not None or getsourcefile...

In your case, _filename is ''. This is the value returned
from getfile(), when using attribute .co_filename from the
code object.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-20 08:59

Message:
Logged In: YES 
user_id=33168

Confirmed this is bad: 
inspect.getmodule(compile('a=10','','single'))

----------------------------------------------------------------------

Comment By: Connelly (connelly)
Date: 2006-07-20 08:40

Message:
Logged In: YES 
user_id=1039782

I tried pje's Revision 50526 and this still causes infinite recursion with:

>>> inspect.getmodule(compile('a=10','','single'))


----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2006-07-10 21:05

Message:
Logged In: YES 
user_id=56214

Fixed in revision 50526.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-05 03:53

Message:
Logged In: YES 
user_id=33168

Phillip any comments?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1516184&group_id=5470

From noreply at sourceforge.net  Thu Jul 20 15:00:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 20 Jul 2006 06:00:46 -0700
Subject: [ python-Bugs-1525866 ] Bug in shutil.copytree on Windows
Message-ID: <E1G3Y90-00088k-7I@sc8-sf-web2.sourceforge.net>

Bugs item #1525866, was opened at 2006-07-20 13: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=1525866&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Foord (mjfoord)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bug in shutil.copytree on Windows

Initial Comment:
The problem is that the call to 'copystat(src, dst)'
was added to the shutil.copytree function, in svn
r38363 probably.  It will fail always on Windows, since
os.utime does not work on directories.

I guess that a patch similar to this one should fix it:

Index: shutil.py
===================================================================
--- shutil.py	(Revision 50710)
+++ shutil.py	(Arbeitskopie)
@@ -127,7 +127,12 @@
         # continue with other files
         except Error, err:
             errors.extend(err.args[0])
-    copystat(src, dst)
+    try:
+        copystat(src, dst)
+    except WindowsError:
+        pass
+    except OSError, err:
+        errors.extend(err.args[0])
     if errors:
         raise Error, errors

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525866&group_id=5470

From noreply at sourceforge.net  Thu Jul 20 16:22:21 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 20 Jul 2006 07:22:21 -0700
Subject: [ python-Bugs-1525919 ] email package quoted printable behaviour
	changed
Message-ID: <E1G3ZPx-0001SN-CV@sc8-sf-web6.sourceforge.net>

Bugs item #1525919, was opened at 2006-07-20 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=1525919&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Arendsen Hein (thomas_ah)
Assigned to: Nobody/Anonymous (nobody)
Summary: email package quoted printable behaviour changed

Initial Comment:
from email.Message import Message
from email.Charset import Charset, QP
text = "="
msg = Message()
charset = Charset("utf-8")
charset.header_encoding = QP
charset.body_encoding = QP
msg.set_charset(charset)
msg.set_payload(text)
print msg.as_string()

Gives

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

=3D


With the email package from python2.4.3 and 2.4.4c0 the
last '=3D' becomes just '=', so an extra
msg.body_encode(text) is needed.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525919&group_id=5470

From noreply at sourceforge.net  Thu Jul 20 16:24:02 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 20 Jul 2006 07:24:02 -0700
Subject: [ python-Bugs-1525919 ] email package quoted printable behaviour
	changed
Message-ID: <E1G3ZRa-00045Y-22@sc8-sf-web6.sourceforge.net>

Bugs item #1525919, was opened at 2006-07-20 16:22
Message generated for change (Settings changed) made by thomas_ah
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525919&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Arendsen Hein (thomas_ah)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email package quoted printable behaviour changed

Initial Comment:
from email.Message import Message
from email.Charset import Charset, QP
text = "="
msg = Message()
charset = Charset("utf-8")
charset.header_encoding = QP
charset.body_encoding = QP
msg.set_charset(charset)
msg.set_payload(text)
print msg.as_string()

Gives

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

=3D


With the email package from python2.4.3 and 2.4.4c0 the
last '=3D' becomes just '=', so an extra
msg.body_encode(text) is needed.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525919&group_id=5470

From noreply at sourceforge.net  Thu Jul 20 17:56:08 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 20 Jul 2006 08:56:08 -0700
Subject: [ python-Bugs-1516184 ] inspect.py: still infinite recursion
	inspecting frames
Message-ID: <E1G3asi-00017o-1t@sc8-sf-web1.sourceforge.net>

Bugs item #1516184, was opened at 2006-07-03 08:39
Message generated for change (Comment added) made by pje
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1516184&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Don Quijote (dq_searchlores)
Assigned to: Phillip J. Eby (pje)
Summary: inspect.py: still infinite recursion inspecting frames

Initial Comment:
Using python 2.5 beta 1 on Windows XP, and py2exe 0.6.5.

After packing and compressing a project via py2exe,
there's still an infinite recursion involving functions
getsourcefile, getmodule and getabsfile in module
inspect.py.

I was able to fix this infinite recursion by

1) changing the declaration of getabsfile & getmodule to:
def getabsfile(object, filename=None):
def getmodule(object, filename=None):

2) including the "filename" parameter in all calls to
getabsfile inside of function getmodule.

3) having getabsfile return the absolute and normalized
filename if not null.

Perhaps this change helps to clean up the 'ugliness'
introduced in version 45822.

Kind regards,
Don Quijote 

----------------------------------------------------------------------

>Comment By: Phillip J. Eby (pje)
Date: 2006-07-20 15:56

Message:
Logged In: YES 
user_id=56214

Added a test for the new issue and fixed in revision 50719.


----------------------------------------------------------------------

Comment By: Don Quijote (dq_searchlores)
Date: 2006-07-20 12:36

Message:
Logged In: YES 
user_id=1118684

A possible simple fix:
In function getabsfile(), test _filename explicitly with:
...abspath(_filename is not None or getsourcefile...

In your case, _filename is ''. This is the value returned
from getfile(), when using attribute .co_filename from the
code object.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-20 06:59

Message:
Logged In: YES 
user_id=33168

Confirmed this is bad: 
inspect.getmodule(compile('a=10','','single'))

----------------------------------------------------------------------

Comment By: Connelly (connelly)
Date: 2006-07-20 06:40

Message:
Logged In: YES 
user_id=1039782

I tried pje's Revision 50526 and this still causes infinite recursion with:

>>> inspect.getmodule(compile('a=10','','single'))


----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2006-07-10 19:05

Message:
Logged In: YES 
user_id=56214

Fixed in revision 50526.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-05 01:53

Message:
Logged In: YES 
user_id=33168

Phillip any comments?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1516184&group_id=5470

From noreply at sourceforge.net  Thu Jul 20 18:01:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 20 Jul 2006 09:01:24 -0700
Subject: [ python-Bugs-1525919 ] email package quoted printable behaviour
	changed
Message-ID: <E1G3axl-0000kx-D3@sc8-sf-web6.sourceforge.net>

Bugs item #1525919, was opened at 2006-07-20 16:22
Message generated for change (Comment added) made by thomas_ah
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525919&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Arendsen Hein (thomas_ah)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email package quoted printable behaviour changed

Initial Comment:
from email.Message import Message
from email.Charset import Charset, QP
text = "="
msg = Message()
charset = Charset("utf-8")
charset.header_encoding = QP
charset.body_encoding = QP
msg.set_charset(charset)
msg.set_payload(text)
print msg.as_string()

Gives

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

=3D


With the email package from python2.4.3 and 2.4.4c0 the
last '=3D' becomes just '=', so an extra
msg.body_encode(text) is needed.


----------------------------------------------------------------------

>Comment By: Thomas Arendsen Hein (thomas_ah)
Date: 2006-07-20 18:01

Message:
Logged In: YES 
user_id=839582

One program which got hit by this is MoinMoin, see
http://moinmoin.wikiwikiweb.de/MoinMoinBugs/ResetPasswordEmailImproperlyEncoded


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525919&group_id=5470

From noreply at sourceforge.net  Thu Jul 20 18:14:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 20 Jul 2006 09:14:24 -0700
Subject: [ python-Bugs-1525866 ] Bug in shutil.copytree on Windows
Message-ID: <E1G3bAO-0007SD-RG@sc8-sf-web1.sourceforge.net>

Bugs item #1525866, was opened at 2006-07-20 15:00
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525866&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Foord (mjfoord)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bug in shutil.copytree on Windows

Initial Comment:
The problem is that the call to 'copystat(src, dst)'
was added to the shutil.copytree function, in svn
r38363 probably.  It will fail always on Windows, since
os.utime does not work on directories.

I guess that a patch similar to this one should fix it:

Index: shutil.py
===================================================================
--- shutil.py	(Revision 50710)
+++ shutil.py	(Arbeitskopie)
@@ -127,7 +127,12 @@
         # continue with other files
         except Error, err:
             errors.extend(err.args[0])
-    copystat(src, dst)
+    try:
+        copystat(src, dst)
+    except WindowsError:
+        pass
+    except OSError, err:
+        errors.extend(err.args[0])
     if errors:
         raise Error, errors

----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-07-20 18:14

Message:
Logged In: YES 
user_id=21627

Can you also come up with a patch to the test suite?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525866&group_id=5470

From noreply at sourceforge.net  Thu Jul 20 20:09:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 20 Jul 2006 11:09:05 -0700
Subject: [ python-Bugs-1519816 ] urllib2 proxy does not work in 2.4.3
Message-ID: <E1G3cxN-0002Ig-0a@sc8-sf-web2.sourceforge.net>

Bugs item #1519816, was opened at 2006-07-10 09:29
Message generated for change (Comment added) made by jjlee
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519816&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Michal Niklas (mniklas)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 proxy does not work in 2.4.3

Initial Comment:
My python app had to retrieve some web pages and while 
our network environment requires proxy it uses urllib2 
opener (source is in attachment). It worked very well 
on older Python interpreters:
ActivePython 2.4.2 Build 248 (ActiveState Corp.) based 
on
Python 2.4.2 (#67, Oct 30 2005, 16:11:18) [MSC v.1310 
32 bit (Intel)] on win32

It works on linux with 2.3 and 2.4.1:
Python 2.4.1 (#2, May 5 2005, 11:32:06)
[GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2

But it does not work with newest 2.4.3 on Linux:
Python 2.4.3 (#1, Jul 10 2006, 09:57:52)
[GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2

Desired result:
isof-mark:~# python2.3 proxy_bug.py
trying http://www.python.org ...
OK.  We have reply from http://www.python.org.
Size: 13757 [b]
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 
Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/
xhtml1-transitional.dtd">
<html lang="en" xml:lang="en" xmlns="http://www.w3.org/
1999/xhtml">
<head>
<me
...
 Yorkshire">design by pollenation</a>
</div>
Copyright ???? 1990-2006, <a href="psf">Python Software 
Foundation</a><br />
<a href="about/legal">Legal Statements</a>
</div>
</div>
</div>
</body>
</html>


isof-mark:~# /usr/local/bin/python proxy_bug.py
trying http://www.python.org ...
Traceback (most recent call last):
  File "proxy_bug.py", line 37, in ?
    get_page()
  File "proxy_bug.py", line 27, in get_page
    f = urllib2.urlopen(request)
  File "/usr/local/lib/python2.4/urllib2.py", line 
130, in urlopen
    return _opener.open(url, data)
  File "/usr/local/lib/python2.4/urllib2.py", line 
364, in open
    response = meth(req, response)
  File "/usr/local/lib/python2.4/urllib2.py", line 
471, in http_response
    response = self.parent.error(
  File "/usr/local/lib/python2.4/urllib2.py", line 
402, in error
    return self._call_chain(*args)
  File "/usr/local/lib/python2.4/urllib2.py", line 
337, in _call_chain
    result = func(*args)
  File "/usr/local/lib/python2.4/urllib2.py", line 
480, in http_error_default
    raise HTTPError(req.get_full_url(), code, msg, 
hdrs, fp)
urllib2.HTTPError: HTTP Error 407: Proxy 
Authentication Required

I have raported it on ActiveState bug list (http://
bugs.activestate.com/show_bug.cgi?id=47018) while I 
first spot this bug on their destribution but it seems 
that bug is in others distributions too.

Regards,
Michal Niklas


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2006-07-20 19:09

Message:
Logged In: YES 
user_id=261020

You're sure you didn't copy over the urllib2.py from 2.5b2
also?  That might make the bug appear to go away, when
really it's still there.

The way to be sure is to try it on a different machine.

Thanks for your report.


----------------------------------------------------------------------

Comment By: Michal Niklas (mniklas)
Date: 2006-07-19 12:12

Message:
Logged In: YES 
user_id=226518

I have checked that the last wersion my script works with 
is 2.4.2 and copied that version urllib2.py to 2.4.3 Lib 
directory.  It works again.  The only change in urllib2.py 
is in retry_http_basic_auth(), line 723:
 2.4.2
  user,pw = self.passwd.find_user_password(realm, host)
 2.4.3
  user, pw = self.passwd.find_user_password(realm, 
req.get_full_url())

So "host" is replaced by "req.get_full_url()".

Checked again with 2.5b2 and it works!
Probably I destroyed my test environment and tested
it wrong way :(

So the problem is only with 2.4.3.
Previous versions and 2.5b works well.

Regards,
Michal Niklas


----------------------------------------------------------------------

Comment By: Michal Niklas (mniklas)
Date: 2006-07-13 11:09

Message:
Logged In: YES 
user_id=226518

2.5b2 does not work any better:
Python 2.5b2 (r25b2:50512, Jul 11 2006, 10:16:14) [MSC 
v.1310 32 bit (Intel)] on win32

Result is the same as in 2.5b1 :(


----------------------------------------------------------------------

Comment By: Michal Niklas (mniklas)
Date: 2006-07-11 07:27

Message:
Logged In: YES 
user_id=226518

Tried it with 2.5 beta 1 and it is not better :(

c:\tools\pyscripts\scripts>c:\python25\python2.5
Python 2.5b1 (r25b1:47027, Jun 20 2006, 09:31:33) [MSC 
v.1310 32 bit (Intel)] on win32


c:\tools\pyscripts\scripts>c:\python25\python2.5 
proxy_bug.py
trying http://www.python.org ...
Traceback (most recent call last):
  File "proxy_bug.py", line 37, in <module>
    get_page()
  File "proxy_bug.py", line 27, in get_page
    f = urllib2.urlopen(request)
  File "c:\python25\lib\urllib2.py", line 121, in urlopen
    return _opener.open(url, data)
  File "c:\python25\lib\urllib2.py", line 380, in open
    response = meth(req, response)
  File "c:\python25\lib\urllib2.py", line 491, in 
http_response
    'http', request, response, code, msg, hdrs)
  File "c:\python25\lib\urllib2.py", line 412, in error
    result = self._call_chain(*args)
  File "c:\python25\lib\urllib2.py", line 353, in 
_call_chain
    result = func(*args)
  File "c:\python25\lib\urllib2.py", line 831, in 
http_error_407
    authority, req, headers)
  File "c:\python25\lib\urllib2.py", line 795, in 
http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "c:\python25\lib\urllib2.py", line 805, in 
retry_http_basic_auth
    return self.parent.open(req)
  File "c:\python25\lib\urllib2.py", line 380, in open
    response = meth(req, response)
  File "c:\python25\lib\urllib2.py", line 491, in 
http_response
    'http', request, response, code, msg, hdrs)
  File "c:\python25\lib\urllib2.py", line 418, in error
    return self._call_chain(*args)
  File "c:\python25\lib\urllib2.py", line 353, in 
_call_chain
    result = func(*args)
  File "c:\python25\lib\urllib2.py", line 499, in 
http_error_default
    raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
urllib2.HTTPError: HTTP Error 407: Proxy Authentication 
Required

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-07-10 13:49

Message:
Logged In: YES 
user_id=849994

Can you please try with 2.5b1? A lot of urllib2 related bugs
have been fixed before this release.

----------------------------------------------------------------------

Comment By: Michal Niklas (mniklas)
Date: 2006-07-10 09:41

Message:
Logged In: YES 
user_id=226518

Cannot add attachment via upload so I put it here:
#!/usr/bin/python
# -*- coding: cp1250 -*-

import urllib
import urllib2

def get_page():
	url = 'http://www.python.org'
	print "trying %s ..." % (url)

	# Setup proxy & authentication
	proxy = "poczta.heuthes:8080"
	usr1 = "USER"
	pass1 = "PASSWD"
	proxy_handler = urllib2.ProxyHandler({"http" : "http:/
/" + proxy})
	pass_mgr = urllib2.HTTPPasswordMgrWithDefaultRealm()
	pass_mgr.add_password(None, "http://" + proxy, usr1, 
pass1)
	pass_mgr.add_password(None, proxy, usr1, pass1)
	auth_handler = urllib2.HTTPBasicAuthHandler(pass_mgr)
	proxy_auth_handler = 
urllib2.ProxyBasicAuthHandler(pass_mgr)

	# Now build a new URL opener and install it
	opener = urllib2.build_opener(proxy_handler, 
proxy_auth_handler, auth_handler, urllib2.HTTPHandler)
	urllib2.install_opener(opener)

	request = urllib2.Request(url)
	f = urllib2.urlopen(request)
	data = f.read()
	print "OK.  We have reply from %s.\nSize: %d [b]" % 
(url, len(data))
	if len(data) < 400:
		print data
	else:
		print data[:200]
		print "..."
		print data[-200:]

get_page()


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519816&group_id=5470

From noreply at sourceforge.net  Thu Jul 20 20:22:47 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 20 Jul 2006 11:22:47 -0700
Subject: [ python-Bugs-1346874 ] httplib simply ignores CONTINUE
Message-ID: <E1G3dAd-0005jd-3j@sc8-sf-web6.sourceforge.net>

Bugs item #1346874, was opened at 2005-11-03 12:23
Message generated for change (Comment added) made by jjlee
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346874&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Looijmans (cdwave)
Assigned to: Nobody/Anonymous (nobody)
Summary: httplib simply ignores CONTINUE

Initial Comment:
I bumped into this code in httplib.py HTTPConnection,
begin():

        # read until we get a non-100 response
        while True:
            version, status, reason = self._read_status()
            if status != CONTINUE:
                break
            # skip the header from the 100 response
            while True:
                skip = self.fp.readline().strip()
                if not skip:
                    break
                if self.debuglevel > 0:
                    print "header:", skip

This basically silently eats any 100-continue response
that the server may send to us.
This is not according to the spec - the client should
WAIT for the 100-continue, and then post the data.
Because of this code snippet, it is impossible for a
client to wait for a 100-continue response, since it is
silently eaten by this code.

A correct implementation would be:

- Check the outgoing headers for "Expect: 100-continue"
- If that is present, set an "expectcontinue" flag.
- If the client tries to send data to the connection,
or if the data member was set in the request, wait for
the server to send the 100 response BEFORE sending out
any data at all, if the flag is set.
- If the server fails to send it, the connection will
eventually time out.

I'd be happy to provide an implementation myself, as it
doesn't seem hard to implement and would really help my
project.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2006-07-20 19:22

Message:
Logged In: YES 
user_id=261020

I don't see any violation of RFC 2616 here.  Which part of
the spec., precisely, do you claim is violated?

Still, implementing better 100 Continue handling would be
useful, if done correctly, so go ahead and write that patch!


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-11-04 02:17

Message:
Logged In: YES 
user_id=33168

It's much easier to get a patch integrated since there
should be less work than a bug.  I encourage you to work on
a patch.  

Don't forget that a patch, must do many things:  1) fix the
code, 2) fix (or add!) tests, 3) fix the documentation with
an appropriate \versionchanged (or \versionadded) tag, and
finally 4) update Misc/NEWS.

The old behaviour should generally be backwards compatible
by default when adding new functionality.  If it's a bug, it
may still be desirable to maintain backwards compatibility.
 I don't know enough about HTTP to provide any guidance here.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346874&group_id=5470

From noreply at sourceforge.net  Fri Jul 21 01:27:01 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 20 Jul 2006 16:27:01 -0700
Subject: [ python-Bugs-1524081 ] logging using the SysLog handler fails if
	locale is set
Message-ID: <E1G3hv3-0008B0-73@sc8-sf-web6.sourceforge.net>

Bugs item #1524081, was opened at 2006-07-17 19:33
Message generated for change (Settings changed) made by vsajip
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1524081&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Mihai Ibanescu (misa)
Assigned to: Nobody/Anonymous (nobody)
Summary: logging using the SysLog handler fails if locale is set

Initial Comment:
This affectes b2 and python 2.4 too.
Initially reported here:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=198971

Looking at logging/handlers.py:

Line 635:
self.encodePriority(self.facility,                    
            string.lower(record.levelname)), msg)

Line 611 in encodePriority:
priority = self.priority_names[priority]

priority_names is declared on line 527:
    priority_names = {
        "alert":    LOG_ALERT,
        "crit":     LOG_CRIT,
        ...
        "info":     LOG_INFO,
        ...

Now, if one initializes the locale (i.e. 
locale.setlocale(locale.LC_ALL, "")

and then tries to use the logging module, it will fail
with an exception looking kinda like:

  File "/usr/lib64/python2.4/logging/handlers.py", line
627, in encodePriority
    priority = self.priority_names[priority]
KeyError: 'Info'

if they choose LANG=tr_TR.UTF-8

This happens because in that particular locale,
"INFO".lower() != "info"

----------------------------------------------------------------------

>Comment By: Vinay Sajip (vsajip)
Date: 2006-07-20 23:27

Message:
Logged In: YES 
user_id=308438

Fixed by using a dict to map logging level names to syslog
priority level names. This also facilitates usage when
custom logging levels are present.

Fix is checked into Subversion.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1524081&group_id=5470

From noreply at sourceforge.net  Fri Jul 21 02:10:01 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 20 Jul 2006 17:10:01 -0700
Subject: [ python-Bugs-1526203 ] Win32: subprocess.Popen() w/o "pipe" throws
	an exception
Message-ID: <E1G3iaf-0005Ph-D0@sc8-sf-web3.sourceforge.net>

Bugs item #1526203, was opened at 2006-07-21 00: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=1526203&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Larry Hastings (lhastings)
Assigned to: Nobody/Anonymous (nobody)
Summary: Win32: subprocess.Popen() w/o "pipe" throws an exception

Initial Comment:

This is under Windows (XP).

I have a script which calls subprocess.Popen without
the "pipe=" argument, as so:

--
from subprocess import *
Popen("cmd.exe /c dir") 
--

If I run that with Python 2.5, it throws the following
exception:

Exception exceptions.AttributeError: "'NoneType' object
has no attribute 'append'" in <bound method
Popen.__del__ of <subprocess.Popen object at
0x00C04EB0>> ignored 

The same script run under Python 2.4(.2) does not throw
any exceptions.

Note that this happens with any call to
subprocess.Popen; what process you invoke seems irrelevant.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1526203&group_id=5470

From noreply at sourceforge.net  Fri Jul 21 02:47:53 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 20 Jul 2006 17:47:53 -0700
Subject: [ python-Bugs-1526203 ] Win32: subprocess.Popen() w/o "pipe" throws
	an exception
Message-ID: <E1G3jBJ-0003R2-CA@sc8-sf-web5.sourceforge.net>

Bugs item #1526203, was opened at 2006-07-21 00:10
Message generated for change (Comment added) made by tcdelaney
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1526203&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Larry Hastings (lhastings)
Assigned to: Nobody/Anonymous (nobody)
Summary: Win32: subprocess.Popen() w/o "pipe" throws an exception

Initial Comment:

This is under Windows (XP).

I have a script which calls subprocess.Popen without
the "pipe=" argument, as so:

--
from subprocess import *
Popen("cmd.exe /c dir") 
--

If I run that with Python 2.5, it throws the following
exception:

Exception exceptions.AttributeError: "'NoneType' object
has no attribute 'append'" in <bound method
Popen.__del__ of <subprocess.Popen object at
0x00C04EB0>> ignored 

The same script run under Python 2.4(.2) does not throw
any exceptions.

Note that this happens with any call to
subprocess.Popen; what process you invoke seems irrelevant.

----------------------------------------------------------------------

Comment By: Tim Delaney (tcdelaney)
Date: 2006-07-21 00:47

Message:
Logged In: YES 
user_id=603121

Kevin Jacobs reported it to python-dev with a possible 
patch in:

http://mail.python.org/pipermail/python-dev/2006-
July/067311.html

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1526203&group_id=5470

From noreply at sourceforge.net  Fri Jul 21 07:41:53 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 20 Jul 2006 22:41:53 -0700
Subject: [ python-Bugs-1525589 ] Malloc, memory error, failmalloc, low memory.
Message-ID: <E1G3nlp-00053L-PC@sc8-sf-web5.sourceforge.net>

Bugs item #1525589, was opened at 2006-07-19 16:28
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525589&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Rene Dudfield (illume)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: Malloc, memory error, failmalloc, low memory.

Initial Comment:
The failmalloc library can be used to simulate high
load, low memory conditions.

http://www.nongnu.org/failmalloc/

It reports that python segfaults under some conditions
when memory allocation fails.

"
$ LD_PRELOAD=libfailmalloc.so FAILMALLOC_INTERVAL=10 python
Fatal Python error: Can't initialize 'type'
Aborted
$ LD_PRELOAD=libfailmalloc.so FAILMALLOC_INTERVAL=100
python
Segmentation fault
"

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-20 22:41

Message:
Logged In: YES 
user_id=33168

Committed revision 50743.
Committed revision 50742.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525589&group_id=5470

From noreply at sourceforge.net  Fri Jul 21 07:56:44 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 20 Jul 2006 22:56:44 -0700
Subject: [ python-Bugs-1229788 ] Bus error in extension with gcc 3.3
Message-ID: <E1G3o0C-0005tO-KA@sc8-sf-web1.sourceforge.net>

Bugs item #1229788, was opened at 2005-06-29 08:43
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229788&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gary Robinson (garyrob)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bus error in extension with gcc 3.3

Initial Comment:
This text contains a c module with 4 versions of the same 
extremely simple function. All they do is return a float double to 
python. 

On Windows I have received a report from someone who can built 
the module, imported it into Python, and ran it successfully. 

It has also been reported that there is no problem when the 
extension is compiled with gcc 4.0 on OS X.

However, on OS X, if the extension is compiled with gcc 3.3, the 4th 
of the 4 function results in a bus error:


>>> from check import *
 fun0()
411.0
>>> fun1()
534.30000000000007
>>> fun2()
411.0
>>> fun3()
Bus error


I originally reported this on the C++ sig's mail list. They suggested I 
try dev-python. Scott David Daniels on that list helped me refine 
some 
test cases and verified that they all worked on Windows. 

Along the way it was suggested that I post a bug report. So this is it.

The code follows:

#include "Python.h"
static double value = 411.0;

static PyObject *
fun0(PyObject *self, PyObject *args)
{
    if (!PyArg_ParseTuple(args, "", NULL)) return NULL;
    return Py_BuildValue("d", value);
}

static PyObject *
fun1(PyObject *self, PyObject *args)
{
    return Py_BuildValue("d", 1.3*value);
}

static PyObject *
fun2(PyObject *self, PyObject *args)
{
    return PyFloat_FromDouble(value);
}

static PyObject *
fun3(PyObject *self, PyObject *args)
{
    return Py_BuildValue("d", value);
}


static PyMethodDef TestMethods[] = {
    {"fun0", fun0, METH_VARARGS, "Read args and return value"},
    {"fun1", fun1, METH_VARARGS, "Return value multiplied inline 
by 
1.3"},
    {"fun2", fun2, METH_VARARGS, "Return value using 
PyFloat_FromDouble"},
    {"fun3", fun3, METH_VARARGS, "Return value using 
Py_BuildValue 
without reading args -- causes bus error on OS X Panther with 
XCode 1.5 
installed"},
    {NULL, NULL, 0, NULL}        /* Sentinel */
};

PyMODINIT_FUNC
initcheck(void)
{
    PyObject *module;

    module = Py_InitModule3("check", TestMethods,
		"extension module with three functions.");
    if (module) {
	PyModule_AddStringConstant(module, "__version__", "0.02");
    }
}


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-20 22:56

Message:
Logged In: YES 
user_id=33168

Gary, care to comment?  It's possible there was a bug fix or
two related to alignment of floats.  But if we can't
reproduce this bug, we will have to close it.  Please
respond if you still have this problem within a week or two.

----------------------------------------------------------------------

Comment By: Darryl Dixon (esrever_otua)
Date: 2005-07-12 21:36

Message:
Logged In: YES 
user_id=567623

Bus errors are generally caused by unaligned memory
accesses, or by attempts to read past the end of a
file-descriptor (or something along those lines).  This
sounds like a gcc bug rather than a Python bug.  Can I
suggest changing your compiler flags and experimenting with
things like different -O levels?  (-O3, -O1, etc) to see if
it makes a difference...  Also, you may want to raise a bug
with gcc (although I've no idea how seriously they would
take it :(  ).  Finally, what version of gcc is Python
compiled with on Panther?  There may be a conflict there
(once again, different optimisations might be the problem).

Anyhow, just my random thoughts,
D

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-07-01 20:13

Message:
Logged In: YES 
user_id=593130

I understand that you got advice to post, but I strongly doubt that 
core Python code is involved for three reasons.

1. On the Unix I used, bus errors were much rarer and esoteric 
than segmentation violations (from bad pointers).  But maybe 
BSD-derived OSX is different.

2. The only difference between fun1 that works and fun3 that 
doesn't, seems to be how the arg in computed.  The receiving 
function only gets a value (which it copies) and does not know its 
history.

3. You report that upgrading the compiler fixes the problem.  (So 
why not just do that?)

If you want to experiment more, redo fun1 and fun3 with 'value' 
replaced by its literal value.  Then redo again with value = 
534.30000000000007 instead of 411 and change arg in fun1 to 
value/1.3 instead of 1.3*value.

About stack trace: On unix (of 15 years ago), program crashes 
usually resulted in a file called 'core' added to either the startup 
or current working directory.  A debugger program could extract 
a stack trace, which was more readable if the executable still had 
the symbol table attached and not stripped.  I don't know 
equivalent for OSX, but I found it very helpful for debugging.

----------------------------------------------------------------------

Comment By: Gary Robinson (garyrob)
Date: 2005-06-30 13:15

Message:
Logged In: YES 
user_id=136420

It was reproduced by someone with Python 2.4 and gcc 3.3. So it is not 
my machine.

As to closing it, a couple of people in the python C++ sig and python-dev 
suggested I post it here as a bug, so I did. I'm just doing what was 
requested of me. I don't mind if someone else feels it should be closed 
without doing anything about it, but I don't think everyone would agree with 
that action.

As for stack trace, I don't know how to look for that. All I got was the "bus 
error" message. If you tell me what to look for I'll look for it. 

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-06-30 13:05

Message:
Logged In: YES 
user_id=593130

Do you have any reason to think the bug is in Python rather than 
the older version of gcc?  Or OSX?  Or even your computer?

If not, please consider closing.

Does OSX give you a stack trace?  If so,what is executing when 
the crash occurs?  In fun3, Py_BuildValue, or somehow 
inbewteen?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229788&group_id=5470

From noreply at sourceforge.net  Fri Jul 21 08:00:04 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 20 Jul 2006 23:00:04 -0700
Subject: [ python-Bugs-1526203 ] Win32: subprocess.Popen() w/o "pipe" throws
	an exception
Message-ID: <E1G3o3Q-0007Vr-Ba@sc8-sf-web1.sourceforge.net>

Bugs item #1526203, was opened at 2006-07-21 00:10
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1526203&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Larry Hastings (lhastings)
Assigned to: Nobody/Anonymous (nobody)
Summary: Win32: subprocess.Popen() w/o "pipe" throws an exception

Initial Comment:

This is under Windows (XP).

I have a script which calls subprocess.Popen without
the "pipe=" argument, as so:

--
from subprocess import *
Popen("cmd.exe /c dir") 
--

If I run that with Python 2.5, it throws the following
exception:

Exception exceptions.AttributeError: "'NoneType' object
has no attribute 'append'" in <bound method
Popen.__del__ of <subprocess.Popen object at
0x00C04EB0>> ignored 

The same script run under Python 2.4(.2) does not throw
any exceptions.

Note that this happens with any call to
subprocess.Popen; what process you invoke seems irrelevant.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-21 06:00

Message:
Logged In: YES 
user_id=849994

This was fixed in rev. 50720.

----------------------------------------------------------------------

Comment By: Tim Delaney (tcdelaney)
Date: 2006-07-21 00:47

Message:
Logged In: YES 
user_id=603121

Kevin Jacobs reported it to python-dev with a possible 
patch in:

http://mail.python.org/pipermail/python-dev/2006-
July/067311.html

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1526203&group_id=5470

From noreply at sourceforge.net  Fri Jul 21 09:59:41 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 21 Jul 2006 00:59:41 -0700
Subject: [ python-Bugs-1519816 ] urllib2 proxy does not work in 2.4.3
Message-ID: <E1G3pvB-0004MG-Es@sc8-sf-web5.sourceforge.net>

Bugs item #1519816, was opened at 2006-07-10 10:29
Message generated for change (Comment added) made by mniklas
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519816&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Michal Niklas (mniklas)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 proxy does not work in 2.4.3

Initial Comment:
My python app had to retrieve some web pages and while 
our network environment requires proxy it uses urllib2 
opener (source is in attachment). It worked very well 
on older Python interpreters:
ActivePython 2.4.2 Build 248 (ActiveState Corp.) based 
on
Python 2.4.2 (#67, Oct 30 2005, 16:11:18) [MSC v.1310 
32 bit (Intel)] on win32

It works on linux with 2.3 and 2.4.1:
Python 2.4.1 (#2, May 5 2005, 11:32:06)
[GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2

But it does not work with newest 2.4.3 on Linux:
Python 2.4.3 (#1, Jul 10 2006, 09:57:52)
[GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2

Desired result:
isof-mark:~# python2.3 proxy_bug.py
trying http://www.python.org ...
OK.  We have reply from http://www.python.org.
Size: 13757 [b]
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 
Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/
xhtml1-transitional.dtd">
<html lang="en" xml:lang="en" xmlns="http://www.w3.org/
1999/xhtml">
<head>
<me
...
 Yorkshire">design by pollenation</a>
</div>
Copyright ???? 1990-2006, <a href="psf">Python Software 
Foundation</a><br />
<a href="about/legal">Legal Statements</a>
</div>
</div>
</div>
</body>
</html>


isof-mark:~# /usr/local/bin/python proxy_bug.py
trying http://www.python.org ...
Traceback (most recent call last):
  File "proxy_bug.py", line 37, in ?
    get_page()
  File "proxy_bug.py", line 27, in get_page
    f = urllib2.urlopen(request)
  File "/usr/local/lib/python2.4/urllib2.py", line 
130, in urlopen
    return _opener.open(url, data)
  File "/usr/local/lib/python2.4/urllib2.py", line 
364, in open
    response = meth(req, response)
  File "/usr/local/lib/python2.4/urllib2.py", line 
471, in http_response
    response = self.parent.error(
  File "/usr/local/lib/python2.4/urllib2.py", line 
402, in error
    return self._call_chain(*args)
  File "/usr/local/lib/python2.4/urllib2.py", line 
337, in _call_chain
    result = func(*args)
  File "/usr/local/lib/python2.4/urllib2.py", line 
480, in http_error_default
    raise HTTPError(req.get_full_url(), code, msg, 
hdrs, fp)
urllib2.HTTPError: HTTP Error 407: Proxy 
Authentication Required

I have raported it on ActiveState bug list (http://
bugs.activestate.com/show_bug.cgi?id=47018) while I 
first spot this bug on their destribution but it seems 
that bug is in others distributions too.

Regards,
Michal Niklas


----------------------------------------------------------------------

>Comment By: Michal Niklas (mniklas)
Date: 2006-07-21 09:59

Message:
Logged In: YES 
user_id=226518

I have just installed new virtual machine with Python 2.5b2 
and my program works.  It seems that only 2.4.3 is broken.

Regards,
Michal


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2006-07-20 20:09

Message:
Logged In: YES 
user_id=261020

You're sure you didn't copy over the urllib2.py from 2.5b2
also?  That might make the bug appear to go away, when
really it's still there.

The way to be sure is to try it on a different machine.

Thanks for your report.


----------------------------------------------------------------------

Comment By: Michal Niklas (mniklas)
Date: 2006-07-19 13:12

Message:
Logged In: YES 
user_id=226518

I have checked that the last wersion my script works with 
is 2.4.2 and copied that version urllib2.py to 2.4.3 Lib 
directory.  It works again.  The only change in urllib2.py 
is in retry_http_basic_auth(), line 723:
 2.4.2
  user,pw = self.passwd.find_user_password(realm, host)
 2.4.3
  user, pw = self.passwd.find_user_password(realm, 
req.get_full_url())

So "host" is replaced by "req.get_full_url()".

Checked again with 2.5b2 and it works!
Probably I destroyed my test environment and tested
it wrong way :(

So the problem is only with 2.4.3.
Previous versions and 2.5b works well.

Regards,
Michal Niklas


----------------------------------------------------------------------

Comment By: Michal Niklas (mniklas)
Date: 2006-07-13 12:09

Message:
Logged In: YES 
user_id=226518

2.5b2 does not work any better:
Python 2.5b2 (r25b2:50512, Jul 11 2006, 10:16:14) [MSC 
v.1310 32 bit (Intel)] on win32

Result is the same as in 2.5b1 :(


----------------------------------------------------------------------

Comment By: Michal Niklas (mniklas)
Date: 2006-07-11 08:27

Message:
Logged In: YES 
user_id=226518

Tried it with 2.5 beta 1 and it is not better :(

c:\tools\pyscripts\scripts>c:\python25\python2.5
Python 2.5b1 (r25b1:47027, Jun 20 2006, 09:31:33) [MSC 
v.1310 32 bit (Intel)] on win32


c:\tools\pyscripts\scripts>c:\python25\python2.5 
proxy_bug.py
trying http://www.python.org ...
Traceback (most recent call last):
  File "proxy_bug.py", line 37, in <module>
    get_page()
  File "proxy_bug.py", line 27, in get_page
    f = urllib2.urlopen(request)
  File "c:\python25\lib\urllib2.py", line 121, in urlopen
    return _opener.open(url, data)
  File "c:\python25\lib\urllib2.py", line 380, in open
    response = meth(req, response)
  File "c:\python25\lib\urllib2.py", line 491, in 
http_response
    'http', request, response, code, msg, hdrs)
  File "c:\python25\lib\urllib2.py", line 412, in error
    result = self._call_chain(*args)
  File "c:\python25\lib\urllib2.py", line 353, in 
_call_chain
    result = func(*args)
  File "c:\python25\lib\urllib2.py", line 831, in 
http_error_407
    authority, req, headers)
  File "c:\python25\lib\urllib2.py", line 795, in 
http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "c:\python25\lib\urllib2.py", line 805, in 
retry_http_basic_auth
    return self.parent.open(req)
  File "c:\python25\lib\urllib2.py", line 380, in open
    response = meth(req, response)
  File "c:\python25\lib\urllib2.py", line 491, in 
http_response
    'http', request, response, code, msg, hdrs)
  File "c:\python25\lib\urllib2.py", line 418, in error
    return self._call_chain(*args)
  File "c:\python25\lib\urllib2.py", line 353, in 
_call_chain
    result = func(*args)
  File "c:\python25\lib\urllib2.py", line 499, in 
http_error_default
    raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
urllib2.HTTPError: HTTP Error 407: Proxy Authentication 
Required

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-07-10 14:49

Message:
Logged In: YES 
user_id=849994

Can you please try with 2.5b1? A lot of urllib2 related bugs
have been fixed before this release.

----------------------------------------------------------------------

Comment By: Michal Niklas (mniklas)
Date: 2006-07-10 10:41

Message:
Logged In: YES 
user_id=226518

Cannot add attachment via upload so I put it here:
#!/usr/bin/python
# -*- coding: cp1250 -*-

import urllib
import urllib2

def get_page():
	url = 'http://www.python.org'
	print "trying %s ..." % (url)

	# Setup proxy & authentication
	proxy = "poczta.heuthes:8080"
	usr1 = "USER"
	pass1 = "PASSWD"
	proxy_handler = urllib2.ProxyHandler({"http" : "http:/
/" + proxy})
	pass_mgr = urllib2.HTTPPasswordMgrWithDefaultRealm()
	pass_mgr.add_password(None, "http://" + proxy, usr1, 
pass1)
	pass_mgr.add_password(None, proxy, usr1, pass1)
	auth_handler = urllib2.HTTPBasicAuthHandler(pass_mgr)
	proxy_auth_handler = 
urllib2.ProxyBasicAuthHandler(pass_mgr)

	# Now build a new URL opener and install it
	opener = urllib2.build_opener(proxy_handler, 
proxy_auth_handler, auth_handler, urllib2.HTTPHandler)
	urllib2.install_opener(opener)

	request = urllib2.Request(url)
	f = urllib2.urlopen(request)
	data = f.read()
	print "OK.  We have reply from %s.\nSize: %d [b]" % 
(url, len(data))
	if len(data) < 400:
		print data
	else:
		print data[:200]
		print "..."
		print data[-200:]

get_page()


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519816&group_id=5470

From noreply at sourceforge.net  Fri Jul 21 15:05:41 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 21 Jul 2006 06:05:41 -0700
Subject: [ python-Feature Requests-1474577 ] feature requests for logging lib
Message-ID: <E1G3uhJ-00077d-GP@sc8-sf-web2.sourceforge.net>

Feature Requests item #1474577, was opened at 2006-04-22 09:50
Message generated for change (Settings changed) made by vsajip
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1474577&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
>Status: Pending
>Resolution: Invalid
Priority: 5
Submitted By: blaize rhodes (blaize)
Assigned to: Vinay Sajip (vsajip)
Summary: feature requests for logging lib

Initial Comment:


The logger module interface is a bit broken, I reckon.
 My problems specifically are:
 
	i) It's hard to get access to the LogRecord classes
for customization.
	ii) the semantics of the debug, log, info, etc calls
is a bit strange/confusing...



Here are my proposed fixes:

a)  Add a method 
   Logger.setLogRecordClass( myLogRecordSubClass )

which sets the class that is instantiated in the
makeRecord() fn/method (yes there are two of them).

This would make customizing the LogRecord easier... 
Otherwise (I believe) in order to subclass the
LogRecord you also have to overload the Logger and
possibly the root makeRecord() function as well?  This
bloke's writen up his approach to this (it's doable but
not as nice as it should be).
 
http://qix.it/~ludoo/archive/2004/05/python_logging_customization.html

Another problem is that LogRecords are instantiated in
Logger._log so it's difficult to customize __init__
behaviour for the LogRecord (and I argue that this is a
useful thing)..  

b) A second problem is that the semantics of the log,
info, debug, etc fns is a bit broken.  Currently the
defn looks like this:

  def debug(self, msg, *args, **kwargs):

this suggests to me that a call like this is OK...

  logger.debug("here we go %(foo)s", foo = 'bar')

but it's not.  This is discussed further here...

http://groups.google.com.au/group/comp.lang.python/browse_thread/thread/322919fcac0113ec/98ceaf6fc0c56881?lnk=st&q=python+logging+keywords&rnum=1#98ceaf6fc0c56881

Instead kwargs are used for customizing the behaviour
of the debug method (e.g. exc_info, and extra).  This
seems i) a bit incongrous with its definition and
therefore confusing, and ii) a bit of a hack (it's not
completely insane though when you think about what's
happening under the hood).  Instead I propose using a
couple of calls along the lines of printf/fprintf.  In
my world we'd have a simple printf-style function... 

  def debug(self, msg, *args):  

and a more complex, more easily customizable
fprintf-style one

  def x_debug(self, log_record, msg, *args):  

In these calls *args is a valid argument for the string
formatting operator %, either a tuple of the right
length or a dictionary.  Any customization of the
behaviour of the system can be done (using keyword args
if you wish) in the log_record initializer (an example
will follow).

(Having said that perhaps we can check whether the
first arg to the new simple debug() is a logrecord and
if it is call the (hidden) extended version - that's
more pythonic I imagine)


c) This is not so much a feature request but a
motivating mode of operation that I'd like to be able
to use...

Currently you can set up log filters.  What you can
filter is largely based on what information appears in
the log record.  It'd be nice to filter messages based
on metadata  that you add at log time (i.e. in the
logger.debug(...) method).  Currently it's quite
painfull to set this up.  This is because we can't
customize the initialization of the log_record.  The
call structure in ii) above allows us to setup nice
filtering mechanisms
eg..

class GUIFilter:
   "A filter that only lets messges with gui tags
through."""
	def filter(self, log_record):
	    return hasattr(log_record, 'gui')

# set up a log, and a handler...
log = logging.getLogger(..)
file_handler = FileHandler(..)
log.addHandler(file_handler)
gui_msg_bar_handler = StreamHandler(..)
log.addHandler(gui_msg_bar_handler)
gui_msg_bar_handler.addFilter(GUIFilter())

# msg only goes to the file_handler
log.debug("here we go %s", "here's an arg")  

# msg goes to the file_handler and to the gui_handler.
log.x_debug(LogRecord(gui=True), "what you just tried
to do didn't work %s", "fool")


Change a) could be made with no backward compatability
problems (I can see), change b) could be made without
probs if you didn't overload the existing logging
methods with the new ones, and then deprecate the
existing ones  (though what you'd call the new fns I
don't know).

That said I quite like the logger lib and I use it. 
It's a lot better than anything I would have thought up.


cheers
    blaize



----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2006-05-02 09:11

Message:
Logged In: YES 
user_id=308438

Why does the recent introduction of the 'extra' keyword
argument, meant to allow easily adding extra attributes to
the LogRecord, not meet your use cases? The LogRecord is
meant to be just a handy container and not have much logic
(e.g. it needs to be serialised as XML, pickle etc.); why do
you need to customise LogRecord.__init__? I didn't see an
actual argument above for doing this, please point it out.

It's also the case that the msg argument passed to a logging
call need not be a string; it can be an arbitrary object on
which str() is called at message formatting time to get the
actual format string. So a custom object defining __str__
can return a customised message string.

Perhaps I'm not seeing the use case you have in sufficient
detail to understand why existing functionality does not
meet your needs; please feel free to follow up with more
detailed info.



----------------------------------------------------------------------

Comment By: blaize rhodes (blaize)
Date: 2006-04-22 09:56

Message:
Logged In: YES 
user_id=264689



For readability put an "if __name__ == '__main__':" above the 

# set up a log, and a handler...

line.  Sorry I didn't realize all my whitespace would get
eaten rendering the code ambiguous.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1474577&group_id=5470

From noreply at sourceforge.net  Fri Jul 21 19:18:58 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 21 Jul 2006 10:18:58 -0700
Subject: [ python-Bugs-1526585 ] Concatenation on a long string breaks
Message-ID: <E1G3yeQ-0004Xu-9S@sc8-sf-web6.sourceforge.net>

Bugs item #1526585, was opened at 2006-07-21 13: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=1526585&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Jp Calderone (kuran)
Assigned to: Nobody/Anonymous (nobody)
Summary: Concatenation on a long string breaks

Initial Comment:
Consider this transcript:

exarkun at charm:~/Projects/python/trunk$ ./python
Python 2.5b2 (trunk:50698, Jul 18 2006, 10:08:36)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> x = 'x' * (2 ** 31 - 1)
>>> x = x + 'x'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SystemError: Objects/stringobject.c:4103: bad argument
to internal function
>>> len(x)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'x' is not defined
>>> 


I would expect some exception other than SystemError
and for the locals namespace to not become corrupted.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1526585&group_id=5470

From noreply at sourceforge.net  Sat Jul 22 02:27:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 21 Jul 2006 17:27:05 -0700
Subject: [ python-Bugs-1526785 ] current directory added to sys.path on win32
Message-ID: <E1G45Kj-00079q-2q@sc8-sf-web5.sourceforge.net>

Bugs item #1526785, was opened at 2006-07-22 00: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=1526785&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: John Ehresman (jpe)
Assigned to: Nobody/Anonymous (nobody)
Summary: current directory added to sys.path on win32

Initial Comment:
The current directory at the time python starts is
added to sys.path as the 3rd item (usually), regardless
of whether the python file run is in this directory. 
This is apparently due to getpythonregpath in
getpathp.c returning "" when skiphome is true and there
are 0 subkeys in the registry.  Since this is != NULL,
it is appended to the path after the library zip file
is and later is expanded to the current directory.

Because of this, 'import string' fails when an empty
re.py is in the current directory because this file is
used when string tries to import re.  I know it's not a
good idea to have an empty re.py file, but I can't
control what's on other people's machines.

I've been debugging this in python 2.4, but 2.5 beta 2
seems to have the same behavior.  This fix may be to
set machinepath and userpath to NULL if they are "".

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1526785&group_id=5470

From noreply at sourceforge.net  Sat Jul 22 06:03:47 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 21 Jul 2006 21:03:47 -0700
Subject: [ python-Bugs-1526834 ] unbalanced parentheses from command line
	crash pdb
Message-ID: <E1G48iR-0002RP-Nj@sc8-sf-web5.sourceforge.net>

Bugs item #1526834, was opened at 2006-07-21 21: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=1526834&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Ilya Sandler (isandler)
Assigned to: Nobody/Anonymous (nobody)
Summary: unbalanced parentheses  from command line crash pdb

Initial Comment:
 bagira:~/python-svn/patches> cat simple
 print 123

 bagira:~/python-svn/patches> ../python/trunk/python -m
pdb simple

 (Pdb) b f(                   #crashes your program
 Traceback (most recent call last):
 ...
  File "/home/ilya/python-svn/python/trunk/Lib/sre.py",  
  line 233, in _compile
    raise error, v # invalid expression
 error: unbalanced parenthesis
 Uncaught exception. Entering post mortem debugging

 (Pdb) b f(   # doing it post-mortem fully crashes pdb
 Traceback (most recent call last):
 ..
    raise error, v # invalid expression
 sre_constants.error: unbalanced parenthesis

 bagira:~/python-svn/patches>


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1526834&group_id=5470

From noreply at sourceforge.net  Sat Jul 22 11:00:35 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 22 Jul 2006 02:00:35 -0700
Subject: [ python-Bugs-1526585 ] Concatenation on a long string breaks
Message-ID: <E1G4DLf-0003pW-51@sc8-sf-web2.sourceforge.net>

Bugs item #1526585, was opened at 2006-07-21 18:18
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1526585&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Jp Calderone (kuran)
Assigned to: Nobody/Anonymous (nobody)
Summary: Concatenation on a long string breaks

Initial Comment:
Consider this transcript:

exarkun at charm:~/Projects/python/trunk$ ./python
Python 2.5b2 (trunk:50698, Jul 18 2006, 10:08:36)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> x = 'x' * (2 ** 31 - 1)
>>> x = x + 'x'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SystemError: Objects/stringobject.c:4103: bad argument
to internal function
>>> len(x)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'x' is not defined
>>> 


I would expect some exception other than SystemError
and for the locals namespace to not become corrupted.


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2006-07-22 10:00

Message:
Logged In: YES 
user_id=6656

Confirmed with 2.4.  Ouch.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1526585&group_id=5470

From noreply at sourceforge.net  Sat Jul 22 16:11:20 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 22 Jul 2006 07:11:20 -0700
Subject: [ python-Bugs-1526585 ] Concatenation on a long string breaks
Message-ID: <E1G4ICO-0003H0-Ej@sc8-sf-web2.sourceforge.net>

Bugs item #1526585, was opened at 2006-07-21 13: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=1526585&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Jp Calderone (kuran)
Assigned to: Nobody/Anonymous (nobody)
Summary: Concatenation on a long string breaks

Initial Comment:
Consider this transcript:

exarkun at charm:~/Projects/python/trunk$ ./python
Python 2.5b2 (trunk:50698, Jul 18 2006, 10:08:36)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> x = 'x' * (2 ** 31 - 1)
>>> x = x + 'x'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SystemError: Objects/stringobject.c:4103: bad argument
to internal function
>>> len(x)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'x' is not defined
>>> 


I would expect some exception other than SystemError
and for the locals namespace to not become corrupted.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-07-22 10:11

Message:
Logged In: YES 
user_id=31435

Part of the problem appears to be that ceval.c's
string_concatenate() doesn't check for overflow in the
second argument here:

if (_PyString_Resize(&v, v_len + w_len) != 0)

The Windows malloc on my box returns NULL (and so Python
raises MemoryError) on the initial:

x = 'x' * (2 ** 31 - 1)

attempt, so I never get that far.  I'm afraid this is
muddier in strange ways on Linux because the Linux malloc()
is pathologically optimistic (can return a non-NULL value
pointing at "memory" that can't actually be used for anything).

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2006-07-22 05:00

Message:
Logged In: YES 
user_id=6656

Confirmed with 2.4.  Ouch.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1526585&group_id=5470

From noreply at sourceforge.net  Sat Jul 22 19:46:44 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 22 Jul 2006 10:46:44 -0700
Subject: [ python-Bugs-1472251 ] pdb 'run' crashes when the it's first
	argument is non-string
Message-ID: <E1G4LYq-0000lp-Ur@sc8-sf-web6.sourceforge.net>

Bugs item #1472251, was opened at 2006-04-18 05:16
Message generated for change (Comment added) made by isandler
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472251&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 3
Submitted By: Kuba Ko??czyk (jakamkon)
Assigned to: Nobody/Anonymous (nobody)
Summary: pdb 'run' crashes when the it's first argument is non-string

Initial Comment:
Pdb 'run/runeval' commands fails to check the type of
given argument.When argument to 'run/runeval' is
non-string the functions crashes with further
impilications on (correctly)invoking this functions: 

Python 2.5a1 (trunk:45527, Apr 18 2006, 11:12:31)

>>> def x(): pass
>>> import pdb
>>> pdb.run(x())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/jkk/python/python-svn/Lib/pdb.py", line
1113, in run
    Pdb().run(statement, globals, locals)
  File "/home/jkk/python/python-svn/Lib/bdb.py", line
363, in run
    cmd = cmd+'\n'
TypeError: unsupported operand type(s) for +:
'NoneType' and 'str'
>>> pdb.run('x()')
> /home/jkk/python/python-svn/Lib/pdb.py(1113)run()
-> Pdb().run(statement, globals, locals)
(Pdb)
# CTRL-D pressed
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/jkk/python/python-svn/Lib/pdb.py", line
1113, in run
    Pdb().run(statement, globals, locals)
  File "/home/jkk/python/python-svn/Lib/pdb.py", line
1113, in run
    Pdb().run(statement, globals, locals)
  File "/home/jkk/python/python-svn/Lib/bdb.py", line
48, in trace_dispatch
    return self.dispatch_line(frame)
  File "/home/jkk/python/python-svn/Lib/bdb.py", line
67, in dispatch_line
    if self.quitting: raise BdbQuit
bdb.BdbQuit

The solution is to simply ensure that the first
argument passed to the 'run/runeval' functions is string.

----------------------------------------------------------------------

Comment By: Ilya Sandler (isandler)
Date: 2006-07-22 10:46

Message:
Logged In: YES 
user_id=971153

>> Is your comment directly related to this bug?

Yes, my suggestion was to call settrace() after 

  cmd = cmd+'\n'

which should solve the original (bdb leaving tracing on)
problem.. Your latest suggestion would do the same thing by
different means..

However, I think there an even better way: can we simply remove

-    if not isinstance(cmd, types.CodeType):
-        cmd = cmd+'\n'

from bdb.py???

This would both solve the original problem and make error
message more meaningful IMO..

 > exec: arg 1 must be a string, file, or code object

Rather than:

 >Unsupported operand type(s) for +: 'NoneType' and 'str'

This seems to work for me, would you be interested in
testing and submitting a patch for this?


A bit more information: it appears that older versions of
python in some cases required string passed to exec to end
with '\n', this was even mentioned in python FAQ.. E.g if I
feed  
  
 exec 'for i in range(4):\nx=i'

into python2.1, I get a Syntax error..

However, this does work in python2.3.3, 2.4,2.5...

So was this + '\n' indeed a workaround for a deficiency in exec?





apparently older versions of python required the string
passed to exec to end with '\n'. It was even mentioned in
older FAQs... However, latest versions of python seem to
accept strings without new line... Eg. even

----------------------------------------------------------------------

Comment By: Kuba Ko??czyk (jakamkon)
Date: 2006-07-11 08:02

Message:
Logged In: YES 
user_id=1491175

Simple solution is to catch TypeError in bdb's run function:
         try:
            if not isinstance(cmd, types.CodeType):
                    cmd = cmd+'\n'
         except TypeError:
                    pass

Now it seems that handling nonstring arguments is better:

>>> import pdb
>>> def x():pass
...
>>> pdb.run(x())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/jkk/python-svn/Lib/pdb.py", line 1122, in run
    Pdb().run(statement, globals, locals)
  File "/home/jkk/python-svn/Lib/bdb.py", line 369, in run
    exec cmd in globals, locals
TypeError: exec: arg 1 must be a string, file, or code object
>>> pdb.run('x()')
> <string>(1)<module>()
(Pdb) x
<function x at 0x4024a9cc>
(Pdb) pdb.run('x()')
(Pdb)
>>>



----------------------------------------------------------------------

Comment By: Kuba Ko??czyk (jakamkon)
Date: 2006-07-11 07:02

Message:
Logged In: YES 
user_id=1491175

Is your comment directly related to this bug?
Maybe you should create separete bug tracker item to discuss
problem presented in your comment?

----------------------------------------------------------------------

Comment By: Ilya Sandler (isandler)
Date: 2006-06-25 11:54

Message:
Logged In: YES 
user_id=971153

I have looked at what's happening in a bit more detail and
now I agree that the current behaviour seems wrong.

Apparently, when one passes a nonstring to bdb's run(), bdb
sets tracing first and only then throws an exception...
Leaving tracing on seems like a bad thing to do 

Would calling settrace() a couple lines later be the
simplest solution then?

so relevant fragment of  bdb.py's run() becomes:
        if not isinstance(cmd, types.CodeType):
            cmd = cmd+'\n'
        sys.settrace(self.trace_dispatch)

This should prevent bdb from turning tracing too early.
What do you think?

----------------------------------------------------------------------

Comment By: Kuba Ko??czyk (jakamkon)
Date: 2006-06-19 06:48

Message:
Logged In: YES 
user_id=1491175

You're right,but don't you think that this kind of switching
between namespaces could confuse users?

----------------------------------------------------------------------

Comment By: Ilya Sandler (isandler)
Date: 2006-05-22 20:36

Message:
Logged In: YES 
user_id=971153


Well, I don't see anything in bdb's run which could
overwrite your namespace..

What seems to be happenning in your example is that bdb's
first line event happens while bdb is still in run(), so you
when you see pdb's prompt, are in bdb's namespace not in
yours.. If you do "next" you will get where you should be..

 bagira:~> python2.4
 Python 2.4.1 (#2, May  5 2005, 11:32:06) 
 >>> def x(): print "in x"
 >>> import pdb
 >>> pdb.run( x())
 in x
 TypeError: unsupported operand type(s) for +: 'NoneType'
and 'str'
 >>> pdb.run( 'x()' )
 > /usr/lib/python2.4/pdb.py(987)run()
 -> Pdb().run(statement, globals, locals)
 (Pdb) n          #now you are back in your namespace
 > <string>(1)?()
 (Pdb) p x        #and you get your symbols back
 <function x at 0x4021be2c>
 (Pdb) p pdb
 <module 'pdb' from '/usr/lib/python2.4/pdb.pyc'>
 (Pdb) n
 in x
 --Return--
 > <string>(1)?()->None


What do you think?

----------------------------------------------------------------------

Comment By: Kuba Ko??czyk (jakamkon)
Date: 2006-05-22 02:20

Message:
Logged In: YES 
user_id=1491175

The point is that when you want to invoke pdb.run correctly
(with string argument) after getting TypeError as in above
example,
your namespace is probably overwritten or deleted so that
you don't have access to previously defined symbols.

>>> def x():pass
>>> import pdb
>>> pdb.run(x())
TypeError
>>> pdb.run('x()')
> /home/jkk/python-svn/Lib/pdb.py(1122)run()
-> Pdb().run(statement, globals, locals)
(Pdb) pdb
*** NameError: name 'pdb' is not defined
(Pdb) x
*** NameError: name 'x' is not defined


----------------------------------------------------------------------

Comment By: Ilya Sandler (isandler)
Date: 2006-05-21 16:25

Message:
Logged In: YES 
user_id=971153


I would not classify your example as a crash. You passed a
wrong value (None in your case) into pdb.run() and got back
a TypeError...Isn't it an expected response?

E.g if you do:  >>>max(13)

You'll also get: "TypeError"


Am I missing something? Could you clarify?



----------------------------------------------------------------------

Comment By: Kuba Ko??czyk (jakamkon)
Date: 2006-04-18 05:36

Message:
Logged In: YES 
user_id=1491175

Patch is in #1472257

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472251&group_id=5470

From noreply at sourceforge.net  Sat Jul 22 23:23:52 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 22 Jul 2006 14:23:52 -0700
Subject: [ python-Bugs-1517996 ] IDLE (macosx): Class and Path browsers show
	Tk menu
Message-ID: <E1G4Owy-0001ID-E8@sc8-sf-web1.sourceforge.net>

Bugs item #1517996, was opened at 2006-07-06 04:34
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517996&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
>Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: IDLE (macosx): Class and Path browsers show Tk menu

Initial Comment:
I've done some work on fixing the menus for IDLE before 2.5b1, but 
recently found more toplevel windows that don't have their own menu.

Both the Path Browser and Class Browser don't have a menubar of their 
own. The Tk implementation on MacOSX won't accept an empty menubar, 
but will replace that by a generic Tk menubar.

----------------------------------------------------------------------

>Comment By: Kurt B. Kaiser (kbk)
Date: 2006-07-22 17:23

Message:
Logged In: YES 
user_id=149084

> Tk uses the per-window menu for the currently
> selected window

I assume you mean AquaTk uses the per-window...

Please put in a bug request on AquaTk to get it
to conform to how Tk handles this menu on Linux
and Windows.  Then downgrade the priority of this
bug or close it.

Does the debugger have the same problem?

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-18 08:20

Message:
Logged In: YES 
user_id=580910

These menu problems are at the very root caused by differences in the way 
menus work on OSX (one application wide menu at the top of the screen) and 
most other systems (optional menus for every window).  Applications on OSX 
must have some kind of menu (or be full-screen, but we don't want that for 
IDLE), Tk uses the per-window menu for the currently selected window for 
that. If a window doesn't have a menu it makes up one and I haven't found a 
way yet to override that menu (which would solve that problem once and for 
all).

I do believe that my other changes really are good, they make IDLE perform 
more like a true OSX application. This is important because IDLE is the default 
IDE, and hence probably the first thing naive OSX users will see of python.

BTW. AquaTk really sucks, which makes it annoyingly hard to create a really 
good OSX citizen of IDLE and I have given up on getting there. If I understand 
the lazyweb correctly you're supposed to port your appliations to some other 
GUI library (Tile?) to get a native L&F for lots of widgets and standard dialogs.

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2006-07-15 15:51

Message:
Logged In: YES 
user_id=149084

I suppose this is also true for the debugger?

I'd consider this a bug in OSX Tk, it should be
reported there.

Without a specific need for a menubar, all it does
is take up valuable vertical space.  And continuing
to add OSX special casing clutters up the IDLE code;
IMO it should be limited to situations where
functionality is compromised.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517996&group_id=5470

From noreply at sourceforge.net  Sat Jul 22 23:50:19 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 22 Jul 2006 14:50:19 -0700
Subject: [ python-Bugs-768481 ] Column Number is not visible in MacOSX
Message-ID: <E1G4PMZ-0002Z9-OW@sc8-sf-web5.sourceforge.net>

Bugs item #768481, was opened at 2003-07-09 10:11
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768481&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 3
Submitted By: Tiago Castro Henriques (tiagoh)
>Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: Column Number is not visible in MacOSX

Initial Comment:
I'm running IDLE under MacOSX 10.2.6 using Python 2.3b2.

Using Apple's X11 beta 3 version, the column number,
which should appear in the lower right-hand corner, is
not visible. It is obscured by the Aqua resize widget
which is always anchored to the lower right-hand corner.

The column number becomes briefly visible when the IDLE
window is resized, only to be obscured again when the
final redraw is performed.

----------------------------------------------------------------------

>Comment By: Kurt B. Kaiser (kbk)
Date: 2006-07-22 17:50

Message:
Logged In: YES 
user_id=149084

Rev 46859, Ronald Oussoren

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768481&group_id=5470

From noreply at sourceforge.net  Sat Jul 22 23:52:18 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 22 Jul 2006 14:52:18 -0700
Subject: [ python-Bugs-775535 ] Tooltip-window doesn't vanish if...
Message-ID: <E1G4POU-0000Bm-RP@sc8-sf-web3.sourceforge.net>

Bugs item #775535, was opened at 2003-07-22 05:14
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775535&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Gregor Lingl (glingl)
Assigned to: Kurt B. Kaiser (kbk)
Summary: Tooltip-window doesn't vanish if...

Initial Comment:
When entering in the shell window of IDLE:

&gt;&gt;&gt; len(

a tooltip-window appears with content
   
len(object) -&gt; integer

Now, when deleting these four characters (or at least
the opening parentheses) the tooltip-window remains open.

I can enter other expressions, writing even behind this
tooltip-window and it vanishes only

- when clicking the shell-window with the mouse
- when minimizing and remaximizing the shell-window
- wehn using another function call and typing a new
opening parentheses.

It should vanish immediately, when the opening parentheses 
is deleted.

Regards, Gregor

----------------------------------------------------------------------

>Comment By: Kurt B. Kaiser (kbk)
Date: 2006-07-22 17:52

Message:
Logged In: YES 
user_id=149084

Fixed by 'syntax' patch, Rev 41480

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2003-07-23 01:20

Message:
Logged In: YES 
user_id=149084

Related to IDLEfork Bug 683123: ESC doesn't
close the call tip.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775535&group_id=5470

From noreply at sourceforge.net  Sat Jul 22 23:56:11 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 22 Jul 2006 14:56:11 -0700
Subject: [ python-Bugs-791968 ] Arguments tooltip wrong if def contains tuple
Message-ID: <E1G4PSF-0000ZJ-JS@sc8-sf-web3.sourceforge.net>

Bugs item #791968, was opened at 2003-08-20 11:16
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=791968&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Christos Georgiou (tzot)
Assigned to: Kurt B. Kaiser (kbk)
Summary: Arguments tooltip wrong if def contains tuple

Initial Comment:
This happens in IDLE on Windows 2000, from 2.3 EXE 
installer.  Type the following:

&gt;&gt;&gt; def f((a,b), c):
	print a, b, c

&gt;&gt;&gt; f(

The tooltip shows up containing the following exact 
string (but the triple quotes):
&quot;&quot;&quot;(.0, c)&quot;&quot;&quot;


----------------------------------------------------------------------

>Comment By: Kurt B. Kaiser (kbk)
Date: 2006-07-22 17:56

Message:
Logged In: YES 
user_id=149084

Problem still exists in 2.5 as of Rev 50739.

----------------------------------------------------------------------

Comment By: Christos Georgiou (tzot)
Date: 2003-08-20 12:02

Message:
Logged In: YES 
user_id=539787

I tried this:

def f((a,b), c, (d,e)): pass

and f.func_code.co_varnames is

('.0', 'c', '.4', 'a', 'b', 'd', 'e')

That means .0 and .4 are dummy placeholders for the 
argument tuples.  I couldn't find a direct way to know the 
length of each tuple, though --unless one analyzes the first 
UNPACK_SEQUENCE bytecodes of fob.func_code.co_code, 
and then uses the tuple fob.func_code.co_varnames
[fob.func_code.co_argcount:] to recreate the tuples; should 
we get into this trouble, or just do a regular expression 
replace a la:

argText = &quot;(%s)&quot; % re.sub(&quot;\.\d+&quot;, &quot;&lt;tuple&gt;&quot;, argText)

at line 144?

----------------------------------------------------------------------

Comment By: Christos Georgiou (tzot)
Date: 2003-08-20 11:44

Message:
Logged In: YES 
user_id=539787

Quite fast, Neal! :)
It seems it's not exactly an IDLE bug; check ToolTip.py, line 
134 (vanilla 2.3); it's the f.func_code.co_varnames that 
returns this tuple:
('.0', 'c', 'a', 'b')

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=791968&group_id=5470

From noreply at sourceforge.net  Sun Jul 23 04:27:31 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 22 Jul 2006 19:27:31 -0700
Subject: [ python-Bugs-1501330 ] failure of test_ossaudiodev;
	elapsed time .1 sec faster
Message-ID: <E1G4Tgp-0000UL-UI@sc8-sf-web3.sourceforge.net>

Bugs item #1501330, was opened at 2006-06-05 20:23
Message generated for change (Comment added) made by gward
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501330&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Brett Cannon (bcannon)
Assigned to: Greg Ward (gward)
Summary: failure of test_ossaudiodev; elapsed time .1 sec faster

Initial Comment:
I am getting a consistent failure of test_ossaudiodev
on Ubuntu Hoary on an HP xw4300 Workstation.  The
failure is that the test is printing out "elapsed time:
3.0 sec" while the test expects 3.1 sec.

I don't know anything about sound recordings so I don't
know if there is any way to calculate the expected
length of the test sound file and thus know that this
is a true error or the test is just working faster than
normally expected.

----------------------------------------------------------------------

>Comment By: Greg Ward (gward)
Date: 2006-07-22 22:27

Message:
Logged In: YES 
user_id=14422

Fixed in r50775 using the patch I attached earlier.


----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2006-06-12 14:09

Message:
Logged In: YES 
user_id=357491

Output with the patch:

playing test sound file (expected running time: 2.93 sec)
actual running time was 3.09 sec (5.5% difference)

----------------------------------------------------------------------

Comment By: Greg Ward (gward)
Date: 2006-06-11 12:54

Message:
Logged In: YES 
user_id=14422

Brett -- I'm not sure why I put 3.1 sec in there.  It's
probably just what popped out the first time I ran this test
on my machine.  Anyways, simple math reveals that the
theoretical running time of the test file is ~2.93 sec:

  (23493 bytes) / (1 byte/sample) / (8000 samples/sec) =
2.93 sec

which of course ignores the overhead of the file header, but
that seems to pretty small.  "sox" agrees:

$ time /usr/bin/play Lib/test/audiotest.au

Input Filename : Lib/test/audiotest.au
Sample Size    : 8-bits
Sample Encoding: u-law
Channels       : 1
Sample Rate    : 8000

Time: 00:02.93 [00:00.00] of 00:02.93 ( 100.0%) Output
Buffer:  23.46K

Done.
/usr/bin/play Lib/test/audiotest.au  0.03s user 0.02s system
1% cpu 3.127 total

Can you try that on your machine and put the output here?

Anyways, the likely culprits are 1) faster hardware (less
overhead opening audio device, reading file, etc) and 2)
variations in sound chip frequency (8000 Hz is not always
exactly 8000 Hz).  I'll try to fix the test so it's a little
fuzzier.


----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-06-07 09:04

Message:
Logged In: YES 
user_id=11375

Yes, the length is calculable -- you have N bytes in the
file, with so many bits per sample and so many samples per
second.  Perhaps the driver now buffers more and the write()
returns earlier?  Or you could try printing the exact
duration without rounding; maybe it's 3.0999999 or something
and the print is just truncating.


Assigning to Greg Ward, in case he gets around to looking at it.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501330&group_id=5470

From noreply at sourceforge.net  Sun Jul 23 06:20:38 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 22 Jul 2006 21:20:38 -0700
Subject: [ python-Bugs-1027566 ] Argument missing from calltip for new-style
	class init
Message-ID: <E1G4VSI-0003tn-NQ@sc8-sf-web5.sourceforge.net>

Bugs item #1027566, was opened at 2004-09-13 18:17
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1027566&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Loren Guthrie (lguthrie)
Assigned to: Kurt B. Kaiser (kbk)
Summary: Argument missing from calltip for new-style class init

Initial Comment:
The calltip for __init__ on new-style classes doesn't
show the arguments like it does for old-style classes.

>>> import idlelib.CallTips
>>> class OldClass:
... 	"""Old-style class"""
... 	def __init__(self, x):
... 		self.x = x
... 
>>> idlelib.CallTips.get_arg_text(OldClass)
'(x)\nOld-style class'
>>> class NewClass(object):
... 	"""New-style class"""
... 	def __init__(self, x):
... 		self.x = x
... 
>>> idlelib.CallTips.get_arg_text(NewClass)
'New-style class'

Changing CallTips.py line 134 (in get_arg_text) from
if type(ob)==types.ClassType:
to
if type(ob) in [types.ClassType, types.TypeType]:

SEEMS to fix the problem, but I have no idea what
side-effects this might have.

----------------------------------------------------------------------

>Comment By: Kurt B. Kaiser (kbk)
Date: 2006-07-23 00:20

Message:
Logged In: YES 
user_id=149084

Rev 50776.  Thanks for the patch!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1027566&group_id=5470

From noreply at sourceforge.net  Sun Jul 23 07:07:37 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 22 Jul 2006 22:07:37 -0700
Subject: [ python-Bugs-1482122 ] Shift+Backspace exhibits odd behavior
Message-ID: <E1G4WBl-0000ne-A8@sc8-sf-web6.sourceforge.net>

Bugs item #1482122, was opened at 2006-05-04 16:48
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1482122&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Tkinter
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: NothingCanFulfill (ncf)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Shift+Backspace exhibits odd behavior

Initial Comment:
On Windows, pressing Shift+Backspace while in an editor
window will act just like a regular Backspace will,
however under Linux (Gentoo 2006.0 and
Slackware-current), instead of deleting the caracter
before the cursor, it inserts "^B".

Correct me if I'm wrong, but I don't think it'd be too
hard to fix this little annoyance.

(I would do it myself, but I'm not at all familiar with
IDLE's source layout)

----------------------------------------------------------------------

>Comment By: Kurt B. Kaiser (kbk)
Date: 2006-07-23 01:07

Message:
Logged In: YES 
user_id=149084

Can't fix in IDLE by binding Shift-Key-BackSpace.

Using Python interpreter:

>>> import Tkinter
>>> root = Tkinter.Tk()
>>> text = Tkinter.Text()
>>> text.pack()

and try typing some char followed by
backspace and shift-backspace.

In Tcl shift-backspace works correctly.

Not an IDLE issue, appparently a Tkinter issue.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-05 03:03

Message:
Logged In: YES 
user_id=33168

Right now there aren't a lot of IDLE developers.  It would
be great if you could work on a patch.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1482122&group_id=5470

From noreply at sourceforge.net  Sun Jul 23 07:33:26 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 22 Jul 2006 22:33:26 -0700
Subject: [ python-Bugs-1436532 ] length of unicode string changes print
	behaviour
Message-ID: <E1G4Wak-0000tV-Co@sc8-sf-web3.sourceforge.net>

Bugs item #1436532, was opened at 2006-02-22 04:45
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436532&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: James (hover_boy)
>Assigned to: Martin v. L??wis (loewis)
Summary: length of unicode string changes print behaviour

Initial Comment:
Python 2.4.2 and IDLE (with Courier New font) on XP 
and the following code saved as a UTF-8 file 

if __name__ == "__main__": 
    print "??? ??? ??? ??? ??? ??? ?
? ??? ?
?" 
    print "??? ??? ??? ??? ??? ??? ?
? ??? ?
? ??? ??? "

results in...

IDLE 1.1.2 
>>> ================================ RESTART 
================================ 
>>> 
??????? ??????? ?????? ??????? ???????? ??????? ??????????? ??????? 
??? ??? ??? ??? ??? ??? ?
? ??? ?
? ??? ??? 
>>> 





----------------------------------------------------------------------

>Comment By: Kurt B. Kaiser (kbk)
Date: 2006-07-23 01:33

Message:
Logged In: YES 
user_id=149084

I don't have a font installed which will print
those characters.  When I load your sample file,
I see print statements which include unicode
characters like \u5341.  The printed output
contains the same unicode characters as the
input program.  Maybe Martin has an idea.

----------------------------------------------------------------------

Comment By: James (hover_boy)
Date: 2006-03-22 10:21

Message:
Logged In: YES 
user_id=1458491

I've attached an example file to demonstrate the problem 
better.

it seems not to be the length but something else which I 
haven't figured out yet.

I've also added the encoding comment and also tried 
changing the default encoding in sitecustomize.py from latin
-1 to utf-8 but neither seem to work.

thanks,

James.

XP professional, SP2, english


----------------------------------------------------------------------

Comment By: James (hover_boy)
Date: 2006-03-22 10:12

Message:
Logged In: YES 
user_id=1458491




----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2006-03-05 20:44

Message:
Logged In: YES 
user_id=593130

I am fairly ignorant of unicode and encodings, but I am 
surprised you got anything coherent without an encoding 
cookie comment at the top (see manual).  Have you tried 
that?  Other questions that might help someone answer:

What specific XP version?  SP2 installed? Country version?
Your results for
>>> sys.getdefaultencoding()
'ascii'
>>> sys.getfilesystemencoding()
'mbcs'
What happens if you reverse the order of the print 
statements?  (Ie, is it really the shorter string that 
does not work or just the first?)

I don't know enough to know if this is really a bug.  If 
you don't get an answer here, you might try for more info 
on python-list/comp.lang.python

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436532&group_id=5470

From noreply at sourceforge.net  Sun Jul 23 09:26:20 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 23 Jul 2006 00:26:20 -0700
Subject: [ python-Bugs-1517996 ] IDLE (macosx): Class and Path browsers show
	Tk menu
Message-ID: <E1G4YM0-0000xF-Mt@sc8-sf-web5.sourceforge.net>

Bugs item #1517996, was opened at 2006-07-06 10:34
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517996&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.5
Status: Open
Resolution: None
>Priority: 4
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: IDLE (macosx): Class and Path browsers show Tk menu

Initial Comment:
I've done some work on fixing the menus for IDLE before 2.5b1, but 
recently found more toplevel windows that don't have their own menu.

Both the Path Browser and Class Browser don't have a menubar of their 
own. The Tk implementation on MacOSX won't accept an empty menubar, 
but will replace that by a generic Tk menubar.

----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-23 09:26

Message:
Logged In: YES 
user_id=580910

Yes I mean AquaTk. The debugger has the same problem (as expected because 
it doesn't define its own menu)

The behaviour of AquaTk is a feature, not a bug. Appearently the default menu 
is inheritted from the root ("."). I'll see if I can override that menu in 
macosxSupport.setupApp.

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2006-07-22 23:23

Message:
Logged In: YES 
user_id=149084

> Tk uses the per-window menu for the currently
> selected window

I assume you mean AquaTk uses the per-window...

Please put in a bug request on AquaTk to get it
to conform to how Tk handles this menu on Linux
and Windows.  Then downgrade the priority of this
bug or close it.

Does the debugger have the same problem?

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-18 14:20

Message:
Logged In: YES 
user_id=580910

These menu problems are at the very root caused by differences in the way 
menus work on OSX (one application wide menu at the top of the screen) and 
most other systems (optional menus for every window).  Applications on OSX 
must have some kind of menu (or be full-screen, but we don't want that for 
IDLE), Tk uses the per-window menu for the currently selected window for 
that. If a window doesn't have a menu it makes up one and I haven't found a 
way yet to override that menu (which would solve that problem once and for 
all).

I do believe that my other changes really are good, they make IDLE perform 
more like a true OSX application. This is important because IDLE is the default 
IDE, and hence probably the first thing naive OSX users will see of python.

BTW. AquaTk really sucks, which makes it annoyingly hard to create a really 
good OSX citizen of IDLE and I have given up on getting there. If I understand 
the lazyweb correctly you're supposed to port your appliations to some other 
GUI library (Tile?) to get a native L&F for lots of widgets and standard dialogs.

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2006-07-15 21:51

Message:
Logged In: YES 
user_id=149084

I suppose this is also true for the debugger?

I'd consider this a bug in OSX Tk, it should be
reported there.

Without a specific need for a menubar, all it does
is take up valuable vertical space.  And continuing
to add OSX special casing clutters up the IDLE code;
IMO it should be limited to situations where
functionality is compromised.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517996&group_id=5470

From noreply at sourceforge.net  Sun Jul 23 11:31:28 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 23 Jul 2006 02:31:28 -0700
Subject: [ python-Bugs-1525447 ] Build fails on OS X with case sensitive fs
Message-ID: <E1G4aJ6-0005S7-2s@sc8-sf-web5.sourceforge.net>

Bugs item #1525447, was opened at 2006-07-19 19:24
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525447&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 6
Submitted By: gideon may (gdm)
>Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: Build fails on OS X with case sensitive fs

Initial Comment:
When compiling python from svn on a Mac OS X with a 
case sensitive file system I get the following build
error:

running build
running build_ext
db.h: found (4, 3) in /opt/local/include/db4
db lib: using (4, 3) db-4.3
sqlite: found /usr/include/sqlite3.h
/usr/include/sqlite3.h: version 3.1.3
Traceback (most recent call last):
  File "./setup.py", line 1507, in <module>
    main()
.
.
  File "./setup.py", line 1088, in addMacExtension
    raise RuntimeError("%s not found" % name)
RuntimeError: MacOS not found
make: *** [sharedmods] Error 1




It can be fixed by either renaming the file:
  Mac/Modules/macosmodule.c 
to
  Mac/Modules/MacOSmodule.c 

or applying the following patch :
Index: setup.py
===================================================================
--- setup.py    (revision 50687)
+++ setup.py    (working copy)
@@ -1101,7 +1101,7 @@
             carbon_kwds = {'extra_compile_args':
carbon_extra_compile_args,
                            'extra_link_args':
['-framework', 'Carbon'],
                           }
-            CARBON_EXTS = ['ColorPicker', 'gestalt',
'MacOS', 'Nav',
+            CARBON_EXTS = ['ColorPicker', 'gestalt',
'macos', 'Nav',
                            'OSATerminology', 'icglue',
                            # All these are in subdirs
                            '_AE', '_AH', '_App',
'_CarbonEvt', '_Cm', '_Ctl',


Cheers,

Gideon



----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-23 11:31

Message:
Logged In: YES 
user_id=580910

The patch is incorrect, as this would rename user visible name of the python 
extension ('import MacOS' would stop working). 

The rename would be correct.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525447&group_id=5470

From noreply at sourceforge.net  Sun Jul 23 11:35:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 23 Jul 2006 02:35:24 -0700
Subject: [ python-Bugs-1517996 ] IDLE (macosx): Class and Path browsers show
	Tk menu
Message-ID: <E1G4aMu-0007Np-3y@sc8-sf-web5.sourceforge.net>

Bugs item #1517996, was opened at 2006-07-06 10:34
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517996&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.5
Status: Open
Resolution: None
Priority: 4
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: IDLE (macosx): Class and Path browsers show Tk menu

Initial Comment:
I've done some work on fixing the menus for IDLE before 2.5b1, but 
recently found more toplevel windows that don't have their own menu.

Both the Path Browser and Class Browser don't have a menubar of their 
own. The Tk implementation on MacOSX won't accept an empty menubar, 
but will replace that by a generic Tk menubar.

----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-23 11:35

Message:
Logged In: YES 
user_id=580910

Changing the default root menu is indeed possible without changes outside 
macosxSupport.py. I'm going to apply the attached patch later today.

Annoyingly enough AquaTk still adds an (empty) Help menu to our menubar. It 
would be nice to fill that menu, but that would IMHO add to much code. I'm 
happy enough to blame that glitch on AquaTk.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-23 09:26

Message:
Logged In: YES 
user_id=580910

Yes I mean AquaTk. The debugger has the same problem (as expected because 
it doesn't define its own menu)

The behaviour of AquaTk is a feature, not a bug. Appearently the default menu 
is inheritted from the root ("."). I'll see if I can override that menu in 
macosxSupport.setupApp.

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2006-07-22 23:23

Message:
Logged In: YES 
user_id=149084

> Tk uses the per-window menu for the currently
> selected window

I assume you mean AquaTk uses the per-window...

Please put in a bug request on AquaTk to get it
to conform to how Tk handles this menu on Linux
and Windows.  Then downgrade the priority of this
bug or close it.

Does the debugger have the same problem?

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-18 14:20

Message:
Logged In: YES 
user_id=580910

These menu problems are at the very root caused by differences in the way 
menus work on OSX (one application wide menu at the top of the screen) and 
most other systems (optional menus for every window).  Applications on OSX 
must have some kind of menu (or be full-screen, but we don't want that for 
IDLE), Tk uses the per-window menu for the currently selected window for 
that. If a window doesn't have a menu it makes up one and I haven't found a 
way yet to override that menu (which would solve that problem once and for 
all).

I do believe that my other changes really are good, they make IDLE perform 
more like a true OSX application. This is important because IDLE is the default 
IDE, and hence probably the first thing naive OSX users will see of python.

BTW. AquaTk really sucks, which makes it annoyingly hard to create a really 
good OSX citizen of IDLE and I have given up on getting there. If I understand 
the lazyweb correctly you're supposed to port your appliations to some other 
GUI library (Tile?) to get a native L&F for lots of widgets and standard dialogs.

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2006-07-15 21:51

Message:
Logged In: YES 
user_id=149084

I suppose this is also true for the debugger?

I'd consider this a bug in OSX Tk, it should be
reported there.

Without a specific need for a menubar, all it does
is take up valuable vertical space.  And continuing
to add OSX special casing clutters up the IDLE code;
IMO it should be limited to situations where
functionality is compromised.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517996&group_id=5470

From noreply at sourceforge.net  Sun Jul 23 11:46:38 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 23 Jul 2006 02:46:38 -0700
Subject: [ python-Bugs-1517996 ] IDLE (macosx): Class and Path browsers show
	Tk menu
Message-ID: <E1G4aXm-0004Zy-31@sc8-sf-web5.sourceforge.net>

Bugs item #1517996, was opened at 2006-07-06 10:34
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517996&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 4
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: IDLE (macosx): Class and Path browsers show Tk menu

Initial Comment:
I've done some work on fixing the menus for IDLE before 2.5b1, but 
recently found more toplevel windows that don't have their own menu.

Both the Path Browser and Class Browser don't have a menubar of their 
own. The Tk implementation on MacOSX won't accept an empty menubar, 
but will replace that by a generic Tk menubar.

----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-23 11:46

Message:
Logged In: YES 
user_id=580910

Applied in revision 50785

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-23 11:35

Message:
Logged In: YES 
user_id=580910

Changing the default root menu is indeed possible without changes outside 
macosxSupport.py. I'm going to apply the attached patch later today.

Annoyingly enough AquaTk still adds an (empty) Help menu to our menubar. It 
would be nice to fill that menu, but that would IMHO add to much code. I'm 
happy enough to blame that glitch on AquaTk.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-23 09:26

Message:
Logged In: YES 
user_id=580910

Yes I mean AquaTk. The debugger has the same problem (as expected because 
it doesn't define its own menu)

The behaviour of AquaTk is a feature, not a bug. Appearently the default menu 
is inheritted from the root ("."). I'll see if I can override that menu in 
macosxSupport.setupApp.

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2006-07-22 23:23

Message:
Logged In: YES 
user_id=149084

> Tk uses the per-window menu for the currently
> selected window

I assume you mean AquaTk uses the per-window...

Please put in a bug request on AquaTk to get it
to conform to how Tk handles this menu on Linux
and Windows.  Then downgrade the priority of this
bug or close it.

Does the debugger have the same problem?

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-18 14:20

Message:
Logged In: YES 
user_id=580910

These menu problems are at the very root caused by differences in the way 
menus work on OSX (one application wide menu at the top of the screen) and 
most other systems (optional menus for every window).  Applications on OSX 
must have some kind of menu (or be full-screen, but we don't want that for 
IDLE), Tk uses the per-window menu for the currently selected window for 
that. If a window doesn't have a menu it makes up one and I haven't found a 
way yet to override that menu (which would solve that problem once and for 
all).

I do believe that my other changes really are good, they make IDLE perform 
more like a true OSX application. This is important because IDLE is the default 
IDE, and hence probably the first thing naive OSX users will see of python.

BTW. AquaTk really sucks, which makes it annoyingly hard to create a really 
good OSX citizen of IDLE and I have given up on getting there. If I understand 
the lazyweb correctly you're supposed to port your appliations to some other 
GUI library (Tile?) to get a native L&F for lots of widgets and standard dialogs.

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2006-07-15 21:51

Message:
Logged In: YES 
user_id=149084

I suppose this is also true for the debugger?

I'd consider this a bug in OSX Tk, it should be
reported there.

Without a specific need for a menubar, all it does
is take up valuable vertical space.  And continuing
to add OSX special casing clutters up the IDLE code;
IMO it should be limited to situations where
functionality is compromised.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517996&group_id=5470

From noreply at sourceforge.net  Sun Jul 23 19:29:36 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 23 Jul 2006 10:29:36 -0700
Subject: [ python-Bugs-1527397 ] PythonLauncher uses incorrect working
	directory
Message-ID: <E1G4hlo-0001sl-Kz@sc8-sf-web5.sourceforge.net>

Bugs item #1527397, was opened at 2006-07-23 13: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=1527397&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: Python 2.5
Status: Open
Resolution: None
Priority: 7
Submitted By: Bob Ippolito (etrepum)
Assigned to: Jack Jansen (jackjansen)
Summary: PythonLauncher uses incorrect working directory

Initial Comment:
PythonLauncher, the application used to launch .py files by double-click, 
does not launch with the correct working directory. This means that any 
script that depends on data files will not work via PythonLauncher.

Users expect the working directory to be that of the launched script, like 
on other platforms, but PythonLauncher launches with a working directory 
of $HOME.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1527397&group_id=5470

From noreply at sourceforge.net  Sun Jul 23 20:11:37 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 23 Jul 2006 11:11:37 -0700
Subject: [ python-Bugs-1525447 ] Build fails on OS X with case sensitive fs
Message-ID: <E1G4iQT-0002B9-Pe@sc8-sf-web3.sourceforge.net>

Bugs item #1525447, was opened at 2006-07-19 19:24
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525447&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 6
Submitted By: gideon may (gdm)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: Build fails on OS X with case sensitive fs

Initial Comment:
When compiling python from svn on a Mac OS X with a 
case sensitive file system I get the following build
error:

running build
running build_ext
db.h: found (4, 3) in /opt/local/include/db4
db lib: using (4, 3) db-4.3
sqlite: found /usr/include/sqlite3.h
/usr/include/sqlite3.h: version 3.1.3
Traceback (most recent call last):
  File "./setup.py", line 1507, in <module>
    main()
.
.
  File "./setup.py", line 1088, in addMacExtension
    raise RuntimeError("%s not found" % name)
RuntimeError: MacOS not found
make: *** [sharedmods] Error 1




It can be fixed by either renaming the file:
  Mac/Modules/macosmodule.c 
to
  Mac/Modules/MacOSmodule.c 

or applying the following patch :
Index: setup.py
===================================================================
--- setup.py    (revision 50687)
+++ setup.py    (working copy)
@@ -1101,7 +1101,7 @@
             carbon_kwds = {'extra_compile_args':
carbon_extra_compile_args,
                            'extra_link_args':
['-framework', 'Carbon'],
                           }
-            CARBON_EXTS = ['ColorPicker', 'gestalt',
'MacOS', 'Nav',
+            CARBON_EXTS = ['ColorPicker', 'gestalt',
'macos', 'Nav',
                            'OSATerminology', 'icglue',
                            # All these are in subdirs
                            '_AE', '_AH', '_App',
'_CarbonEvt', '_Cm', '_Ctl',


Cheers,

Gideon



----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-23 20:11

Message:
Logged In: YES 
user_id=580910

Could you please test if renaming Mac/Modules/macosmodule.c to Mac/
Modules/MacOS.c solves your problem?  With that rename the build still works 
for me, but I don't have a case-sensitive filesystem.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-23 11:31

Message:
Logged In: YES 
user_id=580910

The patch is incorrect, as this would rename user visible name of the python 
extension ('import MacOS' would stop working). 

The rename would be correct.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525447&group_id=5470

From noreply at sourceforge.net  Sun Jul 23 20:50:08 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 23 Jul 2006 11:50:08 -0700
Subject: [ python-Bugs-1527397 ] PythonLauncher uses incorrect working
	directory
Message-ID: <E1G4j1k-0005d2-Oa@sc8-sf-web5.sourceforge.net>

Bugs item #1527397, was opened at 2006-07-23 19:29
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1527397&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: Python 2.5
Status: Open
Resolution: None
Priority: 7
Submitted By: Bob Ippolito (etrepum)
Assigned to: Jack Jansen (jackjansen)
Summary: PythonLauncher uses incorrect working directory

Initial Comment:
PythonLauncher, the application used to launch .py files by double-click, 
does not launch with the correct working directory. This means that any 
script that depends on data files will not work via PythonLauncher.

Users expect the working directory to be that of the launched script, like 
on other platforms, but PythonLauncher launches with a working directory 
of $HOME.

----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-23 20:50

Message:
Logged In: YES 
user_id=580910

I agree that the current behaviour is not what users expect and should be 
considered a bug.

I'd like to get the attached patch into 2.5, it changes the CWD to the directory 
containing the script and should be perfectly save.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1527397&group_id=5470

From noreply at sourceforge.net  Sun Jul 23 21:42:19 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 23 Jul 2006 12:42:19 -0700
Subject: [ python-Bugs-1436532 ] length of unicode string changes print
	behaviour
Message-ID: <E1G4jqF-0007Ld-JA@sc8-sf-web6.sourceforge.net>

Bugs item #1436532, was opened at 2006-02-22 10:45
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436532&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.4
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: James (hover_boy)
Assigned to: Martin v. L??wis (loewis)
Summary: length of unicode string changes print behaviour

Initial Comment:
Python 2.4.2 and IDLE (with Courier New font) on XP 
and the following code saved as a UTF-8 file 

if __name__ == "__main__": 
    print "??? ??? ??? ??? ??? ??? ?
? ??? ?
?" 
    print "??? ??? ??? ??? ??? ??? ?
? ??? ?
? ??? ??? "

results in...

IDLE 1.1.2 
>>> ================================ RESTART 
================================ 
>>> 
??????? ??????? ?????? ??????? ???????? ??????? ??????????? ??????? 
??? ??? ??? ??? ??? ??? ?
? ??? ?
? ??? ??? 
>>> 





----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-07-23 21:42

Message:
Logged In: YES 
user_id=21627

This is not a bug. The program should not attempt to print
byte strings, since it cannot know what the encoding of the
byte strings is. Instead, the program should use Unicode
strings, such as

    print u"?
??
??
??
??
??
??
??
??
??
??
??
??
??
??
??
??
??
??
??
??
??
?"

If you attempt to print byte strings, they have to be in the
encoding of stdout, or else the behaviour is unspecified.

In my installation/locale, sys.stdout.encoding is cp1250.
IDLE's OutputWindow.write has this code:

        # Tk assumes that byte strings are Latin-1;
        # we assume that they are in the locale's encoding
        if isinstance(s, str):
            try:
                s = unicode(s, IOBinding.encoding)
            except UnicodeError:
                # some other encoding; let Tcl deal with it
                pass

Of the strings specified in the source file, only strings
2..5 decode properly as cp1250; the others don't. So these
get passed directly to Tcl, which then assumes they are
UTF-8, with some fallback also. The strings that look
"incorrectly" are actually printed out as designed: using
sys.stdout.encoding.


----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2006-07-23 07:33

Message:
Logged In: YES 
user_id=149084

I don't have a font installed which will print
those characters.  When I load your sample file,
I see print statements which include unicode
characters like \u5341.  The printed output
contains the same unicode characters as the
input program.  Maybe Martin has an idea.

----------------------------------------------------------------------

Comment By: James (hover_boy)
Date: 2006-03-22 16:21

Message:
Logged In: YES 
user_id=1458491

I've attached an example file to demonstrate the problem 
better.

it seems not to be the length but something else which I 
haven't figured out yet.

I've also added the encoding comment and also tried 
changing the default encoding in sitecustomize.py from latin
-1 to utf-8 but neither seem to work.

thanks,

James.

XP professional, SP2, english


----------------------------------------------------------------------

Comment By: James (hover_boy)
Date: 2006-03-22 16:12

Message:
Logged In: YES 
user_id=1458491




----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2006-03-06 02:44

Message:
Logged In: YES 
user_id=593130

I am fairly ignorant of unicode and encodings, but I am 
surprised you got anything coherent without an encoding 
cookie comment at the top (see manual).  Have you tried 
that?  Other questions that might help someone answer:

What specific XP version?  SP2 installed? Country version?
Your results for
>>> sys.getdefaultencoding()
'ascii'
>>> sys.getfilesystemencoding()
'mbcs'
What happens if you reverse the order of the print 
statements?  (Ie, is it really the shorter string that 
does not work or just the first?)

I don't know enough to know if this is really a bug.  If 
you don't get an answer here, you might try for more info 
on python-list/comp.lang.python

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436532&group_id=5470

From noreply at sourceforge.net  Sun Jul 23 21:53:54 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 23 Jul 2006 12:53:54 -0700
Subject: [ python-Bugs-1525678 ] exec and eval allocate lots of memory and do
	not free it
Message-ID: <E1G4k1S-0004BD-UI@sc8-sf-web6.sourceforge.net>

Bugs item #1525678, was opened at 2006-07-20 05:57
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525678&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Connelly (connelly)
Assigned to: Nobody/Anonymous (nobody)
Summary: exec and eval allocate lots of memory and do not free it

Initial Comment:
I'm not sure if this is a bug.  The "bug" is that if I start a new Python 
session, create a dict or list called d which takes around 2 MB of 
memory, and then I set d = eval(repr(d)), the Python process now is 
using ~38 MB of memory more than where it started at.  The high 
memory usage continues even after d is deleted.

Example 1:

% python
>>> # Memory use: 3216 KB
>>> d = dict.fromkeys(range(50000))
>>> # Memory use: 5400 KB
>>> d = eval('%r' % d)
>>> # Memory use: 41620 KB
>>> del d
>>> # Memory use: 40080 KB

I am using Python 2.4.1 (#65, Mar 30 2005) on Windows XP SP2 with 
512 MB RAM.

If we start with a larger initial dict -- say 
dict.fromkeys(range(1000**2)), then the line d = eval('%r' % d) can 
easily cause the process to start paging to disk, even though both the 
data structure and its string representation fit easily in memory.

Perhaps this behavior is due Python caching bytecodes.  One 
peculiarity about this "bug" is that if Example 1 is repeated with a 
second variable such as "d2", which is set to the value 
dict.fromkeys(range(50000,100000)), then the memory usage ends up 
exactly at 40080 KB after the second "del" statement.  If Python were 
caching the bytecodes, then one would expect the repetition of the 
example to put the memory usage at ~80000 KB.


----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-07-23 21:53

Message:
Logged In: YES 
user_id=21627

This "bug" falls into the "won't fix" category, and also in
the "already fixed" category.

Python does indeed free the memory; there is no caching
going on. It just doesn't return the memory to the operating
system. You can see that the memory is really freed by
performing the same operating over and over again (say, a
thousand times), and watch the memory consumption not grow.

Python obtains the memory not from the system, but from
malloc, which obtains it from the system. Whether or not
malloc will return memory to the system depends on the
malloc implementation; this is out of our control (it's in
the Microsoft C library).

However, Python does not return the memory to malloc,
either. In the specific case, there are two allocators on
top of malloc operating: the integer allocator, and the
small objects allocator. 

The integer allocator allocates a chunk from malloc and then
subdivides it into integer objects. This memory is never
returned to malloc; you are using this allocator within the
range() function. When the integers are released, the memory
becomes available for other integer objects, but not for
objects of another kind.

The small objects allocator is likely used for the repr
strings of the integers. Object sizes are rounded up to the
next multiple of 8 (say, 24), and then a pool of
24-byte-sized blocks is maintained. When the string objects
are released, they are released to the pool. In Python 2.4,
pool memory is never returned to malloc.

In Python 2.5, this aspect is fixed: under certain
circumstances (which are too involved to describe here),
pool memory is returned to malloc, which then hopefully
returns it to the system.

Closing as "won't fix".

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525678&group_id=5470

From noreply at sourceforge.net  Sun Jul 23 22:00:58 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 23 Jul 2006 13:00:58 -0700
Subject: [ python-Bugs-1524938 ] MemoryError with a lot of available memory -
	gc not called
Message-ID: <E1G4k8H-0004nB-Od@sc8-sf-web5.sourceforge.net>

Bugs item #1524938, was opened at 2006-07-19 04:46
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1524938&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Matusevich (markmat)
Assigned to: Nobody/Anonymous (nobody)
Summary: MemoryError with a lot of available memory - gc not called

Initial Comment:
Also the gc behavior is consistent with the
documentation, I beleave it is wrong. I think, that Gc
should be called automatically before any memory
allocation is raised.

Example 1:
for i in range(700): 
   a = [range(5000000)]
   a.append(a)
   print i

This example will crash on any any PC with less then
20Gb RAM. On my PC (Windows 2000, 256Mb) it crashes at
i==7.
Also, this example can be fixed by addition of a call
to gc.collect() in the loop, in real cases it may be
unreasonable. 


----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-07-23 22:00

Message:
Logged In: YES 
user_id=21627

This is very difficult to implement. The best way might be
to introduce yet another allocation function, one that
invokes gc before failing, and call that function in all
interesting places (of which there are many).

Contributions are welcome and should probably start with a
PEP first.

----------------------------------------------------------------------

Comment By: Rene Dudfield (illume)
Date: 2006-07-20 01:20

Message:
Logged In: YES 
user_id=2042

Perhaps better than checking before every memory allocation,
would be to check once a memory error happens in an allocation.

That way there is only the gc hit once there is low memory.

So...

res = malloc(...);
if(!res) {
    gc.collect();
}

res = malloc(...);
if(!res) {
    raise memory error.
}





----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1524938&group_id=5470

From noreply at sourceforge.net  Sun Jul 23 22:11:17 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 23 Jul 2006 13:11:17 -0700
Subject: [ python-Bugs-1524938 ] MemoryError with a lot of available memory -
	gc not called
Message-ID: <E1G4kIH-00012b-AD@sc8-sf-web2.sourceforge.net>

Bugs item #1524938, was opened at 2006-07-19 05:46
Message generated for change (Comment added) made by markmat
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1524938&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Matusevich (markmat)
Assigned to: Nobody/Anonymous (nobody)
Summary: MemoryError with a lot of available memory - gc not called

Initial Comment:
Also the gc behavior is consistent with the
documentation, I beleave it is wrong. I think, that Gc
should be called automatically before any memory
allocation is raised.

Example 1:
for i in range(700): 
   a = [range(5000000)]
   a.append(a)
   print i

This example will crash on any any PC with less then
20Gb RAM. On my PC (Windows 2000, 256Mb) it crashes at
i==7.
Also, this example can be fixed by addition of a call
to gc.collect() in the loop, in real cases it may be
unreasonable. 


----------------------------------------------------------------------

>Comment By: Mark Matusevich (markmat)
Date: 2006-07-23 23:11

Message:
Logged In: YES 
user_id=1337765

This is exectly what I meant. 
For my recollection, this is the policy in Java GC. I never
had to handle MemoryError in Java, because I knew, that I
really do not have any more memory.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-07-23 23:00

Message:
Logged In: YES 
user_id=21627

This is very difficult to implement. The best way might be
to introduce yet another allocation function, one that
invokes gc before failing, and call that function in all
interesting places (of which there are many).

Contributions are welcome and should probably start with a
PEP first.

----------------------------------------------------------------------

Comment By: Rene Dudfield (illume)
Date: 2006-07-20 02:20

Message:
Logged In: YES 
user_id=2042

Perhaps better than checking before every memory allocation,
would be to check once a memory error happens in an allocation.

That way there is only the gc hit once there is low memory.

So...

res = malloc(...);
if(!res) {
    gc.collect();
}

res = malloc(...);
if(!res) {
    raise memory error.
}





----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1524938&group_id=5470

From noreply at sourceforge.net  Sun Jul 23 22:19:09 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 23 Jul 2006 13:19:09 -0700
Subject: [ python-Bugs-1524938 ] MemoryError with a lot of available memory -
	gc not called
Message-ID: <E1G4kPt-0004eA-Al@sc8-sf-web2.sourceforge.net>

Bugs item #1524938, was opened at 2006-07-19 05:46
Message generated for change (Comment added) made by markmat
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1524938&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Matusevich (markmat)
Assigned to: Nobody/Anonymous (nobody)
Summary: MemoryError with a lot of available memory - gc not called

Initial Comment:
Also the gc behavior is consistent with the
documentation, I beleave it is wrong. I think, that Gc
should be called automatically before any memory
allocation is raised.

Example 1:
for i in range(700): 
   a = [range(5000000)]
   a.append(a)
   print i

This example will crash on any any PC with less then
20Gb RAM. On my PC (Windows 2000, 256Mb) it crashes at
i==7.
Also, this example can be fixed by addition of a call
to gc.collect() in the loop, in real cases it may be
unreasonable. 


----------------------------------------------------------------------

>Comment By: Mark Matusevich (markmat)
Date: 2006-07-23 23:19

Message:
Logged In: YES 
user_id=1337765

Sorry, my last comment was to illume (I am slow typer :( )

----------------------------------------------------------------------

Comment By: Mark Matusevich (markmat)
Date: 2006-07-23 23:11

Message:
Logged In: YES 
user_id=1337765

This is exectly what I meant. 
For my recollection, this is the policy in Java GC. I never
had to handle MemoryError in Java, because I knew, that I
really do not have any more memory.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-07-23 23:00

Message:
Logged In: YES 
user_id=21627

This is very difficult to implement. The best way might be
to introduce yet another allocation function, one that
invokes gc before failing, and call that function in all
interesting places (of which there are many).

Contributions are welcome and should probably start with a
PEP first.

----------------------------------------------------------------------

Comment By: Rene Dudfield (illume)
Date: 2006-07-20 02:20

Message:
Logged In: YES 
user_id=2042

Perhaps better than checking before every memory allocation,
would be to check once a memory error happens in an allocation.

That way there is only the gc hit once there is low memory.

So...

res = malloc(...);
if(!res) {
    gc.collect();
}

res = malloc(...);
if(!res) {
    raise memory error.
}





----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1524938&group_id=5470

From noreply at sourceforge.net  Sun Jul 23 22:30:44 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 23 Jul 2006 13:30:44 -0700
Subject: [ python-Bugs-1524938 ] PEP MemoryError with a lot of available
	memory gc not called
Message-ID: <E1G4kb6-0001WR-FB@sc8-sf-web2.sourceforge.net>

Bugs item #1524938, was opened at 2006-07-19 05:46
Message generated for change (Settings changed) made by markmat
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1524938&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Matusevich (markmat)
Assigned to: Nobody/Anonymous (nobody)
>Summary: PEP MemoryError with a lot of available memory gc not called

Initial Comment:
Also the gc behavior is consistent with the
documentation, I beleave it is wrong. I think, that Gc
should be called automatically before any memory
allocation is raised.

Example 1:
for i in range(700): 
   a = [range(5000000)]
   a.append(a)
   print i

This example will crash on any any PC with less then
20Gb RAM. On my PC (Windows 2000, 256Mb) it crashes at
i==7.
Also, this example can be fixed by addition of a call
to gc.collect() in the loop, in real cases it may be
unreasonable. 


----------------------------------------------------------------------

Comment By: Mark Matusevich (markmat)
Date: 2006-07-23 23:19

Message:
Logged In: YES 
user_id=1337765

Sorry, my last comment was to illume (I am slow typer :( )

----------------------------------------------------------------------

Comment By: Mark Matusevich (markmat)
Date: 2006-07-23 23:11

Message:
Logged In: YES 
user_id=1337765

This is exectly what I meant. 
For my recollection, this is the policy in Java GC. I never
had to handle MemoryError in Java, because I knew, that I
really do not have any more memory.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-07-23 23:00

Message:
Logged In: YES 
user_id=21627

This is very difficult to implement. The best way might be
to introduce yet another allocation function, one that
invokes gc before failing, and call that function in all
interesting places (of which there are many).

Contributions are welcome and should probably start with a
PEP first.

----------------------------------------------------------------------

Comment By: Rene Dudfield (illume)
Date: 2006-07-20 02:20

Message:
Logged In: YES 
user_id=2042

Perhaps better than checking before every memory allocation,
would be to check once a memory error happens in an allocation.

That way there is only the gc hit once there is low memory.

So...

res = malloc(...);
if(!res) {
    gc.collect();
}

res = malloc(...);
if(!res) {
    raise memory error.
}





----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1524938&group_id=5470

From noreply at sourceforge.net  Sun Jul 23 22:45:33 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 23 Jul 2006 13:45:33 -0700
Subject: [ python-Bugs-1012435 ] ctrl-left/-right works incorectly with
	diacritics
Message-ID: <E1G4kpR-0000Bb-9g@sc8-sf-web5.sourceforge.net>

Bugs item #1012435, was opened at 2004-08-19 15:40
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1012435&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Tkinter
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Krzysztof Wilkosz (sophros)
>Assigned to: Nobody/Anonymous (nobody)
Summary: ctrl-left/-right works incorectly with diacritics

Initial Comment:
When left- or right-going in line with ctrl-arrow
(left/right) I have encountered problems:

example word with polish (cp1250) diacritics: za&#380;?&#322;&#263;
(last 4 letters might be unreadable) this keybord
shortcut stops each time diacritic letter is
encountered, not at the end of the word. It is
frustrating as I have many strings and comments in
Polish. I thing it might work bad also in the case of
any other non-ASCII letters.

----------------------------------------------------------------------

>Comment By: Kurt B. Kaiser (kbk)
Date: 2006-07-23 16:45

Message:
Logged In: YES 
user_id=149084

The control-{right,left} action appears to be
implemented in Tkinter, probably in Tcl/Tk, it's
not an IDLE issue.

Someone should check if the problem exists in 
Tk.  Passing this on to the Tkinter crew.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1012435&group_id=5470

From noreply at sourceforge.net  Sun Jul 23 22:47:04 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 23 Jul 2006 13:47:04 -0700
Subject: [ python-Bugs-1512124 ] OSX: debugger hangs IDLE
Message-ID: <E1G4kqu-0000uK-QK@sc8-sf-web5.sourceforge.net>

Bugs item #1512124, was opened at 2006-06-25 09:45
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512124&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.5
Status: Open
Resolution: Accepted
Priority: 7
Submitted By: Aahz (aahz)
Assigned to: Nobody/Anonymous (nobody)
Summary: OSX: debugger hangs IDLE

Initial Comment:
This has been previously found on 2.3/2.4 and verified again with 2.5b1
(was hoping that the 1.2 IDLE update would fix):

When you bring up the debugger window in IDLE on OSX, you'll notice that
it's vibrating, as if it's stuck in a resize loop.  Unless you
immediately resize the window manually, IDLE will hang the next time you
try to do something that updates the debugger window.


----------------------------------------------------------------------

>Comment By: Kurt B. Kaiser (kbk)
Date: 2006-07-23 16:47

Message:
Logged In: YES 
user_id=149084

Please try running IDLE w/o the subprocess by
starting it with the -n switch.  Does the issue
still exist?

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-06-25 16:49

Message:
Logged In: YES 
user_id=580910

And when you do resize the window layout sucks, automatic layout seems to 
be buggy here (although I must admit that I haven't seen IDLE on other 
platforms).

I have no idea what is causing this bug. Upgrading the Tk version to the very 
latest instead of using the system version doesn't help.

I've checked in a workaround in revision 47091. That patch avoids explicitly 
sizing the stackviewer widget on OSX, which seems to fix this problem. The 
debugger window now is rather less wide than it was before, which means 
users will likely have to resize the window if they want to use the debugger.

I'm leaving this bug open and unassign it in the hope that someone who 
actually knows Tkinter proposed a better fix.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512124&group_id=5470

From noreply at sourceforge.net  Mon Jul 24 07:06:08 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 23 Jul 2006 22:06:08 -0700
Subject: [ python-Feature Requests-1510853 ] Add Windows 9x/ME (lack of)
	support information to README.TX
Message-ID: <E1G4sds-0008NA-JQ@sc8-sf-web1.sourceforge.net>

Feature Requests item #1510853, was opened at 2006-06-22 20:36
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1510853&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: ajaksu (ajaksu2)
Assigned to: A.M. Kuchling (akuchling)
Summary: Add Windows 9x/ME (lack of) support information to README.TX

Initial Comment:
I suggest that following informative note should be
added as a new sub-section in README.TXT's "Unsupported
systems" (which really needs mentioning MacOS 9). The
sub-section idea regards README.TXT only talking about
already unsupported platforms. 

Motivation:
As one of the few Windows 98 users that program in
Python AND installed the 2.5 beta1, I was greeted by
Tools/msi/msi.py's warning message. However, no further
information was available in the downloaded release or
in the online beta documents (What's New, release
notes, etc.).

Best regards,
Daniel Diniz


-----
Warning on install in Windows 98 and Windows Me

Following Microsoft's closing of Extended Support for
Windows 98/ME (July 11, 2006), Python 2.6 will stop
supporting these platforms. Python development and
maintainability becomes easier (and more reliable) when
platform specific code targeting OSes with few users
and no dedicated expert developers is taken out. The
vendor also warns that the OS versions listed above
"can expose customers to security risks" and recommends
upgrade. For a more detailed discussion regarding
no-longer-supported and resupporting platforms, as well
as a list of platforms that became or will be
unsupported, see PEP 11.

Current behavior
The Python 2.5 installer presents a warning message on
those systems: "Warning: Python 2.5.x is the last
Python release for Windows 9x."

Suggested readings
PEP 11: Removing support for little used platforms
(http://www.python.org/dev/peps/pep-0011)
End of support for Windows 98, Windows Me, and Windows
XP Service Pack 1
(http://www.microsoft.com/windows/support/endofsupport.mspx)

Copyright
    This document has been placed in the public domain.

------

----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-07-24 07:06

Message:
Logged In: YES 
user_id=21627

Thanks for the suggestion. I added the text (in some form)
to README in r50794.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-06-22 20:59

Message:
Logged In: YES 
user_id=849994

Andrew?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1510853&group_id=5470

From noreply at sourceforge.net  Mon Jul 24 08:09:52 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 23 Jul 2006 23:09:52 -0700
Subject: [ python-Bugs-1512124 ] OSX: debugger hangs IDLE
Message-ID: <E1G4tdY-0005qy-JO@sc8-sf-web1.sourceforge.net>

Bugs item #1512124, was opened at 2006-06-25 15:45
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512124&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.5
Status: Open
Resolution: Accepted
Priority: 7
Submitted By: Aahz (aahz)
Assigned to: Nobody/Anonymous (nobody)
Summary: OSX: debugger hangs IDLE

Initial Comment:
This has been previously found on 2.3/2.4 and verified again with 2.5b1
(was hoping that the 1.2 IDLE update would fix):

When you bring up the debugger window in IDLE on OSX, you'll notice that
it's vibrating, as if it's stuck in a resize loop.  Unless you
immediately resize the window manually, IDLE will hang the next time you
try to do something that updates the debugger window.


----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-24 08:09

Message:
Logged In: YES 
user_id=580910

You'd have to test with a version of python before 2.5b1, after that I've added a 
workaround for this issue. This workaround makes the debugger window 
narrower than intended, but at least you have a working version of IDLE.

My guess is that the root cause of this issue is a bug in TkAqua. I haven't filed a 
bug with them because I have never programmed in Tcl and would therefore 
require lots of time to get a Tcl program going that demonstrates this problem.

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2006-07-23 22:47

Message:
Logged In: YES 
user_id=149084

Please try running IDLE w/o the subprocess by
starting it with the -n switch.  Does the issue
still exist?

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-06-25 22:49

Message:
Logged In: YES 
user_id=580910

And when you do resize the window layout sucks, automatic layout seems to 
be buggy here (although I must admit that I haven't seen IDLE on other 
platforms).

I have no idea what is causing this bug. Upgrading the Tk version to the very 
latest instead of using the system version doesn't help.

I've checked in a workaround in revision 47091. That patch avoids explicitly 
sizing the stackviewer widget on OSX, which seems to fix this problem. The 
debugger window now is rather less wide than it was before, which means 
users will likely have to resize the window if they want to use the debugger.

I'm leaving this bug open and unassign it in the hope that someone who 
actually knows Tkinter proposed a better fix.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512124&group_id=5470

From noreply at sourceforge.net  Mon Jul 24 13:47:17 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 24 Jul 2006 04:47:17 -0700
Subject: [ python-Bugs-1526785 ] current directory added to sys.path on win32
Message-ID: <E1G4yu5-0006z8-0i@sc8-sf-web6.sourceforge.net>

Bugs item #1526785, was opened at 2006-07-22 02:27
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1526785&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: John Ehresman (jpe)
Assigned to: Nobody/Anonymous (nobody)
Summary: current directory added to sys.path on win32

Initial Comment:
The current directory at the time python starts is
added to sys.path as the 3rd item (usually), regardless
of whether the python file run is in this directory. 
This is apparently due to getpythonregpath in
getpathp.c returning "" when skiphome is true and there
are 0 subkeys in the registry.  Since this is != NULL,
it is appended to the path after the library zip file
is and later is expanded to the current directory.

Because of this, 'import string' fails when an empty
re.py is in the current directory because this file is
used when string tries to import re.  I know it's not a
good idea to have an empty re.py file, but I can't
control what's on other people's machines.

I've been debugging this in python 2.4, but 2.5 beta 2
seems to have the same behavior.  This fix may be to
set machinepath and userpath to NULL if they are "".

----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-07-24 13:47

Message:
Logged In: YES 
user_id=21627

This is fixed with patch #1232023.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1526785&group_id=5470

From noreply at sourceforge.net  Mon Jul 24 14:03:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 24 Jul 2006 05:03:42 -0700
Subject: [ python-Bugs-1527705 ] optparse should support arbitrary number of
	arguments
Message-ID: <E1G4z9y-0005xY-Vl@sc8-sf-web6.sourceforge.net>

Bugs item #1527705, was opened at 2006-07-24 17: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=1527705&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Ritesh Raj Sarraf (riteshsarraf)
Assigned to: Nobody/Anonymous (nobody)
Summary: optparse should support arbitrary number of arguments

Initial Comment:
Currently, the number of arguments an option 
can/should have, needs be defined.

This is done using "nagrs".

parser.add_option("", "--my-option", nargs=3)

The problem is that at times it isn't predictable how 
many arguments you'll be receiving.

I request the implementation of this feature in 
optparse, where the following could be possible.

parser.add_option("", "--my-option", nargs=*)

Thanks,
Ritesh

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1527705&group_id=5470

From noreply at sourceforge.net  Mon Jul 24 14:57:10 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 24 Jul 2006 05:57:10 -0700
Subject: [ python-Bugs-1527705 ] optparse should support arbitrary number of
	arguments
Message-ID: <E1G4zzi-0004Xl-OO@sc8-sf-web5.sourceforge.net>

Bugs item #1527705, was opened at 2006-07-24 12:03
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1527705&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Feature Request
>Status: Pending
>Resolution: Rejected
Priority: 5
Submitted By: Ritesh Raj Sarraf (riteshsarraf)
Assigned to: Nobody/Anonymous (nobody)
Summary: optparse should support arbitrary number of arguments

Initial Comment:
Currently, the number of arguments an option 
can/should have, needs be defined.

This is done using "nagrs".

parser.add_option("", "--my-option", nargs=3)

The problem is that at times it isn't predictable how 
many arguments you'll be receiving.

I request the implementation of this feature in 
optparse, where the following could be possible.

parser.add_option("", "--my-option", nargs=*)

Thanks,
Ritesh

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-24 12:57

Message:
Logged In: YES 
user_id=849994

I don't know of any program that uses command line switches
with a variable number of args, partly because you then
cannot distinguish between option arguments and normal
arguments.

I you still need this, you can implement a custom callback,
I think.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1527705&group_id=5470

From noreply at sourceforge.net  Mon Jul 24 14:58:06 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 24 Jul 2006 05:58:06 -0700
Subject: [ python-Bugs-1524310 ] os.listdir doesn't check error code from
	FindNextFile
Message-ID: <E1G500c-0007Ib-CA@sc8-sf-web1.sourceforge.net>

Bugs item #1524310, was opened at 2006-07-18 09:35
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1524310&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Roger Upole (rupole)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.listdir doesn't check error code from FindNextFile

Initial Comment:
The Windows implementation of listdir returns 
successfully as soon as FindNextFile returns False, 
without checking that GetLastError returns 
ERROR_NO_MORE_FILES.  If the operation is interrupted 
(eg removable media ejected, network connection to UNC 
path lost, and so on) an incomplete directory listing 
is returned instead of throwing an exception.
This behaviour exists in 2.4.3 and 2.5b2.


----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-07-24 14:58

Message:
Logged In: YES 
user_id=21627

Thanks for the report. Fixed with r50797 and r50798

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1524310&group_id=5470

From noreply at sourceforge.net  Mon Jul 24 15:00:14 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 24 Jul 2006 06:00:14 -0700
Subject: [ python-Bugs-1257728 ] error message incorrectly claims Visual C++
	is required
Message-ID: <E1G502g-00071z-OC@sc8-sf-web6.sourceforge.net>

Bugs item #1257728, was opened at 2005-08-12 17:28
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257728&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Zooko O'Whielacronx (zooko)
Assigned to: Nobody/Anonymous (nobody)
Summary: error message incorrectly claims Visual C++ is required

Initial Comment:
Thank you for the excellent distutils tool!

Two problems:

First, this error message is emitted on win32, but it
appears to be incorrect, inasmuch as the Microsoft
compiler is not actually required:

"""
error: Python was built with version 7.1 of Visual
Studio, and extensions need to be built with the same
version of the compiler, but it isn't installed.
Error: Subprocess exited with result 1 for project core
"""

Second, the usage of distutils is somewhat confusing,
as the following line emits that error message:

./setup.py build -c mingw32; ./setup.py install

but the following line, which I intuitively believed to
be equivalent at first, works to compile and install
the package:

./setup.py build -c mingw32 install

----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-07-24 15:00

Message:
Logged In: YES 
user_id=21627

What would you like to say the error message instead?

----------------------------------------------------------------------

Comment By: Zooko O'Whielacronx (zooko)
Date: 2006-03-31 13:35

Message:
Logged In: YES 
user_id=52562

Changing this from category Distutils to category Windows.

----------------------------------------------------------------------

Comment By: Zooko O'Whielacronx (zooko)
Date: 2005-11-23 19:51

Message:
Logged In: YES 
user_id=52562

Whoo!  Progress!  Now it no longer spuriously claims that
Visual C++ is required for building extensions for Python,
and instead it spuriously claims that the .NET SDK is
required for building extensions for Python!

"""
error: The .NET Framework SDK needs to be installed before
building extensions for Python.
"""

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257728&group_id=5470

From noreply at sourceforge.net  Mon Jul 24 15:02:09 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 24 Jul 2006 06:02:09 -0700
Subject: [ python-Bugs-1283895 ] os.path.abspath() / os.chdir() buggy with
	unicode paths
Message-ID: <E1G504X-0004fe-G5@sc8-sf-web2.sourceforge.net>

Bugs item #1283895, was opened at 2005-09-07 14:30
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1283895&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.4
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Antoine Pitrou (pitrou)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.abspath() / os.chdir() buggy with unicode paths

Initial Comment:
Hi,

Under Windows Explorer, one can create directory names
using characters not belonging to the user locale. For
example, one of our users created a directory named
"C:\Mes Documents\&#12467;&#12500;&#12540; &#65374; solipsis_svn". 

Unfortunately, when trying to manipulate such a
pathname, os.path.abspath() and os.chdir() don't work
hand in hand. os.path.abspath() uses the garbled
directory name as displayed by the command prompt and
then os.chdir() refuses the path:

C:\>cd "C:\Mes Documents\??? ~ solipsis_svn"

C:\Mes Documents\??? ~ solipsis_svn>python
Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>>
>>> import os
>>> os.curdir
'.'
>>> os.path.abspath(os.curdir)
'C:\\Mes Documents\\??? ~ solipsis_svn'
>>> os.chdir(os.path.abspath(os.curdir))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OSError: [Errno 22] Invalid argument: 'C:\\Mes
Documents\\??? ~ solipsis_svn'
>>>


----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-07-24 15:02

Message:
Logged In: YES 
user_id=21627

This is not a bug. You need to use Unicode path names to
operate on files with names outside of the system code page.

----------------------------------------------------------------------

Comment By: Neil Hodgson (nyamatongwe)
Date: 2005-09-09 15:08

Message:
Logged In: YES 
user_id=12579

This is using byte string arguments causing byte string
processing rather than unicode calls with unicode
processing. Windows code that may encounter file paths
outside the default locale should stick to unicode for
paths. Try converting os.curdir to unicode before calling
other functions:
os.path.abspath(unicode(os.curdir))

----------------------------------------------------------------------

Comment By: Antoine Pitrou (pitrou)
Date: 2005-09-07 14:36

Message:
Logged In: YES 
user_id=133955

> "C:\Mes Documents\&#12467;&#12500;&#12540; &#65374;
solipsis_svn"

Gasp. Sourceforge escapes HTML entities instead of showing
the real characters... These are Japanese characters, btw.
It's easy to copy/paste some Japanese characters from a Web
site and paste them into Windows Explorer to create a
directory (at least it works with Mozilla Firefox).


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1283895&group_id=5470

From noreply at sourceforge.net  Mon Jul 24 15:10:45 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 24 Jul 2006 06:10:45 -0700
Subject: [ python-Bugs-1283895 ] os.path.abspath() / os.chdir() buggy with
	unicode paths
Message-ID: <E1G50Cr-0004HI-Hx@sc8-sf-web6.sourceforge.net>

Bugs item #1283895, was opened at 2005-09-07 14:30
Message generated for change (Comment added) made by pitrou
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1283895&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.4
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Antoine Pitrou (pitrou)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.abspath() / os.chdir() buggy with unicode paths

Initial Comment:
Hi,

Under Windows Explorer, one can create directory names
using characters not belonging to the user locale. For
example, one of our users created a directory named
"C:\Mes Documents\&#12467;&#12500;&#12540; &#65374; solipsis_svn". 

Unfortunately, when trying to manipulate such a
pathname, os.path.abspath() and os.chdir() don't work
hand in hand. os.path.abspath() uses the garbled
directory name as displayed by the command prompt and
then os.chdir() refuses the path:

C:\>cd "C:\Mes Documents\??? ~ solipsis_svn"

C:\Mes Documents\??? ~ solipsis_svn>python
Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>>
>>> import os
>>> os.curdir
'.'
>>> os.path.abspath(os.curdir)
'C:\\Mes Documents\\??? ~ solipsis_svn'
>>> os.chdir(os.path.abspath(os.curdir))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OSError: [Errno 22] Invalid argument: 'C:\\Mes
Documents\\??? ~ solipsis_svn'
>>>


----------------------------------------------------------------------

>Comment By: Antoine Pitrou (pitrou)
Date: 2006-07-24 15:10

Message:
Logged In: YES 
user_id=133955

Then why doesn't abspath() throw an exception instead of
silently returning a bogus result? Its behaviour is
counter-intuitive and produces hard-to-find bugs.


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-07-24 15:02

Message:
Logged In: YES 
user_id=21627

This is not a bug. You need to use Unicode path names to
operate on files with names outside of the system code page.

----------------------------------------------------------------------

Comment By: Neil Hodgson (nyamatongwe)
Date: 2005-09-09 15:08

Message:
Logged In: YES 
user_id=12579

This is using byte string arguments causing byte string
processing rather than unicode calls with unicode
processing. Windows code that may encounter file paths
outside the default locale should stick to unicode for
paths. Try converting os.curdir to unicode before calling
other functions:
os.path.abspath(unicode(os.curdir))

----------------------------------------------------------------------

Comment By: Antoine Pitrou (pitrou)
Date: 2005-09-07 14:36

Message:
Logged In: YES 
user_id=133955

> "C:\Mes Documents\&#12467;&#12500;&#12540; &#65374;
solipsis_svn"

Gasp. Sourceforge escapes HTML entities instead of showing
the real characters... These are Japanese characters, btw.
It's easy to copy/paste some Japanese characters from a Web
site and paste them into Windows Explorer to create a
directory (at least it works with Mozilla Firefox).


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1283895&group_id=5470

From noreply at sourceforge.net  Mon Jul 24 15:14:15 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 24 Jul 2006 06:14:15 -0700
Subject: [ python-Bugs-1384175 ] random module - Provider DLL failed to
	initialize correctly
Message-ID: <E1G50GF-0004KV-P9@sc8-sf-web1.sourceforge.net>

Bugs item #1384175, was opened at 2005-12-18 02:18
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1384175&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Hazel (ghazel)
Assigned to: Nobody/Anonymous (nobody)
Summary: random module - Provider DLL failed to initialize correctly

Initial Comment:
   File "random.pyc", line 828, in ?
   File "random.pyc", line 95, in __init__
   File "random.pyc", line 109, in seed
 WindowsError: [Errno -2146893795] Provider DLL failed 
to initialize correctly





----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-07-24 15:14

Message:
Logged In: YES 
user_id=21627

The errors are actually different. The first one is

0x8009001d: NTE_PROVIDER_DLL_FAIL (Provider DLL failed to
initialize correctly) 

and the second one is

0x80090006: NTE_BAD_SIGNATURE (Invalid Signature)

For the second error, please check whether

http://support.microsoft.com/default.aspx?scid=kb;en-us;811886

applies. For the first error, I only found

http://support.microsoft.com/default.aspx?scid=kb;en-us;321459

but I doubt it's relevant.

In any case, I'm tempted to declare this a Windows bug.

----------------------------------------------------------------------

Comment By: Greg Hazel (ghazel)
Date: 2006-03-05 02:06

Message:
Logged In: YES 
user_id=731668

This time from Windows 98 SE:

  File "random.pyc", line 828, in ?
  File "random.pyc", line 95, in __init__
  File "random.pyc", line 109, in seed
WindowsError: [Errno -2146893818] Windows Error 0x80090006

----------------------------------------------------------------------

Comment By: Greg Hazel (ghazel)
Date: 2005-12-30 08:06

Message:
Logged In: YES 
user_id=731668

Windows XP, python 2.4.2
Not sure how to reproduce it.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-12-18 12:00

Message:
Logged In: YES 
user_id=1188172

Could you provide some more information? OS specs, Python
version, reproducability etc.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1384175&group_id=5470

From noreply at sourceforge.net  Mon Jul 24 15:21:52 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 24 Jul 2006 06:21:52 -0700
Subject: [ python-Bugs-1527705 ] optparse should support arbitrary number of
	arguments
Message-ID: <E1G50Nc-0000sp-GX@sc8-sf-web6.sourceforge.net>

Bugs item #1527705, was opened at 2006-07-24 17:33
Message generated for change (Comment added) made by riteshsarraf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1527705&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Feature Request
>Status: Open
>Resolution: None
Priority: 5
Submitted By: Ritesh Raj Sarraf (riteshsarraf)
Assigned to: Nobody/Anonymous (nobody)
Summary: optparse should support arbitrary number of arguments

Initial Comment:
Currently, the number of arguments an option 
can/should have, needs be defined.

This is done using "nagrs".

parser.add_option("", "--my-option", nargs=3)

The problem is that at times it isn't predictable how 
many arguments you'll be receiving.

I request the implementation of this feature in 
optparse, where the following could be possible.

parser.add_option("", "--my-option", nargs=*)

Thanks,
Ritesh

----------------------------------------------------------------------

>Comment By: Ritesh Raj Sarraf (riteshsarraf)
Date: 2006-07-24 18:51

Message:
Logged In: YES 
user_id=382018

Can you please go through the following link and give your 
comments ?

http://groups.google.com/group/comp.lang.python/browse_thre
ad/thread/277522927334b8d8

I feel its a valid feature request.

Ritesh

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-07-24 18:27

Message:
Logged In: YES 
user_id=849994

I don't know of any program that uses command line switches
with a variable number of args, partly because you then
cannot distinguish between option arguments and normal
arguments.

I you still need this, you can implement a custom callback,
I think.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1527705&group_id=5470

From noreply at sourceforge.net  Mon Jul 24 15:31:07 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 24 Jul 2006 06:31:07 -0700
Subject: [ python-Feature Requests-1527705 ] optparse should support arbitrary
	number of arguments
Message-ID: <E1G50WZ-0005pE-6R@sc8-sf-web2.sourceforge.net>

Feature Requests item #1527705, was opened at 2006-07-24 12:03
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1527705&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Python Library
>Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ritesh Raj Sarraf (riteshsarraf)
>Assigned to: Greg Ward (gward)
Summary: optparse should support arbitrary number of arguments

Initial Comment:
Currently, the number of arguments an option 
can/should have, needs be defined.

This is done using "nagrs".

parser.add_option("", "--my-option", nargs=3)

The problem is that at times it isn't predictable how 
many arguments you'll be receiving.

I request the implementation of this feature in 
optparse, where the following could be possible.

parser.add_option("", "--my-option", nargs=*)

Thanks,
Ritesh

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-24 13:31

Message:
Logged In: YES 
user_id=849994

I share effbot's view on that, but leaving to Greg to
decide. In any case, this is a feature request.

----------------------------------------------------------------------

Comment By: Ritesh Raj Sarraf (riteshsarraf)
Date: 2006-07-24 13:21

Message:
Logged In: YES 
user_id=382018

Can you please go through the following link and give your 
comments ?

http://groups.google.com/group/comp.lang.python/browse_thre
ad/thread/277522927334b8d8

I feel its a valid feature request.

Ritesh

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-07-24 12:57

Message:
Logged In: YES 
user_id=849994

I don't know of any program that uses command line switches
with a variable number of args, partly because you then
cannot distinguish between option arguments and normal
arguments.

I you still need this, you can implement a custom callback,
I think.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1527705&group_id=5470

From noreply at sourceforge.net  Mon Jul 24 15:37:43 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 24 Jul 2006 06:37:43 -0700
Subject: [ python-Bugs-1467929 ] %-formatting and dicts
Message-ID: <E1G50cx-0007sE-FN@sc8-sf-web2.sourceforge.net>

Bugs item #1467929, was opened at 2006-04-10 19:39
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467929&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: M.-A. Lemburg (lemburg)
>Assigned to: Martin v. L??wis (loewis)
Summary: %-formatting and dicts

Initial Comment:
This looks like a bug in the way the %-formatting code
works or is it a feature ?

>>> '%s %(a)s' % {'a': 'xyz'}
"{'a': 'xyz'} xyz"

>>> u'%s %(a)s' % {'a': 'xyz'}
u"{'a': 'xyz'} xyz"

Note that both strings and Unicode are affected.

Python 2.3 and 2.4 also show this behavior.

I would have expected an exception or the %-formatter
simply ignoring the first %s.




----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-24 13:37

Message:
Logged In: YES 
user_id=849994

The library ref specifies that if a dict is supplied, the
format specifiers MUST include a mapping key, so the right
thing to do would be to raise an exception.

Is it worth breaking backwards compatibility, Martin?

----------------------------------------------------------------------

Comment By: Hasan Diwan (hdiwan650)
Date: 2006-04-14 08:33

Message:
Logged In: YES 
user_id=1185570

It looks as though it's a feature... The first %s will print
the whole dictionary as a string, the second, only that
value looked up by the key.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467929&group_id=5470

From noreply at sourceforge.net  Mon Jul 24 15:49:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 24 Jul 2006 06:49:24 -0700
Subject: [ python-Bugs-1439538 ] test -e is not portable (Solaris 2.7)
Message-ID: <E1G50oG-00035Y-MR@sc8-sf-web2.sourceforge.net>

Bugs item #1439538, was opened at 2006-02-27 10:51
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1439538&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: H??vard Tveite (havatv)
Assigned to: Martin v. L??wis (loewis)
Summary: test -e is not portable (Solaris 2.7)

Initial Comment:
I was adviced by Barry Warsaw to file a bug on this.

I tried to install Python 2.4.2 (and 2.3.5) on Solaris
2.7, but configure failed.
The Solaris 2.7 sh does not support "test -e".
"test -e" is used two times in configure.

The use of "test -e" is not recommended for "Portable
Shell Programming":
<URL:
http://www.gnu.org/software/autoconf/manual/autoconf-2.57/html_chapter/autoconf_10.html
>

I replaced "test -e" with "test -r", and it seems to work
(configure finishes OK, and the files are found), but
I do not know if this is the correct way to do it.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-24 13:49

Message:
Logged In: YES 
user_id=849994

Martin, is the replacement correct?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1439538&group_id=5470

From noreply at sourceforge.net  Mon Jul 24 15:53:32 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 24 Jul 2006 06:53:32 -0700
Subject: [ python-Bugs-1521491 ] file.seek() influelce write() when opened
	with a+ mode
Message-ID: <E1G50sG-0004QB-0n@sc8-sf-web2.sourceforge.net>

Bugs item #1521491, was opened at 2006-07-12 22:04
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521491&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
>Status: Pending
Resolution: None
Priority: 5
Submitted By: Lior (rudnik_lior)
Assigned to: Nobody/Anonymous (nobody)
Summary: file.seek() influelce write() when opened with a+ mode

Initial Comment:
Python 2.5b1 (r25b1:47027, Jun 20 2006, 09:31:33)

Assuming documentation is correct: (from seek() help
"Note that if the file is opened for appending (mode
'a' or 'a+'), any seek() operations will be undone at
the next write"

Doing the following is __not__ undoing the seek
operation after calling this a few times (Simplified
code snippet):

from __future__ import with_statement
with open(path,'a+') as f:
    f.seek(0,2) # go to end
    pos = f.tell() 
    f.seek(0,0)
    line = f.readline().strip()
    f.seek(0,2) # go to end, not effective if opened
with mode a/a+ (currently bug?)
    f.write("something")

Calling the above code repeatedly didnt increase the
file size beyond 166 bytes (in my code)



----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-07-13 07:43

Message:
Logged In: YES 
user_id=849994

I also cannot see any problem with the above code and can
append to a file indefinitely. What exactly are you
expecting the code to do, and what do you get? Which OS is this?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-13 06:29

Message:
Logged In: YES 
user_id=33168

This seems to work for me on Linux.  Maybe we are testing
differently.  What o/s and version are you using?  Does this
work with Python 2.4?  Can you attach a complete test case
that demonstrates this problem?

Thanks.

----------------------------------------------------------------------

Comment By: Lior (rudnik_lior)
Date: 2006-07-12 22:09

Message:
Logged In: YES 
user_id=1364480

Re-tried the code with empty file - it doesnt grow beyond
creating and writting at position 0 so it seems the seek
does influence the write position.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521491&group_id=5470

From noreply at sourceforge.net  Mon Jul 24 15:54:01 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 24 Jul 2006 06:54:01 -0700
Subject: [ python-Bugs-1520176 ] non-uniform behavior in 'startswith' /
	'endswith'
Message-ID: <E1G50sj-0004Y9-Fk@sc8-sf-web2.sourceforge.net>

Bugs item #1520176, was opened at 2006-07-10 19:49
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1520176&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
>Status: Pending
Resolution: None
Priority: 5
Submitted By: Milind (t-milich)
Assigned to: Raymond Hettinger (rhettinger)
Summary: non-uniform behavior in  'startswith' / 'endswith'

Initial Comment:
compare the two versions of 'endswith'.
Either  both of them should throw TypeErorr or both 
should return boolean value. 


>>> 'abc'.endswith( ('abc',None))

True

>>> 'abc'.endswith( ('abc',None),4,3)

Traceback (most recent call last):

  File "<stdin>", line 1, in <module>

TypeError: expected a character buffer object



----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-07-10 20:15

Message:
Logged In: YES 
user_id=849994

The current code shortcuts if it finds a match, so I think
this is not a bug. Raymond?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1520176&group_id=5470

From noreply at sourceforge.net  Mon Jul 24 16:12:06 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 24 Jul 2006 07:12:06 -0700
Subject: [ python-Bugs-1515163 ] traceback now masks some string exceptions
Message-ID: <E1G51AE-0004jR-9R@sc8-sf-web3.sourceforge.net>

Bugs item #1515163, was opened at 2006-06-30 14:34
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1515163&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: traceback now masks some string exceptions

Initial Comment:
With 2.5, exceptions became new-style.  Unfortunately, 
the traceback module wasn't fully updated to still 
properly handle all (admittedly deprecated) string 
exceptions.  I noticed this because of its affect on 
unittest, where the original exception was masked.

Under 2.4.3:

>>> import traceback
>>> traceback.format_exception_only("strtype", 
"strvalue")
['strtype: strvalue\n']

Under 2.5b1:
>>> import traceback
>>> traceback.format_exception_only("strtype", 
"strvalue")

Traceback (most recent call last):
  File "<pyshell#1>", line 1, in <module>
    traceback.format_exception_only("strtype", 
"strvalue")
  File "C:\Python25\lib\traceback.py", line 168, in 
format_exception_only
    if issubclass(etype, SyntaxError):
TypeError: issubclass() arg 1 must be a class

I will also be entering a patch, but know that we need 
a bug number at this stage.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-24 14:12

Message:
Logged In: YES 
user_id=849994

Your patch was applied. Thanks!

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2006-06-30 22:09

Message:
Logged In: YES 
user_id=764593

Patch 1515343 fixes this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1515163&group_id=5470

From noreply at sourceforge.net  Mon Jul 24 19:14:49 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 24 Jul 2006 10:14:49 -0700
Subject: [ python-Bugs-1010370 ] sys.ps1 not protected in EditorWindow.py
Message-ID: <E1G5413-0003Kz-Vb@sc8-sf-web2.sourceforge.net>

Bugs item #1010370, was opened at 2004-08-16 18:15
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010370&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Dave Florek (d_florek)
Assigned to: Kurt B. Kaiser (kbk)
Summary: sys.ps1 not protected in EditorWindow.py

Initial Comment:

Python 2.3.4 on
Linux <host> 2.4.19-xfs-p3-929 #1 SMP Thu Oct 24
11:29:34 PDT 2002 i686 unknown
(RedHat 7.3, patched)

Auto-indenting fails (and dumps errors to the shell)
when idle is started as a file editor.  I've wrapped
original lines 987 and 1057 of EditorWindow.py
(last_line_of_prompt = sys.ps1.split('\n')[-1]) with

if self.context_use_ps1:
    last_line_of_prompt = sys.ps1.split('\n')[-1]
else:
    last_line_of_prompt = '>>> '

This seems to fix it (might want to double-check other
attempts to access sys.ps1 and make sure they're
likewise protected).

FYI, the errors I got (other than incorrect line
numbers -- I was  tracking down a different problem
when I stumbled across this) are:

Exception in Tkinter callback
Traceback (most recent call last):
  File "/usr/local/lib/python2.3/lib-tk/Tkinter.py",
line 1345, in __call__
    return self.func(*args)
  File
"/work/florek/dev/python2.3/idlelib/EditorWindow.py",
line 1069, in newline_and_indent_event
    last_line_of_prompt = sys.ps1.split('\n')[-1]
AttributeError: 'module' object has no attribute 'ps1'



----------------------------------------------------------------------

>Comment By: Kurt B. Kaiser (kbk)
Date: 2006-07-24 13:14

Message:
Logged In: YES 
user_id=149084

Rev 50804
moved sys.ps1 test to EditorWindow init.

----------------------------------------------------------------------

Comment By: Dave Florek (d_florek)
Date: 2004-08-18 16:48

Message:
Logged In: YES 
user_id=1105316

Whatever fixes the problem is fine with me.  Knock yourself
out.  Seems to me that cases which are specific to
run-as-shell or run-as-editor should be sensibly divided
rather than "if there isn't a prompt then create a fake one"
hacks, but you're the one who has to maintain it down the
road.  As I illustrated, I already have a fix in place.

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2004-08-17 22:15

Message:
Logged In: YES 
user_id=149084

I'm thinking that it might be best to move the code
which sets sys.ps1 from PyShell.main() to the 
EditorWindow module toplevel.  Do you see a
downside to that? (sys.ps1 is only defined for the
python interactive interpreter, so it's undefined in
IDLE until set.)

----------------------------------------------------------------------

Comment By: Dave Florek (d_florek)
Date: 2004-08-17 13:10

Message:
Logged In: YES 
user_id=1105316

We have a Tk-based app that integrates IDLE as the default
text editor for python "scriptlets".  We create a new
idlelib.FileList attached to the parent gui, and then
on-demand from a button do a

editor = self.parentGui.flist.open(file)
editor.set_close_hook(lambda self=self:
self.parentGui.close_idle(self))
self.editor = editor

the close_idle callback, among other things, calls
flist.close_edit(widget.editor)

I'll look at idle.py and PyShell.py for more ideas, but it
seems to me if there's a valid "context" flag that indicates
whether IDLE is acting as a Python shell interface or as a
text-editor, then that flag should be used in this
particular case, since there won't be a prompt when acting
as a text-editor, and then there's no need to ensure that
sys.ps1 is currently defined.

Thanks,
Dave


----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2004-08-17 02:36

Message:
Logged In: YES 
user_id=149084

When IDLE starts via PyShell.main() sys.ps1 is set
to '>>>' at line 1273.  How are you "starting idle as a
file editor?"  It may be started either with the idle script
(probably in /usr/bin/ if IDLE was installed from the rpm)
or by calling ../../python ./PyShell.py from .../Lib/idlelib.
Also, take a look at idle.py, it's pretty flexible.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010370&group_id=5470

From noreply at sourceforge.net  Mon Jul 24 19:23:32 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 24 Jul 2006 10:23:32 -0700
Subject: [ python-Bugs-1512124 ] OSX: debugger hangs IDLE
Message-ID: <E1G549U-0001Fg-I4@sc8-sf-web5.sourceforge.net>

Bugs item #1512124, was opened at 2006-06-25 09:45
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512124&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.5
Status: Open
Resolution: Accepted
>Priority: 5
Submitted By: Aahz (aahz)
>Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: OSX: debugger hangs IDLE

Initial Comment:
This has been previously found on 2.3/2.4 and verified again with 2.5b1
(was hoping that the 1.2 IDLE update would fix):

When you bring up the debugger window in IDLE on OSX, you'll notice that
it's vibrating, as if it's stuck in a resize loop.  Unless you
immediately resize the window manually, IDLE will hang the next time you
try to do something that updates the debugger window.


----------------------------------------------------------------------

>Comment By: Kurt B. Kaiser (kbk)
Date: 2006-07-24 13:23

Message:
Logged In: YES 
user_id=149084

Could you revert your fix locally and try running
w/o the subprocess?  If that fixes it you could
blame the rather elaborate communication between
the subprocess and the debugger gui, and it would
be good to check before blaming AquaTk.

If it's still there, maybe you could provide a cutdown
in Tkinter (w/o IDLE) and change the Category to 
Tkinter?

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-24 02:09

Message:
Logged In: YES 
user_id=580910

You'd have to test with a version of python before 2.5b1, after that I've added a 
workaround for this issue. This workaround makes the debugger window 
narrower than intended, but at least you have a working version of IDLE.

My guess is that the root cause of this issue is a bug in TkAqua. I haven't filed a 
bug with them because I have never programmed in Tcl and would therefore 
require lots of time to get a Tcl program going that demonstrates this problem.

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2006-07-23 16:47

Message:
Logged In: YES 
user_id=149084

Please try running IDLE w/o the subprocess by
starting it with the -n switch.  Does the issue
still exist?

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-06-25 16:49

Message:
Logged In: YES 
user_id=580910

And when you do resize the window layout sucks, automatic layout seems to 
be buggy here (although I must admit that I haven't seen IDLE on other 
platforms).

I have no idea what is causing this bug. Upgrading the Tk version to the very 
latest instead of using the system version doesn't help.

I've checked in a workaround in revision 47091. That patch avoids explicitly 
sizing the stackviewer widget on OSX, which seems to fix this problem. The 
debugger window now is rather less wide than it was before, which means 
users will likely have to resize the window if they want to use the debugger.

I'm leaving this bug open and unassign it in the hope that someone who 
actually knows Tkinter proposed a better fix.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512124&group_id=5470

From noreply at sourceforge.net  Mon Jul 24 19:29:30 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 24 Jul 2006 10:29:30 -0700
Subject: [ python-Bugs-1517990 ] IDLE on macosx keybindings need work
Message-ID: <E1G54FG-0006C2-PX@sc8-sf-web3.sourceforge.net>

Bugs item #1517990, was opened at 2006-07-06 04:26
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517990&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.5
Status: Open
Resolution: None
Priority: 7
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: IDLE on macosx keybindings need work

Initial Comment:
There is a serious issue with the keybindings for IDLE on OSX: a lot of 
them don't work correctly. One example of a not-working key-binding is 
'CMD-W', this should close the current window but doesn't.  'CMD-N' does 
create a new window though, so at least some keybindings work.


----------------------------------------------------------------------

>Comment By: Kurt B. Kaiser (kbk)
Date: 2006-07-24 13:29

Message:
Logged In: YES 
user_id=149084

I see you made a change yesterday to EditorWindow
which appears to address the cmd-w bug. Could you
make an entry in NEWS.txt when you modify IDLE's
functionality?

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-18 08:09

Message:
Logged In: YES 
user_id=580910

The keybinding definition itself seems to be correct (although I haven't reviewed 
it completely yet). The problem at this point is that IDLE doesn't respond to 
some (or even most) of them. I suspect that AquaTk is at fault here, it is really 
lousy at times.

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2006-07-17 14:06

Message:
Logged In: YES 
user_id=149084

Unfortunately, I don't have a Mac to work with.

The current Mac keybindings were devised by Tony
Lownds (tonylownds) during the transition to OSX.

Would you like to create a new section in 
config-keys.def named OSX and work up some new
bindings?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517990&group_id=5470

From noreply at sourceforge.net  Mon Jul 24 20:06:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 24 Jul 2006 11:06:42 -0700
Subject: [ python-Bugs-1417598 ] EditorWindow demo causes attr-error
Message-ID: <E1G54pG-0005pq-Aj@sc8-sf-web2.sourceforge.net>

Bugs item #1417598, was opened at 2006-01-28 16:16
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1417598&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
>Priority: 3
Submitted By: snowman (snow_k2)
>Assigned to: Kurt B. Kaiser (kbk)
Summary: EditorWindow demo causes attr-error

Initial Comment:
Running EditorWindow.py causes next error : 
>>>>>>>>>>
Traceback (most recent call last):
  File "C:\Python24\Lib\idlelib\EditorWindow.py", line 
1410, in -toplevel-
    test()
  File "C:\Python24\Lib\idlelib\EditorWindow.py", line 
1404, in test
    edit = EditorWindow(root=root, filename=filename)
  File "C:\Python24\Lib\idlelib\EditorWindow.py", line 
190, in __init__
    self.update_recent_files_list()
  File "C:\Python24\Lib\idlelib\EditorWindow.py", line 
602, in update_recent_files_list
    if self.top.hasattr('instance_dict'):
AttributeError: ListedToplevel instance has no 
attribute 'hasattr'
<<<<<<<

I think EditorWindow.update_recent_files_list() should
check the 'instance_dict' attribute existance before
accessing self.top.instance_dict.keys() in the def.

  if hasattr(self.top, 'instance_dict'):
    xxxxx
    xxxxx



----------------------------------------------------------------------

>Comment By: Kurt B. Kaiser (kbk)
Date: 2006-07-24 14:06

Message:
Logged In: YES 
user_id=149084

Rev 50805

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1417598&group_id=5470

From noreply at sourceforge.net  Mon Jul 24 21:44:06 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 24 Jul 2006 12:44:06 -0700
Subject: [ python-Bugs-1486335 ] httplib: read/_read_chunked failes with
	ValueError sometime
Message-ID: <E1G56LW-0008Uz-AI@sc8-sf-web3.sourceforge.net>

Bugs item #1486335, was opened at 2006-05-11 05:14
Message generated for change (Settings changed) made by gward
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486335&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: kxroberto (kxroberto)
>Assigned to: Greg Ward (gward)
Summary: httplib: read/_read_chunked failes with ValueError sometime

Initial Comment:
This occasionally shows up in a logged trace, when a
application crahes on ValueError on a
http(s)_response.read() :

(py2.3.5 - yet relevant httplib code is still the same
in current httplib) 


.... \'  File "socket.pyo", line 283,
in read\\n\', \'  File "httplib.pyo", line 389, in
read\\n\', \'  File "httplib.pyo", line 426, in
_read_chunked\\n\', \'ValueError: invalid literal for
int(): \\n\']  :::

its the line:

chunk_left = int(line, 16)


Don't know what this line is about. Yet, that should be
protected, as a http_response.read() should not fail
with ValueError, but only with
IOError/EnvironmentError, socket.error - otherwise
Error Exception handling becomes a random task.

-Robert


Side note regarding IO exception handling: See also FR
#1481036 (IOBaseError): why socket.error.__bases__ is
(<class exceptions.Exception at 0x011244E0>,)  ?


----------------------------------------------------------------------

Comment By: Greg Ward (gward)
Date: 2006-07-24 15:38

Message:
Logged In: YES 
user_id=14422

I'm seeing this with Python 2.3.5 and 2.4.3 hitting a PHP
app and getting a large error page.  It looks as though the
server is incorrectly chunking the response: lwp-request at
least gives a better error message than httplib.py:

  $ GET "http://..."
  500 EOF when chunk header expected

I'm unclear on precisely what the server is doing wrong. 
The response looks like this:

HTTP/1.1 200 OK
Date: Mon, 24 Jul 2006 19:18:47 GMT
Server: Apache/2.0.54 (Fedora)
X-Powered-By: PHP/4.3.11
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8

2169\r\n
\r\n
[...first 0x2169 bytes of response...]\r\n
20b2\r\n
[...next 0x20b2 bytes...]
[...repeat many times...]
20b2\r\n
[...the last 0x20b2 bytes...]
\r\n

The blank line at eof appears to be confusing httplib.py: it
bombs because 

  int('', 16)

raises ValueError.

Observation #1: if this is indeed a protocol error (ie. the
server is in the wrong), httplib.py should turn the
ValueError into an HTTPException.  Perhaps it should define
a new exception class for low-level protocol errors (bad
chunking).  Maybe it should reuse IncompleteRead.

Observation #2: gee, my web browser doesn't barf on this
response, so why should httplib.py?  If there is an error
here, it's at EOF, so it's not that big a deal.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486335&group_id=5470

From noreply at sourceforge.net  Mon Jul 24 22:01:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 24 Jul 2006 13:01:24 -0700
Subject: [ python-Bugs-1283895 ] os.path.abspath() / os.chdir() buggy with
	unicode paths
Message-ID: <E1G56cG-0006e8-9O@sc8-sf-web6.sourceforge.net>

Bugs item #1283895, was opened at 2005-09-07 14:30
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1283895&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.4
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Antoine Pitrou (pitrou)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.abspath() / os.chdir() buggy with unicode paths

Initial Comment:
Hi,

Under Windows Explorer, one can create directory names
using characters not belonging to the user locale. For
example, one of our users created a directory named
"C:\Mes Documents\&#12467;&#12500;&#12540; &#65374; solipsis_svn". 

Unfortunately, when trying to manipulate such a
pathname, os.path.abspath() and os.chdir() don't work
hand in hand. os.path.abspath() uses the garbled
directory name as displayed by the command prompt and
then os.chdir() refuses the path:

C:\>cd "C:\Mes Documents\??? ~ solipsis_svn"

C:\Mes Documents\??? ~ solipsis_svn>python
Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>>
>>> import os
>>> os.curdir
'.'
>>> os.path.abspath(os.curdir)
'C:\\Mes Documents\\??? ~ solipsis_svn'
>>> os.chdir(os.path.abspath(os.curdir))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OSError: [Errno 22] Invalid argument: 'C:\\Mes
Documents\\??? ~ solipsis_svn'
>>>


----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-07-24 22:01

Message:
Logged In: YES 
user_id=21627

abspath invokes getcwd() for a relative string; this, in
turn, invokes the C library function getcwd(); this, in
turn, invokes GetCurrentDirectoryA(); this, in turn, already
returns a bogus response.

So it is Windows that returns a bogus response; there is
nothing Python can do here.

----------------------------------------------------------------------

Comment By: Antoine Pitrou (pitrou)
Date: 2006-07-24 15:10

Message:
Logged In: YES 
user_id=133955

Then why doesn't abspath() throw an exception instead of
silently returning a bogus result? Its behaviour is
counter-intuitive and produces hard-to-find bugs.


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-07-24 15:02

Message:
Logged In: YES 
user_id=21627

This is not a bug. You need to use Unicode path names to
operate on files with names outside of the system code page.

----------------------------------------------------------------------

Comment By: Neil Hodgson (nyamatongwe)
Date: 2005-09-09 15:08

Message:
Logged In: YES 
user_id=12579

This is using byte string arguments causing byte string
processing rather than unicode calls with unicode
processing. Windows code that may encounter file paths
outside the default locale should stick to unicode for
paths. Try converting os.curdir to unicode before calling
other functions:
os.path.abspath(unicode(os.curdir))

----------------------------------------------------------------------

Comment By: Antoine Pitrou (pitrou)
Date: 2005-09-07 14:36

Message:
Logged In: YES 
user_id=133955

> "C:\Mes Documents\&#12467;&#12500;&#12540; &#65374;
solipsis_svn"

Gasp. Sourceforge escapes HTML entities instead of showing
the real characters... These are Japanese characters, btw.
It's easy to copy/paste some Japanese characters from a Web
site and paste them into Windows Explorer to create a
directory (at least it works with Mozilla Firefox).


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1283895&group_id=5470

From noreply at sourceforge.net  Mon Jul 24 22:07:18 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 24 Jul 2006 13:07:18 -0700
Subject: [ python-Bugs-1467929 ] %-formatting and dicts
Message-ID: <E1G56hy-0006bO-Vi@sc8-sf-web6.sourceforge.net>

Bugs item #1467929, was opened at 2006-04-10 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=1467929&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: M.-A. Lemburg (lemburg)
>Assigned to: Anthony Baxter (anthonybaxter)
Summary: %-formatting and dicts

Initial Comment:
This looks like a bug in the way the %-formatting code
works or is it a feature ?

>>> '%s %(a)s' % {'a': 'xyz'}
"{'a': 'xyz'} xyz"

>>> u'%s %(a)s' % {'a': 'xyz'}
u"{'a': 'xyz'} xyz"

Note that both strings and Unicode are affected.

Python 2.3 and 2.4 also show this behavior.

I would have expected an exception or the %-formatter
simply ignoring the first %s.




----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-07-24 22:07

Message:
Logged In: YES 
user_id=21627

IMO, it's correct to break backwards compatibility, as the
current behaviour clearly violates the spec; I'm not sure
whether it's good to break the behaviour *now* (i.e. with no
further betas before the release of 2.5).

Deferring to the release manager.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-07-24 15:37

Message:
Logged In: YES 
user_id=849994

The library ref specifies that if a dict is supplied, the
format specifiers MUST include a mapping key, so the right
thing to do would be to raise an exception.

Is it worth breaking backwards compatibility, Martin?

----------------------------------------------------------------------

Comment By: Hasan Diwan (hdiwan650)
Date: 2006-04-14 10:33

Message:
Logged In: YES 
user_id=1185570

It looks as though it's a feature... The first %s will print
the whole dictionary as a string, the second, only that
value looked up by the key.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467929&group_id=5470

From noreply at sourceforge.net  Mon Jul 24 23:00:59 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 24 Jul 2006 14:00:59 -0700
Subject: [ python-Bugs-1527974 ] tarfile chokes on ipython archive on Windows
Message-ID: <E1G57Xv-0001jk-3I@sc8-sf-web6.sourceforge.net>

Bugs item #1527974, was opened at 2006-07-24 23: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=1527974&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Arve Knudsen (arve_knudsen)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile chokes on ipython archive on Windows

Initial Comment:
I'm trying to extract files from the latest ipython tar
archive, available from
http://ipython.scipy.org/dist/ipython-0.7.2.tar.gz,
using tarfile. This is on Windows XP, using Python
2.4.3. There is only a problem if I open the archive in
stream mode (the "mode" argument to tarfile.open is
"r|gz"), in which case tarfile raises StreamError. I'd
be happy if this error could be sorted out.

The following script should trigger the error:

import tarfile

f = file(r"ipython-0.7.2.tar.gz", "rb")
tar = tarfile.open(fileobj=f, mode="r|gz")
try:
    for m in tar:
        tar.extract(m)
finally:
    tar.close()
    f.close(

The resulting exception:
Traceback (most recent call last):
  File "tst.py", line 7, in ?
    tar.extract(m)
  File "C:\Program Files\Python24\lib\tarfile.py", line
1335, in extract
    self._extract_member(tarinfo, os.path.join(path,
tarinfo.name))
  File "C:\Program Files\Python24\lib\tarfile.py", line
1431, in _extract_member

    self.makelink(tarinfo, targetpath)
  File "C:\Program Files\Python24\lib\tarfile.py", line
1515, in makelink
    self._extract_member(self.getmember(linkpath),
targetpath)
  File "C:\Program Files\Python24\lib\tarfile.py", line
1423, in _extract_member

    self.makefile(tarinfo, targetpath)
  File "C:\Program Files\Python24\lib\tarfile.py", line
1461, in makefile
    copyfileobj(source, target)
  File "C:\Program Files\Python24\lib\tarfile.py", line
158, in copyfileobj
    shutil.copyfileobj(src, dst)
  File "C:\Program Files\Python24\lib\shutil.py", line
22, in copyfileobj
    buf = fsrc.read(length)
  File "C:\Program Files\Python24\lib\tarfile.py", line
551, in _readnormal
    self.fileobj.seek(self.offset + self.pos)
  File "C:\Program Files\Python24\lib\tarfile.py", line
420, in seek
    raise StreamError, "seeking backwards is not allowed"
tarfile.StreamError: seeking backwards is not allowed

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1527974&group_id=5470

From noreply at sourceforge.net  Mon Jul 24 23:04:04 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 24 Jul 2006 14:04:04 -0700
Subject: [ python-Bugs-1229646 ] httplib error checking.
Message-ID: <E1G57au-0006gM-I3@sc8-sf-web6.sourceforge.net>

Bugs item #1229646, was opened at 2005-06-29 07:39
Message generated for change (Comment added) made by gward
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229646&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris Johns (cjohns)
>Assigned to: Greg Ward (gward)
Summary: httplib error checking.

Initial Comment:
The httplib does not seem to handle error codes cleanly
or in a portable way. The socket could return a
ECONNRESET and does on the RTEMS platform. Also value
32 is normally EPIPE, but ECONNRESET is different so
the Python errno should be used.

 [please excuse the manual diff :-)]

line 657:
<           if v[0] == 32:      # Broken pipe
line 657:
>           if v[0] == errno.EPIPE or v[0] ==
errno.ECONNRESET:


line 803:
>           if v[0] != 32 or not self.auto_open:
line 803:
>            if (v[0] != errno.EPIPE and v[0] !=
errno.ECONNRESET) or not self.auto_open:

I can provide a patch if this change make sense.

----------------------------------------------------------------------

>Comment By: Greg Ward (gward)
Date: 2006-07-24 17:04

Message:
Logged In: YES 
user_id=14422

Yes, this bug report absolutely makes sense.  httplib.py
hardcodes errno values, e.g. it uses 32 when it should use
errno.EPIPE.  Bogus.  IMHO this can and should be fixed.

Adding checks for ECONNRESET at the same time as checking
for EPIPE seems OK to me, but I'm not really sure.  I'll try
to whip up a patch.


----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-02 06:50

Message:
Logged In: YES 
user_id=1188172

Can someone judge if this makes sense?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229646&group_id=5470

From noreply at sourceforge.net  Mon Jul 24 21:38:14 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 24 Jul 2006 12:38:14 -0700
Subject: [ python-Bugs-1486335 ] httplib: read/_read_chunked failes with
	ValueError sometime
Message-ID: <E1G56Fq-0002TR-04@sc8-sf-web2.sourceforge.net>

Bugs item #1486335, was opened at 2006-05-11 05:14
Message generated for change (Comment added) made by gward
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486335&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: httplib: read/_read_chunked failes with ValueError sometime

Initial Comment:
This occasionally shows up in a logged trace, when a
application crahes on ValueError on a
http(s)_response.read() :

(py2.3.5 - yet relevant httplib code is still the same
in current httplib) 


.... \'  File "socket.pyo", line 283,
in read\\n\', \'  File "httplib.pyo", line 389, in
read\\n\', \'  File "httplib.pyo", line 426, in
_read_chunked\\n\', \'ValueError: invalid literal for
int(): \\n\']  :::

its the line:

chunk_left = int(line, 16)


Don't know what this line is about. Yet, that should be
protected, as a http_response.read() should not fail
with ValueError, but only with
IOError/EnvironmentError, socket.error - otherwise
Error Exception handling becomes a random task.

-Robert


Side note regarding IO exception handling: See also FR
#1481036 (IOBaseError): why socket.error.__bases__ is
(<class exceptions.Exception at 0x011244E0>,)  ?


----------------------------------------------------------------------

>Comment By: Greg Ward (gward)
Date: 2006-07-24 15:38

Message:
Logged In: YES 
user_id=14422

I'm seeing this with Python 2.3.5 and 2.4.3 hitting a PHP
app and getting a large error page.  It looks as though the
server is incorrectly chunking the response: lwp-request at
least gives a better error message than httplib.py:

  $ GET "http://..."
  500 EOF when chunk header expected

I'm unclear on precisely what the server is doing wrong. 
The response looks like this:

HTTP/1.1 200 OK
Date: Mon, 24 Jul 2006 19:18:47 GMT
Server: Apache/2.0.54 (Fedora)
X-Powered-By: PHP/4.3.11
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8

2169\r\n
\r\n
[...first 0x2169 bytes of response...]\r\n
20b2\r\n
[...next 0x20b2 bytes...]
[...repeat many times...]
20b2\r\n
[...the last 0x20b2 bytes...]
\r\n

The blank line at eof appears to be confusing httplib.py: it
bombs because 

  int('', 16)

raises ValueError.

Observation #1: if this is indeed a protocol error (ie. the
server is in the wrong), httplib.py should turn the
ValueError into an HTTPException.  Perhaps it should define
a new exception class for low-level protocol errors (bad
chunking).  Maybe it should reuse IncompleteRead.

Observation #2: gee, my web browser doesn't barf on this
response, so why should httplib.py?  If there is an error
here, it's at EOF, so it's not that big a deal.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486335&group_id=5470

From noreply at sourceforge.net  Mon Jul 24 23:25:56 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 24 Jul 2006 14:25:56 -0700
Subject: [ python-Feature Requests-1527597 ] New module: miniconf
Message-ID: <E1G57w4-0001Rz-Ca@sc8-sf-web1.sourceforge.net>

Feature Requests item #1527597, was opened at 2006-07-24 07:43
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1527597&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: None
>Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: S.Fourmanoit (syfou)
Assigned to: Nobody/Anonymous (nobody)
Summary: New module: miniconf

Initial Comment:
Find enclosed a new data persistence module: miniconf,
that basically allows the casual creation and reading
of configuration files and similar simple data sets.

I ended-up using part of this code in many projects I
did in Python (such as adesklets), and many other
fellow developers borrowed it from me, so I though it
could be nice to have it as a part of the standard library.

So I cleaned it up, re-factored it as a simple,
standalone module, and here it is, complete with
documentation and its test module.

Find enclosed a patch against svn trunck (Python 2.5b2,
revision 50794). It changes nothing to the tree,
besides adding a one-liner to Doc/lib/lib.tex to
reference the new documentation.

The module also works untouched on Python 2.4.3; I will
be glad to provide a patch against any other tree if
you want me too; all comments are of course welcomed. 


----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-07-24 19:55

Message:
Logged In: YES 
user_id=849994

You'll at least have to raise this on the python-dev list.
It is most probable that you're then asked to let a user
base grow by making the module available e.g. via Cheese
Shop and report back at a time where 2.6 is nearing.

----------------------------------------------------------------------

Comment By: S.Fourmanoit (syfou)
Date: 2006-07-24 16:44

Message:
Logged In: YES 
user_id=1175491

> Have you published this on the Python Cheese Shop?

If did not; without being trivial, I felt this was both
generic and useful enough to be worth the inclusion into the
base library; I managed to miss the feature freeze on python
2.5 -- sorry about that... 

I don't mind submitting it to the Python Cheese Shop, if it
is the right track to have it eventually committed to Python
code base; miniconf having virtually no collateral impact on
the rest of the code, it is indeed perfectly suitable for
distribution as a standalone module for both the 2.4.x and
incoming 2.5.x Python interpreters.

I don't mind either waiting for the end of the feature
freeze, keeping the module up to date as needed against any
new code. I am foreign to the development cycle of Python --
do you know what will be the next window of opportunity?
Into the incoming 2.5 tree when it will be out of the
freeze? Into python 2.6? 

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-07-24 13:39

Message:
Logged In: YES 
user_id=849994

Have you published this on the Python Cheese Shop? This
might be the more appropriate way to make this module known
to other Python developers since there's no way to include
it in 2.5 any more.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1527597&group_id=5470

From noreply at sourceforge.net  Tue Jul 25 01:59:52 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 24 Jul 2006 16:59:52 -0700
Subject: [ python-Bugs-1528074 ] difflib.SequenceMatcher.find_longest_match()
	wrong result
Message-ID: <E1G5AL2-0002oV-Tm@sc8-sf-web6.sourceforge.net>

Bugs item #1528074, was opened at 2006-07-25 09: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=1528074&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: John Machin (sjmachin)
Assigned to: Nobody/Anonymous (nobody)
Summary: difflib.SequenceMatcher.find_longest_match()  wrong result

Initial Comment:
A short example script is attached.
Two strings, each 500 bytes long. Longest match is the
first 32 bytes of each string. Result produced is a
10-byte match later in the string.

If one byte is chopped off the end of each string (len
now 499 each), the correct result is produced.

Other observations, none of which may be relevant:
1. Problem may be in the heuristic for "popular"
elements in the __chain_b method. In this particular
example, the character '0' (which has frequency of 6 in
the "b" string) is not "popular" with a len of 500 but
is "popular" with a len of 499.
2. '0' is the last byte of the correct longest match.
3. The correct longest match is at the start of the
each of the strings.
4. Disabling the "popular" heuristic (like below)
appears to make the problem go away:

                if 0:
                # if n >= 200 and len(indices) * 100 > n:
                    populardict[elt] = 1
                    del indices[:]
                else:
                    indices.append(i)
5. The callable self.isbpopular is created but appears
to be unused.
6. The determination of "popular" doesn't accord with
the comments, which say 1%. However with len==500,
takes 6 to be popular.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528074&group_id=5470

From noreply at sourceforge.net  Tue Jul 25 05:35:55 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 24 Jul 2006 20:35:55 -0700
Subject: [ python-Bugs-1527974 ] tarfile chokes on ipython archive on Windows
Message-ID: <E1G5Di7-0004ni-3Y@sc8-sf-web5.sourceforge.net>

Bugs item #1527974, was opened at 2006-07-24 14:00
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1527974&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Arve Knudsen (arve_knudsen)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile chokes on ipython archive on Windows

Initial Comment:
I'm trying to extract files from the latest ipython tar
archive, available from
http://ipython.scipy.org/dist/ipython-0.7.2.tar.gz,
using tarfile. This is on Windows XP, using Python
2.4.3. There is only a problem if I open the archive in
stream mode (the "mode" argument to tarfile.open is
"r|gz"), in which case tarfile raises StreamError. I'd
be happy if this error could be sorted out.

The following script should trigger the error:

import tarfile

f = file(r"ipython-0.7.2.tar.gz", "rb")
tar = tarfile.open(fileobj=f, mode="r|gz")
try:
    for m in tar:
        tar.extract(m)
finally:
    tar.close()
    f.close(

The resulting exception:
Traceback (most recent call last):
  File "tst.py", line 7, in ?
    tar.extract(m)
  File "C:\Program Files\Python24\lib\tarfile.py", line
1335, in extract
    self._extract_member(tarinfo, os.path.join(path,
tarinfo.name))
  File "C:\Program Files\Python24\lib\tarfile.py", line
1431, in _extract_member

    self.makelink(tarinfo, targetpath)
  File "C:\Program Files\Python24\lib\tarfile.py", line
1515, in makelink
    self._extract_member(self.getmember(linkpath),
targetpath)
  File "C:\Program Files\Python24\lib\tarfile.py", line
1423, in _extract_member

    self.makefile(tarinfo, targetpath)
  File "C:\Program Files\Python24\lib\tarfile.py", line
1461, in makefile
    copyfileobj(source, target)
  File "C:\Program Files\Python24\lib\tarfile.py", line
158, in copyfileobj
    shutil.copyfileobj(src, dst)
  File "C:\Program Files\Python24\lib\shutil.py", line
22, in copyfileobj
    buf = fsrc.read(length)
  File "C:\Program Files\Python24\lib\tarfile.py", line
551, in _readnormal
    self.fileobj.seek(self.offset + self.pos)
  File "C:\Program Files\Python24\lib\tarfile.py", line
420, in seek
    raise StreamError, "seeking backwards is not allowed"
tarfile.StreamError: seeking backwards is not allowed

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-24 20:35

Message:
Logged In: YES 
user_id=33168

I tested this on Linux with both 2.5 and 2.4.3+ without
problems.  I believe there were some fixes in this area. 
Could you try testing with the 2.4.3+ current which will
become 2.4.4 (or 2.5b2)?  If this is still a problem, it
looks like it may be Windows specific.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1527974&group_id=5470

From noreply at sourceforge.net  Tue Jul 25 05:46:36 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 24 Jul 2006 20:46:36 -0700
Subject: [ python-Bugs-1526585 ] Concatenation on a long string breaks
Message-ID: <E1G5DsS-0001cW-Vt@sc8-sf-web5.sourceforge.net>

Bugs item #1526585, was opened at 2006-07-21 10:18
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1526585&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
>Priority: 6
Submitted By: Jp Calderone (kuran)
Assigned to: Nobody/Anonymous (nobody)
Summary: Concatenation on a long string breaks

Initial Comment:
Consider this transcript:

exarkun at charm:~/Projects/python/trunk$ ./python
Python 2.5b2 (trunk:50698, Jul 18 2006, 10:08:36)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> x = 'x' * (2 ** 31 - 1)
>>> x = x + 'x'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SystemError: Objects/stringobject.c:4103: bad argument
to internal function
>>> len(x)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'x' is not defined
>>> 


I would expect some exception other than SystemError
and for the locals namespace to not become corrupted.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-24 20:46

Message:
Logged In: YES 
user_id=33168

Attached a patch against 2.5.  The patch should work against
2.4 too, but you will need to change all Py_ssize_t to int.
 Tim since we know both lens are >= 0, is this test
sufficient for verifying overflow:

      Py_ssize_t new_len = v_len + w_len;
      if (new_len < 0) {

Jp, can you test the patch?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-22 07:11

Message:
Logged In: YES 
user_id=31435

Part of the problem appears to be that ceval.c's
string_concatenate() doesn't check for overflow in the
second argument here:

if (_PyString_Resize(&v, v_len + w_len) != 0)

The Windows malloc on my box returns NULL (and so Python
raises MemoryError) on the initial:

x = 'x' * (2 ** 31 - 1)

attempt, so I never get that far.  I'm afraid this is
muddier in strange ways on Linux because the Linux malloc()
is pathologically optimistic (can return a non-NULL value
pointing at "memory" that can't actually be used for anything).

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2006-07-22 02:00

Message:
Logged In: YES 
user_id=6656

Confirmed with 2.4.  Ouch.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1526585&group_id=5470

From noreply at sourceforge.net  Tue Jul 25 05:57:51 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 24 Jul 2006 20:57:51 -0700
Subject: [ python-Bugs-1526585 ] Concatenation on a long string breaks
Message-ID: <E1G5E3L-0007jF-Uz@sc8-sf-web3.sourceforge.net>

Bugs item #1526585, was opened at 2006-07-21 13: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=1526585&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 6
Submitted By: Jp Calderone (kuran)
Assigned to: Nobody/Anonymous (nobody)
Summary: Concatenation on a long string breaks

Initial Comment:
Consider this transcript:

exarkun at charm:~/Projects/python/trunk$ ./python
Python 2.5b2 (trunk:50698, Jul 18 2006, 10:08:36)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> x = 'x' * (2 ** 31 - 1)
>>> x = x + 'x'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SystemError: Objects/stringobject.c:4103: bad argument
to internal function
>>> len(x)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'x' is not defined
>>> 


I would expect some exception other than SystemError
and for the locals namespace to not become corrupted.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-07-24 23:57

Message:
Logged In: YES 
user_id=31435

[Neal]
>  Tim since we know both lens are >= 0, is this test
> sufficient for verifying overflow:
>
>     Py_ssize_t new_len = v_len + w_len;
>     if (new_len < 0) {

Right!  That's all the new checking needed in
string_concatenate().

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-24 23:46

Message:
Logged In: YES 
user_id=33168

Attached a patch against 2.5.  The patch should work against
2.4 too, but you will need to change all Py_ssize_t to int.
 Tim since we know both lens are >= 0, is this test
sufficient for verifying overflow:

      Py_ssize_t new_len = v_len + w_len;
      if (new_len < 0) {

Jp, can you test the patch?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-22 10:11

Message:
Logged In: YES 
user_id=31435

Part of the problem appears to be that ceval.c's
string_concatenate() doesn't check for overflow in the
second argument here:

if (_PyString_Resize(&v, v_len + w_len) != 0)

The Windows malloc on my box returns NULL (and so Python
raises MemoryError) on the initial:

x = 'x' * (2 ** 31 - 1)

attempt, so I never get that far.  I'm afraid this is
muddier in strange ways on Linux because the Linux malloc()
is pathologically optimistic (can return a non-NULL value
pointing at "memory" that can't actually be used for anything).

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2006-07-22 05:00

Message:
Logged In: YES 
user_id=6656

Confirmed with 2.4.  Ouch.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1526585&group_id=5470

From noreply at sourceforge.net  Tue Jul 25 06:06:28 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 24 Jul 2006 21:06:28 -0700
Subject: [ python-Bugs-1518621 ] optparse.parse_args() ret value seems to be a
	dict but isn't
Message-ID: <E1G5EBg-00020k-C5@sc8-sf-web1.sourceforge.net>

Bugs item #1518621, was opened at 2006-07-07 02:35
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1518621&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: rhunger (rhunger)
>Assigned to: Greg Ward (gward)
Summary: optparse.parse_args() ret value seems to be a dict but isn't

Initial Comment:
...
from optparse import OptionParser
parser = OptionParser()
...
(options, args) = parser.parse_args()
print options
...

options seems to be a dict but isn't. So it's not possible to use e.g.

print "Option 1: %(firstOption)s" % options

Here it's easy to use "options.firstOption" but with a larger number of program options it would be nice to be able to use "options" as a dict directly.

(patch attached)

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-24 21:06

Message:
Logged In: YES 
user_id=33168

Greg, are you using the Python tracker or only optik tracker?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1518621&group_id=5470

From noreply at sourceforge.net  Tue Jul 25 06:44:07 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 24 Jul 2006 21:44:07 -0700
Subject: [ python-Feature Requests-1528154 ] New sequences for Unicode classes
	needed
Message-ID: <E1G5Em7-000538-Da@sc8-sf-web5.sourceforge.net>

Feature Requests item #1528154, was opened at 2006-07-25 15:44
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=1528154&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Regular Expressions
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: gmarketer (gmarketer)
Assigned to: Nobody/Anonymous (nobody)
Summary: New sequences for Unicode classes needed

Initial Comment:
The special sequences consist of "\" and another
character need to be added to RE sintax to simplify the
finding of several Unicode classes like:
 * All uppercase letters
 * All lowercase letters


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1528154&group_id=5470

From noreply at sourceforge.net  Tue Jul 25 06:45:17 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 24 Jul 2006 21:45:17 -0700
Subject: [ python-Feature Requests-1528154 ] New sequences for Unicode classes
	needed
Message-ID: <E1G5EnF-0003tb-Ju@sc8-sf-web6.sourceforge.net>

Feature Requests item #1528154, was opened at 2006-07-25 15:44
Message generated for change (Settings changed) made by gmarketer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1528154&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Regular Expressions
Group: None
Status: Open
Resolution: None
>Priority: 6
Submitted By: gmarketer (gmarketer)
Assigned to: Nobody/Anonymous (nobody)
Summary: New sequences for Unicode classes needed

Initial Comment:
The special sequences consist of "\" and another
character need to be added to RE sintax to simplify the
finding of several Unicode classes like:
 * All uppercase letters
 * All lowercase letters


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1528154&group_id=5470

From noreply at sourceforge.net  Tue Jul 25 08:20:11 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 24 Jul 2006 23:20:11 -0700
Subject: [ python-Feature Requests-1527597 ] New module: miniconf
Message-ID: <E1G5GH5-0001ad-5k@sc8-sf-web6.sourceforge.net>

Feature Requests item #1527597, was opened at 2006-07-24 03:43
Message generated for change (Comment added) made by syfou
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1527597&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: S.Fourmanoit (syfou)
Assigned to: Nobody/Anonymous (nobody)
Summary: New module: miniconf

Initial Comment:
Find enclosed a new data persistence module: miniconf,
that basically allows the casual creation and reading
of configuration files and similar simple data sets.

I ended-up using part of this code in many projects I
did in Python (such as adesklets), and many other
fellow developers borrowed it from me, so I though it
could be nice to have it as a part of the standard library.

So I cleaned it up, re-factored it as a simple,
standalone module, and here it is, complete with
documentation and its test module.

Find enclosed a patch against svn trunck (Python 2.5b2,
revision 50794). It changes nothing to the tree,
besides adding a one-liner to Doc/lib/lib.tex to
reference the new documentation.

The module also works untouched on Python 2.4.3; I will
be glad to provide a patch against any other tree if
you want me too; all comments are of course welcomed. 


----------------------------------------------------------------------

>Comment By: S.Fourmanoit (syfou)
Date: 2006-07-25 02:20

Message:
Logged In: YES 
user_id=1175491

Current miniconf entry on the Python Cheese Shop:

http://cheeseshop.python.org/pypi?:action=display&name=miniconf&version=1.0.1

Thanks for your diligent feedback so far; I will send a
short message to python-dev tomorrow.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-07-24 15:55

Message:
Logged In: YES 
user_id=849994

You'll at least have to raise this on the python-dev list.
It is most probable that you're then asked to let a user
base grow by making the module available e.g. via Cheese
Shop and report back at a time where 2.6 is nearing.

----------------------------------------------------------------------

Comment By: S.Fourmanoit (syfou)
Date: 2006-07-24 12:44

Message:
Logged In: YES 
user_id=1175491

> Have you published this on the Python Cheese Shop?

If did not; without being trivial, I felt this was both
generic and useful enough to be worth the inclusion into the
base library; I managed to miss the feature freeze on python
2.5 -- sorry about that... 

I don't mind submitting it to the Python Cheese Shop, if it
is the right track to have it eventually committed to Python
code base; miniconf having virtually no collateral impact on
the rest of the code, it is indeed perfectly suitable for
distribution as a standalone module for both the 2.4.x and
incoming 2.5.x Python interpreters.

I don't mind either waiting for the end of the feature
freeze, keeping the module up to date as needed against any
new code. I am foreign to the development cycle of Python --
do you know what will be the next window of opportunity?
Into the incoming 2.5 tree when it will be out of the
freeze? Into python 2.6? 

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-07-24 09:39

Message:
Logged In: YES 
user_id=849994

Have you published this on the Python Cheese Shop? This
might be the more appropriate way to make this module known
to other Python developers since there's no way to include
it in 2.5 any more.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1527597&group_id=5470

From noreply at sourceforge.net  Tue Jul 25 09:29:51 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 25 Jul 2006 00:29:51 -0700
Subject: [ python-Bugs-1527974 ] tarfile chokes on ipython archive on Windows
Message-ID: <E1G5HMV-0001v7-GV@sc8-sf-web2.sourceforge.net>

Bugs item #1527974, was opened at 2006-07-24 23:00
Message generated for change (Comment added) made by arve_knudsen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1527974&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Arve Knudsen (arve_knudsen)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile chokes on ipython archive on Windows

Initial Comment:
I'm trying to extract files from the latest ipython tar
archive, available from
http://ipython.scipy.org/dist/ipython-0.7.2.tar.gz,
using tarfile. This is on Windows XP, using Python
2.4.3. There is only a problem if I open the archive in
stream mode (the "mode" argument to tarfile.open is
"r|gz"), in which case tarfile raises StreamError. I'd
be happy if this error could be sorted out.

The following script should trigger the error:

import tarfile

f = file(r"ipython-0.7.2.tar.gz", "rb")
tar = tarfile.open(fileobj=f, mode="r|gz")
try:
    for m in tar:
        tar.extract(m)
finally:
    tar.close()
    f.close(

The resulting exception:
Traceback (most recent call last):
  File "tst.py", line 7, in ?
    tar.extract(m)
  File "C:\Program Files\Python24\lib\tarfile.py", line
1335, in extract
    self._extract_member(tarinfo, os.path.join(path,
tarinfo.name))
  File "C:\Program Files\Python24\lib\tarfile.py", line
1431, in _extract_member

    self.makelink(tarinfo, targetpath)
  File "C:\Program Files\Python24\lib\tarfile.py", line
1515, in makelink
    self._extract_member(self.getmember(linkpath),
targetpath)
  File "C:\Program Files\Python24\lib\tarfile.py", line
1423, in _extract_member

    self.makefile(tarinfo, targetpath)
  File "C:\Program Files\Python24\lib\tarfile.py", line
1461, in makefile
    copyfileobj(source, target)
  File "C:\Program Files\Python24\lib\tarfile.py", line
158, in copyfileobj
    shutil.copyfileobj(src, dst)
  File "C:\Program Files\Python24\lib\shutil.py", line
22, in copyfileobj
    buf = fsrc.read(length)
  File "C:\Program Files\Python24\lib\tarfile.py", line
551, in _readnormal
    self.fileobj.seek(self.offset + self.pos)
  File "C:\Program Files\Python24\lib\tarfile.py", line
420, in seek
    raise StreamError, "seeking backwards is not allowed"
tarfile.StreamError: seeking backwards is not allowed

----------------------------------------------------------------------

>Comment By: Arve Knudsen (arve_knudsen)
Date: 2006-07-25 09:29

Message:
Logged In: YES 
user_id=1522083

Well yeah, it appears to be Windows specific. I just tested
on Linux (Ubuntu), also with Python 2.4.3. I'll try 2.4.3+
on Windows to see if it makes any difference. Come to think
of it I think I experienced this problem in that past on
Linux, but then I solved it by repacking ipython. Also, if I
pack it myself on Windows using bsdtar it works fine.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-25 05:35

Message:
Logged In: YES 
user_id=33168

I tested this on Linux with both 2.5 and 2.4.3+ without
problems.  I believe there were some fixes in this area. 
Could you try testing with the 2.4.3+ current which will
become 2.4.4 (or 2.5b2)?  If this is still a problem, it
looks like it may be Windows specific.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1527974&group_id=5470

From noreply at sourceforge.net  Tue Jul 25 09:46:00 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 25 Jul 2006 00:46:00 -0700
Subject: [ python-Feature Requests-1528154 ] New sequences for Unicode classes
	needed
Message-ID: <E1G5Hc8-0008EO-9L@sc8-sf-web2.sourceforge.net>

Feature Requests item #1528154, was opened at 2006-07-25 06:44
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1528154&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Regular Expressions
Group: None
Status: Open
Resolution: None
Priority: 6
Submitted By: gmarketer (gmarketer)
Assigned to: Nobody/Anonymous (nobody)
Summary: New sequences for Unicode classes needed

Initial Comment:
The special sequences consist of "\" and another
character need to be added to RE sintax to simplify the
finding of several Unicode classes like:
 * All uppercase letters
 * All lowercase letters


----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2006-07-25 09:45

Message:
Logged In: YES 
user_id=38388

Could you make your request a little more specific ?

We already have catregories in the re module, so adding a
few more would be possible (patches are welcome !). However,
we do need to know why you need them and whether there are
other RE implementations that already have such special
matching characters, e.g. the Perl RE implementation.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1528154&group_id=5470

From noreply at sourceforge.net  Tue Jul 25 09:54:33 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 25 Jul 2006 00:54:33 -0700
Subject: [ python-Bugs-1465408 ] Building 2.5a1 requires python
Message-ID: <E1G5HkP-0003k7-3g@sc8-sf-web6.sourceforge.net>

Bugs item #1465408, was opened at 2006-04-06 09:34
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465408&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
>Status: Closed
>Resolution: Accepted
Priority: 7
Submitted By: Ralf W. Grosse-Kunstleve (rwgk)
Assigned to: Nobody/Anonymous (nobody)
Summary: Building 2.5a1 requires python

Initial Comment:
% uname -a
HP-UX td176 B.11.23 U ia64 1928826293 unlimited-user
license

% cc -V
cc: HP aC++/ANSI C B3910B A.06.07 [Feb 2 2006]

env CC=cc CXX=aCC ./configure
--prefix=/var/tmp/rwgk/py25a1 --without-gcc
make

The output of make ends with:

  No such file or directory: python
  *** Error exit code 127

  Stop.

I'll upload the full output of configure and make.

Note that the testdrive machine is publically accessible:

http://www.testdrive.hp.com/
telnet td176.testdrive.hp.com


----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-07-25 17:54

Message:
Logged In: YES 
user_id=29957

The welease tool now does the right thing to touch the files
before building the tarballs.


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-11 19:26

Message:
Logged In: YES 
user_id=21627

The welease script should check that the exported time
stamps are already in the right sequence (i.e.
Python-ast.[ch] newer than their dependencies). If this is
not the case, a commit should be forced on the file that is
too old. Then, if the files don't change before the next
release, no time stamp changing will be necessary.

----------------------------------------------------------------------

Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2006-04-07 02:16

Message:
Logged In: YES 
user_id=71407

I get a complete build if I

touch Include/Python-ast.h Python/Python-ast.c

before running configure. If you wait a second after the svn
export and then touch these two files I'd expect the tarball
to work out of the box.

Another idea is to work with MD5 signatures, like SCons
does. But if you don't have a Python yet it is probably
difficult to find a fully portable solution.


----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-04-06 17:56

Message:
Logged In: YES 
user_id=29957

Right. Python.asdl and the output files that depend on it
have the same timestamps in the tarball. This is because
they get updated and all checked in in the same svn
revision. When the export is done, the timestamps are set to
the same time. 

Possible solutions:
  - make ignores this failure. Bad, because it might stop
_real_ errors.
  - make catches lack of Python, and skips the step. Ugly,
and hard to do in a platform-compatible way.
  - I change the 'welease.py' script to adjust the
timestamps of the files before making the release tarballs.
 This is so nasty it makes me sick. But I can't see a better
option. 


----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-04-06 17:48

Message:
Logged In: YES 
user_id=29957



If you put a '-' at the start of the line in the Makefile,
it should build ok. Make it:

$(AST_H) $(AST_C): $(AST_ASDL) $(ASDLGEN_FILES)
        -$(ASDLGEN) $(AST_ASDL)

Obviously there's some issues with timestamps on the files
and it's trying to rebuild the file unnecessarily...


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465408&group_id=5470

From noreply at sourceforge.net  Tue Jul 25 10:04:44 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 25 Jul 2006 01:04:44 -0700
Subject: [ python-Bugs-1527974 ] tarfile chokes on ipython archive on Windows
Message-ID: <E1G5HuG-00023j-2g@sc8-sf-web6.sourceforge.net>

Bugs item #1527974, was opened at 2006-07-24 23:00
Message generated for change (Comment added) made by arve_knudsen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1527974&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Arve Knudsen (arve_knudsen)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile chokes on ipython archive on Windows

Initial Comment:
I'm trying to extract files from the latest ipython tar
archive, available from
http://ipython.scipy.org/dist/ipython-0.7.2.tar.gz,
using tarfile. This is on Windows XP, using Python
2.4.3. There is only a problem if I open the archive in
stream mode (the "mode" argument to tarfile.open is
"r|gz"), in which case tarfile raises StreamError. I'd
be happy if this error could be sorted out.

The following script should trigger the error:

import tarfile

f = file(r"ipython-0.7.2.tar.gz", "rb")
tar = tarfile.open(fileobj=f, mode="r|gz")
try:
    for m in tar:
        tar.extract(m)
finally:
    tar.close()
    f.close(

The resulting exception:
Traceback (most recent call last):
  File "tst.py", line 7, in ?
    tar.extract(m)
  File "C:\Program Files\Python24\lib\tarfile.py", line
1335, in extract
    self._extract_member(tarinfo, os.path.join(path,
tarinfo.name))
  File "C:\Program Files\Python24\lib\tarfile.py", line
1431, in _extract_member

    self.makelink(tarinfo, targetpath)
  File "C:\Program Files\Python24\lib\tarfile.py", line
1515, in makelink
    self._extract_member(self.getmember(linkpath),
targetpath)
  File "C:\Program Files\Python24\lib\tarfile.py", line
1423, in _extract_member

    self.makefile(tarinfo, targetpath)
  File "C:\Program Files\Python24\lib\tarfile.py", line
1461, in makefile
    copyfileobj(source, target)
  File "C:\Program Files\Python24\lib\tarfile.py", line
158, in copyfileobj
    shutil.copyfileobj(src, dst)
  File "C:\Program Files\Python24\lib\shutil.py", line
22, in copyfileobj
    buf = fsrc.read(length)
  File "C:\Program Files\Python24\lib\tarfile.py", line
551, in _readnormal
    self.fileobj.seek(self.offset + self.pos)
  File "C:\Program Files\Python24\lib\tarfile.py", line
420, in seek
    raise StreamError, "seeking backwards is not allowed"
tarfile.StreamError: seeking backwards is not allowed

----------------------------------------------------------------------

>Comment By: Arve Knudsen (arve_knudsen)
Date: 2006-07-25 10:04

Message:
Logged In: YES 
user_id=1522083

Ok, I've verified now that the problem persists with Python
2.4.4 (from the 2.4 branch in svn). The exact same thing
happens.

----------------------------------------------------------------------

Comment By: Arve Knudsen (arve_knudsen)
Date: 2006-07-25 09:29

Message:
Logged In: YES 
user_id=1522083

Well yeah, it appears to be Windows specific. I just tested
on Linux (Ubuntu), also with Python 2.4.3. I'll try 2.4.3+
on Windows to see if it makes any difference. Come to think
of it I think I experienced this problem in that past on
Linux, but then I solved it by repacking ipython. Also, if I
pack it myself on Windows using bsdtar it works fine.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-25 05:35

Message:
Logged In: YES 
user_id=33168

I tested this on Linux with both 2.5 and 2.4.3+ without
problems.  I believe there were some fixes in this area. 
Could you try testing with the 2.4.3+ current which will
become 2.4.4 (or 2.5b2)?  If this is still a problem, it
looks like it may be Windows specific.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1527974&group_id=5470

From noreply at sourceforge.net  Tue Jul 25 10:42:37 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 25 Jul 2006 01:42:37 -0700
Subject: [ python-Bugs-1527974 ] tarfile chokes on ipython archive on Windows
Message-ID: <E1G5IUv-00044Q-BI@sc8-sf-web2.sourceforge.net>

Bugs item #1527974, was opened at 2006-07-24 23:00
Message generated for change (Comment added) made by gustaebel
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1527974&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Arve Knudsen (arve_knudsen)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile chokes on ipython archive on Windows

Initial Comment:
I'm trying to extract files from the latest ipython tar
archive, available from
http://ipython.scipy.org/dist/ipython-0.7.2.tar.gz,
using tarfile. This is on Windows XP, using Python
2.4.3. There is only a problem if I open the archive in
stream mode (the "mode" argument to tarfile.open is
"r|gz"), in which case tarfile raises StreamError. I'd
be happy if this error could be sorted out.

The following script should trigger the error:

import tarfile

f = file(r"ipython-0.7.2.tar.gz", "rb")
tar = tarfile.open(fileobj=f, mode="r|gz")
try:
    for m in tar:
        tar.extract(m)
finally:
    tar.close()
    f.close(

The resulting exception:
Traceback (most recent call last):
  File "tst.py", line 7, in ?
    tar.extract(m)
  File "C:\Program Files\Python24\lib\tarfile.py", line
1335, in extract
    self._extract_member(tarinfo, os.path.join(path,
tarinfo.name))
  File "C:\Program Files\Python24\lib\tarfile.py", line
1431, in _extract_member

    self.makelink(tarinfo, targetpath)
  File "C:\Program Files\Python24\lib\tarfile.py", line
1515, in makelink
    self._extract_member(self.getmember(linkpath),
targetpath)
  File "C:\Program Files\Python24\lib\tarfile.py", line
1423, in _extract_member

    self.makefile(tarinfo, targetpath)
  File "C:\Program Files\Python24\lib\tarfile.py", line
1461, in makefile
    copyfileobj(source, target)
  File "C:\Program Files\Python24\lib\tarfile.py", line
158, in copyfileobj
    shutil.copyfileobj(src, dst)
  File "C:\Program Files\Python24\lib\shutil.py", line
22, in copyfileobj
    buf = fsrc.read(length)
  File "C:\Program Files\Python24\lib\tarfile.py", line
551, in _readnormal
    self.fileobj.seek(self.offset + self.pos)
  File "C:\Program Files\Python24\lib\tarfile.py", line
420, in seek
    raise StreamError, "seeking backwards is not allowed"
tarfile.StreamError: seeking backwards is not allowed

----------------------------------------------------------------------

Comment By: Lars Gust?bel (gustaebel)
Date: 2006-07-25 10:42

Message:
Logged In: YES 
user_id=642936

The traceback tells me that there is a hard link inside the
archive which means that a file in the archive is referenced
to twice. This hard link can be extracted only on platforms
that have an os.link() function. On Win32 they're not
supported by the file system, but tarfile works around this
by extracting the referenced file twice. In order to extract
the file the second time it is necessary that tarfile seeks
back in the input file to access the file's data again. But
"seeking backwards is not allowed" when a file is opened in
streaming mode ;-)
If you do not necessarily need streaming mode for your
application, better use "r:gz" or "r" and the problem will
be gone.

----------------------------------------------------------------------

Comment By: Arve Knudsen (arve_knudsen)
Date: 2006-07-25 10:04

Message:
Logged In: YES 
user_id=1522083

Ok, I've verified now that the problem persists with Python
2.4.4 (from the 2.4 branch in svn). The exact same thing
happens.

----------------------------------------------------------------------

Comment By: Arve Knudsen (arve_knudsen)
Date: 2006-07-25 09:29

Message:
Logged In: YES 
user_id=1522083

Well yeah, it appears to be Windows specific. I just tested
on Linux (Ubuntu), also with Python 2.4.3. I'll try 2.4.3+
on Windows to see if it makes any difference. Come to think
of it I think I experienced this problem in that past on
Linux, but then I solved it by repacking ipython. Also, if I
pack it myself on Windows using bsdtar it works fine.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-25 05:35

Message:
Logged In: YES 
user_id=33168

I tested this on Linux with both 2.5 and 2.4.3+ without
problems.  I believe there were some fixes in this area. 
Could you try testing with the 2.4.3+ current which will
become 2.4.4 (or 2.5b2)?  If this is still a problem, it
looks like it may be Windows specific.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1527974&group_id=5470

From noreply at sourceforge.net  Tue Jul 25 10:59:47 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 25 Jul 2006 01:59:47 -0700
Subject: [ python-Bugs-1527974 ] tarfile chokes on ipython archive on Windows
Message-ID: <E1G5IlX-0003tN-GT@sc8-sf-web1.sourceforge.net>

Bugs item #1527974, was opened at 2006-07-24 23:00
Message generated for change (Comment added) made by arve_knudsen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1527974&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Arve Knudsen (arve_knudsen)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile chokes on ipython archive on Windows

Initial Comment:
I'm trying to extract files from the latest ipython tar
archive, available from
http://ipython.scipy.org/dist/ipython-0.7.2.tar.gz,
using tarfile. This is on Windows XP, using Python
2.4.3. There is only a problem if I open the archive in
stream mode (the "mode" argument to tarfile.open is
"r|gz"), in which case tarfile raises StreamError. I'd
be happy if this error could be sorted out.

The following script should trigger the error:

import tarfile

f = file(r"ipython-0.7.2.tar.gz", "rb")
tar = tarfile.open(fileobj=f, mode="r|gz")
try:
    for m in tar:
        tar.extract(m)
finally:
    tar.close()
    f.close(

The resulting exception:
Traceback (most recent call last):
  File "tst.py", line 7, in ?
    tar.extract(m)
  File "C:\Program Files\Python24\lib\tarfile.py", line
1335, in extract
    self._extract_member(tarinfo, os.path.join(path,
tarinfo.name))
  File "C:\Program Files\Python24\lib\tarfile.py", line
1431, in _extract_member

    self.makelink(tarinfo, targetpath)
  File "C:\Program Files\Python24\lib\tarfile.py", line
1515, in makelink
    self._extract_member(self.getmember(linkpath),
targetpath)
  File "C:\Program Files\Python24\lib\tarfile.py", line
1423, in _extract_member

    self.makefile(tarinfo, targetpath)
  File "C:\Program Files\Python24\lib\tarfile.py", line
1461, in makefile
    copyfileobj(source, target)
  File "C:\Program Files\Python24\lib\tarfile.py", line
158, in copyfileobj
    shutil.copyfileobj(src, dst)
  File "C:\Program Files\Python24\lib\shutil.py", line
22, in copyfileobj
    buf = fsrc.read(length)
  File "C:\Program Files\Python24\lib\tarfile.py", line
551, in _readnormal
    self.fileobj.seek(self.offset + self.pos)
  File "C:\Program Files\Python24\lib\tarfile.py", line
420, in seek
    raise StreamError, "seeking backwards is not allowed"
tarfile.StreamError: seeking backwards is not allowed

----------------------------------------------------------------------

>Comment By: Arve Knudsen (arve_knudsen)
Date: 2006-07-25 10:59

Message:
Logged In: YES 
user_id=1522083

Thanks for the clarification, Lars. I'd prefer to continue
with my current approach however, since it allows me to
report progress as the tarfile is unpacked/decompressed.
Also, I don't think it would be satisfactory at all if
tarfile would just die with a mysterious error in such cases.

In order to resolve this, why must tarfile extract the file
again, can't it copy the already extracted file?

----------------------------------------------------------------------

Comment By: Lars Gust?bel (gustaebel)
Date: 2006-07-25 10:42

Message:
Logged In: YES 
user_id=642936

The traceback tells me that there is a hard link inside the
archive which means that a file in the archive is referenced
to twice. This hard link can be extracted only on platforms
that have an os.link() function. On Win32 they're not
supported by the file system, but tarfile works around this
by extracting the referenced file twice. In order to extract
the file the second time it is necessary that tarfile seeks
back in the input file to access the file's data again. But
"seeking backwards is not allowed" when a file is opened in
streaming mode ;-)
If you do not necessarily need streaming mode for your
application, better use "r:gz" or "r" and the problem will
be gone.

----------------------------------------------------------------------

Comment By: Arve Knudsen (arve_knudsen)
Date: 2006-07-25 10:04

Message:
Logged In: YES 
user_id=1522083

Ok, I've verified now that the problem persists with Python
2.4.4 (from the 2.4 branch in svn). The exact same thing
happens.

----------------------------------------------------------------------

Comment By: Arve Knudsen (arve_knudsen)
Date: 2006-07-25 09:29

Message:
Logged In: YES 
user_id=1522083

Well yeah, it appears to be Windows specific. I just tested
on Linux (Ubuntu), also with Python 2.4.3. I'll try 2.4.3+
on Windows to see if it makes any difference. Come to think
of it I think I experienced this problem in that past on
Linux, but then I solved it by repacking ipython. Also, if I
pack it myself on Windows using bsdtar it works fine.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-25 05:35

Message:
Logged In: YES 
user_id=33168

I tested this on Linux with both 2.5 and 2.4.3+ without
problems.  I believe there were some fixes in this area. 
Could you try testing with the 2.4.3+ current which will
become 2.4.4 (or 2.5b2)?  If this is still a problem, it
looks like it may be Windows specific.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1527974&group_id=5470

From noreply at sourceforge.net  Tue Jul 25 11:13:04 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 25 Jul 2006 02:13:04 -0700
Subject: [ python-Bugs-1528258 ] urllib2 data argument
Message-ID: <E1G5IyO-0000kb-OH@sc8-sf-web6.sourceforge.net>

Bugs item #1528258, was opened at 2006-07-25 09: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=1528258&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 data argument

Initial Comment:
urllib2.Request takes constructor args (url, data,
headers, ...) where data and headers are optional. 
data is described as a string which, if supplied,
causes urlopen to process the request as a POST rather
than a GET.  And there's no way to set headers without
passing a value for data.  So if you want to send a GET
with special headers, the docs leave you scratching
your head.

The solution is to pass None instead of a string for
data.  The doc should say that.

In general the urllib2 docs are somewhat dependent on
the urllib docs.  Some refactoring would be good.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528258&group_id=5470

From noreply at sourceforge.net  Tue Jul 25 11:13:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 25 Jul 2006 02:13:46 -0700
Subject: [ python-Bugs-1528258 ] urllib2 data argument
Message-ID: <E1G5Iz4-0006v4-KM@sc8-sf-web2.sourceforge.net>

Bugs item #1528258, was opened at 2006-07-25 09:13
Message generated for change (Comment added) made by phr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528258&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 data argument

Initial Comment:
urllib2.Request takes constructor args (url, data,
headers, ...) where data and headers are optional. 
data is described as a string which, if supplied,
causes urlopen to process the request as a POST rather
than a GET.  And there's no way to set headers without
passing a value for data.  So if you want to send a GET
with special headers, the docs leave you scratching
your head.

The solution is to pass None instead of a string for
data.  The doc should say that.

In general the urllib2 docs are somewhat dependent on
the urllib docs.  Some refactoring would be good.

----------------------------------------------------------------------

>Comment By: paul rubin (phr)
Date: 2006-07-25 09:13

Message:
Logged In: YES 
user_id=72053

Forgot to mention, this is Python 2.4.1.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528258&group_id=5470

From noreply at sourceforge.net  Tue Jul 25 11:31:29 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 25 Jul 2006 02:31:29 -0700
Subject: [ python-Bugs-1527974 ] tarfile chokes on ipython archive on Windows
Message-ID: <E1G5JGD-0007TX-Ao@sc8-sf-web1.sourceforge.net>

Bugs item #1527974, was opened at 2006-07-24 23:00
Message generated for change (Comment added) made by gustaebel
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1527974&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Arve Knudsen (arve_knudsen)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile chokes on ipython archive on Windows

Initial Comment:
I'm trying to extract files from the latest ipython tar
archive, available from
http://ipython.scipy.org/dist/ipython-0.7.2.tar.gz,
using tarfile. This is on Windows XP, using Python
2.4.3. There is only a problem if I open the archive in
stream mode (the "mode" argument to tarfile.open is
"r|gz"), in which case tarfile raises StreamError. I'd
be happy if this error could be sorted out.

The following script should trigger the error:

import tarfile

f = file(r"ipython-0.7.2.tar.gz", "rb")
tar = tarfile.open(fileobj=f, mode="r|gz")
try:
    for m in tar:
        tar.extract(m)
finally:
    tar.close()
    f.close(

The resulting exception:
Traceback (most recent call last):
  File "tst.py", line 7, in ?
    tar.extract(m)
  File "C:\Program Files\Python24\lib\tarfile.py", line
1335, in extract
    self._extract_member(tarinfo, os.path.join(path,
tarinfo.name))
  File "C:\Program Files\Python24\lib\tarfile.py", line
1431, in _extract_member

    self.makelink(tarinfo, targetpath)
  File "C:\Program Files\Python24\lib\tarfile.py", line
1515, in makelink
    self._extract_member(self.getmember(linkpath),
targetpath)
  File "C:\Program Files\Python24\lib\tarfile.py", line
1423, in _extract_member

    self.makefile(tarinfo, targetpath)
  File "C:\Program Files\Python24\lib\tarfile.py", line
1461, in makefile
    copyfileobj(source, target)
  File "C:\Program Files\Python24\lib\tarfile.py", line
158, in copyfileobj
    shutil.copyfileobj(src, dst)
  File "C:\Program Files\Python24\lib\shutil.py", line
22, in copyfileobj
    buf = fsrc.read(length)
  File "C:\Program Files\Python24\lib\tarfile.py", line
551, in _readnormal
    self.fileobj.seek(self.offset + self.pos)
  File "C:\Program Files\Python24\lib\tarfile.py", line
420, in seek
    raise StreamError, "seeking backwards is not allowed"
tarfile.StreamError: seeking backwards is not allowed

----------------------------------------------------------------------

Comment By: Lars Gust?bel (gustaebel)
Date: 2006-07-25 11:31

Message:
Logged In: YES 
user_id=642936

Copying the previously extracted file is no option. When the
archive is extracted inside a loop, you never know what
happens between two extract() calls. The original file could
have been renamed, changed or removed. Suppose you want to
extract just those members which are hard links:

for tarinfo in tar:
    if tarinfo.islnk():
        tar.extract(tarinfo)

I agree with you that the error message is bad because it
does not give the slightest idea of what's going wrong. I'll
see what I can do about that.

To work around your particular problem, my idea is to
subclass the TarFile class and replace the makelink() method
with one that simply copies the file as you proposed.

----------------------------------------------------------------------

Comment By: Arve Knudsen (arve_knudsen)
Date: 2006-07-25 10:59

Message:
Logged In: YES 
user_id=1522083

Thanks for the clarification, Lars. I'd prefer to continue
with my current approach however, since it allows me to
report progress as the tarfile is unpacked/decompressed.
Also, I don't think it would be satisfactory at all if
tarfile would just die with a mysterious error in such cases.

In order to resolve this, why must tarfile extract the file
again, can't it copy the already extracted file?

----------------------------------------------------------------------

Comment By: Lars Gust?bel (gustaebel)
Date: 2006-07-25 10:42

Message:
Logged In: YES 
user_id=642936

The traceback tells me that there is a hard link inside the
archive which means that a file in the archive is referenced
to twice. This hard link can be extracted only on platforms
that have an os.link() function. On Win32 they're not
supported by the file system, but tarfile works around this
by extracting the referenced file twice. In order to extract
the file the second time it is necessary that tarfile seeks
back in the input file to access the file's data again. But
"seeking backwards is not allowed" when a file is opened in
streaming mode ;-)
If you do not necessarily need streaming mode for your
application, better use "r:gz" or "r" and the problem will
be gone.

----------------------------------------------------------------------

Comment By: Arve Knudsen (arve_knudsen)
Date: 2006-07-25 10:04

Message:
Logged In: YES 
user_id=1522083

Ok, I've verified now that the problem persists with Python
2.4.4 (from the 2.4 branch in svn). The exact same thing
happens.

----------------------------------------------------------------------

Comment By: Arve Knudsen (arve_knudsen)
Date: 2006-07-25 09:29

Message:
Logged In: YES 
user_id=1522083

Well yeah, it appears to be Windows specific. I just tested
on Linux (Ubuntu), also with Python 2.4.3. I'll try 2.4.3+
on Windows to see if it makes any difference. Come to think
of it I think I experienced this problem in that past on
Linux, but then I solved it by repacking ipython. Also, if I
pack it myself on Windows using bsdtar it works fine.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-25 05:35

Message:
Logged In: YES 
user_id=33168

I tested this on Linux with both 2.5 and 2.4.3+ without
problems.  I believe there were some fixes in this area. 
Could you try testing with the 2.4.3+ current which will
become 2.4.4 (or 2.5b2)?  If this is still a problem, it
looks like it may be Windows specific.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1527974&group_id=5470

From noreply at sourceforge.net  Tue Jul 25 11:58:15 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 25 Jul 2006 02:58:15 -0700
Subject: [ python-Bugs-1527974 ] tarfile chokes on ipython archive on Windows
Message-ID: <E1G5Jg7-0000UD-Mw@sc8-sf-web5.sourceforge.net>

Bugs item #1527974, was opened at 2006-07-24 23:00
Message generated for change (Comment added) made by arve_knudsen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1527974&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Arve Knudsen (arve_knudsen)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile chokes on ipython archive on Windows

Initial Comment:
I'm trying to extract files from the latest ipython tar
archive, available from
http://ipython.scipy.org/dist/ipython-0.7.2.tar.gz,
using tarfile. This is on Windows XP, using Python
2.4.3. There is only a problem if I open the archive in
stream mode (the "mode" argument to tarfile.open is
"r|gz"), in which case tarfile raises StreamError. I'd
be happy if this error could be sorted out.

The following script should trigger the error:

import tarfile

f = file(r"ipython-0.7.2.tar.gz", "rb")
tar = tarfile.open(fileobj=f, mode="r|gz")
try:
    for m in tar:
        tar.extract(m)
finally:
    tar.close()
    f.close(

The resulting exception:
Traceback (most recent call last):
  File "tst.py", line 7, in ?
    tar.extract(m)
  File "C:\Program Files\Python24\lib\tarfile.py", line
1335, in extract
    self._extract_member(tarinfo, os.path.join(path,
tarinfo.name))
  File "C:\Program Files\Python24\lib\tarfile.py", line
1431, in _extract_member

    self.makelink(tarinfo, targetpath)
  File "C:\Program Files\Python24\lib\tarfile.py", line
1515, in makelink
    self._extract_member(self.getmember(linkpath),
targetpath)
  File "C:\Program Files\Python24\lib\tarfile.py", line
1423, in _extract_member

    self.makefile(tarinfo, targetpath)
  File "C:\Program Files\Python24\lib\tarfile.py", line
1461, in makefile
    copyfileobj(source, target)
  File "C:\Program Files\Python24\lib\tarfile.py", line
158, in copyfileobj
    shutil.copyfileobj(src, dst)
  File "C:\Program Files\Python24\lib\shutil.py", line
22, in copyfileobj
    buf = fsrc.read(length)
  File "C:\Program Files\Python24\lib\tarfile.py", line
551, in _readnormal
    self.fileobj.seek(self.offset + self.pos)
  File "C:\Program Files\Python24\lib\tarfile.py", line
420, in seek
    raise StreamError, "seeking backwards is not allowed"
tarfile.StreamError: seeking backwards is not allowed

----------------------------------------------------------------------

>Comment By: Arve Knudsen (arve_knudsen)
Date: 2006-07-25 11:58

Message:
Logged In: YES 
user_id=1522083

Yes I admit that is a weakness to my proposed approach.
Perhaps it would be a better idea to extract hardlinked
files to a temporary location and copy those files when
needed, as a cache? The only problem that I can think of
with this approach is the overhead, but perhaps this could
be configurable through a keyword if you think it would pose
a significant problem (i.e. keeping extra copies of
potentially huge files)?

The temporary cache would be private to tarfile, so there
should be no need to worry about modifications to the
contained files.

----------------------------------------------------------------------

Comment By: Lars Gust?bel (gustaebel)
Date: 2006-07-25 11:31

Message:
Logged In: YES 
user_id=642936

Copying the previously extracted file is no option. When the
archive is extracted inside a loop, you never know what
happens between two extract() calls. The original file could
have been renamed, changed or removed. Suppose you want to
extract just those members which are hard links:

for tarinfo in tar:
    if tarinfo.islnk():
        tar.extract(tarinfo)

I agree with you that the error message is bad because it
does not give the slightest idea of what's going wrong. I'll
see what I can do about that.

To work around your particular problem, my idea is to
subclass the TarFile class and replace the makelink() method
with one that simply copies the file as you proposed.

----------------------------------------------------------------------

Comment By: Arve Knudsen (arve_knudsen)
Date: 2006-07-25 10:59

Message:
Logged In: YES 
user_id=1522083

Thanks for the clarification, Lars. I'd prefer to continue
with my current approach however, since it allows me to
report progress as the tarfile is unpacked/decompressed.
Also, I don't think it would be satisfactory at all if
tarfile would just die with a mysterious error in such cases.

In order to resolve this, why must tarfile extract the file
again, can't it copy the already extracted file?

----------------------------------------------------------------------

Comment By: Lars Gust?bel (gustaebel)
Date: 2006-07-25 10:42

Message:
Logged In: YES 
user_id=642936

The traceback tells me that there is a hard link inside the
archive which means that a file in the archive is referenced
to twice. This hard link can be extracted only on platforms
that have an os.link() function. On Win32 they're not
supported by the file system, but tarfile works around this
by extracting the referenced file twice. In order to extract
the file the second time it is necessary that tarfile seeks
back in the input file to access the file's data again. But
"seeking backwards is not allowed" when a file is opened in
streaming mode ;-)
If you do not necessarily need streaming mode for your
application, better use "r:gz" or "r" and the problem will
be gone.

----------------------------------------------------------------------

Comment By: Arve Knudsen (arve_knudsen)
Date: 2006-07-25 10:04

Message:
Logged In: YES 
user_id=1522083

Ok, I've verified now that the problem persists with Python
2.4.4 (from the 2.4 branch in svn). The exact same thing
happens.

----------------------------------------------------------------------

Comment By: Arve Knudsen (arve_knudsen)
Date: 2006-07-25 09:29

Message:
Logged In: YES 
user_id=1522083

Well yeah, it appears to be Windows specific. I just tested
on Linux (Ubuntu), also with Python 2.4.3. I'll try 2.4.3+
on Windows to see if it makes any difference. Come to think
of it I think I experienced this problem in that past on
Linux, but then I solved it by repacking ipython. Also, if I
pack it myself on Windows using bsdtar it works fine.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-25 05:35

Message:
Logged In: YES 
user_id=33168

I tested this on Linux with both 2.5 and 2.4.3+ without
problems.  I believe there were some fixes in this area. 
Could you try testing with the 2.4.3+ current which will
become 2.4.4 (or 2.5b2)?  If this is still a problem, it
looks like it may be Windows specific.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1527974&group_id=5470

From noreply at sourceforge.net  Tue Jul 25 14:35:41 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 25 Jul 2006 05:35:41 -0700
Subject: [ python-Bugs-1467929 ] %-formatting and dicts
Message-ID: <E1G5M8T-0000cA-SH@sc8-sf-web1.sourceforge.net>

Bugs item #1467929, was opened at 2006-04-10 15:39
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467929&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: M.-A. Lemburg (lemburg)
Assigned to: Anthony Baxter (anthonybaxter)
Summary: %-formatting and dicts

Initial Comment:
This looks like a bug in the way the %-formatting code
works or is it a feature ?

>>> '%s %(a)s' % {'a': 'xyz'}
"{'a': 'xyz'} xyz"

>>> u'%s %(a)s' % {'a': 'xyz'}
u"{'a': 'xyz'} xyz"

Note that both strings and Unicode are affected.

Python 2.3 and 2.4 also show this behavior.

I would have expected an exception or the %-formatter
simply ignoring the first %s.




----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-25 08:35

Message:
Logged In: YES 
user_id=11375

So, what should '%s' % {} do?  Should it be 1) '{}' or 2) an
error because the argument is a mapping but the format
specifier doesn't have a '(key)'?

I've attached a draft patch that fixes stringobject.c; if
the approach is deemed OK, I'll apply it to unicodeobject.c,
too.  PyString_Format() records the type of argument being
processed (a tuple or a mapping) and raises ValueError if
you mix them, at the cost of two extra comparisons for each
format specifier processed.  This preserves the current
behaviour of '%s' % dictionary.

Questions: 1) is the approach reasonably clear?  2) are the
additional two comparisons unacceptably slow?  3) Is
ValueError the right exception?  4) can someone come up with
a better exception message than "both keyed and unkeyed
format specifiers used"?



----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-07-24 16:07

Message:
Logged In: YES 
user_id=21627

IMO, it's correct to break backwards compatibility, as the
current behaviour clearly violates the spec; I'm not sure
whether it's good to break the behaviour *now* (i.e. with no
further betas before the release of 2.5).

Deferring to the release manager.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-07-24 09:37

Message:
Logged In: YES 
user_id=849994

The library ref specifies that if a dict is supplied, the
format specifiers MUST include a mapping key, so the right
thing to do would be to raise an exception.

Is it worth breaking backwards compatibility, Martin?

----------------------------------------------------------------------

Comment By: Hasan Diwan (hdiwan650)
Date: 2006-04-14 04:33

Message:
Logged In: YES 
user_id=1185570

It looks as though it's a feature... The first %s will print
the whole dictionary as a string, the second, only that
value looked up by the key.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467929&group_id=5470

From noreply at sourceforge.net  Tue Jul 25 14:52:08 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 25 Jul 2006 05:52:08 -0700
Subject: [ python-Bugs-1528363 ] forward in turtle module may cause incorrect
	display
Message-ID: <E1G5MOO-0007YU-Fe@sc8-sf-web3.sourceforge.net>

Bugs item #1528363, was opened at 2006-07-25 20: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=1528363&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: NatureMage (naturemage)
Assigned to: Nobody/Anonymous (nobody)
Summary: forward in turtle module may cause incorrect display

Initial Comment:
Use forward() in the turtle module to draw 
horizontally from right to left, if the starting 
position's x and y coordinates are different from the 
origin, the line may not appear straight. But if the 
tk window is redrawn, for example minimized and then 
restored, the line will be properly displayed.

The following code will reproduce this issue:

# start
from turtle import *
from Tkinter import *

color("maroon")
up()
goto(30, 30)
down()
left(180)
forward(100)
    
mainloop()
# end

I checked the source of the turtle module, but failed 
to figure out the reason. The attatchment contains a 
snapshot of what happens.

My environment:
Python version: 2.4.3
OS: Windows XP sp2
Video Card: Nvidia 6600
CPU: P4 2.66G Hz
Mem: 1G

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528363&group_id=5470

From noreply at sourceforge.net  Tue Jul 25 20:25:28 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 25 Jul 2006 11:25:28 -0700
Subject: [ python-Bugs-1526585 ] Concatenation on a long string breaks
Message-ID: <E1G5Ray-0008Nj-OE@sc8-sf-web3.sourceforge.net>

Bugs item #1526585, was opened at 2006-07-21 17:18
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1526585&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 6
Submitted By: Jp Calderone (kuran)
Assigned to: Nobody/Anonymous (nobody)
Summary: Concatenation on a long string breaks

Initial Comment:
Consider this transcript:

exarkun at charm:~/Projects/python/trunk$ ./python
Python 2.5b2 (trunk:50698, Jul 18 2006, 10:08:36)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> x = 'x' * (2 ** 31 - 1)
>>> x = x + 'x'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SystemError: Objects/stringobject.c:4103: bad argument
to internal function
>>> len(x)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'x' is not defined
>>> 


I would expect some exception other than SystemError
and for the locals namespace to not become corrupted.


----------------------------------------------------------------------

>Comment By: Armin Rigo (arigo)
Date: 2006-07-25 18:25

Message:
Logged In: YES 
user_id=4771

The check should be done before the variable is removed
from the namespace, so that 'x' doesn't just disappear.
Attached a patch that does this.  Also, let's produce
an exception consistent with what PyString_Concat()
raises in the same case, which is an OverflowError
instead of a MemoryError.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-25 03:57

Message:
Logged In: YES 
user_id=31435

[Neal]
>  Tim since we know both lens are >= 0, is this test
> sufficient for verifying overflow:
>
>     Py_ssize_t new_len = v_len + w_len;
>     if (new_len < 0) {

Right!  That's all the new checking needed in
string_concatenate().

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-25 03:46

Message:
Logged In: YES 
user_id=33168

Attached a patch against 2.5.  The patch should work against
2.4 too, but you will need to change all Py_ssize_t to int.
 Tim since we know both lens are >= 0, is this test
sufficient for verifying overflow:

      Py_ssize_t new_len = v_len + w_len;
      if (new_len < 0) {

Jp, can you test the patch?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-22 14:11

Message:
Logged In: YES 
user_id=31435

Part of the problem appears to be that ceval.c's
string_concatenate() doesn't check for overflow in the
second argument here:

if (_PyString_Resize(&v, v_len + w_len) != 0)

The Windows malloc on my box returns NULL (and so Python
raises MemoryError) on the initial:

x = 'x' * (2 ** 31 - 1)

attempt, so I never get that far.  I'm afraid this is
muddier in strange ways on Linux because the Linux malloc()
is pathologically optimistic (can return a non-NULL value
pointing at "memory" that can't actually be used for anything).

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2006-07-22 09:00

Message:
Logged In: YES 
user_id=6656

Confirmed with 2.4.  Ouch.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1526585&group_id=5470

From noreply at sourceforge.net  Wed Jul 26 04:13:01 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 25 Jul 2006 19:13:01 -0700
Subject: [ python-Bugs-1486335 ] httplib: read/_read_chunked failes with
	ValueError sometime
Message-ID: <E1G5YtR-0001wr-An@sc8-sf-web2.sourceforge.net>

Bugs item #1486335, was opened at 2006-05-11 05:14
Message generated for change (Comment added) made by gward
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486335&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: kxroberto (kxroberto)
Assigned to: Greg Ward (gward)
Summary: httplib: read/_read_chunked failes with ValueError sometime

Initial Comment:
This occasionally shows up in a logged trace, when a
application crahes on ValueError on a
http(s)_response.read() :

(py2.3.5 - yet relevant httplib code is still the same
in current httplib) 


.... \'  File "socket.pyo", line 283,
in read\\n\', \'  File "httplib.pyo", line 389, in
read\\n\', \'  File "httplib.pyo", line 426, in
_read_chunked\\n\', \'ValueError: invalid literal for
int(): \\n\']  :::

its the line:

chunk_left = int(line, 16)


Don't know what this line is about. Yet, that should be
protected, as a http_response.read() should not fail
with ValueError, but only with
IOError/EnvironmentError, socket.error - otherwise
Error Exception handling becomes a random task.

-Robert


Side note regarding IO exception handling: See also FR
#1481036 (IOBaseError): why socket.error.__bases__ is
(<class exceptions.Exception at 0x011244E0>,)  ?


----------------------------------------------------------------------

>Comment By: Greg Ward (gward)
Date: 2006-07-25 22:13

Message:
Logged In: YES 
user_id=14422

OK, I've been working on this some more and I have a very
crude addition to test_httplib.py.  I'm going to attach it
here and solicit feedback on python-dev: I'm not sure how
many kinds of bad response chunking I really want to worry
about.  

----------------------------------------------------------------------

Comment By: Greg Ward (gward)
Date: 2006-07-24 15:38

Message:
Logged In: YES 
user_id=14422

I'm seeing this with Python 2.3.5 and 2.4.3 hitting a PHP
app and getting a large error page.  It looks as though the
server is incorrectly chunking the response: lwp-request at
least gives a better error message than httplib.py:

  $ GET "http://..."
  500 EOF when chunk header expected

I'm unclear on precisely what the server is doing wrong. 
The response looks like this:

HTTP/1.1 200 OK
Date: Mon, 24 Jul 2006 19:18:47 GMT
Server: Apache/2.0.54 (Fedora)
X-Powered-By: PHP/4.3.11
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8

2169\r\n
\r\n
[...first 0x2169 bytes of response...]\r\n
20b2\r\n
[...next 0x20b2 bytes...]
[...repeat many times...]
20b2\r\n
[...the last 0x20b2 bytes...]
\r\n

The blank line at eof appears to be confusing httplib.py: it
bombs because 

  int('', 16)

raises ValueError.

Observation #1: if this is indeed a protocol error (ie. the
server is in the wrong), httplib.py should turn the
ValueError into an HTTPException.  Perhaps it should define
a new exception class for low-level protocol errors (bad
chunking).  Maybe it should reuse IncompleteRead.

Observation #2: gee, my web browser doesn't barf on this
response, so why should httplib.py?  If there is an error
here, it's at EOF, so it's not that big a deal.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486335&group_id=5470

From noreply at sourceforge.net  Wed Jul 26 06:19:48 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 25 Jul 2006 21:19:48 -0700
Subject: [ python-Bugs-1526585 ] Concatenation on a long string breaks
Message-ID: <E1G5as8-0007Zv-15@sc8-sf-web3.sourceforge.net>

Bugs item #1526585, was opened at 2006-07-21 10:18
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1526585&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
>Resolution: Accepted
Priority: 6
Submitted By: Jp Calderone (kuran)
>Assigned to: Armin Rigo (arigo)
Summary: Concatenation on a long string breaks

Initial Comment:
Consider this transcript:

exarkun at charm:~/Projects/python/trunk$ ./python
Python 2.5b2 (trunk:50698, Jul 18 2006, 10:08:36)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> x = 'x' * (2 ** 31 - 1)
>>> x = x + 'x'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SystemError: Objects/stringobject.c:4103: bad argument
to internal function
>>> len(x)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'x' is not defined
>>> 


I would expect some exception other than SystemError
and for the locals namespace to not become corrupted.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-25 21:19

Message:
Logged In: YES 
user_id=33168

Armin, can you check in your patch and backport?  Also a
news entry and a test in test_bigmem would be great. 
Thanks.  If not let me know (assign to me) and I'll finish
this up.

This fix should be backported as well.

----------------------------------------------------------------------

Comment By: Jp Calderone (kuran)
Date: 2006-07-25 13:06

Message:
Logged In: YES 
user_id=366566

Tested Armin's patch, looks like it addresses the issue. 
One thing I noticed though, ('x' * (2 ** 32 - 2) + 'x')
fails the same way ('x' * (2 ** 32 - 1) + 'x').  Don't
really understand why, just thought I'd mention it.


----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2006-07-25 11:25

Message:
Logged In: YES 
user_id=4771

The check should be done before the variable is removed
from the namespace, so that 'x' doesn't just disappear.
Attached a patch that does this.  Also, let's produce
an exception consistent with what PyString_Concat()
raises in the same case, which is an OverflowError
instead of a MemoryError.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-24 20:57

Message:
Logged In: YES 
user_id=31435

[Neal]
>  Tim since we know both lens are >= 0, is this test
> sufficient for verifying overflow:
>
>     Py_ssize_t new_len = v_len + w_len;
>     if (new_len < 0) {

Right!  That's all the new checking needed in
string_concatenate().

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-24 20:46

Message:
Logged In: YES 
user_id=33168

Attached a patch against 2.5.  The patch should work against
2.4 too, but you will need to change all Py_ssize_t to int.
 Tim since we know both lens are >= 0, is this test
sufficient for verifying overflow:

      Py_ssize_t new_len = v_len + w_len;
      if (new_len < 0) {

Jp, can you test the patch?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-22 07:11

Message:
Logged In: YES 
user_id=31435

Part of the problem appears to be that ceval.c's
string_concatenate() doesn't check for overflow in the
second argument here:

if (_PyString_Resize(&v, v_len + w_len) != 0)

The Windows malloc on my box returns NULL (and so Python
raises MemoryError) on the initial:

x = 'x' * (2 ** 31 - 1)

attempt, so I never get that far.  I'm afraid this is
muddier in strange ways on Linux because the Linux malloc()
is pathologically optimistic (can return a non-NULL value
pointing at "memory" that can't actually be used for anything).

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2006-07-22 02:00

Message:
Logged In: YES 
user_id=6656

Confirmed with 2.4.  Ouch.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1526585&group_id=5470

From noreply at sourceforge.net  Wed Jul 26 11:01:38 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 26 Jul 2006 02:01:38 -0700
Subject: [ python-Bugs-1526585 ] Concatenation on a long string breaks
Message-ID: <E1G5fGs-00052q-K9@sc8-sf-web6.sourceforge.net>

Bugs item #1526585, was opened at 2006-07-21 17:18
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1526585&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: Accepted
Priority: 6
Submitted By: Jp Calderone (kuran)
Assigned to: Armin Rigo (arigo)
Summary: Concatenation on a long string breaks

Initial Comment:
Consider this transcript:

exarkun at charm:~/Projects/python/trunk$ ./python
Python 2.5b2 (trunk:50698, Jul 18 2006, 10:08:36)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> x = 'x' * (2 ** 31 - 1)
>>> x = x + 'x'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SystemError: Objects/stringobject.c:4103: bad argument
to internal function
>>> len(x)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'x' is not defined
>>> 


I would expect some exception other than SystemError
and for the locals namespace to not become corrupted.


----------------------------------------------------------------------

>Comment By: Armin Rigo (arigo)
Date: 2006-07-26 09:01

Message:
Logged In: YES 
user_id=4771

I'm unsure about how the bigmem tests should be used.
I think that I am not supposed to set a >2G limit on
a 32-bit machine, right?  When I do, I get 9 failures:
8 OverflowErrors and a stranger AssertionError in
test_hash.  I think that these tests are meant to
test the int/Py_ssize_t difference on 64-bit 
machines instead.  The bug this tracker is about
only shows up on 32-bit machines.

My concern is that if we add a test for the current
bug in test_bigmem, then with a memory limit < 2GB
the test is essentially skipped, and with a memory
limit > 2GB then 9 other tests fail anyway.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-26 04:19

Message:
Logged In: YES 
user_id=33168

Armin, can you check in your patch and backport?  Also a
news entry and a test in test_bigmem would be great. 
Thanks.  If not let me know (assign to me) and I'll finish
this up.

This fix should be backported as well.

----------------------------------------------------------------------

Comment By: Jp Calderone (kuran)
Date: 2006-07-25 20:06

Message:
Logged In: YES 
user_id=366566

Tested Armin's patch, looks like it addresses the issue. 
One thing I noticed though, ('x' * (2 ** 32 - 2) + 'x')
fails the same way ('x' * (2 ** 32 - 1) + 'x').  Don't
really understand why, just thought I'd mention it.


----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2006-07-25 18:25

Message:
Logged In: YES 
user_id=4771

The check should be done before the variable is removed
from the namespace, so that 'x' doesn't just disappear.
Attached a patch that does this.  Also, let's produce
an exception consistent with what PyString_Concat()
raises in the same case, which is an OverflowError
instead of a MemoryError.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-25 03:57

Message:
Logged In: YES 
user_id=31435

[Neal]
>  Tim since we know both lens are >= 0, is this test
> sufficient for verifying overflow:
>
>     Py_ssize_t new_len = v_len + w_len;
>     if (new_len < 0) {

Right!  That's all the new checking needed in
string_concatenate().

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-25 03:46

Message:
Logged In: YES 
user_id=33168

Attached a patch against 2.5.  The patch should work against
2.4 too, but you will need to change all Py_ssize_t to int.
 Tim since we know both lens are >= 0, is this test
sufficient for verifying overflow:

      Py_ssize_t new_len = v_len + w_len;
      if (new_len < 0) {

Jp, can you test the patch?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-22 14:11

Message:
Logged In: YES 
user_id=31435

Part of the problem appears to be that ceval.c's
string_concatenate() doesn't check for overflow in the
second argument here:

if (_PyString_Resize(&v, v_len + w_len) != 0)

The Windows malloc on my box returns NULL (and so Python
raises MemoryError) on the initial:

x = 'x' * (2 ** 31 - 1)

attempt, so I never get that far.  I'm afraid this is
muddier in strange ways on Linux because the Linux malloc()
is pathologically optimistic (can return a non-NULL value
pointing at "memory" that can't actually be used for anything).

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2006-07-22 09:00

Message:
Logged In: YES 
user_id=6656

Confirmed with 2.4.  Ouch.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1526585&group_id=5470

From noreply at sourceforge.net  Wed Jul 26 14:14:40 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 26 Jul 2006 05:14:40 -0700
Subject: [ python-Bugs-978833 ] SSL-ed sockets don't close correct?
Message-ID: <E1G5iHg-0003Vg-3i@sc8-sf-web5.sourceforge.net>

Bugs item #978833, was opened at 2004-06-24 11:57
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=978833&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
>Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 8
Submitted By: kxroberto (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: Martin v. L?wis (loewis)
Date: 2006-07-26 14:14

Message:
Logged In: YES 
user_id=21627

This is now fixed in 50844. I won't backport it to 2.4, as
it may cause working code to fail. For example, httplib
would fail since it would already close the connection in
getresponse, when the response object should still be able
to read from the connection.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-07-03 14:03

Message:
Logged In: YES 
user_id=21627

Can you please try the attached patch? It makes sure
_socketobject.close really closes the socket, rather than
relying on reference counting to close it.

----------------------------------------------------------------------

Comment By: kxroberto (kxroberto)
Date: 2006-05-11 14:05

Message:
Logged In: YES 
user_id=972995

Testing it with Python2.5a2, the problem is still there.

Without the .shutdown(2) (or .shutdown(1)) patch to the
httplib.SharedSocket (base for FakeSocket), the ftps example
freezes on the cmd channel, because the SSL'ed data channel
doesn't close/terminate --> FTPS server doesn't respond on
the cmd channel. The ftps example is most specific to show
the bug. 

Yet you can also easily blow up a HTTPS-server with this
decent test code who only opens (bigger!) files and closes
without reading everything:

Python 2.5a2 (r25a2:45740, May 11 2006, 11:25:30)
[GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
Robert's Interactive Python - TAB=complete
import sys,os,re,string,time,glob,thread,pdb
>>> import urllib
>>> l=[]
>>> for i in range(10):
...    f=urllib.urlopen('https://srv/big-Python-2.5a2.tgz')
...    f.close()
...    l.append(f)
...
>>>


=> in the (apache) servers ssl_engine_log you can see that
connections remain open (until apache times out after 2
minutes) and lots of extra apache daemons are started!

=> f.close() doesn't really close the connection (until it
is __del__'ed )


Trying around I found that the original undeleted f.fp._ssl
is most probably the cause and holds the real socket open. 
a f.fp._sock.close() doesn't close also  - but only when del
f.fp._ssl is done. (only a f.fp._sock._sock.close() would
force the close). The original fp is held in closures of
.readline(s)/__iter__/next... 

--

I now tried an alternative patch (instead of the
shutdown(2)-patch), which also so far seems to cure
everything . Maybe thats the right solution for the bug:

--- httplib.py.orig     2006-05-11 11:25:32.000000000 +0200
+++ httplib.py  2006-05-11 13:45:07.000000000 +0200
@@ -970,6 +970,7 @@
             self._shared.decref()
             self._closed = 1
             self._shared = None
+            self._ssl = None

 class SSLFile(SharedSocketClient):
     """File-like object wrapping an SSL socket."""
@@ -1085,6 +1086,7 @@
     def close(self):
         SharedSocketClient.close(self)
         self._sock = self.__class__._closedsocket()
+        self._ssl = None

     def makefile(self, mode, bufsize=None):
         if mode != 'r' and mode != 'rb':


--------------



In another application with SSL'ed SMTP connections there
arose similar problems.

I also worked around the problem in smtplib.py so far in a
similar style:

    def close(self):
        self.realsock.shutdown(2)
        self.realsock.close()


---

Yet, the right patch maybe (not tested extensively so far):


--- Lib-orig/smtplib.py 2006-05-03 13:10:40.000000000 +0200
+++ Lib/smtplib.py      2006-05-11 13:50:12.000000000 +0200
@@ -142,6 +142,7 @@
     sendall = send

     def close(self):
+        self.sslobj = None
         self.realsock.close()

 class SSLFakeFile:
@@ -161,7 +162,7 @@
         return str

     def close(self):
-        pass
+        self.sslobj = None

 def quoteaddr(addr):
     """Quote a subset of the email addresses defined by RFC
821.


------------------

-robert

----------------------------------------------------------------------

Comment By: kxroberto (kxroberto)
Date: 2005-09-24 21:45

Message:
Logged In: YES 
user_id=972995

Now I managed to solve the problem for me with attached
patch of httplib.py: a explicit shutdown ( 2 or 1 ) of the
(faked) ssl'ed socket solves it. 
I still guess the ssl'ed socket (ssl dll) should do that
auto on sock.close() 
Thus I  leave it as a bug HERE. Right?

[ I also have the hope, that this also solves the
ssl-eof-errors with https (of some of my users; will see
this in future)


*** \usr\src\py24old/httplib.py Sat Sep 24 21:35:28 2005
--- httplib.py  Sat Sep 24 21:37:48 2005
*************** class SharedSocket:
*** 899,904 ****
--- 899,905 ----
          self._refcnt -= 1
          assert self._refcnt >= 0
          if self._refcnt == 0:
+             self.sock.shutdown(2)
              self.sock.close()

      def __del__(self):

----------------------------------------------------------------------

Comment By: kxroberto (kxroberto)
Date: 2005-09-24 21:06

Message:
Logged In: YES 
user_id=972995

I retried that again with py2.4.1. The problem/bug is still
there.

In attachment I supplied a full FTPS client test_ftpslib.py
with simple test function - ready to run into the problem:
At the end of ftp.retrlines 'return self.voidresp()' 
freezes : waiting eternally for response bytes at the
command port. the same at the end of .storelines after the
data is transfered on the data port.

My preliminary guess is still, that python's ssl has a
severe (EOF?) problem closing a socket/connection correctly.
 obviously this problem doesn't show up with https because
everything is done on one connection - no dependency on a
correct socket/connect close signal.

(from other https communication with some proxies in between
my users get ssl-eof-error errors also. I still can't solve
that bug too. this shows python's ssl has a severe EOF bug
with complex https also - or cannot handle certain
situations correct.)

I learned the FTPS/TLS client from M2crypto's ftpslib. the
only difference in (transposed) logic, that I can see is,
that M2crpyto uses an additional line
"conn.set_session(self.sock.get_session())" during setup of
the data port ssl connection. I don't know what it is,
pythons ssl doesn't have sucht "session"-functions, but I
think it has no severe meaning.?

Robert

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-12-22 06:14

Message:
Logged In: YES 
user_id=357491

Since I believe this was fixed with the patch Tino mentions and Roberto 
has not replied, I am closing as fixed.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-08-17 01:18

Message:
Logged In: YES 
user_id=357491

Is this still a problem for you, Roberto, with Python 2.4a2?

----------------------------------------------------------------------

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  Tue Jul 25 22:47:00 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 25 Jul 2006 13:47:00 -0700
Subject: [ python-Bugs-1512124 ] OSX: debugger hangs IDLE
Message-ID: <E1G5Tnw-0004CG-Hv@sc8-sf-web2.sourceforge.net>

Bugs item #1512124, was opened at 2006-06-25 15:45
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512124&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Tkinter
Group: Python 2.5
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Aahz (aahz)
>Assigned to: Nobody/Anonymous (nobody)
Summary: OSX: debugger hangs IDLE

Initial Comment:
This has been previously found on 2.3/2.4 and verified again with 2.5b1
(was hoping that the 1.2 IDLE update would fix):

When you bring up the debugger window in IDLE on OSX, you'll notice that
it's vibrating, as if it's stuck in a resize loop.  Unless you
immediately resize the window manually, IDLE will hang the next time you
try to do something that updates the debugger window.


----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-25 22:47

Message:
Logged In: YES 
user_id=580910

The vibration problem also occurs if you start idle with 'python idle.py -n'. 

I'm moving this to Tkinter. I'll see if I can extract a small program that shows the 
problem, I'm not exactly a Tkinter expert. I'm also unassigning this bug, there's 
little change that I'm going to fix this.

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2006-07-24 19:23

Message:
Logged In: YES 
user_id=149084

Could you revert your fix locally and try running
w/o the subprocess?  If that fixes it you could
blame the rather elaborate communication between
the subprocess and the debugger gui, and it would
be good to check before blaming AquaTk.

If it's still there, maybe you could provide a cutdown
in Tkinter (w/o IDLE) and change the Category to 
Tkinter?

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-24 08:09

Message:
Logged In: YES 
user_id=580910

You'd have to test with a version of python before 2.5b1, after that I've added a 
workaround for this issue. This workaround makes the debugger window 
narrower than intended, but at least you have a working version of IDLE.

My guess is that the root cause of this issue is a bug in TkAqua. I haven't filed a 
bug with them because I have never programmed in Tcl and would therefore 
require lots of time to get a Tcl program going that demonstrates this problem.

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2006-07-23 22:47

Message:
Logged In: YES 
user_id=149084

Please try running IDLE w/o the subprocess by
starting it with the -n switch.  Does the issue
still exist?

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-06-25 22:49

Message:
Logged In: YES 
user_id=580910

And when you do resize the window layout sucks, automatic layout seems to 
be buggy here (although I must admit that I haven't seen IDLE on other 
platforms).

I have no idea what is causing this bug. Upgrading the Tk version to the very 
latest instead of using the system version doesn't help.

I've checked in a workaround in revision 47091. That patch avoids explicitly 
sizing the stackviewer widget on OSX, which seems to fix this problem. The 
debugger window now is rather less wide than it was before, which means 
users will likely have to resize the window if they want to use the debugger.

I'm leaving this bug open and unassign it in the hope that someone who 
actually knows Tkinter proposed a better fix.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512124&group_id=5470

From noreply at sourceforge.net  Wed Jul 26 17:50:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 26 Jul 2006 08:50:46 -0700
Subject: [ python-Bugs-1526585 ] Concatenation on a long string breaks
Message-ID: <E1G5leo-0001Az-K9@sc8-sf-web6.sourceforge.net>

Bugs item #1526585, was opened at 2006-07-21 10:18
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1526585&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: Accepted
Priority: 6
Submitted By: Jp Calderone (kuran)
Assigned to: Armin Rigo (arigo)
Summary: Concatenation on a long string breaks

Initial Comment:
Consider this transcript:

exarkun at charm:~/Projects/python/trunk$ ./python
Python 2.5b2 (trunk:50698, Jul 18 2006, 10:08:36)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> x = 'x' * (2 ** 31 - 1)
>>> x = x + 'x'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SystemError: Objects/stringobject.c:4103: bad argument
to internal function
>>> len(x)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'x' is not defined
>>> 


I would expect some exception other than SystemError
and for the locals namespace to not become corrupted.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-26 08:50

Message:
Logged In: YES 
user_id=33168

You're correct that bigmem is primarily for testing
int/Py_ssize_t.  But it doesn't have to be.  It has support
for machines with largish amounts of memory (and limiting
test runs).  I didn't know where else to put such a test.  I
agree that this bug would only occur on 32-bit platforms. 
Most machines can't run it, so about the only other option I
can think of would be to put it in it's own file and add a
-u option.  That seemed like even more work.

I'm not tied to bigmem at all, but it would be nice to have
a test for this somewhere.  I'm sure there are a bunch of
other places we have this sort of overflow and it would be
good to test them somewhere.  Do whatever you think is best.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2006-07-26 02:01

Message:
Logged In: YES 
user_id=4771

I'm unsure about how the bigmem tests should be used.
I think that I am not supposed to set a >2G limit on
a 32-bit machine, right?  When I do, I get 9 failures:
8 OverflowErrors and a stranger AssertionError in
test_hash.  I think that these tests are meant to
test the int/Py_ssize_t difference on 64-bit 
machines instead.  The bug this tracker is about
only shows up on 32-bit machines.

My concern is that if we add a test for the current
bug in test_bigmem, then with a memory limit < 2GB
the test is essentially skipped, and with a memory
limit > 2GB then 9 other tests fail anyway.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-25 21:19

Message:
Logged In: YES 
user_id=33168

Armin, can you check in your patch and backport?  Also a
news entry and a test in test_bigmem would be great. 
Thanks.  If not let me know (assign to me) and I'll finish
this up.

This fix should be backported as well.

----------------------------------------------------------------------

Comment By: Jp Calderone (kuran)
Date: 2006-07-25 13:06

Message:
Logged In: YES 
user_id=366566

Tested Armin's patch, looks like it addresses the issue. 
One thing I noticed though, ('x' * (2 ** 32 - 2) + 'x')
fails the same way ('x' * (2 ** 32 - 1) + 'x').  Don't
really understand why, just thought I'd mention it.


----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2006-07-25 11:25

Message:
Logged In: YES 
user_id=4771

The check should be done before the variable is removed
from the namespace, so that 'x' doesn't just disappear.
Attached a patch that does this.  Also, let's produce
an exception consistent with what PyString_Concat()
raises in the same case, which is an OverflowError
instead of a MemoryError.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-24 20:57

Message:
Logged In: YES 
user_id=31435

[Neal]
>  Tim since we know both lens are >= 0, is this test
> sufficient for verifying overflow:
>
>     Py_ssize_t new_len = v_len + w_len;
>     if (new_len < 0) {

Right!  That's all the new checking needed in
string_concatenate().

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-24 20:46

Message:
Logged In: YES 
user_id=33168

Attached a patch against 2.5.  The patch should work against
2.4 too, but you will need to change all Py_ssize_t to int.
 Tim since we know both lens are >= 0, is this test
sufficient for verifying overflow:

      Py_ssize_t new_len = v_len + w_len;
      if (new_len < 0) {

Jp, can you test the patch?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-22 07:11

Message:
Logged In: YES 
user_id=31435

Part of the problem appears to be that ceval.c's
string_concatenate() doesn't check for overflow in the
second argument here:

if (_PyString_Resize(&v, v_len + w_len) != 0)

The Windows malloc on my box returns NULL (and so Python
raises MemoryError) on the initial:

x = 'x' * (2 ** 31 - 1)

attempt, so I never get that far.  I'm afraid this is
muddier in strange ways on Linux because the Linux malloc()
is pathologically optimistic (can return a non-NULL value
pointing at "memory" that can't actually be used for anything).

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2006-07-22 02:00

Message:
Logged In: YES 
user_id=6656

Confirmed with 2.4.  Ouch.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1526585&group_id=5470

From noreply at sourceforge.net  Tue Jul 25 22:34:02 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 25 Jul 2006 13:34:02 -0700
Subject: [ python-Bugs-1528620 ] Python 2.5b2 fails to build on Solaris 10
Message-ID: <E1G5TbO-00042q-Vw@sc8-sf-web6.sourceforge.net>

Bugs item #1528620, was opened at 2006-07-25 22:34
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=1528620&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido Ostkamp (ostkamp)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.5b2 fails to build on Solaris 10

Initial Comment:
Hello,

I tried to build Python 2.5b2 on Solaris 10 with the
Sun Workshop Compiler, which fails.

Please see the attachment for a complete log in several
stages. Here is a short summary:

*
build/temp.solaris-2.10-sun4us-2.5/libffi/include/ffi.h
contains illegal C-syntax __attribute(...)

This might be legal for GCC, but not for other compilers. 

* Even if this is removed, there are other fatal
compiler errors in the _ctypes module later on.

* The build process seems to invoke _cursesmodule.c.
This contains the use of a function  mvwgetnstr(). This
function does not exist in /usr/lib/libcurses.so.

* The build process fails to link with libcurses.so.

The Python 2.4.3 release fails for the same reasons
regarding the curses problems, but the _ctypes stuff
did not exist in this form. 

I would appreciate, if these bugs could be fixed.

Regards,

Guido

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528620&group_id=5470

From noreply at sourceforge.net  Wed Jul 26 19:45:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 26 Jul 2006 10:45:42 -0700
Subject: [ python-Bugs-1525469 ] SimpleXMLRpcServer still uses sys.exc_value
	and sys.exc_type
Message-ID: <E1G5nS2-000737-ED@sc8-sf-web3.sourceforge.net>

Bugs item #1525469, was opened at 2006-07-19 14:06
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525469&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Russell Warren (qopit)
>Assigned to: A.M. Kuchling (akuchling)
Summary: SimpleXMLRpcServer still uses sys.exc_value and sys.exc_type

Initial Comment:
Use of sys.exc_value and sys.exc_type is not thread
safe.  It should just use sys.exc_info.

Both exc_value and exc_type are used in two exceptiuon
trapping locations.

This goes back to at least 2.3, and I've checked 2.5
svn ver 50569 and it is still an issue.

Russ


----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-26 13:45

Message:
Logged In: YES 
user_id=11375

Tested patch attached.  I want to get the go-ahead from the
release manager before committing this change.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525469&group_id=5470

From noreply at sourceforge.net  Wed Jul 26 19:56:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 26 Jul 2006 10:56:46 -0700
Subject: [ python-Bugs-1442493 ] IDLE shell window gets very slow when
	displaying long lines
Message-ID: <E1G5nck-0000kY-BC@sc8-sf-web1.sourceforge.net>

Bugs item #1442493, was opened at 2006-03-03 16:45
Message generated for change (Comment added) made by taleinat
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1442493&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.4
Status: Open
Resolution: Wont Fix
Priority: 5
Submitted By: Heiko Selber (drhok)
Assigned to: Nobody/Anonymous (nobody)
Summary: IDLE shell window gets very slow when displaying long lines

Initial Comment:
I wrote a little python script that prints a large 
dictionary to stdout (simply using 'print 
mydictionary').

In fact, the type is irrelevant, what matters is that 
the resulting output had approx. 200,000 characters.

The shell prints the dictionary into a single line, 
which causes the window to be almost non-responding, 
e.g. when I try to scroll the window.

Even on a high-end PC it takes a minute or even 
longer to react to anything.

I use Python 2.4.2 on Windows XP SP2.

I am aware that it is not exactly wise to print such 
large objects, but I usually print return values to 
stdout when I debug a script, and I do not always 
expect an object to be that large.

The average text editor handles such long lines much 
better.

A quick workaround might be to break very long lines 
automagically (perhaps at around column 1000).

PS: I already observed the bug some years ago. I 
think I even submitted it to python or idlefork a 
long time ago but I was unable to find it in the 
buglist.


----------------------------------------------------------------------

Comment By: Tal Einat (taleinat)
Date: 2006-07-26 20:56

Message:
Logged In: YES 
user_id=1330769

The Squeezer extension works like a charm! It's also been
thoroughly tested by tens of users over the past several years.

Why not include it as one of the default extensions, and
have it enabled by default?

BTW I have a tweaked version of Squeezer (I fixed the line
counting code), if you're interested.

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2006-03-29 22:52

Message:
Logged In: YES 
user_id=149084

It's not that I don't consider it an issue, but I can't
do anything to improve the performance of the Tk text
widget.  IDLE is pure Python.

One thing that comes to mind is to set a maximum line 
length.  If the line exceeds that, print line(:(MAX -100)
+ '...' + line(:-100)  instead of printing the whole thing
which no one wants to look at anyway.

Another thing I've wanted to do is provide the ability
to clear the shell window when it gets too full, w/o
restarting IDLE.

Yes, you might ask the tkinter guys on their mail list,
I'd be interested in hearing their reply.

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-03-29 22:35

Message:
Logged In: YES 
user_id=341410

You can close the window which includes the Shell that has
the huge output, or even reduce the priority of your Idle
shell (you can make it automatic by mucking about with the
shortcut; see the 'start' command).

----------------------------------------------------------------------

Comment By: Heiko Selber (drhok)
Date: 2006-03-29 22:19

Message:
Logged In: YES 
user_id=865975

Hi kbk,

well, my use case is debugging. I write a script and run it
with IDLE. It doesn't behave as expected, so I insert a
print statement. Next time I run it, IDLE hangs. Oops, it
was a long array; it should have been an int. Line too long.
Duh.

OK, I wait through it, correct the bug, run it again. What
happens? IDLE hangs again, trying to scroll a long line (of
the previous run).

Never mind, I can always kill the process... Dammit, I
can't! It eats 100% CPU; task manager doesn't respond.

IMHO his takes away one of python's strengths, which is
making quick hacks really quick.

Would you suggest redirecting this issue to tkinter? You
don't seem to consider this an issue at all.

I will give squeezer a try. Or maybe PyDev?


----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2006-03-29 01:08

Message:
Logged In: YES 
user_id=149084

This is a known problem with Tk/Tcl/tkinter - large output 
scrolls slowly. It's not something that can be fixed in IDLE.  I 
tried it on Arch Linux - IDLE 2.5a0 - Tk 8.4.  250,000 character 
output not too bad , 25 sec, but 10,000 lines of 25 char takes 
over twice that long, so breaking the lines doesn't help.

I don't see any response problem once the output completes.  The 
situation is exponentially worse at 500,000 char.

What is your use case?  IDLE is designed to be an IDE.  Why 
output such massive data?

You may be interested in Squeezer, a Noam Raphael extension to 
IDLEfork.

http://sourceforge.net/tracker/index.php?
func=detail&aid=704316&group_id=9579&atid=309579

I haven't tried it myself, but it might be what you're looking 
for.

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-03-10 22:18

Message:
Logged In: YES 
user_id=341410

Generally speaking, most wrapping text controls have issues
with wrapping long lines.  It would seem reasonable to get
the width of the text control in characters, and manually
wrap all incoming lines regardless.  If the existance or not
of real line endings are important, one could mark which
lines are manually wrapped and remove the line endings on
copy (edit->copy, ctrl+c, etc.).

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2006-03-10 01:45

Message:
Logged In: YES 
user_id=593130

I verified this with print 100000*'a', also XP (home) sp2.
The sluggishness continued after getting the prompt back 
and trying to do something simple, like 2+2, taking maybe 
1/2 minute to print 4 and then the >>> prompt again.
The sluggishness *also* continued after restarting the 
shell (^F6).  This indicates that the problem is with the 
window, not with IDLE.  Hope someone can try same on *nix 
system to see if general with TKinter or specific to Win 
systems.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1442493&group_id=5470

From noreply at sourceforge.net  Wed Jul 26 06:11:27 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 25 Jul 2006 21:11:27 -0700
Subject: [ python-Bugs-1528620 ] Python 2.5b2 fails to build on Solaris 10
Message-ID: <E1G5ak3-0004Fo-84@sc8-sf-web6.sourceforge.net>

Bugs item #1528620, was opened at 2006-07-25 13:34
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528620&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
>Priority: 5
Submitted By: Guido Ostkamp (ostkamp)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.5b2 fails to build on Solaris 10

Initial Comment:
Hello,

I tried to build Python 2.5b2 on Solaris 10 with the
Sun Workshop Compiler, which fails.

Please see the attachment for a complete log in several
stages. Here is a short summary:

*
build/temp.solaris-2.10-sun4us-2.5/libffi/include/ffi.h
contains illegal C-syntax __attribute(...)

This might be legal for GCC, but not for other compilers. 

* Even if this is removed, there are other fatal
compiler errors in the _ctypes module later on.

* The build process seems to invoke _cursesmodule.c.
This contains the use of a function  mvwgetnstr(). This
function does not exist in /usr/lib/libcurses.so.

* The build process fails to link with libcurses.so.

The Python 2.4.3 release fails for the same reasons
regarding the curses problems, but the _ctypes stuff
did not exist in this form. 

I would appreciate, if these bugs could be fixed.

Regards,

Guido

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-25 21:11

Message:
Logged In: YES 
user_id=33168

Can you provide a patch to address these problems?

I don't know that any developers have access to the sun
workshop compiler.  We have a Solaris 10 box, but it only
has gcc AFAIK.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528620&group_id=5470

From noreply at sourceforge.net  Wed Jul 26 20:46:00 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 26 Jul 2006 11:46:00 -0700
Subject: [ python-Bugs-1501291 ] python/ncurses bug in 2.4.3 with extended
	ascii
Message-ID: <E1G5oOO-0007hc-37@sc8-sf-web2.sourceforge.net>

Bugs item #1501291, was opened at 2006-06-05 18:34
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501291&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: UnixOps (unixops1234)
Assigned to: Nobody/Anonymous (nobody)
Summary: python/ncurses bug in 2.4.3 with extended ascii

Initial Comment:
There is a problem displaying extended ascii characters
in ncurses through python, which does not exist in
versions prior to 2.4.2. I am running RedHat Enterprise
Linux WS 3 with updated patches, using the system
version of ncurses (ncurses-5.3-9.4 and devel). When
building a vanilla python 2.4.3 from source, printing
extended ascii characters in ncurses fails:

$ cat test.py
import curses

screen = curses.initscr()

screen.addstr("\x80")

screen.getch()
curses.endwin()

$ python test.py
Traceback (most recent call last):hon test.py
File "test.py", line 5, in ?
screen.addstr("\x80")
_curses.error: addstr() returned ERR

This should produce a blank ncurses screen, rather than
the addstr() error. I've been able to confirm that it
works with python 2.4.2 and earlier. 

To ensure that ncurses was able to display the
character, I wrote this test C program: 

$ cat test.c
#include <ncurses.h>

int main()
{
initscr();
int rtn = addstr("\x80");
getch(); 
endwin();
printf("The return value was %d.\n",rtn);
return 0;
}

$ gcc test.c -o test -lncurses
$ ./test

This works just fine, so I think the problem lies
somewhere in the python interface to ncurses. Python
can print this character without errors when not using
ncurses. Perhaps ncurses is expecting different
initialization than python is providing.  

I've also tested this on a RedHat WS 4 machine, where
it works just fine. This system is running
ncurses-5.4-13 and ncurses-devel-5.4-13. It seems the
newer release of python has changed something that the
older versions of ncurses are unable to handle.  

Can this be fixed in _cursesmodule.c?

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-26 14:45

Message:
Logged In: YES 
user_id=11375

The ncurses 5.5 changelog, currently at
http://www.gnu.org/software/ncurses/ncurses.html, contains
this entry:

  * use setlocale() to query the program's current locale
rather than using getenv(). This supports applications which
rely upon legacy treatment of 8-bit characters when the
locale is not initialized.

So maybe this is a problem in ncurses 5.4 that can be
avoided if your Python script calls 'locale.setlocale("<some
locale that uses Latin-1>")'.


----------------------------------------------------------------------

Comment By: UnixOps (unixops1234)
Date: 2006-06-08 16:02

Message:
Logged In: YES 
user_id=1534776

I tried recompiling Python with the patch from bug #1464056
that fixes the panelw linking in _curses_panel.so. It now
properly links with libpanelw instead of libpanel, but the
original problem persists. I still get "_curses.error:
addstr() returned ERR" when running the test code.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-06-08 13:58

Message:
Logged In: YES 
user_id=21627

I doubt it can be fixed in _cursesmodule. Notice that Python
links with ncursesw now, not with ncurses anymore. There is
a bug in 2.4.3 which links, apparently incorrectly, with
panel instead of panelw. Try changing that and see whether
it helps.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501291&group_id=5470

From noreply at sourceforge.net  Tue Jul 25 21:49:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 25 Jul 2006 12:49:23 -0700
Subject: [ python-Bugs-1528593 ] IDLE: printing issue on OSX
Message-ID: <E1G5SuB-0005mF-Nk@sc8-sf-web6.sourceforge.net>

Bugs item #1528593, was opened at 2006-07-25 21: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=1528593&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.6
Status: Open
Resolution: None
Priority: 3
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Nobody/Anonymous (nobody)
Summary: IDLE: printing issue on OSX

Initial Comment:
The printing solution for IDLE on OSX is lacking a page setup dialog, or 
even a print dialog. This means output will also be sent to the default 
printer.

If there is no default printer (which means the user hasn't defined a 
printer at all) the user will get a confusing message (lpr failed). BTW. the 
message is clear for technical users, but not for mac users that aren't unix 
saffy.

It would be nice if IDLE could interface with the Carbon/Cocoa print 
system using a real print dialog. That way users can select another than 
the default printer, change page settings and can even print to PDF.

I've filed this as a low-priority issue for 2.6 because there's no way this 
will get into 2.5 and it likey non-trivial as well.

BTW. this might be a feature-request rather than a bug.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528593&group_id=5470

From noreply at sourceforge.net  Tue Jul 25 22:34:39 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 25 Jul 2006 13:34:39 -0700
Subject: [ python-Bugs-1528620 ] Python 2.5b2 fails to build on Solaris 10
Message-ID: <E1G5Tbz-0004mZ-2Q@sc8-sf-web6.sourceforge.net>

Bugs item #1528620, was opened at 2006-07-25 22:34
Message generated for change (Settings changed) made by ostkamp
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528620&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
>Priority: 9
Submitted By: Guido Ostkamp (ostkamp)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.5b2 fails to build on Solaris 10

Initial Comment:
Hello,

I tried to build Python 2.5b2 on Solaris 10 with the
Sun Workshop Compiler, which fails.

Please see the attachment for a complete log in several
stages. Here is a short summary:

*
build/temp.solaris-2.10-sun4us-2.5/libffi/include/ffi.h
contains illegal C-syntax __attribute(...)

This might be legal for GCC, but not for other compilers. 

* Even if this is removed, there are other fatal
compiler errors in the _ctypes module later on.

* The build process seems to invoke _cursesmodule.c.
This contains the use of a function  mvwgetnstr(). This
function does not exist in /usr/lib/libcurses.so.

* The build process fails to link with libcurses.so.

The Python 2.4.3 release fails for the same reasons
regarding the curses problems, but the _ctypes stuff
did not exist in this form. 

I would appreciate, if these bugs could be fixed.

Regards,

Guido

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528620&group_id=5470

From noreply at sourceforge.net  Wed Jul 26 22:38:08 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 26 Jul 2006 13:38:08 -0700
Subject: [ python-Bugs-1442493 ] IDLE shell window gets very slow when
	displaying long lines
Message-ID: <E1G5q8u-0004HK-05@sc8-sf-web6.sourceforge.net>

Bugs item #1442493, was opened at 2006-03-03 09:45
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1442493&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.4
Status: Open
>Resolution: None
Priority: 5
Submitted By: Heiko Selber (drhok)
Assigned to: Nobody/Anonymous (nobody)
Summary: IDLE shell window gets very slow when displaying long lines

Initial Comment:
I wrote a little python script that prints a large 
dictionary to stdout (simply using 'print 
mydictionary').

In fact, the type is irrelevant, what matters is that 
the resulting output had approx. 200,000 characters.

The shell prints the dictionary into a single line, 
which causes the window to be almost non-responding, 
e.g. when I try to scroll the window.

Even on a high-end PC it takes a minute or even 
longer to react to anything.

I use Python 2.4.2 on Windows XP SP2.

I am aware that it is not exactly wise to print such 
large objects, but I usually print return values to 
stdout when I debug a script, and I do not always 
expect an object to be that large.

The average text editor handles such long lines much 
better.

A quick workaround might be to break very long lines 
automagically (perhaps at around column 1000).

PS: I already observed the bug some years ago. I 
think I even submitted it to python or idlefork a 
long time ago but I was unable to find it in the 
buglist.


----------------------------------------------------------------------

>Comment By: Kurt B. Kaiser (kbk)
Date: 2006-07-26 16:38

Message:
Logged In: YES 
user_id=149084

Sure, please open a patch and supply a diff against
Noam's version.

----------------------------------------------------------------------

Comment By: Tal Einat (taleinat)
Date: 2006-07-26 13:56

Message:
Logged In: YES 
user_id=1330769

The Squeezer extension works like a charm! It's also been
thoroughly tested by tens of users over the past several years.

Why not include it as one of the default extensions, and
have it enabled by default?

BTW I have a tweaked version of Squeezer (I fixed the line
counting code), if you're interested.

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2006-03-29 15:52

Message:
Logged In: YES 
user_id=149084

It's not that I don't consider it an issue, but I can't
do anything to improve the performance of the Tk text
widget.  IDLE is pure Python.

One thing that comes to mind is to set a maximum line 
length.  If the line exceeds that, print line(:(MAX -100)
+ '...' + line(:-100)  instead of printing the whole thing
which no one wants to look at anyway.

Another thing I've wanted to do is provide the ability
to clear the shell window when it gets too full, w/o
restarting IDLE.

Yes, you might ask the tkinter guys on their mail list,
I'd be interested in hearing their reply.

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-03-29 15:35

Message:
Logged In: YES 
user_id=341410

You can close the window which includes the Shell that has
the huge output, or even reduce the priority of your Idle
shell (you can make it automatic by mucking about with the
shortcut; see the 'start' command).

----------------------------------------------------------------------

Comment By: Heiko Selber (drhok)
Date: 2006-03-29 15:19

Message:
Logged In: YES 
user_id=865975

Hi kbk,

well, my use case is debugging. I write a script and run it
with IDLE. It doesn't behave as expected, so I insert a
print statement. Next time I run it, IDLE hangs. Oops, it
was a long array; it should have been an int. Line too long.
Duh.

OK, I wait through it, correct the bug, run it again. What
happens? IDLE hangs again, trying to scroll a long line (of
the previous run).

Never mind, I can always kill the process... Dammit, I
can't! It eats 100% CPU; task manager doesn't respond.

IMHO his takes away one of python's strengths, which is
making quick hacks really quick.

Would you suggest redirecting this issue to tkinter? You
don't seem to consider this an issue at all.

I will give squeezer a try. Or maybe PyDev?


----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2006-03-28 18:08

Message:
Logged In: YES 
user_id=149084

This is a known problem with Tk/Tcl/tkinter - large output 
scrolls slowly. It's not something that can be fixed in IDLE.  I 
tried it on Arch Linux - IDLE 2.5a0 - Tk 8.4.  250,000 character 
output not too bad , 25 sec, but 10,000 lines of 25 char takes 
over twice that long, so breaking the lines doesn't help.

I don't see any response problem once the output completes.  The 
situation is exponentially worse at 500,000 char.

What is your use case?  IDLE is designed to be an IDE.  Why 
output such massive data?

You may be interested in Squeezer, a Noam Raphael extension to 
IDLEfork.

http://sourceforge.net/tracker/index.php?
func=detail&aid=704316&group_id=9579&atid=309579

I haven't tried it myself, but it might be what you're looking 
for.

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-03-10 15:18

Message:
Logged In: YES 
user_id=341410

Generally speaking, most wrapping text controls have issues
with wrapping long lines.  It would seem reasonable to get
the width of the text control in characters, and manually
wrap all incoming lines regardless.  If the existance or not
of real line endings are important, one could mark which
lines are manually wrapped and remove the line endings on
copy (edit->copy, ctrl+c, etc.).

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2006-03-09 18:45

Message:
Logged In: YES 
user_id=593130

I verified this with print 100000*'a', also XP (home) sp2.
The sluggishness continued after getting the prompt back 
and trying to do something simple, like 2+2, taking maybe 
1/2 minute to print 4 and then the >>> prompt again.
The sluggishness *also* continued after restarting the 
shell (^F6).  This indicates that the problem is with the 
window, not with IDLE.  Hope someone can try same on *nix 
system to see if general with TKinter or specific to Win 
systems.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1442493&group_id=5470

From noreply at sourceforge.net  Wed Jul 26 23:17:07 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 26 Jul 2006 14:17:07 -0700
Subject: [ python-Bugs-1529269 ] Python 2.5b2 fails to build (GCC) on Solaris
	10
Message-ID: <E1G5qkd-0002Ew-Bd@sc8-sf-web3.sourceforge.net>

Bugs item #1529269, was opened at 2006-07-26 23: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=1529269&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido Ostkamp (ostkamp)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.5b2 fails to build (GCC) on Solaris 10

Initial Comment:
Hello,

as promised here is the second report because of
problems with building Python 2.5b2 on Solaris 10
(Sparc). I have been using the GCC this time.

These are the problems (for full logs please see
attachments):

building '_ctypes' extension
gcc -shared
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules
/_ctypes/_ctypes.o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/
Modules/_ctypes/callbacks.o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Pyth
on-2.5b2/Modules/_ctypes/callproc.o
build/temp.solaris-2.10-sun4us-2.5/home/ostk
amp/Python-2.5b2/Modules/_ctypes/stgdict.o
build/temp.solaris-2.10-sun4us-2.5/ho
me/ostkamp/Python-2.5b2/Modules/_ctypes/cfield.o
build/temp.solaris-2.10-sun4us-
2.5/home/ostkamp/Python-2.5b2/Modules/_ctypes/malloc_closure.o
build/temp.solari
s-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/prep_cif.
o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules/_ctypes/l
ibffi/src/sparc/ffi.o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5
b2/Modules/_ctypes/libffi/src/sparc/v8.o
build/temp.solaris-2.10-sun4us-2.5/home
/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v9.o
-o build/lib.solaris
-2.10-sun4us-2.5/_ctypes.so
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol <unknow
n>: offset 0xfeedcca5 is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol <unknow
n>: offset 0xfeedccab is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol <unknow
n>: offset 0xfeedccaf is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol <unknow
n>: offset 0xfeedccb3 is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol <unknow
n>: offset 0xfeeeae06 is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol <unknow
n>: offset 0xfeeecaf6 is non-aligned
collect2: ld returned 1 exit status

building '_curses' extension
gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -I. -I/
home/ostkamp/Python-2.5b2/./Include -I./Include -I.
-I/home/ostkamp/Python-2.5b2
/Include -I/home/ostkamp/Python-2.5b2 -c
/home/ostkamp/Python-2.5b2/Modules/_cur
sesmodule.c -o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modu
les/_cursesmodule.o
/home/ostkamp/Python-2.5b2/Modules/_cursesmodule.c: In
function `PyCursesWindow_
GetStr':
/home/ostkamp/Python-2.5b2/Modules/_cursesmodule.c:822:
warning: implicit declar
ation of function `mvwgetnstr'
gcc -shared
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules
/_cursesmodule.o -lcurses -ltermcap -o
build/lib.solaris-2.10-sun4us-2.5/_curses
.so
*** WARNING: renaming "_curses" since importing it
failed: ld.so.1: python: fata
l: relocation error: file
build/lib.solaris-2.10-sun4us-2.5/_curses.so: symbol m
vwgetnstr: referenced symbol not found
building '_curses_panel' extension
gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -I. -I/
home/ostkamp/Python-2.5b2/./Include -I./Include -I.
-I/home/ostkamp/Python-2.5b2
/Include -I/home/ostkamp/Python-2.5b2 -c
/home/ostkamp/Python-2.5b2/Modules/_cur
ses_panel.c -o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modu
les/_curses_panel.o
gcc -shared
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules
/_curses_panel.o -lpanel -lcurses -ltermcap -o
build/lib.solaris-2.10-sun4us-2.5
/_curses_panel.so
*** WARNING: renaming "_curses_panel" since importing
it failed: No module named
 _curses
running build_scripts

Regards,

Guido

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529269&group_id=5470

From noreply at sourceforge.net  Wed Jul 26 23:19:35 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 26 Jul 2006 14:19:35 -0700
Subject: [ python-Bugs-1529269 ] Python 2.5b2 fails to build on Solaris 10
	(GCC Compiler)
Message-ID: <E1G5qn1-0003VQ-OV@sc8-sf-web3.sourceforge.net>

Bugs item #1529269, was opened at 2006-07-26 23:17
Message generated for change (Settings changed) made by ostkamp
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529269&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido Ostkamp (ostkamp)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Python 2.5b2 fails to build on Solaris 10 (GCC Compiler)

Initial Comment:
Hello,

as promised here is the second report because of
problems with building Python 2.5b2 on Solaris 10
(Sparc). I have been using the GCC this time.

These are the problems (for full logs please see
attachments):

building '_ctypes' extension
gcc -shared
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules
/_ctypes/_ctypes.o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/
Modules/_ctypes/callbacks.o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Pyth
on-2.5b2/Modules/_ctypes/callproc.o
build/temp.solaris-2.10-sun4us-2.5/home/ostk
amp/Python-2.5b2/Modules/_ctypes/stgdict.o
build/temp.solaris-2.10-sun4us-2.5/ho
me/ostkamp/Python-2.5b2/Modules/_ctypes/cfield.o
build/temp.solaris-2.10-sun4us-
2.5/home/ostkamp/Python-2.5b2/Modules/_ctypes/malloc_closure.o
build/temp.solari
s-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/prep_cif.
o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules/_ctypes/l
ibffi/src/sparc/ffi.o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5
b2/Modules/_ctypes/libffi/src/sparc/v8.o
build/temp.solaris-2.10-sun4us-2.5/home
/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v9.o
-o build/lib.solaris
-2.10-sun4us-2.5/_ctypes.so
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol <unknow
n>: offset 0xfeedcca5 is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol <unknow
n>: offset 0xfeedccab is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol <unknow
n>: offset 0xfeedccaf is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol <unknow
n>: offset 0xfeedccb3 is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol <unknow
n>: offset 0xfeeeae06 is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol <unknow
n>: offset 0xfeeecaf6 is non-aligned
collect2: ld returned 1 exit status

building '_curses' extension
gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -I. -I/
home/ostkamp/Python-2.5b2/./Include -I./Include -I.
-I/home/ostkamp/Python-2.5b2
/Include -I/home/ostkamp/Python-2.5b2 -c
/home/ostkamp/Python-2.5b2/Modules/_cur
sesmodule.c -o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modu
les/_cursesmodule.o
/home/ostkamp/Python-2.5b2/Modules/_cursesmodule.c: In
function `PyCursesWindow_
GetStr':
/home/ostkamp/Python-2.5b2/Modules/_cursesmodule.c:822:
warning: implicit declar
ation of function `mvwgetnstr'
gcc -shared
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules
/_cursesmodule.o -lcurses -ltermcap -o
build/lib.solaris-2.10-sun4us-2.5/_curses
.so
*** WARNING: renaming "_curses" since importing it
failed: ld.so.1: python: fata
l: relocation error: file
build/lib.solaris-2.10-sun4us-2.5/_curses.so: symbol m
vwgetnstr: referenced symbol not found
building '_curses_panel' extension
gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -I. -I/
home/ostkamp/Python-2.5b2/./Include -I./Include -I.
-I/home/ostkamp/Python-2.5b2
/Include -I/home/ostkamp/Python-2.5b2 -c
/home/ostkamp/Python-2.5b2/Modules/_cur
ses_panel.c -o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modu
les/_curses_panel.o
gcc -shared
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules
/_curses_panel.o -lpanel -lcurses -ltermcap -o
build/lib.solaris-2.10-sun4us-2.5
/_curses_panel.so
*** WARNING: renaming "_curses_panel" since importing
it failed: No module named
 _curses
running build_scripts

Regards,

Guido

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529269&group_id=5470

From noreply at sourceforge.net  Thu Jul 27 00:04:48 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 26 Jul 2006 15:04:48 -0700
Subject: [ python-Bugs-1529297 ] unrelated variable messing up doctests
Message-ID: <E1G5rUm-00066m-T2@sc8-sf-web1.sourceforge.net>

Bugs item #1529297, was opened at 2006-07-26 15:02
Message generated for change (Settings changed) made by macquigg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529297&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: David MacQuigg (macquigg)
Assigned to: Nobody/Anonymous (nobody)
>Summary: unrelated variable messing up doctests

Initial Comment:
Version 2.5b2 with IDLE 1.2b2 running on Windows XP 
Home, fully updated.

Unpack the attached zip file.
Open program.py, test_suite.py, in separate IDLE 
windows.  
Run test_suite.py.  
  8 passed and 0 failed.
Now add a variable at the top of program.py, any name 
will do.
  xyz = 2
Re-run test_suite.py.  
  7 passed and 1 failed !!

I haven't been able to isolate the problem, but it is 
repeatable.  Taking out blocks of unrelated statements 
changes the behavior.  Feels like a memory allocation 
error, or something strange.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529297&group_id=5470

From noreply at sourceforge.net  Tue Jul 25 22:52:59 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 25 Jul 2006 13:52:59 -0700
Subject: [ python-Bugs-1516068 ] Under OS X,
	compiling against local readline fails
Message-ID: <E1G5Ttj-0004LF-W0@sc8-sf-web3.sourceforge.net>

Bugs item #1516068, was opened at 2006-07-03 02:42
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1516068&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Nelson Arzola (narzola72)
Assigned to: Nobody/Anonymous (nobody)
Summary: Under OS X, compiling against local readline fails

Initial Comment:
I've installed a version of the GNU Readline (5.1) in a
local directory (/Volumes/DATA/dev/toolset/{include,lib}.

I'm compiling Python with:

CFLAGS=-I/Volumes/DATA/dev/toolset/include \
LDFLAGS=-L/Volumes/DATA/dev/toolset/lib \
./configure \
     --prefix=/Volues/DATA/dev/toolset/inst/python \
     --with-libs="-lexpat -lncurses -lreadline"
make

I get the following error:

./Modules/readline.c:885: error: 'HISTORY_STATE'
undeclared (first use in this function)
./Modules/readline.c:885: error: 'state' undeclared
(first use in this function)
./Modules/readline.c:887: warning: assignment discards
qualifiers from pointer target type

When I look at the gcc command that was used to compile
Modules/readline.c, I see that my CFLAGS is not passed
to gcc and so the (broken) system readline is being used.

I can temporarily solve this problem with:

echo "readline readline.c ${CFLAGS} ${LDFLAGS}
-lreadline -l termcap" >> Modules/Setup.local

before I call make.

What I can't understand is why the build process
correctly uses the local version of expat (2.0.0) that
is installed in the directories with readline, but not
readline?

----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-25 22:52

Message:
Logged In: YES 
user_id=580910

I think this is fixed in python2.5, could you verify that?

I've applied a patch to setup.py a while back that makes it use -I and -L flags 
that in LDFLAGS/CFLAGS during the build of python (on osx only).

I'm building 2.5 with a local installation of readline (and several other libraries) 
and that works fine. 2.4 also works for me, but my 2.4 tree contains a number 
of patches that might affect this issue.

----------------------------------------------------------------------

Comment By: Nelson Arzola (narzola72)
Date: 2006-07-06 12:06

Message:
Logged In: YES 
user_id=1478788

I also included the complete session build log because I can
see that the CFLAGS and LDFLAGS are being passed through at
least some of the time.  Hope this all helps.

----------------------------------------------------------------------

Comment By: Nelson Arzola (narzola72)
Date: 2006-07-06 12:04

Message:
Logged In: YES 
user_id=1478788

I redid my build, and I can confirm that the build process
picked up the correct version of expat and will not pick up
the correct version of readline without the fix labeled above.

I've included my config.log because I think it might help
you -- atleast you can see the various settings that I had
in place.

Here is the output of otool -L:

CWD> /Volumes/DATA/dev/toolset/bin 
narzola at macmini 133> ./python
Python 2.4.3 (#1, Jul  6 2006, 02:42:44) 
[GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin
Type "help", "copyright", "credits" or "license" for more
information.
>>> 
CWD> /Volumes/DATA/dev/toolset/bin 
narzola at macmini 134> otool -L python
python:
       
/Volumes/DATA/dev/toolset/inst/expat/lib/libexpat.1.dylib
(compatibility version 7.0.0, current version 7.0.0)
        /usr/lib/libncurses.5.4.dylib (compatibility version
5.4.0, current version 5.4.0)
       
/Volumes/DATA/dev/toolset/inst/readline/lib/libreadline.5.1.dylib
(compatibility version 5.0.0, current version 5.1.0)
        /usr/lib/libSystem.B.dylib (compatibility version
1.0.0, current version 88.1.6)
        /usr/lib/libstdc++.6.dylib (compatibility version
7.0.0, current version 7.4.0)
        /usr/lib/libgcc_s.1.dylib (compatibility version
1.0.0, current version 1.0.0)
CWD> /Volumes/DATA/dev/toolset/bin 
narzola at macmini 135> 

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-06 10:22

Message:
Logged In: YES 
user_id=580910

Are you sure it picks up the copy of expat you expect it to use?

I fixed this issue (CFLAGS being ignored) for python 2.5 (on the mac only).

BTW. You should use "OPT" instead of "CFLAGS" to pass additional compiler 
flags, IIRC the latter is replaced completely by the configure script.

----------------------------------------------------------------------

Comment By: Nelson Arzola (narzola72)
Date: 2006-07-03 02:44

Message:
Logged In: YES 
user_id=1478788

Sorry, I forgot to mention that I'm using the latest verion
of Python 2.4.3 from python.org.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1516068&group_id=5470

From noreply at sourceforge.net  Wed Jul 26 19:33:27 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 26 Jul 2006 10:33:27 -0700
Subject: [ python-Bugs-1528074 ] difflib.SequenceMatcher.find_longest_match()
	wrong result
Message-ID: <E1G5nGB-0004Xm-C7@sc8-sf-web1.sourceforge.net>

Bugs item #1528074, was opened at 2006-07-24 19:59
Message generated for change (Settings changed) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528074&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: John Machin (sjmachin)
>Assigned to: Tim Peters (tim_one)
Summary: difflib.SequenceMatcher.find_longest_match()  wrong result

Initial Comment:
A short example script is attached.
Two strings, each 500 bytes long. Longest match is the
first 32 bytes of each string. Result produced is a
10-byte match later in the string.

If one byte is chopped off the end of each string (len
now 499 each), the correct result is produced.

Other observations, none of which may be relevant:
1. Problem may be in the heuristic for "popular"
elements in the __chain_b method. In this particular
example, the character '0' (which has frequency of 6 in
the "b" string) is not "popular" with a len of 500 but
is "popular" with a len of 499.
2. '0' is the last byte of the correct longest match.
3. The correct longest match is at the start of the
each of the strings.
4. Disabling the "popular" heuristic (like below)
appears to make the problem go away:

                if 0:
                # if n >= 200 and len(indices) * 100 > n:
                    populardict[elt] = 1
                    del indices[:]
                else:
                    indices.append(i)
5. The callable self.isbpopular is created but appears
to be unused.
6. The determination of "popular" doesn't accord with
the comments, which say 1%. However with len==500,
takes 6 to be popular.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528074&group_id=5470

From noreply at sourceforge.net  Wed Jul 26 22:52:13 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 26 Jul 2006 13:52:13 -0700
Subject: [ python-Bugs-1528620 ] Python 2.5b2 fails to build on Solaris 10
Message-ID: <E1G5qMX-0006iv-V0@sc8-sf-web3.sourceforge.net>

Bugs item #1528620, was opened at 2006-07-25 22:34
Message generated for change (Comment added) made by ostkamp
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528620&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido Ostkamp (ostkamp)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.5b2 fails to build on Solaris 10

Initial Comment:
Hello,

I tried to build Python 2.5b2 on Solaris 10 with the
Sun Workshop Compiler, which fails.

Please see the attachment for a complete log in several
stages. Here is a short summary:

*
build/temp.solaris-2.10-sun4us-2.5/libffi/include/ffi.h
contains illegal C-syntax __attribute(...)

This might be legal for GCC, but not for other compilers. 

* Even if this is removed, there are other fatal
compiler errors in the _ctypes module later on.

* The build process seems to invoke _cursesmodule.c.
This contains the use of a function  mvwgetnstr(). This
function does not exist in /usr/lib/libcurses.so.

* The build process fails to link with libcurses.so.

The Python 2.4.3 release fails for the same reasons
regarding the curses problems, but the _ctypes stuff
did not exist in this form. 

I would appreciate, if these bugs could be fixed.

Regards,

Guido

----------------------------------------------------------------------

>Comment By: Guido Ostkamp (ostkamp)
Date: 2006-07-26 22:52

Message:
Logged In: YES 
user_id=1028306

Hello,

@nnorwitz:

Unfortunately I cannot provide a patch, but can give some hints:

If you (or the developers) have a Solaris 10 box, they can
download the Sun Studio 11 which includes the Sun Compiler
for free from the URL:
<http://developers.sun.com/prodtech/cc/downloads/index.jsp>

Then you should be able to verify the problems yourself
(though I am using an older version of the compiler from the
times when it was commercial).

Regarding the _ctypes module problems:

The module contains a libffi which nowadays appears to be
part of the GNU GCC. This lib was never made to work with
anything else but GCC, as it seems. Even older versions do
not compile.

Therefore, if this module is not really necessary, it should
be removed or at least deactivated by the configuration if
not using GCC. It also seems, that other modules like
_struct appear to be depending on this, if I'm right.

Regarding the curses problem:

I can workaround this if changing the mvwgetnstr() to
mvwgetstr() with omitting the last parameter. However this
should be configured automatically.

Futhermore there was no linking of the correct library
(/usr/lib/libcurses.so). I had to activate the curses entry
in Modules/Setup manually and to call make two more times. 

Regarding GCC on Solaris: I tried with GCC but it failed on
Solaris 10 as well. I will open a new fault report for the
GCC problems.

@akuchling:

You say the curses bug should be fixed in 2.4 and 2.5. It
isn't. I tried 2.4.3 yesterday as well and ran into the very
same problem. Or do you mean it was changed more recently?



----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-26 19:28

Message:
Logged In: YES 
user_id=11375

The _cursesmodule mvwgetnstr() problem was reported as bug
#1471938 and should now be fixed on both the 2.4 and 2.5
branches.



----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-26 06:11

Message:
Logged In: YES 
user_id=33168

Can you provide a patch to address these problems?

I don't know that any developers have access to the sun
workshop compiler.  We have a Solaris 10 box, but it only
has gcc AFAIK.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528620&group_id=5470

From noreply at sourceforge.net  Thu Jul 27 05:31:08 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 26 Jul 2006 20:31:08 -0700
Subject: [ python-Bugs-1513611 ] xml.sax.ParseException weirdness in python
	2.5b1
Message-ID: <E1G5waa-0007CL-Qr@sc8-sf-web3.sourceforge.net>

Bugs item #1513611, was opened at 2006-06-27 14:06
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513611&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: XML
Group: Python 2.5
Status: Open
Resolution: None
>Priority: 9
Submitted By: Marien Zwart (marienz)
Assigned to: Nobody/Anonymous (nobody)
Summary: xml.sax.ParseException weirdness in python 2.5b1

Initial Comment:
There is something weird going on with xml.sax
exceptions, probably related to the xml/xmlcore shuffle:

from xml.sax import make_parser, SAXParseException
from StringIO import StringIO

parser = make_parser()

try:
    parser.parse(StringIO('invalid'))
except SAXParseException:
    print 'caught it!'

On python 2.4.3 this prints "caught it!". On python
2.5b1 the exception is not caught, because it is a
different  exception: an
xmlcore.sax._exceptions.SAXParseException. Printing the
SAXParseException imported from xml.sax gives "<class
'xml.sax._exceptions.SAXParseException'>".

Stumbled on this running the logilab-common (see
logilab.org) tests with python 2.5b1, but it seems
likely other code will be affected.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-26 20:31

Message:
Logged In: YES 
user_id=33168

I think Martin is of the same opinion.  This needs to be
resolved soon.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-26 20:03

Message:
Logged In: YES 
user_id=3066

I've managed to come up with a patch that solves this
specific issue, but it really deals with the symptom and not
the real problems.

While I think the "xmlcore" package was the right idea, I'm
not convinced it can be correctly implemented without
enormous effort at this time.  Given the release schedule,
it doesn't make sense to jump through those hoops.  The
previous hackery that made allowed the PyXML distribution to
"replace" the standard library version of the "xml" package
worked only because there was only one public name for
whichever was being used.  Moving to the "xmlcore" package
proved to be more than that hack could support.

I think the right thing to do for Python 2.5 is to revert
the changes that added the "xmlcore" package.  Further
investigation into a better approach can be made for Python 2.6.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-26 19:36

Message:
Logged In: YES 
user_id=3066

The patch attached contains the wrong bug number, but it
really is for this issue.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-26 19:01

Message:
Logged In: YES 
user_id=3066

Patch #1519796 does not do anything for this, based on the
current trunk.  I've attached a diff containing a test case.

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-07-10 00:37

Message:
Logged In: YES 
user_id=1326842

This bug is simmilar to http://python.org/sf/1511497.
It is caused by absolute imports in xmlcore.sax.expatreader.
Patch #1519796 ( http://python.org/sf/1519796 )
should fix it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513611&group_id=5470

From noreply at sourceforge.net  Thu Jul 27 06:35:54 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 26 Jul 2006 21:35:54 -0700
Subject: [ python-Bugs-1521947 ] possible bug in mystrtol.c with recent gcc
Message-ID: <E1G5xbG-0000vG-Fz@sc8-sf-web6.sourceforge.net>

Bugs item #1521947, was opened at 2006-07-13 10:39
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521947&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Marien Zwart (marienz)
Assigned to: Nobody/Anonymous (nobody)
Summary: possible bug in mystrtol.c with recent gcc

Initial Comment:
python 2.5b2 compiled with gentoo's gcc 4.1.1 and -O2
fails test_unary_minus in test_compile.py. Some
investigating showed that the -ftree-vrp pass of that
gcc (implied by -O2) optimizes out the "result ==
-result" test on line 215 of PyOS_strtol, meaning
PyOS_strtol of the most negative long will incorrectly
overflow. 

Python deals with this in this case by constructing a
python long object instead of a python int object, so
at least in this case the problem is not serious. I
have no idea if there is a case where this is a "real"
problem.

At first I reported this as a gentoo compiler bug, but
got the reply that:

"""
I'm pretty sure it's broken. -LONG_MIN overflows when
LONG_MIN < -LONG_MAX, and in standard C as well as "GNU
C", behaviour after overflow on signed integer
operations is undefined.
"""

(see https://bugs.gentoo.org/show_bug.cgi?id=140133)

So now I'm reporting this here. There seems to be a
LONG_MIN constant in limits.h here that could checked
against instead, but I have absolutely no idea how
standard that is. Or this could be a compiler bug after
all, in which case I would appreciate information I Can
use to back that up :)

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-26 21:35

Message:
Logged In: YES 
user_id=33168

Tim's fix corrected the problem on amd64 gentoo linux with
gcc 4.1.1.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-26 18:16

Message:
Logged In: YES 
user_id=31435

Made a non-heroic effort to repair this in rev 50855, but
have no platform on which it could make any difference (and
apparently no Python buildbot test platform cares either) .
 Would be nice if someone who has such a platform could
check against current Python trunk.

----------------------------------------------------------------------

Comment By: Nick Maclaren (nmm)
Date: 2006-07-17 02:20

Message:
Logged In: YES 
user_id=42444

Yes, this is a duplicate of 1521726.

The compiler people's answer is correct, and mystrtoul.c is
incorrect. LONG_MIN has been in C since C90, so should be
safe, but its value may not always be what you expect.

However, the code breakage is worse that just that test, and
there are the following 3 cases of undefined behaviour:

    1) Casting and unsigned long to long above LONG_MAX.
    2) That test.
    3) result = -result.

The fix should be to make result unsigned long, and check
the range BEFORE any conversion.  Nothing else is safe.

It is a matter of taste whether to include a fiddle for the
number that can be held only when negated - I wouldn't, and
would let that number be converted to a Python long, but
others might disagree.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-16 18:13

Message:
Logged In: YES 
user_id=33168

Is this a duplicate of 1521726?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521947&group_id=5470

From noreply at sourceforge.net  Thu Jul 27 05:03:19 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 26 Jul 2006 20:03:19 -0700
Subject: [ python-Bugs-1513611 ] xml.sax.ParseException weirdness in python
	2.5b1
Message-ID: <E1G5w9f-0007XM-Np@sc8-sf-web1.sourceforge.net>

Bugs item #1513611, was opened at 2006-06-27 17:06
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513611&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: XML
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Marien Zwart (marienz)
Assigned to: Nobody/Anonymous (nobody)
Summary: xml.sax.ParseException weirdness in python 2.5b1

Initial Comment:
There is something weird going on with xml.sax
exceptions, probably related to the xml/xmlcore shuffle:

from xml.sax import make_parser, SAXParseException
from StringIO import StringIO

parser = make_parser()

try:
    parser.parse(StringIO('invalid'))
except SAXParseException:
    print 'caught it!'

On python 2.4.3 this prints "caught it!". On python
2.5b1 the exception is not caught, because it is a
different  exception: an
xmlcore.sax._exceptions.SAXParseException. Printing the
SAXParseException imported from xml.sax gives "<class
'xml.sax._exceptions.SAXParseException'>".

Stumbled on this running the logilab-common (see
logilab.org) tests with python 2.5b1, but it seems
likely other code will be affected.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-26 23:03

Message:
Logged In: YES 
user_id=3066

I've managed to come up with a patch that solves this
specific issue, but it really deals with the symptom and not
the real problems.

While I think the "xmlcore" package was the right idea, I'm
not convinced it can be correctly implemented without
enormous effort at this time.  Given the release schedule,
it doesn't make sense to jump through those hoops.  The
previous hackery that made allowed the PyXML distribution to
"replace" the standard library version of the "xml" package
worked only because there was only one public name for
whichever was being used.  Moving to the "xmlcore" package
proved to be more than that hack could support.

I think the right thing to do for Python 2.5 is to revert
the changes that added the "xmlcore" package.  Further
investigation into a better approach can be made for Python 2.6.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-26 22:36

Message:
Logged In: YES 
user_id=3066

The patch attached contains the wrong bug number, but it
really is for this issue.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-26 22:01

Message:
Logged In: YES 
user_id=3066

Patch #1519796 does not do anything for this, based on the
current trunk.  I've attached a diff containing a test case.

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-07-10 03:37

Message:
Logged In: YES 
user_id=1326842

This bug is simmilar to http://python.org/sf/1511497.
It is caused by absolute imports in xmlcore.sax.expatreader.
Patch #1519796 ( http://python.org/sf/1519796 )
should fix it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513611&group_id=5470

From noreply at sourceforge.net  Tue Jul 25 22:06:14 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 25 Jul 2006 13:06:14 -0700
Subject: [ python-Bugs-1526585 ] Concatenation on a long string breaks
Message-ID: <E1G5TAU-0007dC-AH@sc8-sf-web6.sourceforge.net>

Bugs item #1526585, was opened at 2006-07-21 13:18
Message generated for change (Comment added) made by kuran
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1526585&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 6
Submitted By: Jp Calderone (kuran)
Assigned to: Nobody/Anonymous (nobody)
Summary: Concatenation on a long string breaks

Initial Comment:
Consider this transcript:

exarkun at charm:~/Projects/python/trunk$ ./python
Python 2.5b2 (trunk:50698, Jul 18 2006, 10:08:36)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> x = 'x' * (2 ** 31 - 1)
>>> x = x + 'x'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SystemError: Objects/stringobject.c:4103: bad argument
to internal function
>>> len(x)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'x' is not defined
>>> 


I would expect some exception other than SystemError
and for the locals namespace to not become corrupted.


----------------------------------------------------------------------

>Comment By: Jp Calderone (kuran)
Date: 2006-07-25 16:06

Message:
Logged In: YES 
user_id=366566

Tested Armin's patch, looks like it addresses the issue. 
One thing I noticed though, ('x' * (2 ** 32 - 2) + 'x')
fails the same way ('x' * (2 ** 32 - 1) + 'x').  Don't
really understand why, just thought I'd mention it.


----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2006-07-25 14:25

Message:
Logged In: YES 
user_id=4771

The check should be done before the variable is removed
from the namespace, so that 'x' doesn't just disappear.
Attached a patch that does this.  Also, let's produce
an exception consistent with what PyString_Concat()
raises in the same case, which is an OverflowError
instead of a MemoryError.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-24 23:57

Message:
Logged In: YES 
user_id=31435

[Neal]
>  Tim since we know both lens are >= 0, is this test
> sufficient for verifying overflow:
>
>     Py_ssize_t new_len = v_len + w_len;
>     if (new_len < 0) {

Right!  That's all the new checking needed in
string_concatenate().

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-24 23:46

Message:
Logged In: YES 
user_id=33168

Attached a patch against 2.5.  The patch should work against
2.4 too, but you will need to change all Py_ssize_t to int.
 Tim since we know both lens are >= 0, is this test
sufficient for verifying overflow:

      Py_ssize_t new_len = v_len + w_len;
      if (new_len < 0) {

Jp, can you test the patch?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-22 10:11

Message:
Logged In: YES 
user_id=31435

Part of the problem appears to be that ceval.c's
string_concatenate() doesn't check for overflow in the
second argument here:

if (_PyString_Resize(&v, v_len + w_len) != 0)

The Windows malloc on my box returns NULL (and so Python
raises MemoryError) on the initial:

x = 'x' * (2 ** 31 - 1)

attempt, so I never get that far.  I'm afraid this is
muddier in strange ways on Linux because the Linux malloc()
is pathologically optimistic (can return a non-NULL value
pointing at "memory" that can't actually be used for anything).

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2006-07-22 05:00

Message:
Logged In: YES 
user_id=6656

Confirmed with 2.4.  Ouch.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1526585&group_id=5470

From noreply at sourceforge.net  Tue Jul 25 23:10:20 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 25 Jul 2006 14:10:20 -0700
Subject: [ python-Bugs-1257728 ] error message incorrectly claims Visual C++
	is required
Message-ID: <E1G5UAW-0001Ts-NP@sc8-sf-web6.sourceforge.net>

Bugs item #1257728, was opened at 2005-08-12 15:28
Message generated for change (Comment added) made by zooko
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257728&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Zooko O'Whielacronx (zooko)
Assigned to: Nobody/Anonymous (nobody)
Summary: error message incorrectly claims Visual C++ is required

Initial Comment:
Thank you for the excellent distutils tool!

Two problems:

First, this error message is emitted on win32, but it
appears to be incorrect, inasmuch as the Microsoft
compiler is not actually required:

"""
error: Python was built with version 7.1 of Visual
Studio, and extensions need to be built with the same
version of the compiler, but it isn't installed.
Error: Subprocess exited with result 1 for project core
"""

Second, the usage of distutils is somewhat confusing,
as the following line emits that error message:

./setup.py build -c mingw32; ./setup.py install

but the following line, which I intuitively believed to
be equivalent at first, works to compile and install
the package:

./setup.py build -c mingw32 install

----------------------------------------------------------------------

>Comment By: Zooko O'Whielacronx (zooko)
Date: 2006-07-25 21:10

Message:
Logged In: YES 
user_id=52562

How about:

"""
error: Python was built with version 7.1 of Visual
Studio, and extensions need to be built with a compiler that
can generate compatible binaries.  Some versions of gcc can
produce compatible binaries if given the "-mno-cygwin" flag.
 Distutils will pass the "-mno-cygwin" flag to gcc if
distutils is given the "-c mingw32" flag to the "build" command.

Error: Subprocess exited with result 1 for project core
"""

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-07-24 13:00

Message:
Logged In: YES 
user_id=21627

What would you like to say the error message instead?

----------------------------------------------------------------------

Comment By: Zooko O'Whielacronx (zooko)
Date: 2006-03-31 11:35

Message:
Logged In: YES 
user_id=52562

Changing this from category Distutils to category Windows.

----------------------------------------------------------------------

Comment By: Zooko O'Whielacronx (zooko)
Date: 2005-11-23 18:51

Message:
Logged In: YES 
user_id=52562

Whoo!  Progress!  Now it no longer spuriously claims that
Visual C++ is required for building extensions for Python,
and instead it spuriously claims that the .NET SDK is
required for building extensions for Python!

"""
error: The .NET Framework SDK needs to be installed before
building extensions for Python.
"""

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257728&group_id=5470

From noreply at sourceforge.net  Thu Jul 27 12:49:49 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 27 Jul 2006 03:49:49 -0700
Subject: [ python-Bugs-1521947 ] possible bug in mystrtol.c with recent gcc
Message-ID: <E1G63R7-0001x8-5T@sc8-sf-web3.sourceforge.net>

Bugs item #1521947, was opened at 2006-07-13 17:39
Message generated for change (Comment added) made by splitscreen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521947&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Marien Zwart (marienz)
Assigned to: Nobody/Anonymous (nobody)
Summary: possible bug in mystrtol.c with recent gcc

Initial Comment:
python 2.5b2 compiled with gentoo's gcc 4.1.1 and -O2
fails test_unary_minus in test_compile.py. Some
investigating showed that the -ftree-vrp pass of that
gcc (implied by -O2) optimizes out the "result ==
-result" test on line 215 of PyOS_strtol, meaning
PyOS_strtol of the most negative long will incorrectly
overflow. 

Python deals with this in this case by constructing a
python long object instead of a python int object, so
at least in this case the problem is not serious. I
have no idea if there is a case where this is a "real"
problem.

At first I reported this as a gentoo compiler bug, but
got the reply that:

"""
I'm pretty sure it's broken. -LONG_MIN overflows when
LONG_MIN < -LONG_MAX, and in standard C as well as "GNU
C", behaviour after overflow on signed integer
operations is undefined.
"""

(see https://bugs.gentoo.org/show_bug.cgi?id=140133)

So now I'm reporting this here. There seems to be a
LONG_MIN constant in limits.h here that could checked
against instead, but I have absolutely no idea how
standard that is. Or this could be a compiler bug after
all, in which case I would appreciate information I Can
use to back that up :)

----------------------------------------------------------------------

Comment By: Matt Fleming (splitscreen)
Date: 2006-07-27 10:49

Message:
Logged In: YES 
user_id=1126061

Fixed for me on NetBSD -current AMD64, gcc 4.1.2

----------------------------------------------------------------------

Comment By: Nick Maclaren (nmm)
Date: 2006-07-27 08:31

Message:
Logged In: YES 
user_id=42444

Fixed for me, too, and the code looks solid.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-27 04:48

Message:
Logged In: YES 
user_id=33168

I reopened this bug as it still affects 2.4.  Tim's fix
should be backported.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-27 04:35

Message:
Logged In: YES 
user_id=33168

Tim's fix corrected the problem on amd64 gentoo linux with
gcc 4.1.1.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 01:16

Message:
Logged In: YES 
user_id=31435

Made a non-heroic effort to repair this in rev 50855, but
have no platform on which it could make any difference (and
apparently no Python buildbot test platform cares either) .
 Would be nice if someone who has such a platform could
check against current Python trunk.

----------------------------------------------------------------------

Comment By: Nick Maclaren (nmm)
Date: 2006-07-17 09:20

Message:
Logged In: YES 
user_id=42444

Yes, this is a duplicate of 1521726.

The compiler people's answer is correct, and mystrtoul.c is
incorrect. LONG_MIN has been in C since C90, so should be
safe, but its value may not always be what you expect.

However, the code breakage is worse that just that test, and
there are the following 3 cases of undefined behaviour:

    1) Casting and unsigned long to long above LONG_MAX.
    2) That test.
    3) result = -result.

The fix should be to make result unsigned long, and check
the range BEFORE any conversion.  Nothing else is safe.

It is a matter of taste whether to include a fiddle for the
number that can be held only when negated - I wouldn't, and
would let that number be converted to a Python long, but
others might disagree.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-17 01:13

Message:
Logged In: YES 
user_id=33168

Is this a duplicate of 1521726?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521947&group_id=5470

From noreply at sourceforge.net  Tue Jul 25 22:40:18 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 25 Jul 2006 13:40:18 -0700
Subject: [ python-Bugs-1519452 ] zipfile -- too many files?
Message-ID: <E1G5ThS-00059E-Vy@sc8-sf-web3.sourceforge.net>

Bugs item #1519452, was opened at 2006-07-09 07:57
Message generated for change (Settings changed) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519452&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Python Library
Group: None
Status: Open
>Resolution: Fixed
Priority: 5
Submitted By: Joe Brown (shmengie)
Assigned to: Nobody/Anonymous (nobody)
Summary: zipfile -- too many files?

Initial Comment:
While creating a huge zipfile (probably too big) the
following error appeared.

Exception exceptions.OverflowError: 'long int too large
to convert to int' in <bound method ZipFile.__del__ of
<zipfile.ZipFile instance at 0x009BD198>> ignored

I assume this is during the closing of the zipfile,
further assuming too many files were added to the archive.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-13 10:17

Message:
Logged In: YES 
user_id=580910

hmm, I should read all new comments before responding :-(

To use the ZIP64 extensions with python2.5 you must add 'allowZip64=True' to 
arguments of the zipfile constructor. ZIP64 is disabled by default because the 
unix zip tools don't support zip64.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-13 09:47

Message:
Logged In: YES 
user_id=580910

The problem with zipfile is not the number of files, but the size of the archive. 
The basic zip file format stores file sizes as 32 bit (signed) integers, there is an 
extension for using 64 bit integers, but that isn't supported in python 2.4.

----------------------------------------------------------------------

Comment By: Joe Brown (shmengie)
Date: 2006-07-12 04:17

Message:
Logged In: YES 
user_id=729883

Windows 2.5 beta 2 responded like this:

Traceback (most recent call last):
  File "C:\python_scripts\archive.py", line 27, in <module>
    main()
  File "C:\python_scripts\archive.py", line 23, in main
    zipper(zip, folder)
  File "C:\python_scripts\archive.py", line 15, in zipper
    zip.write(os.path.join(root, item))
  File "C:\Python25\lib\zipfile.py", line 561, in write
    self._writecheck(zinfo)
  File "C:\Python25\lib\zipfile.py", line 536, in _writecheck
    raise LargeZipFile("Zipfile size would require ZIP64
extensions")
zipfile.LargeZipFile: Zipfile size would require ZIP64
extensions
C:\Python25\lib\struct.py:63: DeprecationWarning: struct
integer overflow maskin
g is deprecated
  return o.pack(*args)

----------------------------------------------------------------------

Comment By: Joe Brown (shmengie)
Date: 2006-07-11 22:08

Message:
Logged In: YES 
user_id=729883

The zip file was on order of 6-9 GBs, surely over 32000
files.  I will give Python2.5 a shot and see how that works.

I've stumbled on another bug with tarfile.  It's not
reporting an error, but I only find 350 files when I
unarchive.  That's entirely different bug tho :-o

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-11 19:47

Message:
Logged In: YES 
user_id=580910

How large is the resulting file? Zipfile in python2.4 cannot handle zipfiles that 
require the zip64 extensions and fails misserably when you do cross that limit.

This was fixed in python 2.5.

----------------------------------------------------------------------

Comment By: Joe Brown (shmengie)
Date: 2006-07-09 08:01

Message:
Logged In: YES 
user_id=729883

Platform: Windows SBS 2003
Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit
(Intel)] on win32

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519452&group_id=5470

From noreply at sourceforge.net  Thu Jul 27 13:51:31 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 27 Jul 2006 04:51:31 -0700
Subject: [ python-Bugs-1469557 ] FTP modue functions are not re-entrant,
	give odd exceptions
Message-ID: <E1G64Op-00045G-Hx@sc8-sf-web6.sourceforge.net>

Bugs item #1469557, was opened at 2006-04-13 00:13
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469557&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
>Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Bruce (brucepeterson)
Assigned to: Nobody/Anonymous (nobody)
Summary: FTP modue functions are not re-entrant,give odd exceptions

Initial Comment:
 If I define a class using the Thread and FTP moudles, 
start a process which gathers FTP responses, 
additional calls to the class may have the responses 
of the thread instead of the main loop (or vice versa)
  This causes weird and unexpected exceptions from the 
ftplib.

  For instance I get the following error when the 
thread process does a pwd() function
error_reply: 213 34603008  

  The "213" reply is a response from the main process 
size() function

---------
Code
---------
from time import sleep
from threading import Thread

class ftpMachine(Thread, ftplib.FTP):
    def __init__(self, svr, user, passwd):
        Thread.__init__(self)
        ftplib.FTP.__init__(self, svr, user, passwd)
        
    def run(self):
        for x in xrange(20):
            output="Thread -"+str(self.nlst())[:30]
            print output
            sleep (0.0100)

def main():
    aCon = ftpMachine("LocalFTP", "user", "")
    aCon.start()
    for x in xrange(20):
        output = "Main -- " + str(aCon.size("File"))
        print output  
        sleep (0.010)

Workround:
  Rewrite code to create a third worker thread for 
response isolation?  Don't know that this would solve 
the problem.


---------------
Exception example
---------------

Exception in thread Thread-1:
Traceback (most recent call last):
  File "C:\Python24\lib\threading.py", line 442, in 
__bootstrap
    self.run()
  File "dualFTPIssue.py", line 17, in run
    output  = "Thread output " + str(self.nlst())[:30]
+" ..."
  File "C:\Python24\lib\ftplib.py", line 448, in nlst
    self.retrlines(cmd, files.append)
  File "C:\Python24\lib\ftplib.py", line 396, in 
retrlines
    conn = self.transfercmd(cmd)
  File "C:\Python24\lib\ftplib.py", line 345, in 
transfercmd
    return self.ntransfercmd(cmd, rest)[0]
  File "C:\Python24\lib\ftplib.py", line 321, in 
ntransfercmd
    host, port = self.makepasv()
  File "C:\Python24\lib\ftplib.py", line 299, in 
makepasv
    host, port = parse227(self.sendcmd('PASV'))
  File "C:\Python24\lib\ftplib.py", line 566, in 
parse227
    raise error_reply, resp
error_reply: 213 34603008

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-13 11:54

Message:
Logged In: YES 
user_id=580910

IMHO this isn't a bug, your accessing a shared resource (the FTP connection) 
from two threads without locking. Most of python's libraries aren't safe for this 
kind of use.

BTW. The fact that you subclass form thread and ftplib.FTP is immaterial, you 
will get the same effect if you create an ftplib.FTP and then use it in two threads.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469557&group_id=5470

From noreply at sourceforge.net  Thu Jul 27 14:15:15 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 27 Jul 2006 05:15:15 -0700
Subject: [ python-Bugs-1529297 ] unrelated variable messing up doctests
Message-ID: <E1G64ln-00055h-5f@sc8-sf-web2.sourceforge.net>

Bugs item #1529297, was opened at 2006-07-26 18:02
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529297&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: David MacQuigg (macquigg)
Assigned to: Nobody/Anonymous (nobody)
Summary: unrelated variable messing up doctests

Initial Comment:
Version 2.5b2 with IDLE 1.2b2 running on Windows XP 
Home, fully updated.

Unpack the attached zip file.
Open program.py, test_suite.py, in separate IDLE 
windows.  
Run test_suite.py.  
  8 passed and 0 failed.
Now add a variable at the top of program.py, any name 
will do.
  xyz = 2
Re-run test_suite.py.  
  7 passed and 1 failed !!

I haven't been able to isolate the problem, but it is 
repeatable.  Taking out blocks of unrelated statements 
changes the behavior.  Feels like a memory allocation 
error, or something strange.


----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-27 08:15

Message:
Logged In: YES 
user_id=11375

On a Linux machine, both 2.4.3 and SVN HEAD report 7 tests
passed, one failed.

For both versions, the failure is: 
Failed example:
    _envrcpt('zz1 at open-mail.org')
Expected:
    CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 101, '']]
Got:
    CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 50, '']]


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-26 23:59

Message:
Logged In: YES 
user_id=33168

Can you try with SVN head?  There was an unitialized read
that the doctests could trigger.  It has been fixed. 
Perhaps you are running into that?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529297&group_id=5470

From noreply at sourceforge.net  Thu Jul 27 14:38:52 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 27 Jul 2006 05:38:52 -0700
Subject: [ python-Bugs-1526834 ] unbalanced parentheses from command line
	crash pdb
Message-ID: <E1G658d-0007x9-LK@sc8-sf-web3.sourceforge.net>

Bugs item #1526834, was opened at 2006-07-22 00:03
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1526834&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Ilya Sandler (isandler)
>Assigned to: A.M. Kuchling (akuchling)
Summary: unbalanced parentheses  from command line crash pdb

Initial Comment:
 bagira:~/python-svn/patches> cat simple
 print 123

 bagira:~/python-svn/patches> ../python/trunk/python -m
pdb simple

 (Pdb) b f(                   #crashes your program
 Traceback (most recent call last):
 ...
  File "/home/ilya/python-svn/python/trunk/Lib/sre.py",  
  line 233, in _compile
    raise error, v # invalid expression
 error: unbalanced parenthesis
 Uncaught exception. Entering post mortem debugging

 (Pdb) b f(   # doing it post-mortem fully crashes pdb
 Traceback (most recent call last):
 ..
    raise error, v # invalid expression
 sre_constants.error: unbalanced parenthesis

 bagira:~/python-svn/patches>


----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-27 08:38

Message:
Logged In: YES 
user_id=11375

Easily fixed by adding a re.escape() call, but this means
that 'b f()', if you've been doing that, will no longer work
to set a breakpoint.  The documentation doesn't claim that
'b f()' should work, but people may be used to typing this.

I've asked the 2.5 release manager about this issue.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1526834&group_id=5470

From noreply at sourceforge.net  Thu Jul 27 14:55:17 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 27 Jul 2006 05:55:17 -0700
Subject: [ python-Bugs-1529655 ] BROWSER path with capital letters
Message-ID: <E1G65OX-0004UM-7j@sc8-sf-web1.sourceforge.net>

Bugs item #1529655, was opened at 2006-07-28 00: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=1529655&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ken McGaugh (kenmcgaugh)
Assigned to: Nobody/Anonymous (nobody)
Summary: BROWSER path with capital letters

Initial Comment:
If you set the BROWSER environment variable to a path
that has capital letters in it, the webbrowser module
will not work.  This is python 2.4.1 under Fedora Core 4
linux.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529655&group_id=5470

From noreply at sourceforge.net  Thu Jul 27 00:20:57 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 26 Jul 2006 15:20:57 -0700
Subject: [ python-Bugs-1527974 ] tarfile chokes on ipython archive on Windows
Message-ID: <E1G5rkP-0004Nn-Rc@sc8-sf-web2.sourceforge.net>

Bugs item #1527974, was opened at 2006-07-24 23:00
Message generated for change (Comment added) made by arve_knudsen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1527974&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Arve Knudsen (arve_knudsen)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile chokes on ipython archive on Windows

Initial Comment:
I'm trying to extract files from the latest ipython tar
archive, available from
http://ipython.scipy.org/dist/ipython-0.7.2.tar.gz,
using tarfile. This is on Windows XP, using Python
2.4.3. There is only a problem if I open the archive in
stream mode (the "mode" argument to tarfile.open is
"r|gz"), in which case tarfile raises StreamError. I'd
be happy if this error could be sorted out.

The following script should trigger the error:

import tarfile

f = file(r"ipython-0.7.2.tar.gz", "rb")
tar = tarfile.open(fileobj=f, mode="r|gz")
try:
    for m in tar:
        tar.extract(m)
finally:
    tar.close()
    f.close(

The resulting exception:
Traceback (most recent call last):
  File "tst.py", line 7, in ?
    tar.extract(m)
  File "C:\Program Files\Python24\lib\tarfile.py", line
1335, in extract
    self._extract_member(tarinfo, os.path.join(path,
tarinfo.name))
  File "C:\Program Files\Python24\lib\tarfile.py", line
1431, in _extract_member

    self.makelink(tarinfo, targetpath)
  File "C:\Program Files\Python24\lib\tarfile.py", line
1515, in makelink
    self._extract_member(self.getmember(linkpath),
targetpath)
  File "C:\Program Files\Python24\lib\tarfile.py", line
1423, in _extract_member

    self.makefile(tarinfo, targetpath)
  File "C:\Program Files\Python24\lib\tarfile.py", line
1461, in makefile
    copyfileobj(source, target)
  File "C:\Program Files\Python24\lib\tarfile.py", line
158, in copyfileobj
    shutil.copyfileobj(src, dst)
  File "C:\Program Files\Python24\lib\shutil.py", line
22, in copyfileobj
    buf = fsrc.read(length)
  File "C:\Program Files\Python24\lib\tarfile.py", line
551, in _readnormal
    self.fileobj.seek(self.offset + self.pos)
  File "C:\Program Files\Python24\lib\tarfile.py", line
420, in seek
    raise StreamError, "seeking backwards is not allowed"
tarfile.StreamError: seeking backwards is not allowed

----------------------------------------------------------------------

>Comment By: Arve Knudsen (arve_knudsen)
Date: 2006-07-27 00:20

Message:
Logged In: YES 
user_id=1522083

Regarding my last comment, sorry about the noise. After 
giving it some more thought I realized it was not very 
realistic implementation wise, seeing as you can't know 
whether a file is being linked to when you encounter it in 
the stream (right?).

So I followed your suggestion instead and handled the links 
on the client level. What I think I'd like to see in 
TarFile though is an 'extractall' method with the ability 
to report progress to an optional callback, since I'm only 
opening in stream mode as a hack to implement this myself 
(by monitoring file position). From browsing tarfile's 
source it seems it might require some effort though (with 
e.g. BZ2File you can't know the amount of data without 
decompressing everything?).

----------------------------------------------------------------------

Comment By: Arve Knudsen (arve_knudsen)
Date: 2006-07-25 11:58

Message:
Logged In: YES 
user_id=1522083

Yes I admit that is a weakness to my proposed approach.
Perhaps it would be a better idea to extract hardlinked
files to a temporary location and copy those files when
needed, as a cache? The only problem that I can think of
with this approach is the overhead, but perhaps this could
be configurable through a keyword if you think it would pose
a significant problem (i.e. keeping extra copies of
potentially huge files)?

The temporary cache would be private to tarfile, so there
should be no need to worry about modifications to the
contained files.

----------------------------------------------------------------------

Comment By: Lars Gust?bel (gustaebel)
Date: 2006-07-25 11:31

Message:
Logged In: YES 
user_id=642936

Copying the previously extracted file is no option. When the
archive is extracted inside a loop, you never know what
happens between two extract() calls. The original file could
have been renamed, changed or removed. Suppose you want to
extract just those members which are hard links:

for tarinfo in tar:
    if tarinfo.islnk():
        tar.extract(tarinfo)

I agree with you that the error message is bad because it
does not give the slightest idea of what's going wrong. I'll
see what I can do about that.

To work around your particular problem, my idea is to
subclass the TarFile class and replace the makelink() method
with one that simply copies the file as you proposed.

----------------------------------------------------------------------

Comment By: Arve Knudsen (arve_knudsen)
Date: 2006-07-25 10:59

Message:
Logged In: YES 
user_id=1522083

Thanks for the clarification, Lars. I'd prefer to continue
with my current approach however, since it allows me to
report progress as the tarfile is unpacked/decompressed.
Also, I don't think it would be satisfactory at all if
tarfile would just die with a mysterious error in such cases.

In order to resolve this, why must tarfile extract the file
again, can't it copy the already extracted file?

----------------------------------------------------------------------

Comment By: Lars Gust?bel (gustaebel)
Date: 2006-07-25 10:42

Message:
Logged In: YES 
user_id=642936

The traceback tells me that there is a hard link inside the
archive which means that a file in the archive is referenced
to twice. This hard link can be extracted only on platforms
that have an os.link() function. On Win32 they're not
supported by the file system, but tarfile works around this
by extracting the referenced file twice. In order to extract
the file the second time it is necessary that tarfile seeks
back in the input file to access the file's data again. But
"seeking backwards is not allowed" when a file is opened in
streaming mode ;-)
If you do not necessarily need streaming mode for your
application, better use "r:gz" or "r" and the problem will
be gone.

----------------------------------------------------------------------

Comment By: Arve Knudsen (arve_knudsen)
Date: 2006-07-25 10:04

Message:
Logged In: YES 
user_id=1522083

Ok, I've verified now that the problem persists with Python
2.4.4 (from the 2.4 branch in svn). The exact same thing
happens.

----------------------------------------------------------------------

Comment By: Arve Knudsen (arve_knudsen)
Date: 2006-07-25 09:29

Message:
Logged In: YES 
user_id=1522083

Well yeah, it appears to be Windows specific. I just tested
on Linux (Ubuntu), also with Python 2.4.3. I'll try 2.4.3+
on Windows to see if it makes any difference. Come to think
of it I think I experienced this problem in that past on
Linux, but then I solved it by repacking ipython. Also, if I
pack it myself on Windows using bsdtar it works fine.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-25 05:35

Message:
Logged In: YES 
user_id=33168

I tested this on Linux with both 2.5 and 2.4.3+ without
problems.  I believe there were some fixes in this area. 
Could you try testing with the 2.4.3+ current which will
become 2.4.4 (or 2.5b2)?  If this is still a problem, it
looks like it may be Windows specific.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1527974&group_id=5470

From noreply at sourceforge.net  Thu Jul 27 03:17:00 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 26 Jul 2006 18:17:00 -0700
Subject: [ python-Bugs-1521947 ] possible bug in mystrtol.c with recent gcc
Message-ID: <E1G5uUm-00032z-0o@sc8-sf-web2.sourceforge.net>

Bugs item #1521947, was opened at 2006-07-13 13:39
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521947&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Marien Zwart (marienz)
Assigned to: Nobody/Anonymous (nobody)
Summary: possible bug in mystrtol.c with recent gcc

Initial Comment:
python 2.5b2 compiled with gentoo's gcc 4.1.1 and -O2
fails test_unary_minus in test_compile.py. Some
investigating showed that the -ftree-vrp pass of that
gcc (implied by -O2) optimizes out the "result ==
-result" test on line 215 of PyOS_strtol, meaning
PyOS_strtol of the most negative long will incorrectly
overflow. 

Python deals with this in this case by constructing a
python long object instead of a python int object, so
at least in this case the problem is not serious. I
have no idea if there is a case where this is a "real"
problem.

At first I reported this as a gentoo compiler bug, but
got the reply that:

"""
I'm pretty sure it's broken. -LONG_MIN overflows when
LONG_MIN < -LONG_MAX, and in standard C as well as "GNU
C", behaviour after overflow on signed integer
operations is undefined.
"""

(see https://bugs.gentoo.org/show_bug.cgi?id=140133)

So now I'm reporting this here. There seems to be a
LONG_MIN constant in limits.h here that could checked
against instead, but I have absolutely no idea how
standard that is. Or this could be a compiler bug after
all, in which case I would appreciate information I Can
use to back that up :)

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-07-26 21:16

Message:
Logged In: YES 
user_id=31435

Made a non-heroic effort to repair this in rev 50855, but
have no platform on which it could make any difference (and
apparently no Python buildbot test platform cares either) .
 Would be nice if someone who has such a platform could
check against current Python trunk.

----------------------------------------------------------------------

Comment By: Nick Maclaren (nmm)
Date: 2006-07-17 05:20

Message:
Logged In: YES 
user_id=42444

Yes, this is a duplicate of 1521726.

The compiler people's answer is correct, and mystrtoul.c is
incorrect. LONG_MIN has been in C since C90, so should be
safe, but its value may not always be what you expect.

However, the code breakage is worse that just that test, and
there are the following 3 cases of undefined behaviour:

    1) Casting and unsigned long to long above LONG_MAX.
    2) That test.
    3) result = -result.

The fix should be to make result unsigned long, and check
the range BEFORE any conversion.  Nothing else is safe.

It is a matter of taste whether to include a fiddle for the
number that can be held only when negated - I wouldn't, and
would let that number be converted to a Python long, but
others might disagree.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-16 21:13

Message:
Logged In: YES 
user_id=33168

Is this a duplicate of 1521726?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521947&group_id=5470

From noreply at sourceforge.net  Thu Jul 27 05:21:49 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 26 Jul 2006 20:21:49 -0700
Subject: [ python-Bugs-1529269 ] Python 2.5b2 fails to build on Solaris 10
	(GCC Compiler)
Message-ID: <E1G5wRZ-0007KH-E7@sc8-sf-web2.sourceforge.net>

Bugs item #1529269, was opened at 2006-07-26 14:17
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529269&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido Ostkamp (ostkamp)
>Assigned to: Thomas Heller (theller)
Summary: Python 2.5b2 fails to build on Solaris 10 (GCC Compiler)

Initial Comment:
Hello,

as promised here is the second report because of
problems with building Python 2.5b2 on Solaris 10
(Sparc). I have been using the GCC this time.

These are the problems (for full logs please see
attachments):

building '_ctypes' extension
gcc -shared
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules
/_ctypes/_ctypes.o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/
Modules/_ctypes/callbacks.o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Pyth
on-2.5b2/Modules/_ctypes/callproc.o
build/temp.solaris-2.10-sun4us-2.5/home/ostk
amp/Python-2.5b2/Modules/_ctypes/stgdict.o
build/temp.solaris-2.10-sun4us-2.5/ho
me/ostkamp/Python-2.5b2/Modules/_ctypes/cfield.o
build/temp.solaris-2.10-sun4us-
2.5/home/ostkamp/Python-2.5b2/Modules/_ctypes/malloc_closure.o
build/temp.solari
s-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/prep_cif.
o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules/_ctypes/l
ibffi/src/sparc/ffi.o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5
b2/Modules/_ctypes/libffi/src/sparc/v8.o
build/temp.solaris-2.10-sun4us-2.5/home
/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v9.o
-o build/lib.solaris
-2.10-sun4us-2.5/_ctypes.so
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol <unknow
n>: offset 0xfeedcca5 is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol <unknow
n>: offset 0xfeedccab is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol <unknow
n>: offset 0xfeedccaf is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol <unknow
n>: offset 0xfeedccb3 is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol <unknow
n>: offset 0xfeeeae06 is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol <unknow
n>: offset 0xfeeecaf6 is non-aligned
collect2: ld returned 1 exit status

building '_curses' extension
gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -I. -I/
home/ostkamp/Python-2.5b2/./Include -I./Include -I.
-I/home/ostkamp/Python-2.5b2
/Include -I/home/ostkamp/Python-2.5b2 -c
/home/ostkamp/Python-2.5b2/Modules/_cur
sesmodule.c -o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modu
les/_cursesmodule.o
/home/ostkamp/Python-2.5b2/Modules/_cursesmodule.c: In
function `PyCursesWindow_
GetStr':
/home/ostkamp/Python-2.5b2/Modules/_cursesmodule.c:822:
warning: implicit declar
ation of function `mvwgetnstr'
gcc -shared
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules
/_cursesmodule.o -lcurses -ltermcap -o
build/lib.solaris-2.10-sun4us-2.5/_curses
.so
*** WARNING: renaming "_curses" since importing it
failed: ld.so.1: python: fata
l: relocation error: file
build/lib.solaris-2.10-sun4us-2.5/_curses.so: symbol m
vwgetnstr: referenced symbol not found
building '_curses_panel' extension
gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -I. -I/
home/ostkamp/Python-2.5b2/./Include -I./Include -I.
-I/home/ostkamp/Python-2.5b2
/Include -I/home/ostkamp/Python-2.5b2 -c
/home/ostkamp/Python-2.5b2/Modules/_cur
ses_panel.c -o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modu
les/_curses_panel.o
gcc -shared
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules
/_curses_panel.o -lpanel -lcurses -ltermcap -o
build/lib.solaris-2.10-sun4us-2.5
/_curses_panel.so
*** WARNING: renaming "_curses_panel" since importing
it failed: No module named
 _curses
running build_scripts

Regards,

Guido

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-26 20:21

Message:
Logged In: YES 
user_id=33168

Thomas can you check out the ctypes problems?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529269&group_id=5470

From noreply at sourceforge.net  Thu Jul 27 04:01:49 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 26 Jul 2006 19:01:49 -0700
Subject: [ python-Bugs-1513611 ] xml.sax.ParseException weirdness in python
	2.5b1
Message-ID: <E1G5vC9-0005YP-I1@sc8-sf-web2.sourceforge.net>

Bugs item #1513611, was opened at 2006-06-27 17:06
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513611&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: XML
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Marien Zwart (marienz)
Assigned to: Nobody/Anonymous (nobody)
Summary: xml.sax.ParseException weirdness in python 2.5b1

Initial Comment:
There is something weird going on with xml.sax
exceptions, probably related to the xml/xmlcore shuffle:

from xml.sax import make_parser, SAXParseException
from StringIO import StringIO

parser = make_parser()

try:
    parser.parse(StringIO('invalid'))
except SAXParseException:
    print 'caught it!'

On python 2.4.3 this prints "caught it!". On python
2.5b1 the exception is not caught, because it is a
different  exception: an
xmlcore.sax._exceptions.SAXParseException. Printing the
SAXParseException imported from xml.sax gives "<class
'xml.sax._exceptions.SAXParseException'>".

Stumbled on this running the logilab-common (see
logilab.org) tests with python 2.5b1, but it seems
likely other code will be affected.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-26 22:01

Message:
Logged In: YES 
user_id=3066

Patch #1519796 does not do anything for this, based on the
current trunk.  I've attached a diff containing a test case.

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-07-10 03:37

Message:
Logged In: YES 
user_id=1326842

This bug is simmilar to http://python.org/sf/1511497.
It is caused by absolute imports in xmlcore.sax.expatreader.
Patch #1519796 ( http://python.org/sf/1519796 )
should fix it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513611&group_id=5470

From noreply at sourceforge.net  Thu Jul 27 04:33:52 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 26 Jul 2006 19:33:52 -0700
Subject: [ python-Bugs-1069433 ] Python 2.4c1 test_univnewlines.py fails
	within IDLE IDE
Message-ID: <E1G5vhA-0000xW-GJ@sc8-sf-web2.sourceforge.net>

Bugs item #1069433, was opened at 2004-11-19 09:33
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1069433&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.4
>Status: Closed
>Resolution: Invalid
>Priority: 4
Submitted By: PieterB (pieterb)
Assigned to: Kurt B. Kaiser (kbk)
Summary: Python 2.4c1 test_univnewlines.py fails within IDLE IDE

Initial Comment:
On my WinXP SP 1 system with Python2.4c1.msi installed
the testcase test_univnewlines.py fails:

Traceback (most recent call last):
  File "C:\Python24\Lib\test\test_univnewlines.py",
line 8, in -toplevel-
    raise test_support.TestSkipped, \
TestSkipped: This Python does not have universal
newline support

I assume Python on WinXP should have universal newline
support. This also causes 
test_subprocess.py to fail at line 334.

Furthermore my test_descr also fails, but I don't know
if it's related:

...
Testing methods...
Testing special operators...

Traceback (most recent call last):
  File "C:\Python24\Lib\test\test_descr.py", line 4065,
in -toplevel-
    test_main()
  File "C:\Python24\Lib\test\test_descr.py", line 4008,
in test_main
    specials()
  File "C:\Python24\Lib\test\test_descr.py", line 1875,
in specials
    print Letter('w')
PicklingError: Can't pickle <class '__main__.Letter'>:
attribute lookup __main__.Letter failed

----------------------------------------------------------------------

>Comment By: Kurt B. Kaiser (kbk)
Date: 2006-07-26 22:33

Message:
Logged In: YES 
user_id=149084

I don't expect IDLE to be able to pass all the
Python tests.  It does pretty well, considering it's
really two instances of Python communicating with
each other.

test_descr:  there is a special test which fails
which causes IDLE to try to pickle an embedded class,
which is illegal, to communicate with its GUI.

The test_subprocess passes on 2.5.

The universal newline support isn't included in IDLE
because as an editor, IDLE preserves the line endings
in the original file.  Any edits are done using the
'native' line endings for that file.  This allows IDLE
files on disc to be moved between different platforms.

If any failing tests are identified in the future which
affect IDLE's functionality or the correct execution of
'real' Python code, please post a bug on the tracker.

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-11-23 04:07

Message:
Logged In: YES 
user_id=1038590

Ah, that makes a big difference - running through IDLE I get
the same three errors (failures in test_descr and
test_subprocess, skip on test_univnewlines).

I'd be inclined to keep the bug, but change the category to
IDLE and assign it to Kurt (SF user 'kbk'). IDLE's his baby
so he can make the call as to whether this is a bug, or
unfortunate but expected behaviour.


----------------------------------------------------------------------

Comment By: PieterB (pieterb)
Date: 2004-11-22 17:13

Message:
Logged In: YES 
user_id=458461

I ran the tests through the IDLE IDE. All tests succeed when
I run regrtest.py from a command prompt or from with Cygwin
1.5.11. (240 tests OK, 50 tests skipped as expected) 

I don't know if running the tests and/or using universal
newlines support within IDLE is/will be supported. Please
close this bug if it's inappropriate.

For more information 
Python is not in the PATH and
TIX_LIBRARY=C:\Python24\tcl\tix8.1 and
TK_LIBRARY=C:\Python24\tcl\tk8.4

>From Python shell within IDLE:

>>> import sys
>>> dir(sys.stdin)
['_RPCProxy__attributes', '_RPCProxy__getattributes',
'_RPCProxy__getmethods', '_RPCProxy__methods', '__doc__',
'__getattr__', '__init__', '__module__', 'encoding', 'oid',
'sockio']
>>> print sys.stdin
<idlelib.rpc.RPCProxy instance at 0x00B20508>

>From a Python shell run from a command prompt:

>>> import sys
>>> dir(sys.stdin)
['__class__', '__delattr__', '__doc__', '__getattribute__',
'__hash__', '__init__', '__iter__', '__new__', '__reduce__',
'__reduce_ex__', '__repr__', '__setattr__', '__str__',
'close', 'closed', 'encoding', 'fileno', 'flush', 'isatty',
'mode', 'name', 'newlines', 'next', 'read', 'readinto',
'readline', 'readlines', 'seek', 'softspace', 'tell',
'truncate', 'write', 'writelines', 'xreadlines']
>>> print sys.stdin
<open file '<stdin>', mode 'r' at 0x0095E020>

PS: I changed the summary because this problem is IDLE specific.

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-11-22 08:51

Message:
Logged In: YES 
user_id=1038590

The three tests mentioned (test_univnewlines,
test_subprocess & test_descr) also all work correctly for me
when invoked directly, rather than through regrtest.py.


----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-11-22 07:19

Message:
Logged In: YES 
user_id=1038590

Win XP Pro, SP 1 here: 240 tests OK, 50 tests skipped (all
expected skips)

The OP needs to check their path settings and their file
associations. If 2.4c1 is installed without registering the
extensions, then the regression tests should be run using:

c:
cd \Python24\Lib\test
\Python24\python.exe regrtest.py

If the .py file association is to a previous version (e.g.
2.2), then "regrtest.py" will invoke that version.

Similarly, if a previous version is on the path, "python
regrtest.py" will also invoke the incorrect version.

----------------------------------------------------------------------

Comment By: Scott David Daniels (scott_daniels)
Date: 2004-11-19 20:01

Message:
Logged In: YES 
user_id=493818

Not replicated on Win2K Service Pack 4.
All named tests pass here.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1069433&group_id=5470

From noreply at sourceforge.net  Thu Jul 27 06:48:18 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 26 Jul 2006 21:48:18 -0700
Subject: [ python-Bugs-1521947 ] possible bug in mystrtol.c with recent gcc
Message-ID: <E1G5xnG-0007CE-3F@sc8-sf-web2.sourceforge.net>

Bugs item #1521947, was opened at 2006-07-13 10:39
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521947&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
>Group: Python 2.4
>Status: Open
>Resolution: None
Priority: 5
Submitted By: Marien Zwart (marienz)
Assigned to: Nobody/Anonymous (nobody)
Summary: possible bug in mystrtol.c with recent gcc

Initial Comment:
python 2.5b2 compiled with gentoo's gcc 4.1.1 and -O2
fails test_unary_minus in test_compile.py. Some
investigating showed that the -ftree-vrp pass of that
gcc (implied by -O2) optimizes out the "result ==
-result" test on line 215 of PyOS_strtol, meaning
PyOS_strtol of the most negative long will incorrectly
overflow. 

Python deals with this in this case by constructing a
python long object instead of a python int object, so
at least in this case the problem is not serious. I
have no idea if there is a case where this is a "real"
problem.

At first I reported this as a gentoo compiler bug, but
got the reply that:

"""
I'm pretty sure it's broken. -LONG_MIN overflows when
LONG_MIN < -LONG_MAX, and in standard C as well as "GNU
C", behaviour after overflow on signed integer
operations is undefined.
"""

(see https://bugs.gentoo.org/show_bug.cgi?id=140133)

So now I'm reporting this here. There seems to be a
LONG_MIN constant in limits.h here that could checked
against instead, but I have absolutely no idea how
standard that is. Or this could be a compiler bug after
all, in which case I would appreciate information I Can
use to back that up :)

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-26 21:48

Message:
Logged In: YES 
user_id=33168

I reopened this bug as it still affects 2.4.  Tim's fix
should be backported.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-26 21:35

Message:
Logged In: YES 
user_id=33168

Tim's fix corrected the problem on amd64 gentoo linux with
gcc 4.1.1.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-26 18:16

Message:
Logged In: YES 
user_id=31435

Made a non-heroic effort to repair this in rev 50855, but
have no platform on which it could make any difference (and
apparently no Python buildbot test platform cares either) .
 Would be nice if someone who has such a platform could
check against current Python trunk.

----------------------------------------------------------------------

Comment By: Nick Maclaren (nmm)
Date: 2006-07-17 02:20

Message:
Logged In: YES 
user_id=42444

Yes, this is a duplicate of 1521726.

The compiler people's answer is correct, and mystrtoul.c is
incorrect. LONG_MIN has been in C since C90, so should be
safe, but its value may not always be what you expect.

However, the code breakage is worse that just that test, and
there are the following 3 cases of undefined behaviour:

    1) Casting and unsigned long to long above LONG_MAX.
    2) That test.
    3) result = -result.

The fix should be to make result unsigned long, and check
the range BEFORE any conversion.  Nothing else is safe.

It is a matter of taste whether to include a fiddle for the
number that can be held only when negated - I wouldn't, and
would let that number be converted to a Python long, but
others might disagree.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-16 18:13

Message:
Logged In: YES 
user_id=33168

Is this a duplicate of 1521726?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521947&group_id=5470

From noreply at sourceforge.net  Thu Jul 27 05:20:06 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 26 Jul 2006 20:20:06 -0700
Subject: [ python-Bugs-1528620 ] Python 2.5b2 fails to build on Solaris 10
	(Sun Compiler)
Message-ID: <E1G5wPu-000682-U4@sc8-sf-web2.sourceforge.net>

Bugs item #1528620, was opened at 2006-07-25 13:34
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528620&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido Ostkamp (ostkamp)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.5b2 fails to build on Solaris 10 (Sun Compiler)

Initial Comment:
Hello,

I tried to build Python 2.5b2 on Solaris 10 with the
Sun Workshop Compiler, which fails.

Please see the attachment for a complete log in several
stages. Here is a short summary:

*
build/temp.solaris-2.10-sun4us-2.5/libffi/include/ffi.h
contains illegal C-syntax __attribute(...)

This might be legal for GCC, but not for other compilers. 

* Even if this is removed, there are other fatal
compiler errors in the _ctypes module later on.

* The build process seems to invoke _cursesmodule.c.
This contains the use of a function  mvwgetnstr(). This
function does not exist in /usr/lib/libcurses.so.

* The build process fails to link with libcurses.so.

The Python 2.4.3 release fails for the same reasons
regarding the curses problems, but the _ctypes stuff
did not exist in this form. 

I would appreciate, if these bugs could be fixed.

Regards,

Guido

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-26 20:20

Message:
Logged In: YES 
user_id=33168

Andrew Kuchling just checked in the change to fix the
problem.  The only way you would be able to verify it is if
you checkout from SVN head for 2.5 or release24-main for 2.4.

The only module that should depend on libffi is ctypes.  If
struct doesn't compile that is a different problem.

----------------------------------------------------------------------

Comment By: Guido Ostkamp (ostkamp)
Date: 2006-07-26 13:52

Message:
Logged In: YES 
user_id=1028306

Hello,

@nnorwitz:

Unfortunately I cannot provide a patch, but can give some hints:

If you (or the developers) have a Solaris 10 box, they can
download the Sun Studio 11 which includes the Sun Compiler
for free from the URL:
<http://developers.sun.com/prodtech/cc/downloads/index.jsp>

Then you should be able to verify the problems yourself
(though I am using an older version of the compiler from the
times when it was commercial).

Regarding the _ctypes module problems:

The module contains a libffi which nowadays appears to be
part of the GNU GCC. This lib was never made to work with
anything else but GCC, as it seems. Even older versions do
not compile.

Therefore, if this module is not really necessary, it should
be removed or at least deactivated by the configuration if
not using GCC. It also seems, that other modules like
_struct appear to be depending on this, if I'm right.

Regarding the curses problem:

I can workaround this if changing the mvwgetnstr() to
mvwgetstr() with omitting the last parameter. However this
should be configured automatically.

Futhermore there was no linking of the correct library
(/usr/lib/libcurses.so). I had to activate the curses entry
in Modules/Setup manually and to call make two more times. 

Regarding GCC on Solaris: I tried with GCC but it failed on
Solaris 10 as well. I will open a new fault report for the
GCC problems.

@akuchling:

You say the curses bug should be fixed in 2.4 and 2.5. It
isn't. I tried 2.4.3 yesterday as well and ran into the very
same problem. Or do you mean it was changed more recently?



----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-26 10:28

Message:
Logged In: YES 
user_id=11375

The _cursesmodule mvwgetnstr() problem was reported as bug
#1471938 and should now be fixed on both the 2.4 and 2.5
branches.



----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-25 21:11

Message:
Logged In: YES 
user_id=33168

Can you provide a patch to address these problems?

I don't know that any developers have access to the sun
workshop compiler.  We have a Solaris 10 box, but it only
has gcc AFAIK.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528620&group_id=5470

From noreply at sourceforge.net  Thu Jul 27 06:40:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 26 Jul 2006 21:40:05 -0700
Subject: [ python-Bugs-1511497 ] xml.sax.expatreader is missing
Message-ID: <E1G5xfJ-00023r-3o@sc8-sf-web3.sourceforge.net>

Bugs item #1511497, was opened at 2006-06-23 11:14
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1511497&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: XML
Group: Python 2.5
Status: Open
Resolution: None
>Priority: 9
Submitted By: Wummel (calvin)
Assigned to: Nobody/Anonymous (nobody)
Summary: xml.sax.expatreader is missing

Initial Comment:
Hi,

when testing the new Python 2.5 subversion tree I
encountered this behaviour:
$ python2.5
Python 2.5b1 (trunk:47065, Jun 22 2006, 20:56:23) 
[GCC 4.1.2 20060613 (prerelease) (Debian 4.1.1-5)] on
linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import xml.sax.expatreader
>>> print xml.sax.expatreader
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute
'expatreader'
>>> 

So the import went ok, but using the attribute gave an
error. This is very strange. Python 2.4 did not have
this behaviour.

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-07-10 00:38

Message:
Logged In: YES 
user_id=1326842

See patch #1519796:
http://python.org/sf/1519796

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-06-26 15:52

Message:
Logged In: YES 
user_id=1326842

I see the same behaviour with the official Python 2.5
beta 1 Windows installer. The interesting thing is that
the expatreader module is present in sys.modules:

Python 2.5b1 (r25b1:47027, Jun 20 2006, 09:31:33)
[MSC v.1310 32 bit (Intel)] on win32
...
>>> import xml.sax.expatreader
>>> xml.sax.expatreader
Traceback (most recent call last):
  ...
AttributeError: 'module' object has no attribute 'expatreader'
>>> import sys
>>> sys.modules['xml.sax.expatreader']
<module 'xml.sax.expatreader' from
'...\lib\xmlcore\sax\expatreader.pyc'>

All of the other modules in xml package can be imported
without any trouble.
I don't understand what is the real problem here,
but it goes away if you import xmlcore.sax package
before expatreader:

[restart python]
>>> import xmlcore.sax
>>> import xml.sax.expatreader
>>> xml.sax.expatreader
<module 'xml.sax.expatreader' from
'...\lib\xmlcore\sax\expatreader.pyc'>

The simplest fix would be to use at least one absolute
import in ...\lib\xmlcore\sax\__init__.py, for example
you could change line 22:

from xmlreader import InputSource

to:

from xmlcore.sax.xmlreader import InputSource

but that might just hide the real bug.

----------------------------------------------------------------------

Comment By: Wummel (calvin)
Date: 2006-06-26 11:15

Message:
Logged In: YES 
user_id=9205

I built Python directly from the SVN trunk repository with
$ ./configure && make altinstall
I attached the pyconfig.h that was generated. If you need
more info, feel free to ask.

After building and installing, I started up python2.5 and
executed "import xml.sax.expatreader" and then "print
xml.sax.expatreader", and nothing else.

Another thing I tried is "import from", which works.
But importing xml.sax.expatreader directly, as noted above,
does not work.

Here is the log with the "import from" test:
Python 2.5b1 (trunk:47090, Jun 25 2006, 09:59:02) 
[GCC 4.1.2 20060613 (prerelease) (Debian 4.1.1-5)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> from xml.sax import expatreader
>>> print expatreader
<module 'xml.sax.expatreader' from
'/usr/local/lib/python2.5/xmlcore/sax/expatreader.pyc'>
>>> print xml.sax.expatreader
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'expatreader'


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-06-24 03:39

Message:
Logged In: YES 
user_id=21627

How precisely did you test it? What configure options did
you set up, what commands did you provide to build Python?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1511497&group_id=5470

From noreply at sourceforge.net  Thu Jul 27 16:11:35 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 27 Jul 2006 07:11:35 -0700
Subject: [ python-Bugs-1529717 ] doc string of read-only properties
Message-ID: <E1G66aN-00019s-1k@sc8-sf-web6.sourceforge.net>

Bugs item #1529717, was opened at 2006-07-27 16: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=1529717&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Amrhein (mamrhein)
Assigned to: Nobody/Anonymous (nobody)
Summary: doc string of read-only properties

Initial Comment:
It would be nice if read-only properties (only fget
defined) that have no doc string assigned would
automatically show the doc string of the fget function.
This would allow to write code like
@property
def prop(self):
    """Property prop"""
    ...
while making the doc string visible at the property level.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529717&group_id=5470

From noreply at sourceforge.net  Thu Jul 27 17:03:04 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 27 Jul 2006 08:03:04 -0700
Subject: [ python-Bugs-1529717 ] doc string of read-only properties
Message-ID: <E1G67OC-0001Pc-EE@sc8-sf-web3.sourceforge.net>

Bugs item #1529717, was opened at 2006-07-27 14:11
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529717&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Feature Request
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Michael Amrhein (mamrhein)
Assigned to: Nobody/Anonymous (nobody)
Summary: doc string of read-only properties

Initial Comment:
It would be nice if read-only properties (only fget
defined) that have no doc string assigned would
automatically show the doc string of the fget function.
This would allow to write code like
@property
def prop(self):
    """Property prop"""
    ...
while making the doc string visible at the property level.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-27 15:03

Message:
Logged In: YES 
user_id=849994

This is already in 2.5.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529717&group_id=5470

From noreply at sourceforge.net  Thu Jul 27 17:07:09 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 27 Jul 2006 08:07:09 -0700
Subject: [ python-Bugs-1529655 ] BROWSER path with capital letters
Message-ID: <E1G67S9-0002nx-Gd@sc8-sf-web3.sourceforge.net>

Bugs item #1529655, was opened at 2006-07-27 12:55
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529655&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
>Status: Pending
>Resolution: Fixed
Priority: 5
Submitted By: Ken McGaugh (kenmcgaugh)
Assigned to: Nobody/Anonymous (nobody)
Summary: BROWSER path with capital letters

Initial Comment:
If you set the BROWSER environment variable to a path
that has capital letters in it, the webbrowser module
will not work.  This is python 2.4.1 under Fedora Core 4
linux.


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-27 15:07

Message:
Logged In: YES 
user_id=849994

webbrowser was almost completely rewritten in 2.5. I guess
that problem will go away then.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529655&group_id=5470

From noreply at sourceforge.net  Thu Jul 27 17:22:36 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 27 Jul 2006 08:22:36 -0700
Subject: [ python-Bugs-1529297 ] unrelated variable messing up doctests
Message-ID: <E1G67h6-0000w0-LS@sc8-sf-web6.sourceforge.net>

Bugs item #1529297, was opened at 2006-07-26 15:02
Message generated for change (Comment added) made by macquigg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529297&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: David MacQuigg (macquigg)
Assigned to: Nobody/Anonymous (nobody)
Summary: unrelated variable messing up doctests

Initial Comment:
Version 2.5b2 with IDLE 1.2b2 running on Windows XP 
Home, fully updated.

Unpack the attached zip file.
Open program.py, test_suite.py, in separate IDLE 
windows.  
Run test_suite.py.  
  8 passed and 0 failed.
Now add a variable at the top of program.py, any name 
will do.
  xyz = 2
Re-run test_suite.py.  
  7 passed and 1 failed !!

I haven't been able to isolate the problem, but it is 
repeatable.  Taking out blocks of unrelated statements 
changes the behavior.  Feels like a memory allocation 
error, or something strange.


----------------------------------------------------------------------

>Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 08:22

Message:
Logged In: YES 
user_id=676422

On my Redhat Linux machine, I see the failure in 2.4.1, but 
not in 2.3.4.

Trying to isolate the problem, I've commented out some 
blocks of unrelated code, but I can't get very far with 
this, because many of the deletions make the problem go 
away.  It's as if the problem depends on the exact position 
in memory of the test variable.

I did manage to delete the DNS queries, so now you can run 
the tests without intermittent failures due to DNS timeouts.
I'll keep the latest at http://www.open-
mail.org/test/test_0607nn.tgz

Thanks for your efforts.


----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-27 05:15

Message:
Logged In: YES 
user_id=11375

On a Linux machine, both 2.4.3 and SVN HEAD report 7 tests
passed, one failed.

For both versions, the failure is: 
Failed example:
    _envrcpt('zz1 at open-mail.org')
Expected:
    CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 101, '']]
Got:
    CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 50, '']]


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-26 20:59

Message:
Logged In: YES 
user_id=33168

Can you try with SVN head?  There was an unitialized read
that the doctests could trigger.  It has been fixed. 
Perhaps you are running into that?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529297&group_id=5470

From noreply at sourceforge.net  Thu Jul 27 18:14:38 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 27 Jul 2006 09:14:38 -0700
Subject: [ python-Bugs-1529297 ] unrelated variable messing up doctests
Message-ID: <E1G68VS-0007Hx-1N@sc8-sf-web2.sourceforge.net>

Bugs item #1529297, was opened at 2006-07-26 18: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=1529297&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: David MacQuigg (macquigg)
Assigned to: Nobody/Anonymous (nobody)
Summary: unrelated variable messing up doctests

Initial Comment:
Version 2.5b2 with IDLE 1.2b2 running on Windows XP 
Home, fully updated.

Unpack the attached zip file.
Open program.py, test_suite.py, in separate IDLE 
windows.  
Run test_suite.py.  
  8 passed and 0 failed.
Now add a variable at the top of program.py, any name 
will do.
  xyz = 2
Re-run test_suite.py.  
  7 passed and 1 failed !!

I haven't been able to isolate the problem, but it is 
repeatable.  Taking out blocks of unrelated statements 
changes the behavior.  Feels like a memory allocation 
error, or something strange.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-07-27 12:14

Message:
Logged In: YES 
user_id=31435

I see exactly the same failure akuchling reported, on
Windows using current trunk, running from a command shell
(not IDLE -- didn't try IDLE).  The attached test_suite.py
throws away everything not needed to see the same failure;
in particular, it gets rid of doctest, the logging module,
and most of the functions in test_suite.py.

Reduced to this, I don't see a reason to suspect a Python
bug.  ci.IDrating is initialized to 100, and the

_envrcpt('zz1 at open-mail.org')

line produces (the expected)

CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 101, '']]

if you /leave ci.IDrating alone/.  However, if you do

ci.hello('zz_IP_192.168.0.8_mailout7.simple.tld')

first, that has a (apparently deliberate) side effect of
changing ci.IDrating to None, and then this path is /not/ taken:

# . . Whitelist pass
    if self.IDrating > whitelvl:
        rcptinfo[4] = 101  # ham > 100% to ignore later
spamscore       ###2e
        self.R.append(rcptinfo)

The 101 vanishes from the expected output then, and I get

CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 50, '']]

instead.

That exactly reproduces the only failure Andrew & I have
seen, and appears to be what the code is telling it to do
(via side effects on the shared `ci` instance).

----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 11:22

Message:
Logged In: YES 
user_id=676422

On my Redhat Linux machine, I see the failure in 2.4.1, but 
not in 2.3.4.

Trying to isolate the problem, I've commented out some 
blocks of unrelated code, but I can't get very far with 
this, because many of the deletions make the problem go 
away.  It's as if the problem depends on the exact position 
in memory of the test variable.

I did manage to delete the DNS queries, so now you can run 
the tests without intermittent failures due to DNS timeouts.
I'll keep the latest at http://www.open-
mail.org/test/test_0607nn.tgz

Thanks for your efforts.


----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-27 08:15

Message:
Logged In: YES 
user_id=11375

On a Linux machine, both 2.4.3 and SVN HEAD report 7 tests
passed, one failed.

For both versions, the failure is: 
Failed example:
    _envrcpt('zz1 at open-mail.org')
Expected:
    CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 101, '']]
Got:
    CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 50, '']]


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-26 23:59

Message:
Logged In: YES 
user_id=33168

Can you try with SVN head?  There was an unitialized read
that the doctests could trigger.  It has been fixed. 
Perhaps you are running into that?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529297&group_id=5470

From noreply at sourceforge.net  Thu Jul 27 19:23:49 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 27 Jul 2006 10:23:49 -0700
Subject: [ python-Bugs-1529269 ] Python 2.5b2 fails to build on Solaris 10
	(GCC Compiler)
Message-ID: <E1G69aP-0008Ry-6D@sc8-sf-web5.sourceforge.net>

Bugs item #1529269, was opened at 2006-07-26 23:17
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529269&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido Ostkamp (ostkamp)
Assigned to: Thomas Heller (theller)
Summary: Python 2.5b2 fails to build on Solaris 10 (GCC Compiler)

Initial Comment:
Hello,

as promised here is the second report because of
problems with building Python 2.5b2 on Solaris 10
(Sparc). I have been using the GCC this time.

These are the problems (for full logs please see
attachments):

building '_ctypes' extension
gcc -shared
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules
/_ctypes/_ctypes.o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/
Modules/_ctypes/callbacks.o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Pyth
on-2.5b2/Modules/_ctypes/callproc.o
build/temp.solaris-2.10-sun4us-2.5/home/ostk
amp/Python-2.5b2/Modules/_ctypes/stgdict.o
build/temp.solaris-2.10-sun4us-2.5/ho
me/ostkamp/Python-2.5b2/Modules/_ctypes/cfield.o
build/temp.solaris-2.10-sun4us-
2.5/home/ostkamp/Python-2.5b2/Modules/_ctypes/malloc_closure.o
build/temp.solari
s-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/prep_cif.
o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules/_ctypes/l
ibffi/src/sparc/ffi.o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5
b2/Modules/_ctypes/libffi/src/sparc/v8.o
build/temp.solaris-2.10-sun4us-2.5/home
/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v9.o
-o build/lib.solaris
-2.10-sun4us-2.5/_ctypes.so
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol <unknow
n>: offset 0xfeedcca5 is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol <unknow
n>: offset 0xfeedccab is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol <unknow
n>: offset 0xfeedccaf is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol <unknow
n>: offset 0xfeedccb3 is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol <unknow
n>: offset 0xfeeeae06 is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol <unknow
n>: offset 0xfeeecaf6 is non-aligned
collect2: ld returned 1 exit status

building '_curses' extension
gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -I. -I/
home/ostkamp/Python-2.5b2/./Include -I./Include -I.
-I/home/ostkamp/Python-2.5b2
/Include -I/home/ostkamp/Python-2.5b2 -c
/home/ostkamp/Python-2.5b2/Modules/_cur
sesmodule.c -o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modu
les/_cursesmodule.o
/home/ostkamp/Python-2.5b2/Modules/_cursesmodule.c: In
function `PyCursesWindow_
GetStr':
/home/ostkamp/Python-2.5b2/Modules/_cursesmodule.c:822:
warning: implicit declar
ation of function `mvwgetnstr'
gcc -shared
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules
/_cursesmodule.o -lcurses -ltermcap -o
build/lib.solaris-2.10-sun4us-2.5/_curses
.so
*** WARNING: renaming "_curses" since importing it
failed: ld.so.1: python: fata
l: relocation error: file
build/lib.solaris-2.10-sun4us-2.5/_curses.so: symbol m
vwgetnstr: referenced symbol not found
building '_curses_panel' extension
gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -I. -I/
home/ostkamp/Python-2.5b2/./Include -I./Include -I.
-I/home/ostkamp/Python-2.5b2
/Include -I/home/ostkamp/Python-2.5b2 -c
/home/ostkamp/Python-2.5b2/Modules/_cur
ses_panel.c -o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modu
les/_curses_panel.o
gcc -shared
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules
/_curses_panel.o -lpanel -lcurses -ltermcap -o
build/lib.solaris-2.10-sun4us-2.5
/_curses_panel.so
*** WARNING: renaming "_curses_panel" since importing
it failed: No module named
 _curses
running build_scripts

Regards,

Guido

----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2006-07-27 19:23

Message:
Logged In: YES 
user_id=11105

I don't have access to a solaris 10 box myself (only the
sourceforge solaris 9 sparc machine).  I'm wondering why the
solaris 10 machine running the Python buildbot does not
report any problems, could it be that this is because it run
configure with '--with-pydebug' ?

Guido, can you please try this?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-27 05:21

Message:
Logged In: YES 
user_id=33168

Thomas can you check out the ctypes problems?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529269&group_id=5470

From noreply at sourceforge.net  Thu Jul 27 19:32:10 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 27 Jul 2006 10:32:10 -0700
Subject: [ python-Bugs-1529297 ] unrelated variable messing up doctests
Message-ID: <E1G69iU-00035m-Bl@sc8-sf-web2.sourceforge.net>

Bugs item #1529297, was opened at 2006-07-26 15:02
Message generated for change (Comment added) made by macquigg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529297&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: David MacQuigg (macquigg)
Assigned to: Nobody/Anonymous (nobody)
Summary: unrelated variable messing up doctests

Initial Comment:
Version 2.5b2 with IDLE 1.2b2 running on Windows XP 
Home, fully updated.

Unpack the attached zip file.
Open program.py, test_suite.py, in separate IDLE 
windows.  
Run test_suite.py.  
  8 passed and 0 failed.
Now add a variable at the top of program.py, any name 
will do.
  xyz = 2
Re-run test_suite.py.  
  7 passed and 1 failed !!

I haven't been able to isolate the problem, but it is 
repeatable.  Taking out blocks of unrelated statements 
changes the behavior.  Feels like a memory allocation 
error, or something strange.


----------------------------------------------------------------------

>Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 10:32

Message:
Logged In: YES 
user_id=676422

The failure is not the specific output of doctest, but the 
fact that it *changes* when I add an unrelated variable 
xyz=2 in the module program.py.  I am not able to reproduce 
this failure with Tim's stripped down test_suite.py.

I agree the problem is not in IDLE.  I can do the same from 
a bash command line with
$ python2.4 test_suite.py
but not with 
$ python2.3 test_suite.py


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 09:14

Message:
Logged In: YES 
user_id=31435

I see exactly the same failure akuchling reported, on
Windows using current trunk, running from a command shell
(not IDLE -- didn't try IDLE).  The attached test_suite.py
throws away everything not needed to see the same failure;
in particular, it gets rid of doctest, the logging module,
and most of the functions in test_suite.py.

Reduced to this, I don't see a reason to suspect a Python
bug.  ci.IDrating is initialized to 100, and the

_envrcpt('zz1 at open-mail.org')

line produces (the expected)

CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 101, '']]

if you /leave ci.IDrating alone/.  However, if you do

ci.hello('zz_IP_192.168.0.8_mailout7.simple.tld')

first, that has a (apparently deliberate) side effect of
changing ci.IDrating to None, and then this path is /not/ taken:

# . . Whitelist pass
    if self.IDrating > whitelvl:
        rcptinfo[4] = 101  # ham > 100% to ignore later
spamscore       ###2e
        self.R.append(rcptinfo)

The 101 vanishes from the expected output then, and I get

CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 50, '']]

instead.

That exactly reproduces the only failure Andrew & I have
seen, and appears to be what the code is telling it to do
(via side effects on the shared `ci` instance).

----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 08:22

Message:
Logged In: YES 
user_id=676422

On my Redhat Linux machine, I see the failure in 2.4.1, but 
not in 2.3.4.

Trying to isolate the problem, I've commented out some 
blocks of unrelated code, but I can't get very far with 
this, because many of the deletions make the problem go 
away.  It's as if the problem depends on the exact position 
in memory of the test variable.

I did manage to delete the DNS queries, so now you can run 
the tests without intermittent failures due to DNS timeouts.
I'll keep the latest at http://www.open-
mail.org/test/test_0607nn.tgz

Thanks for your efforts.


----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-27 05:15

Message:
Logged In: YES 
user_id=11375

On a Linux machine, both 2.4.3 and SVN HEAD report 7 tests
passed, one failed.

For both versions, the failure is: 
Failed example:
    _envrcpt('zz1 at open-mail.org')
Expected:
    CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 101, '']]
Got:
    CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 50, '']]


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-26 20:59

Message:
Logged In: YES 
user_id=33168

Can you try with SVN head?  There was an unitialized read
that the doctests could trigger.  It has been fixed. 
Perhaps you are running into that?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529297&group_id=5470

From noreply at sourceforge.net  Thu Jul 27 19:49:51 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 27 Jul 2006 10:49:51 -0700
Subject: [ python-Bugs-1529871 ] distutils regression related to
	Distribution.run_command
Message-ID: <E1G69zb-0001XS-9i@sc8-sf-web2.sourceforge.net>

Bugs item #1529871, was opened at 2006-07-27 13: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=1529871&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Collin Winter (collinwinter)
Assigned to: Nobody/Anonymous (nobody)
Summary: distutils regression related to Distribution.run_command

Initial Comment:
The following used to work in Python 2.4.x but fails
under Python 2.5:

>>> import setuptools
>>> import distutils.core
>>> distutils.core._setup_stop_after = 'config'
>>> 
>>> import setup
>>> setup.dist.run_command('test')

Where setup.dist is an instance of
distutils.core.Distribution (which setuptools replaces
with setuptools.dist.Distribution).

Under Python 2.4.x, this code would execute setuptools'
test command. Under Python 2.5b2 (as of r50855), this
code results in the following exception:

/opt/dev/python/2.5/lib/python2.5/distutils/dist.py:263:
UserWarning: Unknown distribution option: 'test_suite'
  warnings.warn(msg)
Traceback (most recent call last):
  File "test.py", line 8, in <module>
    setup.dist.run_command('test')
  File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 992, in run_command
    cmd_obj = self.get_command_obj(command)
  File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 868, in get_command_obj
    klass = self.get_command_class(command)
  File
"/opt/dev/python/2.5/lib/python2.5/site-packages/setuptools/dist.py",
line 357, in get_command_class
    return _Distribution.get_command_class(self, command)
  File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 851, in get_command_class
    raise DistutilsModuleError("invalid command '%s'" %
command)
distutils.errors.DistutilsModuleError: invalid command
'test'

I'd greatly appreciate it if this regression could be
fixed before Python 2.5 is released.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529871&group_id=5470

From noreply at sourceforge.net  Thu Jul 27 19:50:08 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 27 Jul 2006 10:50:08 -0700
Subject: [ python-Bugs-1529871 ] distutils regression related to
	Distribution.run_command
Message-ID: <E1G69zs-0001ds-Vz@sc8-sf-web2.sourceforge.net>

Bugs item #1529871, was opened at 2006-07-27 13:49
Message generated for change (Settings changed) made by collinwinter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529871&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
>Priority: 6
Submitted By: Collin Winter (collinwinter)
Assigned to: Nobody/Anonymous (nobody)
Summary: distutils regression related to Distribution.run_command

Initial Comment:
The following used to work in Python 2.4.x but fails
under Python 2.5:

>>> import setuptools
>>> import distutils.core
>>> distutils.core._setup_stop_after = 'config'
>>> 
>>> import setup
>>> setup.dist.run_command('test')

Where setup.dist is an instance of
distutils.core.Distribution (which setuptools replaces
with setuptools.dist.Distribution).

Under Python 2.4.x, this code would execute setuptools'
test command. Under Python 2.5b2 (as of r50855), this
code results in the following exception:

/opt/dev/python/2.5/lib/python2.5/distutils/dist.py:263:
UserWarning: Unknown distribution option: 'test_suite'
  warnings.warn(msg)
Traceback (most recent call last):
  File "test.py", line 8, in <module>
    setup.dist.run_command('test')
  File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 992, in run_command
    cmd_obj = self.get_command_obj(command)
  File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 868, in get_command_obj
    klass = self.get_command_class(command)
  File
"/opt/dev/python/2.5/lib/python2.5/site-packages/setuptools/dist.py",
line 357, in get_command_class
    return _Distribution.get_command_class(self, command)
  File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 851, in get_command_class
    raise DistutilsModuleError("invalid command '%s'" %
command)
distutils.errors.DistutilsModuleError: invalid command
'test'

I'd greatly appreciate it if this regression could be
fixed before Python 2.5 is released.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529871&group_id=5470

From noreply at sourceforge.net  Thu Jul 27 20:03:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 27 Jul 2006 11:03:42 -0700
Subject: [ python-Bugs-1529871 ] distutils regression related to
	Distribution.run_command
Message-ID: <E1G6AD0-0007GG-8e@sc8-sf-web5.sourceforge.net>

Bugs item #1529871, was opened at 2006-07-27 13:49
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529871&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 6
Submitted By: Collin Winter (collinwinter)
>Assigned to: Phillip J. Eby (pje)
Summary: distutils regression related to Distribution.run_command

Initial Comment:
The following used to work in Python 2.4.x but fails
under Python 2.5:

>>> import setuptools
>>> import distutils.core
>>> distutils.core._setup_stop_after = 'config'
>>> 
>>> import setup
>>> setup.dist.run_command('test')

Where setup.dist is an instance of
distutils.core.Distribution (which setuptools replaces
with setuptools.dist.Distribution).

Under Python 2.4.x, this code would execute setuptools'
test command. Under Python 2.5b2 (as of r50855), this
code results in the following exception:

/opt/dev/python/2.5/lib/python2.5/distutils/dist.py:263:
UserWarning: Unknown distribution option: 'test_suite'
  warnings.warn(msg)
Traceback (most recent call last):
  File "test.py", line 8, in <module>
    setup.dist.run_command('test')
  File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 992, in run_command
    cmd_obj = self.get_command_obj(command)
  File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 868, in get_command_obj
    klass = self.get_command_class(command)
  File
"/opt/dev/python/2.5/lib/python2.5/site-packages/setuptools/dist.py",
line 357, in get_command_class
    return _Distribution.get_command_class(self, command)
  File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 851, in get_command_class
    raise DistutilsModuleError("invalid command '%s'" %
command)
distutils.errors.DistutilsModuleError: invalid command
'test'

I'd greatly appreciate it if this regression could be
fixed before Python 2.5 is released.

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-27 14:03

Message:
Logged In: YES 
user_id=11375

Assigned to Phillip.  I don't see any obviously relevant
changes to distutils/dist.py, but maybe this problems stems
from changes to some other module.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529871&group_id=5470

From noreply at sourceforge.net  Thu Jul 27 20:18:36 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 27 Jul 2006 11:18:36 -0700
Subject: [ python-Bugs-1529871 ] distutils regression related to
	Distribution.run_command
Message-ID: <E1G6ARQ-0004mc-0G@sc8-sf-web5.sourceforge.net>

Bugs item #1529871, was opened at 2006-07-27 13:49
Message generated for change (Comment added) made by collinwinter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529871&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 6
Submitted By: Collin Winter (collinwinter)
Assigned to: Phillip J. Eby (pje)
Summary: distutils regression related to Distribution.run_command

Initial Comment:
The following used to work in Python 2.4.x but fails
under Python 2.5:

>>> import setuptools
>>> import distutils.core
>>> distutils.core._setup_stop_after = 'config'
>>> 
>>> import setup
>>> setup.dist.run_command('test')

Where setup.dist is an instance of
distutils.core.Distribution (which setuptools replaces
with setuptools.dist.Distribution).

Under Python 2.4.x, this code would execute setuptools'
test command. Under Python 2.5b2 (as of r50855), this
code results in the following exception:

/opt/dev/python/2.5/lib/python2.5/distutils/dist.py:263:
UserWarning: Unknown distribution option: 'test_suite'
  warnings.warn(msg)
Traceback (most recent call last):
  File "test.py", line 8, in <module>
    setup.dist.run_command('test')
  File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 992, in run_command
    cmd_obj = self.get_command_obj(command)
  File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 868, in get_command_obj
    klass = self.get_command_class(command)
  File
"/opt/dev/python/2.5/lib/python2.5/site-packages/setuptools/dist.py",
line 357, in get_command_class
    return _Distribution.get_command_class(self, command)
  File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 851, in get_command_class
    raise DistutilsModuleError("invalid command '%s'" %
command)
distutils.errors.DistutilsModuleError: invalid command
'test'

I'd greatly appreciate it if this regression could be
fixed before Python 2.5 is released.

----------------------------------------------------------------------

>Comment By: Collin Winter (collinwinter)
Date: 2006-07-27 14:18

Message:
Logged In: YES 
user_id=1344176

Forgot to mention: I've tried this with setuptools 0.6a9 and
0.6c1. Python 2.4.x (2.4.1, 2.4.2 and 2.4.3 tested) with
both setuptools version worked fine, where Python 2.5b2
fails with both.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-27 14:03

Message:
Logged In: YES 
user_id=11375

Assigned to Phillip.  I don't see any obviously relevant
changes to distutils/dist.py, but maybe this problems stems
from changes to some other module.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529871&group_id=5470

From noreply at sourceforge.net  Thu Jul 27 20:34:09 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 27 Jul 2006 11:34:09 -0700
Subject: [ python-Bugs-1529871 ] distutils regression related to
	Distribution.run_command
Message-ID: <E1G6AgT-0003fu-Cz@sc8-sf-web6.sourceforge.net>

Bugs item #1529871, was opened at 2006-07-27 13:49
Message generated for change (Comment added) made by collinwinter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529871&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 6
Submitted By: Collin Winter (collinwinter)
Assigned to: Phillip J. Eby (pje)
Summary: distutils regression related to Distribution.run_command

Initial Comment:
The following used to work in Python 2.4.x but fails
under Python 2.5:

>>> import setuptools
>>> import distutils.core
>>> distutils.core._setup_stop_after = 'config'
>>> 
>>> import setup
>>> setup.dist.run_command('test')

Where setup.dist is an instance of
distutils.core.Distribution (which setuptools replaces
with setuptools.dist.Distribution).

Under Python 2.4.x, this code would execute setuptools'
test command. Under Python 2.5b2 (as of r50855), this
code results in the following exception:

/opt/dev/python/2.5/lib/python2.5/distutils/dist.py:263:
UserWarning: Unknown distribution option: 'test_suite'
  warnings.warn(msg)
Traceback (most recent call last):
  File "test.py", line 8, in <module>
    setup.dist.run_command('test')
  File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 992, in run_command
    cmd_obj = self.get_command_obj(command)
  File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 868, in get_command_obj
    klass = self.get_command_class(command)
  File
"/opt/dev/python/2.5/lib/python2.5/site-packages/setuptools/dist.py",
line 357, in get_command_class
    return _Distribution.get_command_class(self, command)
  File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 851, in get_command_class
    raise DistutilsModuleError("invalid command '%s'" %
command)
distutils.errors.DistutilsModuleError: invalid command
'test'

I'd greatly appreciate it if this regression could be
fixed before Python 2.5 is released.

----------------------------------------------------------------------

>Comment By: Collin Winter (collinwinter)
Date: 2006-07-27 14:34

Message:
Logged In: YES 
user_id=1344176

Further testing reveals that all of setuptools' extension
commands (tested: egg_info, bdist_egg, test, rotate, alias)
are broken under Python 2.5b2, even when called from the
command line, like so:

$ python2.5 setup.py egg_info

This produces an "error: invalid command: 'egg_info'" message.

----------------------------------------------------------------------

Comment By: Collin Winter (collinwinter)
Date: 2006-07-27 14:18

Message:
Logged In: YES 
user_id=1344176

Forgot to mention: I've tried this with setuptools 0.6a9 and
0.6c1. Python 2.4.x (2.4.1, 2.4.2 and 2.4.3 tested) with
both setuptools version worked fine, where Python 2.5b2
fails with both.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-27 14:03

Message:
Logged In: YES 
user_id=11375

Assigned to Phillip.  I don't see any obviously relevant
changes to distutils/dist.py, but maybe this problems stems
from changes to some other module.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529871&group_id=5470

From noreply at sourceforge.net  Tue Jul 25 21:21:59 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 25 Jul 2006 12:21:59 -0700
Subject: [ python-Bugs-1525447 ] Build fails on OS X with case sensitive fs
Message-ID: <E1G5STf-000369-Od@sc8-sf-web3.sourceforge.net>

Bugs item #1525447, was opened at 2006-07-19 19:24
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525447&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
>Resolution: Fixed
Priority: 6
Submitted By: gideon may (gdm)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: Build fails on OS X with case sensitive fs

Initial Comment:
When compiling python from svn on a Mac OS X with a 
case sensitive file system I get the following build
error:

running build
running build_ext
db.h: found (4, 3) in /opt/local/include/db4
db lib: using (4, 3) db-4.3
sqlite: found /usr/include/sqlite3.h
/usr/include/sqlite3.h: version 3.1.3
Traceback (most recent call last):
  File "./setup.py", line 1507, in <module>
    main()
.
.
  File "./setup.py", line 1088, in addMacExtension
    raise RuntimeError("%s not found" % name)
RuntimeError: MacOS not found
make: *** [sharedmods] Error 1




It can be fixed by either renaming the file:
  Mac/Modules/macosmodule.c 
to
  Mac/Modules/MacOSmodule.c 

or applying the following patch :
Index: setup.py
===================================================================
--- setup.py    (revision 50687)
+++ setup.py    (working copy)
@@ -1101,7 +1101,7 @@
             carbon_kwds = {'extra_compile_args':
carbon_extra_compile_args,
                            'extra_link_args':
['-framework', 'Carbon'],
                           }
-            CARBON_EXTS = ['ColorPicker', 'gestalt',
'MacOS', 'Nav',
+            CARBON_EXTS = ['ColorPicker', 'gestalt',
'macos', 'Nav',
                            'OSATerminology', 'icglue',
                            # All these are in subdirs
                            '_AE', '_AH', '_App',
'_CarbonEvt', '_Cm', '_Ctl',


Cheers,

Gideon



----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-25 21:21

Message:
Logged In: YES 
user_id=580910

I've implemented the rename I suggested earlier in revision 50832.

Could you please confirm that this does actually solve your problem?

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-23 20:11

Message:
Logged In: YES 
user_id=580910

Could you please test if renaming Mac/Modules/macosmodule.c to Mac/
Modules/MacOS.c solves your problem?  With that rename the build still works 
for me, but I don't have a case-sensitive filesystem.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-23 11:31

Message:
Logged In: YES 
user_id=580910

The patch is incorrect, as this would rename user visible name of the python 
extension ('import MacOS' would stop working). 

The rename would be correct.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525447&group_id=5470

From noreply at sourceforge.net  Thu Jul 27 10:31:10 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 27 Jul 2006 01:31:10 -0700
Subject: [ python-Bugs-1521947 ] possible bug in mystrtol.c with recent gcc
Message-ID: <E1G61Gw-0002sv-PG@sc8-sf-web6.sourceforge.net>

Bugs item #1521947, was opened at 2006-07-13 17:39
Message generated for change (Comment added) made by nmm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521947&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Marien Zwart (marienz)
Assigned to: Nobody/Anonymous (nobody)
Summary: possible bug in mystrtol.c with recent gcc

Initial Comment:
python 2.5b2 compiled with gentoo's gcc 4.1.1 and -O2
fails test_unary_minus in test_compile.py. Some
investigating showed that the -ftree-vrp pass of that
gcc (implied by -O2) optimizes out the "result ==
-result" test on line 215 of PyOS_strtol, meaning
PyOS_strtol of the most negative long will incorrectly
overflow. 

Python deals with this in this case by constructing a
python long object instead of a python int object, so
at least in this case the problem is not serious. I
have no idea if there is a case where this is a "real"
problem.

At first I reported this as a gentoo compiler bug, but
got the reply that:

"""
I'm pretty sure it's broken. -LONG_MIN overflows when
LONG_MIN < -LONG_MAX, and in standard C as well as "GNU
C", behaviour after overflow on signed integer
operations is undefined.
"""

(see https://bugs.gentoo.org/show_bug.cgi?id=140133)

So now I'm reporting this here. There seems to be a
LONG_MIN constant in limits.h here that could checked
against instead, but I have absolutely no idea how
standard that is. Or this could be a compiler bug after
all, in which case I would appreciate information I Can
use to back that up :)

----------------------------------------------------------------------

Comment By: Nick Maclaren (nmm)
Date: 2006-07-27 08:31

Message:
Logged In: YES 
user_id=42444

Fixed for me, too, and the code looks solid.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-27 04:48

Message:
Logged In: YES 
user_id=33168

I reopened this bug as it still affects 2.4.  Tim's fix
should be backported.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-27 04:35

Message:
Logged In: YES 
user_id=33168

Tim's fix corrected the problem on amd64 gentoo linux with
gcc 4.1.1.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 01:16

Message:
Logged In: YES 
user_id=31435

Made a non-heroic effort to repair this in rev 50855, but
have no platform on which it could make any difference (and
apparently no Python buildbot test platform cares either) .
 Would be nice if someone who has such a platform could
check against current Python trunk.

----------------------------------------------------------------------

Comment By: Nick Maclaren (nmm)
Date: 2006-07-17 09:20

Message:
Logged In: YES 
user_id=42444

Yes, this is a duplicate of 1521726.

The compiler people's answer is correct, and mystrtoul.c is
incorrect. LONG_MIN has been in C since C90, so should be
safe, but its value may not always be what you expect.

However, the code breakage is worse that just that test, and
there are the following 3 cases of undefined behaviour:

    1) Casting and unsigned long to long above LONG_MAX.
    2) That test.
    3) result = -result.

The fix should be to make result unsigned long, and check
the range BEFORE any conversion.  Nothing else is safe.

It is a matter of taste whether to include a fiddle for the
number that can be held only when negated - I wouldn't, and
would let that number be converted to a Python long, but
others might disagree.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-17 01:13

Message:
Logged In: YES 
user_id=33168

Is this a duplicate of 1521726?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521947&group_id=5470

From noreply at sourceforge.net  Thu Jul 27 23:00:38 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 27 Jul 2006 14:00:38 -0700
Subject: [ python-Bugs-1521947 ] possible bug in mystrtol.c with recent gcc
Message-ID: <E1G6CyE-0004hR-P4@sc8-sf-web6.sourceforge.net>

Bugs item #1521947, was opened at 2006-07-13 13:39
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521947&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Marien Zwart (marienz)
Assigned to: Nobody/Anonymous (nobody)
Summary: possible bug in mystrtol.c with recent gcc

Initial Comment:
python 2.5b2 compiled with gentoo's gcc 4.1.1 and -O2
fails test_unary_minus in test_compile.py. Some
investigating showed that the -ftree-vrp pass of that
gcc (implied by -O2) optimizes out the "result ==
-result" test on line 215 of PyOS_strtol, meaning
PyOS_strtol of the most negative long will incorrectly
overflow. 

Python deals with this in this case by constructing a
python long object instead of a python int object, so
at least in this case the problem is not serious. I
have no idea if there is a case where this is a "real"
problem.

At first I reported this as a gentoo compiler bug, but
got the reply that:

"""
I'm pretty sure it's broken. -LONG_MIN overflows when
LONG_MIN < -LONG_MAX, and in standard C as well as "GNU
C", behaviour after overflow on signed integer
operations is undefined.
"""

(see https://bugs.gentoo.org/show_bug.cgi?id=140133)

So now I'm reporting this here. There seems to be a
LONG_MIN constant in limits.h here that could checked
against instead, but I have absolutely no idea how
standard that is. Or this could be a compiler bug after
all, in which case I would appreciate information I Can
use to back that up :)

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-07-27 17:00

Message:
Logged In: YES 
user_id=31435

Neal, as I said in the checkin comment, I expect it's no
less likely that we'll get screwed by goofy platform values
for LONG_MIN and LONG_MAX than that we /got/ screwed by an
"over ambitious" compiler optimizing away "result ==
-result", so I'm not sure backporting is a good idea.  I
stuck in an assert that might fail if a platform is insane;
if there are no reports of that assert triggering, then I'd
feel better about backporting the change.

----------------------------------------------------------------------

Comment By: Matt Fleming (splitscreen)
Date: 2006-07-27 06:49

Message:
Logged In: YES 
user_id=1126061

Fixed for me on NetBSD -current AMD64, gcc 4.1.2

----------------------------------------------------------------------

Comment By: Nick Maclaren (nmm)
Date: 2006-07-27 04:31

Message:
Logged In: YES 
user_id=42444

Fixed for me, too, and the code looks solid.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-27 00:48

Message:
Logged In: YES 
user_id=33168

I reopened this bug as it still affects 2.4.  Tim's fix
should be backported.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-27 00:35

Message:
Logged In: YES 
user_id=33168

Tim's fix corrected the problem on amd64 gentoo linux with
gcc 4.1.1.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-26 21:16

Message:
Logged In: YES 
user_id=31435

Made a non-heroic effort to repair this in rev 50855, but
have no platform on which it could make any difference (and
apparently no Python buildbot test platform cares either) .
 Would be nice if someone who has such a platform could
check against current Python trunk.

----------------------------------------------------------------------

Comment By: Nick Maclaren (nmm)
Date: 2006-07-17 05:20

Message:
Logged In: YES 
user_id=42444

Yes, this is a duplicate of 1521726.

The compiler people's answer is correct, and mystrtoul.c is
incorrect. LONG_MIN has been in C since C90, so should be
safe, but its value may not always be what you expect.

However, the code breakage is worse that just that test, and
there are the following 3 cases of undefined behaviour:

    1) Casting and unsigned long to long above LONG_MAX.
    2) That test.
    3) result = -result.

The fix should be to make result unsigned long, and check
the range BEFORE any conversion.  Nothing else is safe.

It is a matter of taste whether to include a fiddle for the
number that can be held only when negated - I wouldn't, and
would let that number be converted to a Python long, but
others might disagree.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-16 21:13

Message:
Logged In: YES 
user_id=33168

Is this a duplicate of 1521726?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521947&group_id=5470

From noreply at sourceforge.net  Thu Jul 27 23:13:34 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 27 Jul 2006 14:13:34 -0700
Subject: [ python-Bugs-1529871 ] distutils regression related to
	Distribution.run_command
Message-ID: <E1G6DAk-0005EC-OM@sc8-sf-web3.sourceforge.net>

Bugs item #1529871, was opened at 2006-07-27 17:49
Message generated for change (Comment added) made by pje
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529871&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 6
Submitted By: Collin Winter (collinwinter)
Assigned to: Phillip J. Eby (pje)
Summary: distutils regression related to Distribution.run_command

Initial Comment:
The following used to work in Python 2.4.x but fails
under Python 2.5:

>>> import setuptools
>>> import distutils.core
>>> distutils.core._setup_stop_after = 'config'
>>> 
>>> import setup
>>> setup.dist.run_command('test')

Where setup.dist is an instance of
distutils.core.Distribution (which setuptools replaces
with setuptools.dist.Distribution).

Under Python 2.4.x, this code would execute setuptools'
test command. Under Python 2.5b2 (as of r50855), this
code results in the following exception:

/opt/dev/python/2.5/lib/python2.5/distutils/dist.py:263:
UserWarning: Unknown distribution option: 'test_suite'
  warnings.warn(msg)
Traceback (most recent call last):
  File "test.py", line 8, in <module>
    setup.dist.run_command('test')
  File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 992, in run_command
    cmd_obj = self.get_command_obj(command)
  File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 868, in get_command_obj
    klass = self.get_command_class(command)
  File
"/opt/dev/python/2.5/lib/python2.5/site-packages/setuptools/dist.py",
line 357, in get_command_class
    return _Distribution.get_command_class(self, command)
  File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 851, in get_command_class
    raise DistutilsModuleError("invalid command '%s'" %
command)
distutils.errors.DistutilsModuleError: invalid command
'test'

I'd greatly appreciate it if this regression could be
fixed before Python 2.5 is released.

----------------------------------------------------------------------

>Comment By: Phillip J. Eby (pje)
Date: 2006-07-27 21:13

Message:
Logged In: YES 
user_id=56214

Problem source confirmed: reverting the PEP 302 breakage of
r46372 (need-for-speed import cache hack) fixes the problem.

setuptools 0.7a1 doesn't show any problems because it uses
2.5's "pkgutil" module if possible, and r46372 patches
pkgutil in a way that masks the problem, at least as far as
setuptools is concerned, for this one specific feature. 
(Other code in setuptools is affected in both 0.6 *and* 0.7,
and will require further workaround code to be written.)



----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2006-07-27 18:35

Message:
Logged In: YES 
user_id=56214

I can't reproduce this using setuptools 0.7a1 and the Python
2.5 trunk.  Please note that setuptools 0.6 does *not*
support Python 2.5; there were numerous changes needed and
there may still be additional changes needed.  Please try
using setuptools 0.7a1 and let me know what you find out. 
Thanks.


----------------------------------------------------------------------

Comment By: Collin Winter (collinwinter)
Date: 2006-07-27 18:34

Message:
Logged In: YES 
user_id=1344176

Further testing reveals that all of setuptools' extension
commands (tested: egg_info, bdist_egg, test, rotate, alias)
are broken under Python 2.5b2, even when called from the
command line, like so:

$ python2.5 setup.py egg_info

This produces an "error: invalid command: 'egg_info'" message.

----------------------------------------------------------------------

Comment By: Collin Winter (collinwinter)
Date: 2006-07-27 18:18

Message:
Logged In: YES 
user_id=1344176

Forgot to mention: I've tried this with setuptools 0.6a9 and
0.6c1. Python 2.4.x (2.4.1, 2.4.2 and 2.4.3 tested) with
both setuptools version worked fine, where Python 2.5b2
fails with both.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-27 18:03

Message:
Logged In: YES 
user_id=11375

Assigned to Phillip.  I don't see any obviously relevant
changes to distutils/dist.py, but maybe this problems stems
from changes to some other module.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529871&group_id=5470

From noreply at sourceforge.net  Thu Jul 27 23:39:26 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 27 Jul 2006 14:39:26 -0700
Subject: [ python-Bugs-1469557 ] FTP modue functions are not re-entrant,
	give odd exceptions
Message-ID: <E1G6DZm-00015k-Pc@sc8-sf-web6.sourceforge.net>

Bugs item #1469557, was opened at 2006-04-12 17:13
Message generated for change (Comment added) made by brucepeterson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469557&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: brucepeterson (brucepeterson)
Assigned to: Nobody/Anonymous (nobody)
Summary: FTP modue functions are not re-entrant,give odd exceptions

Initial Comment:
 If I define a class using the Thread and FTP moudles, 
start a process which gathers FTP responses, 
additional calls to the class may have the responses 
of the thread instead of the main loop (or vice versa)
  This causes weird and unexpected exceptions from the 
ftplib.

  For instance I get the following error when the 
thread process does a pwd() function
error_reply: 213 34603008  

  The "213" reply is a response from the main process 
size() function

---------
Code
---------
from time import sleep
from threading import Thread

class ftpMachine(Thread, ftplib.FTP):
    def __init__(self, svr, user, passwd):
        Thread.__init__(self)
        ftplib.FTP.__init__(self, svr, user, passwd)
        
    def run(self):
        for x in xrange(20):
            output="Thread -"+str(self.nlst())[:30]
            print output
            sleep (0.0100)

def main():
    aCon = ftpMachine("LocalFTP", "user", "")
    aCon.start()
    for x in xrange(20):
        output = "Main -- " + str(aCon.size("File"))
        print output  
        sleep (0.010)

Workround:
  Rewrite code to create a third worker thread for 
response isolation?  Don't know that this would solve 
the problem.


---------------
Exception example
---------------

Exception in thread Thread-1:
Traceback (most recent call last):
  File "C:\Python24\lib\threading.py", line 442, in 
__bootstrap
    self.run()
  File "dualFTPIssue.py", line 17, in run
    output  = "Thread output " + str(self.nlst())[:30]
+" ..."
  File "C:\Python24\lib\ftplib.py", line 448, in nlst
    self.retrlines(cmd, files.append)
  File "C:\Python24\lib\ftplib.py", line 396, in 
retrlines
    conn = self.transfercmd(cmd)
  File "C:\Python24\lib\ftplib.py", line 345, in 
transfercmd
    return self.ntransfercmd(cmd, rest)[0]
  File "C:\Python24\lib\ftplib.py", line 321, in 
ntransfercmd
    host, port = self.makepasv()
  File "C:\Python24\lib\ftplib.py", line 299, in 
makepasv
    host, port = parse227(self.sendcmd('PASV'))
  File "C:\Python24\lib\ftplib.py", line 566, in 
parse227
    raise error_reply, resp
error_reply: 213 34603008

----------------------------------------------------------------------

>Comment By: brucepeterson (brucepeterson)
Date: 2006-07-27 14:39

Message:
Logged In: YES 
user_id=1500983

Unfortunately I can't start two instances of the FTP client 
as the separate instances use two conneciton resources.  I 
was hoping for a non-exception when a unexpsected response 
happens.  That would require re-working the module.
  For my workaround I set a time to determine when the 
transfer should complete instead of a querry.

  Thanks for your attention in this matter.

  Closing this bug as my case is an unusual one.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-13 04:54

Message:
Logged In: YES 
user_id=580910

IMHO this isn't a bug, your accessing a shared resource (the FTP connection) 
from two threads without locking. Most of python's libraries aren't safe for this 
kind of use.

BTW. The fact that you subclass form thread and ftplib.FTP is immaterial, you 
will get the same effect if you create an ftplib.FTP and then use it in two threads.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469557&group_id=5470

From noreply at sourceforge.net  Thu Jul 27 23:42:44 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 27 Jul 2006 14:42:44 -0700
Subject: [ python-Bugs-1112549 ] cgi.FieldStorage memory usage can spike in
	line-oriented ops
Message-ID: <E1G6Dcy-0000ZM-7V@sc8-sf-web5.sourceforge.net>

Bugs item #1112549, was opened at 2005-01-30 08:40
Message generated for change (Comment added) made by chrism
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112549&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris McDonough (chrism)
Assigned to: Nobody/Anonymous (nobody)
Summary: cgi.FieldStorage memory usage can spike in line-oriented ops

Initial Comment:
Various parts of cgi.FieldStorage call its
"read_lines_to_outerboundary", "read_lines" and
"skip_lines" methods.    These methods use the
"readline" method of the file object that represents an
input stream.  The input stream is typically data
supplied by an untrusted source (such as a user
uploading a file from a web browser).  The input data
is not required by the RFC 822/1521/1522/1867
specifications to contain any newline characters.  For
example, it is within the bounds of the specification
to supply a a multipart/form-data input stream with a
"file-data" part that consists of a 2GB string composed
entirely of "x" characters (which happens to be
something I did that led me to noticing this bug).

The simplest fix is to make use of the "size" argument
of the readline method of the file object where it is
used within all parts of FieldStorage that make use of
it.  A patch against the Python 2.3.4 cgi.py module
that does this is attached.

----------------------------------------------------------------------

>Comment By: Chris McDonough (chrism)
Date: 2006-07-27 17:42

Message:
Logged In: YES 
user_id=32974

The files I've just uploaded are revisions to the cgi and test_cgi modules for the 
current state of the SVN trunk.  If someone could apply these, it would be 
appreciated, or give me access and I'll be happy to.

FTR, this is a bug which exposes systems which use the cgi.FieldStorage class 
(most Python web frameworks do) to a denial of service potential.

----------------------------------------------------------------------

Comment By: Chris McDonough (chrism)
Date: 2005-04-02 23:00

Message:
Logged In: YES 
user_id=32974

FYI, I'd be happy to do the merging here if you wanted to
give me checkin access.

----------------------------------------------------------------------

Comment By: Chris McDonough (chrism)
Date: 2005-04-02 22:42

Message:
Logged In: YES 
user_id=32974

An updated test_cgi.py is attached.  I test both the
readline behavior and add a test for basic multipart parsing. 

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2005-03-31 23:48

Message:
Logged In: YES 
user_id=6380

Can I tweak you into uploading a unit test?

----------------------------------------------------------------------

Comment By: Chris McDonough (chrism)
Date: 2005-03-31 21:56

Message:
Logged In: YES 
user_id=32974

Re: parse_multipart..  yes, it looks like there's no use
fixing that as it just turns around and puts the line into a
list.. it is vulnerable but just by virtue of its non-use of
a tempfile, it appears doomed anyway for large requests.  I
don't know of anything that uses it.
 
Good catch wrt boundary recognition bug, I'm uploading
another patch.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2005-03-31 17:13

Message:
Logged In: YES 
user_id=6380

Methinks that the fix isn't quite right: it would
incorrectly recognize as a boundary a very long line
starting with "--" followed by the appropriate random string
at offset 2**16. This could probably be taken care of by
adding a flag that is true initially and after that keeps
track of whether the previous line ended in \n.

Also, there's a call to fp.readline() in parse_multipart()
that you didn't patch -- it wouldn't help because that code
is saving the lines in a list anyway, but isn't that code
vulnerable as well? Or is it not used?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112549&group_id=5470

From noreply at sourceforge.net  Thu Jul 27 23:45:44 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 27 Jul 2006 14:45:44 -0700
Subject: [ python-Bugs-1529998 ] bz2 lib missing from source distribution
Message-ID: <E1G6Dfs-0003LZ-NP@sc8-sf-web6.sourceforge.net>

Bugs item #1529998, was opened at 2006-07-27 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=1529998&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: james yoo (jyoo_abn)
Assigned to: Nobody/Anonymous (nobody)
Summary: bz2 lib missing from source distribution

Initial Comment:
python 2.4.3

got an import error trying to test PySqlite 

"No module named bz2"

checked my python dirs and yep, no bz2... I thought
that the bz2 module was part of the standard distribution?

checked the python source dir (python-2.4.3.tar.gz) and
no bz2.py in the Lib dir.

what gives?



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529998&group_id=5470

From noreply at sourceforge.net  Thu Jul 27 23:48:19 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 27 Jul 2006 14:48:19 -0700
Subject: [ python-Bugs-1529297 ] unrelated variable messing up doctests
Message-ID: <E1G6DiN-0008TT-SV@sc8-sf-web1.sourceforge.net>

Bugs item #1529297, was opened at 2006-07-26 15:02
Message generated for change (Comment added) made by macquigg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529297&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: David MacQuigg (macquigg)
Assigned to: Nobody/Anonymous (nobody)
Summary: unrelated variable messing up doctests

Initial Comment:
Version 2.5b2 with IDLE 1.2b2 running on Windows XP 
Home, fully updated.

Unpack the attached zip file.
Open program.py, test_suite.py, in separate IDLE 
windows.  
Run test_suite.py.  
  8 passed and 0 failed.
Now add a variable at the top of program.py, any name 
will do.
  xyz = 2
Re-run test_suite.py.  
  7 passed and 1 failed !!

I haven't been able to isolate the problem, but it is 
repeatable.  Taking out blocks of unrelated statements 
changes the behavior.  Feels like a memory allocation 
error, or something strange.


----------------------------------------------------------------------

>Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 14:48

Message:
Logged In: YES 
user_id=676422

Some observations:
If I give the test variable a private name, the problem 
goes away.
.   _xyz = 2
If I assign the variable to an object already in memory, 
the problem doesn't go away.
.   xyz = LocalADDRs
It doesn't matter that the test variable is never used. The 
problem persists, even if I add a second statement:
.   xyz = 2
.   if xyz == 2: pass
It doesn't matter where in the module the statement is 
placed, as long as it is module level, not inside a class 
or function.


----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 10:32

Message:
Logged In: YES 
user_id=676422

The failure is not the specific output of doctest, but the 
fact that it *changes* when I add an unrelated variable 
xyz=2 in the module program.py.  I am not able to reproduce 
this failure with Tim's stripped down test_suite.py.

I agree the problem is not in IDLE.  I can do the same from 
a bash command line with
$ python2.4 test_suite.py
but not with 
$ python2.3 test_suite.py


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 09:14

Message:
Logged In: YES 
user_id=31435

I see exactly the same failure akuchling reported, on
Windows using current trunk, running from a command shell
(not IDLE -- didn't try IDLE).  The attached test_suite.py
throws away everything not needed to see the same failure;
in particular, it gets rid of doctest, the logging module,
and most of the functions in test_suite.py.

Reduced to this, I don't see a reason to suspect a Python
bug.  ci.IDrating is initialized to 100, and the

_envrcpt('zz1 at open-mail.org')

line produces (the expected)

CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 101, '']]

if you /leave ci.IDrating alone/.  However, if you do

ci.hello('zz_IP_192.168.0.8_mailout7.simple.tld')

first, that has a (apparently deliberate) side effect of
changing ci.IDrating to None, and then this path is /not/ taken:

# . . Whitelist pass
    if self.IDrating > whitelvl:
        rcptinfo[4] = 101  # ham > 100% to ignore later
spamscore       ###2e
        self.R.append(rcptinfo)

The 101 vanishes from the expected output then, and I get

CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 50, '']]

instead.

That exactly reproduces the only failure Andrew & I have
seen, and appears to be what the code is telling it to do
(via side effects on the shared `ci` instance).

----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 08:22

Message:
Logged In: YES 
user_id=676422

On my Redhat Linux machine, I see the failure in 2.4.1, but 
not in 2.3.4.

Trying to isolate the problem, I've commented out some 
blocks of unrelated code, but I can't get very far with 
this, because many of the deletions make the problem go 
away.  It's as if the problem depends on the exact position 
in memory of the test variable.

I did manage to delete the DNS queries, so now you can run 
the tests without intermittent failures due to DNS timeouts.
I'll keep the latest at http://www.open-
mail.org/test/test_0607nn.tgz

Thanks for your efforts.


----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-27 05:15

Message:
Logged In: YES 
user_id=11375

On a Linux machine, both 2.4.3 and SVN HEAD report 7 tests
passed, one failed.

For both versions, the failure is: 
Failed example:
    _envrcpt('zz1 at open-mail.org')
Expected:
    CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 101, '']]
Got:
    CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 50, '']]


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-26 20:59

Message:
Logged In: YES 
user_id=33168

Can you try with SVN head?  There was an unitialized read
that the doctests could trigger.  It has been fixed. 
Perhaps you are running into that?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529297&group_id=5470

From noreply at sourceforge.net  Thu Jul 27 23:48:52 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 27 Jul 2006 14:48:52 -0700
Subject: [ python-Bugs-1529297 ] unrelated variable messing up doctests
Message-ID: <E1G6Diu-0002Ws-MY@sc8-sf-web2.sourceforge.net>

Bugs item #1529297, was opened at 2006-07-26 15:02
Message generated for change (Comment added) made by macquigg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529297&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: David MacQuigg (macquigg)
Assigned to: Nobody/Anonymous (nobody)
Summary: unrelated variable messing up doctests

Initial Comment:
Version 2.5b2 with IDLE 1.2b2 running on Windows XP 
Home, fully updated.

Unpack the attached zip file.
Open program.py, test_suite.py, in separate IDLE 
windows.  
Run test_suite.py.  
  8 passed and 0 failed.
Now add a variable at the top of program.py, any name 
will do.
  xyz = 2
Re-run test_suite.py.  
  7 passed and 1 failed !!

I haven't been able to isolate the problem, but it is 
repeatable.  Taking out blocks of unrelated statements 
changes the behavior.  Feels like a memory allocation 
error, or something strange.


----------------------------------------------------------------------

>Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 14:48

Message:
Logged In: YES 
user_id=676422

Some observations:
If I give the test variable a private name, the problem 
goes away.
.   _xyz = 2
If I assign the variable to an object already in memory, 
the problem doesn't go away.
.   xyz = LocalADDRs
It doesn't matter that the test variable is never used. The 
problem persists, even if I add a second statement:
.   xyz = 2
.   if xyz == 2: pass
It doesn't matter where in the module the statement is 
placed, as long as it is module level, not inside a class 
or function.


----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 14:48

Message:
Logged In: YES 
user_id=676422

Some observations:
If I give the test variable a private name, the problem 
goes away.
.   _xyz = 2
If I assign the variable to an object already in memory, 
the problem doesn't go away.
.   xyz = LocalADDRs
It doesn't matter that the test variable is never used. The 
problem persists, even if I add a second statement:
.   xyz = 2
.   if xyz == 2: pass
It doesn't matter where in the module the statement is 
placed, as long as it is module level, not inside a class 
or function.


----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 10:32

Message:
Logged In: YES 
user_id=676422

The failure is not the specific output of doctest, but the 
fact that it *changes* when I add an unrelated variable 
xyz=2 in the module program.py.  I am not able to reproduce 
this failure with Tim's stripped down test_suite.py.

I agree the problem is not in IDLE.  I can do the same from 
a bash command line with
$ python2.4 test_suite.py
but not with 
$ python2.3 test_suite.py


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 09:14

Message:
Logged In: YES 
user_id=31435

I see exactly the same failure akuchling reported, on
Windows using current trunk, running from a command shell
(not IDLE -- didn't try IDLE).  The attached test_suite.py
throws away everything not needed to see the same failure;
in particular, it gets rid of doctest, the logging module,
and most of the functions in test_suite.py.

Reduced to this, I don't see a reason to suspect a Python
bug.  ci.IDrating is initialized to 100, and the

_envrcpt('zz1 at open-mail.org')

line produces (the expected)

CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 101, '']]

if you /leave ci.IDrating alone/.  However, if you do

ci.hello('zz_IP_192.168.0.8_mailout7.simple.tld')

first, that has a (apparently deliberate) side effect of
changing ci.IDrating to None, and then this path is /not/ taken:

# . . Whitelist pass
    if self.IDrating > whitelvl:
        rcptinfo[4] = 101  # ham > 100% to ignore later
spamscore       ###2e
        self.R.append(rcptinfo)

The 101 vanishes from the expected output then, and I get

CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 50, '']]

instead.

That exactly reproduces the only failure Andrew & I have
seen, and appears to be what the code is telling it to do
(via side effects on the shared `ci` instance).

----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 08:22

Message:
Logged In: YES 
user_id=676422

On my Redhat Linux machine, I see the failure in 2.4.1, but 
not in 2.3.4.

Trying to isolate the problem, I've commented out some 
blocks of unrelated code, but I can't get very far with 
this, because many of the deletions make the problem go 
away.  It's as if the problem depends on the exact position 
in memory of the test variable.

I did manage to delete the DNS queries, so now you can run 
the tests without intermittent failures due to DNS timeouts.
I'll keep the latest at http://www.open-
mail.org/test/test_0607nn.tgz

Thanks for your efforts.


----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-27 05:15

Message:
Logged In: YES 
user_id=11375

On a Linux machine, both 2.4.3 and SVN HEAD report 7 tests
passed, one failed.

For both versions, the failure is: 
Failed example:
    _envrcpt('zz1 at open-mail.org')
Expected:
    CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 101, '']]
Got:
    CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 50, '']]


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-26 20:59

Message:
Logged In: YES 
user_id=33168

Can you try with SVN head?  There was an unitialized read
that the doctests could trigger.  It has been fixed. 
Perhaps you are running into that?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529297&group_id=5470

From noreply at sourceforge.net  Thu Jul 27 05:59:06 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 26 Jul 2006 20:59:06 -0700
Subject: [ python-Bugs-1529297 ] unrelated variable messing up doctests
Message-ID: <E1G5x1e-0008Re-Nm@sc8-sf-web5.sourceforge.net>

Bugs item #1529297, was opened at 2006-07-26 15:02
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529297&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: David MacQuigg (macquigg)
Assigned to: Nobody/Anonymous (nobody)
Summary: unrelated variable messing up doctests

Initial Comment:
Version 2.5b2 with IDLE 1.2b2 running on Windows XP 
Home, fully updated.

Unpack the attached zip file.
Open program.py, test_suite.py, in separate IDLE 
windows.  
Run test_suite.py.  
  8 passed and 0 failed.
Now add a variable at the top of program.py, any name 
will do.
  xyz = 2
Re-run test_suite.py.  
  7 passed and 1 failed !!

I haven't been able to isolate the problem, but it is 
repeatable.  Taking out blocks of unrelated statements 
changes the behavior.  Feels like a memory allocation 
error, or something strange.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-26 20:59

Message:
Logged In: YES 
user_id=33168

Can you try with SVN head?  There was an unitialized read
that the doctests could trigger.  It has been fixed. 
Perhaps you are running into that?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529297&group_id=5470

From noreply at sourceforge.net  Fri Jul 28 00:08:40 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 27 Jul 2006 15:08:40 -0700
Subject: [ python-Bugs-1530012 ] Literal strings use BS as octal escape
	character
Message-ID: <E1G6E24-0003ZA-86@sc8-sf-web5.sourceforge.net>

Bugs item #1530012, was opened at 2006-07-27 15: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=1530012&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: brucepeterson (brucepeterson)
Assigned to: Nobody/Anonymous (nobody)
Summary: Literal strings use BS as octal escape character

Initial Comment:
Also in 2.4


  Using a literal to hard code a path.  My directory 
happened to start with a number and I couldn't open 
the file due to the bad directory name.  Found that 
the tripple quote was operating as documented.

  I would have at least expected the tripple double 
quotes to not have an escape character.  (Is this a 
pep?)  (From my reading of the Introduction, the 
triple double quotes should act like a raw string 
except that you can have a single double quote 
included in the string.)

-------------
code snippet:
-------------
dir1 = """C:\1stDirecotry"""
dir2 = '''C:\2ndDirecotry'''
dir3 = '''C:\9thDirecotry'''
print dir1, dir2, dir3

C:?stDirecotry C:?ndDirecotry C:\9thDirecotry

dir1's format was not expected, dir2's format might be 
expected.

>>> '''\1'''
'\x01'
>>> '''\9'''
'\\9'

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530012&group_id=5470

From noreply at sourceforge.net  Fri Jul 28 00:12:45 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 27 Jul 2006 15:12:45 -0700
Subject: [ python-Bugs-1529871 ] distutils regression related to
	Distribution.run_command
Message-ID: <E1G6E61-0005gV-15@sc8-sf-web3.sourceforge.net>

Bugs item #1529871, was opened at 2006-07-27 13:49
Message generated for change (Comment added) made by collinwinter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529871&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 6
Submitted By: Collin Winter (collinwinter)
Assigned to: Phillip J. Eby (pje)
Summary: distutils regression related to Distribution.run_command

Initial Comment:
The following used to work in Python 2.4.x but fails
under Python 2.5:

>>> import setuptools
>>> import distutils.core
>>> distutils.core._setup_stop_after = 'config'
>>> 
>>> import setup
>>> setup.dist.run_command('test')

Where setup.dist is an instance of
distutils.core.Distribution (which setuptools replaces
with setuptools.dist.Distribution).

Under Python 2.4.x, this code would execute setuptools'
test command. Under Python 2.5b2 (as of r50855), this
code results in the following exception:

/opt/dev/python/2.5/lib/python2.5/distutils/dist.py:263:
UserWarning: Unknown distribution option: 'test_suite'
  warnings.warn(msg)
Traceback (most recent call last):
  File "test.py", line 8, in <module>
    setup.dist.run_command('test')
  File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 992, in run_command
    cmd_obj = self.get_command_obj(command)
  File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 868, in get_command_obj
    klass = self.get_command_class(command)
  File
"/opt/dev/python/2.5/lib/python2.5/site-packages/setuptools/dist.py",
line 357, in get_command_class
    return _Distribution.get_command_class(self, command)
  File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 851, in get_command_class
    raise DistutilsModuleError("invalid command '%s'" %
command)
distutils.errors.DistutilsModuleError: invalid command
'test'

I'd greatly appreciate it if this regression could be
fixed before Python 2.5 is released.

----------------------------------------------------------------------

>Comment By: Collin Winter (collinwinter)
Date: 2006-07-27 18:12

Message:
Logged In: YES 
user_id=1344176

I've tried using setuptools 0.7a1 in conjunction with Python
2.5b2 (r50877), and the problem still exists. setuptools'
extension commands still do not work (tested: rotate, alias,
egg_info, bdist_egg, test), that is, 'python2.5 setup.py
test' still fails with "error: invalid command 'test'".

Also, the code snippet in the bug report does not work. I am
sure Python is picking up setuptools 0.7a1 because the path
/opt/dev/python/2.5/lib/python2.5/site-packages/setuptools-0.7a1dev_r50755-py2.4.egg/setuptools/dist.py
appears in the traceback.

----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2006-07-27 17:13

Message:
Logged In: YES 
user_id=56214

Problem source confirmed: reverting the PEP 302 breakage of
r46372 (need-for-speed import cache hack) fixes the problem.

setuptools 0.7a1 doesn't show any problems because it uses
2.5's "pkgutil" module if possible, and r46372 patches
pkgutil in a way that masks the problem, at least as far as
setuptools is concerned, for this one specific feature. 
(Other code in setuptools is affected in both 0.6 *and* 0.7,
and will require further workaround code to be written.)



----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2006-07-27 14:35

Message:
Logged In: YES 
user_id=56214

I can't reproduce this using setuptools 0.7a1 and the Python
2.5 trunk.  Please note that setuptools 0.6 does *not*
support Python 2.5; there were numerous changes needed and
there may still be additional changes needed.  Please try
using setuptools 0.7a1 and let me know what you find out. 
Thanks.


----------------------------------------------------------------------

Comment By: Collin Winter (collinwinter)
Date: 2006-07-27 14:34

Message:
Logged In: YES 
user_id=1344176

Further testing reveals that all of setuptools' extension
commands (tested: egg_info, bdist_egg, test, rotate, alias)
are broken under Python 2.5b2, even when called from the
command line, like so:

$ python2.5 setup.py egg_info

This produces an "error: invalid command: 'egg_info'" message.

----------------------------------------------------------------------

Comment By: Collin Winter (collinwinter)
Date: 2006-07-27 14:18

Message:
Logged In: YES 
user_id=1344176

Forgot to mention: I've tried this with setuptools 0.6a9 and
0.6c1. Python 2.4.x (2.4.1, 2.4.2 and 2.4.3 tested) with
both setuptools version worked fine, where Python 2.5b2
fails with both.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-27 14:03

Message:
Logged In: YES 
user_id=11375

Assigned to Phillip.  I don't see any obviously relevant
changes to distutils/dist.py, but maybe this problems stems
from changes to some other module.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529871&group_id=5470

From noreply at sourceforge.net  Thu Jul 27 06:38:38 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 26 Jul 2006 21:38:38 -0700
Subject: [ python-Bugs-1333982 ] Bugs of the new AST compiler
Message-ID: <E1G5xdu-00013Q-Gn@sc8-sf-web3.sourceforge.net>

Bugs item #1333982, was opened at 2005-10-21 03:08
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1333982&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: AST
Status: Open
Resolution: None
>Priority: 9
Submitted By: Armin Rigo (arigo)
Assigned to: Jeremy Hylton (jhylton)
Summary: Bugs of the new AST compiler

Initial Comment:
The newly merged AST branch is likely to expose
a number of small problems before it stabilizes,
so here is a tentative bug tracker entry to
collect such small problems.


----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2006-07-09 14:23

Message:
Logged In: YES 
user_id=35752

Unary minus bug has been fixed in SVN rev 50495.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2006-07-09 14:05

Message:
Logged In: YES 
user_id=35752

Regarding the -2147483648 bug: the old compiler tries to
fold unary +, - and ~ if the RHS is a constant.  I think
only the minus case is important since the others are just
optimizations, right?  Attaching what seems to be a minimum fix.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2006-07-02 04:29

Message:
Logged In: YES 
user_id=4771

Attached a patch for the LOAD_CONST POP_TOP optimization
(modified from Georg Brandl on python-dev).

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2006-04-11 02:41

Message:
Logged In: YES 
user_id=6656

Good morning Armin!

I've reported that bug already: http://python.org/sf/1441486
There's a patch which purports to fix it: http://python.org/sf/1446922
but I haven't gotten around to testing it.

(this is running the pypy/module/array tests or something, isn't it?)

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2006-04-11 01:45

Message:
Logged In: YES 
user_id=4771

Another one: the literal -2147483648 (i.e. the value of
-sys.maxint-1) gives a long in 2.5, but an int in <= 2.4.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-03 00:30

Message:
Logged In: YES 
user_id=33168

The tuple store problem is fixed.  The only outstanding item
is the LOAD_CONST/POP_TOP.  I will fix that soon.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-17 22:56

Message:
Logged In: YES 
user_id=33168

Jeremy, there's no need to read anything before my last
comment at 2005-12-17 23:10.  The last two by Armin,
Michael, then my last comment are the only important ones. 
Everything that occurred before my 2005-12-17 comment was
taken care of AFAIK.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2006-02-12 13:54

Message:
Logged In: YES 
user_id=4771

Subscripting is generally a bit sloppy: e.g. the AST model has
no way to distinguish between a single value and a one-element
tuple value!  See:

>>> d = {}
>>> d[1,] = 6
>>> d
{1: 6}        # !

I suggest we fix the model to turn the 'subs' of the 'Subscript' node
from a list of nodes to a single, mandatory 'sub' node.  If tupling is
necessary, it can be explicitly represented with a 'sub' containing a
'Tuple' node.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2006-02-09 07:02

Message:
Logged In: YES 
user_id=6656

We found another one.  Something is wrong in the compilation of augmented 
assignment to subscriptions containing tuples; running this code:

class C:
    def __setitem__(self, i, v):
        print i, v
    def __getitem__(self, i):
        print i
        return 0

c = C()
c[4,5] += 1

gives a spurious exception:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: object does not support item assignment

By contrast, "c[(4,5)] += 1" works fine.



----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-12-17 23:10

Message:
Logged In: YES 
user_id=33168

EXTENDED_ARG problem was fixed a while ago.
The assert/pass problem was fixed with: 41756.

That leaves the LOAD_CONST/POP_TOP optimization that was
lost and one compiler warning: marshal_write_mod() not being
used.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-12-10 16:41

Message:
Logged In: YES 
user_id=6656

You have to include those lines in a source file.  It still crashes for me.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2005-12-10 15:44

Message:
Logged In: YES 
user_id=357491

I just checked Armin's problem code on rev. 41638 and it
worked for me in the interpreter.  You still having
problems, Armin?

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-12-04 02:30

Message:
Logged In: YES 
user_id=4771

At rev 41584, the following code snippet triggers an assert
if --with-pydebug is enabled:
Python/compile.c:3843: assemble_lnotab: Assertion 'd_lineno >= 0' failed

-----------------------
assert 1, ([s for s in x] +
           [s for s in x])
pass
-----------------------

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-23 12:14

Message:
Logged In: YES 
user_id=33168

Checkpoint of outstanding issues.  I think all the others
mentioned so far have been fixed:

 * Raymond's warnings in compile.c (unused locals are fixed)
 * EXTENDED_ARG problem
 * LOAD_CONST/POP_TOP (note we can fix this in the optimizer
generally which would get rid of other useless code too)


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-10-22 21:53

Message:
Logged In: YES 
user_id=80475

FWIW, here are the warnings issued by my compiler:

Python-ast.c
C:\py25\Python\Python-ast.c(1995) : warning C4101: 'i' : 
unreferenced local variable
C:\py25\Python\Python-ast.c(2070) : warning C4101: 'i' : 
unreferenced local variable
C:\py25\Python\Python-ast.c(2085) : warning C4101: 'i' : 
unreferenced local variable
C:\py25\Python\Python-ast.c(2130) : warning C4101: 'i' : 
unreferenced local variable
C:\py25\Python\Python-ast.c(2151) : warning C4101: 'i' : 
unreferenced local variable
C:\py25\Python\Python-ast.c(2261) : warning C4101: 'i' : 
unreferenced local variable
C:\py25\Python\Python-ast.c(2270) : warning C4101: 'i' : 
unreferenced local variable


compile.c
C:\py25\Python\compile.c(3782) : warning C4305: '=' : truncation 
from 'const int ' to 'char '
C:\py25\Python\compile.c(3802) : warning C4305: '=' : truncation 
from 'const int ' to 'char '
C:\py25\Python\compile.c(3806) : warning C4305: '=' : truncation 
from 'const int ' to 'char '


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-22 00:28

Message:
Logged In: YES 
user_id=33168

I assigned to Jeremy and Neil in the hopes they will see
this message and know about these problems.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 05:45

Message:
Logged In: YES 
user_id=4771

The following (similarly strange-looking) code snippets
compiled successfully before, now they give SyntaxErrors:

--------------------
def f():
    class g:
        exec "hi"
        x
--------------------
def f(x):
    class g:
        exec "hi"
        x
--------------------
def f():
    class g:
        from a import *
        x
--------------------
def f(x):
    class g:
        from a import *
        x


----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 05:33

Message:
Logged In: YES 
user_id=4771

I would suspect the following one to be due to incorrect
handling of EXTENDED_ARG -- it's from a PyPy test about that:

longexpr = 'x = x or ' + '-x' * 2500
code = '''
def f(x):
    %s
    %s
    %s
    %s
    %s
    %s
    %s
    %s
    %s
    %s
    while x:
        x -= 1
        # EXTENDED_ARG/JUMP_ABSOLUTE here
    return x
''' % ((longexpr,)*10)

exec code
f(5)
SystemError: unknown opcode

dis.dis() shows that the target of both the SETUP_LOOP and
the JUMP_IF_FALSE at the start of the loop are wrong.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 05:15

Message:
Logged In: YES 
user_id=4771

The Python rules about which names get mangled are a bit
insane.  I share mwh's view that mangling should never have
been invented in the first place, but well:

>>> def f():
...   __x = 5
...   class X:
...     def g(self):
...       return __x
...   return X
... 
Fatal Python error: unknown scope for _X__x in X(135832776)
in <stdin>


----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 05:01

Message:
Logged In: YES 
user_id=4771

For reference, an optimization that got lost:

    def f():
        'a'
        'b'

'a' is the docstring, but the 'b' previously did not show
up anywhere in the code object.  Now there is the
LOAD_CONST/POP_TOP pair.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 04:54

Message:
Logged In: YES 
user_id=4771

any reason why lambda functions have a __name__ of
'lambda' now instead of '<lambda>' ?

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 03:22

Message:
Logged In: YES 
user_id=4771

import a as b, c

the 'c' part gets completely forgotten and there is
no 'IMPORT_NAME c' in the bytecode.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 03:13

Message:
Logged In: YES 
user_id=4771

A scoping problem (comparing with the old compiler):

class X:
    print hello

The variable 'hello' is incorrectly looked up with
LOAD_GLOBAL instead of LOAD_NAME.  It causes a crash
in PyPy in a case where the name 'hello' is stored
into the class implicitely (via locals()).  It can
probably be discussed if the bug is in PyPy, but it
is a difference in behavior.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1333982&group_id=5470

From noreply at sourceforge.net  Fri Jul 28 00:30:57 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 27 Jul 2006 15:30:57 -0700
Subject: [ python-Bugs-1529998 ] bz2 lib missing from source distribution
Message-ID: <E1G6ENd-0007u8-O4@sc8-sf-web6.sourceforge.net>

Bugs item #1529998, was opened at 2006-07-27 21:45
Message generated for change (Comment added) made by jyoo_abn
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529998&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: james yoo (jyoo_abn)
Assigned to: Nobody/Anonymous (nobody)
Summary: bz2 lib missing from source distribution

Initial Comment:
python 2.4.3

got an import error trying to test PySqlite 

"No module named bz2"

checked my python dirs and yep, no bz2... I thought
that the bz2 module was part of the standard distribution?

checked the python source dir (python-2.4.3.tar.gz) and
no bz2.py in the Lib dir.

what gives?



----------------------------------------------------------------------

>Comment By: james yoo (jyoo_abn)
Date: 2006-07-27 22:30

Message:
Logged In: YES 
user_id=1562754

actually sorry for the poor assumptions regarding the
existence of a bz2.py file... realize that there is a a
bz2module.c file and that my config.log had a bunch of fatal
ld errors... 

fyi: this is on sunOS 5.8, gcc-3.4.3..

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529998&group_id=5470

From noreply at sourceforge.net  Fri Jul 28 01:21:26 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 27 Jul 2006 16:21:26 -0700
Subject: [ python-Bugs-1529297 ] unrelated variable messing up doctests
Message-ID: <E1G6FAU-0004yn-4G@sc8-sf-web6.sourceforge.net>

Bugs item #1529297, was opened at 2006-07-26 18: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=1529297&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: David MacQuigg (macquigg)
Assigned to: Nobody/Anonymous (nobody)
Summary: unrelated variable messing up doctests

Initial Comment:
Version 2.5b2 with IDLE 1.2b2 running on Windows XP 
Home, fully updated.

Unpack the attached zip file.
Open program.py, test_suite.py, in separate IDLE 
windows.  
Run test_suite.py.  
  8 passed and 0 failed.
Now add a variable at the top of program.py, any name 
will do.
  xyz = 2
Re-run test_suite.py.  
  7 passed and 1 failed !!

I haven't been able to isolate the problem, but it is 
repeatable.  Taking out blocks of unrelated statements 
changes the behavior.  Feels like a memory allocation 
error, or something strange.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-07-27 19:21

Message:
Logged In: YES 
user_id=31435

I think I know what's happening here.  doctest was largely
rewritten for Python 2.4, and it lost a subtle intended
feature:  it used to (<= 2.3) sort tests by name before
running them, but in 2.4 started running them in whatever
order they happen to appear in the hash-code-based module
__dict__.

Changing the namespace in program.py in seemingly random
ways matters because test_suite.py starts with

from program import *

and so everything in program.py's module namespace
"pollutes" test_suite.py's namespace too.  That can change
the order tests run in.  And as I noted before, whether or
not the doctest for _envrcpt() passes or fails depends on
whether or not the doctests for _hello() run before them,
due to side effects on the shared `ci` instance.  Look at
your output carefully, and I expect you'll find that the
order of tests /does/ change depending on crap variable
names you stick in (or remove from) program.py.

If you're with me so far, try changing the end of
doctest.py's DocTestFinder.find() from

    return tests

to

    tests.sort()
    return tests


----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 17:48

Message:
Logged In: YES 
user_id=676422

Some observations:
If I give the test variable a private name, the problem 
goes away.
.   _xyz = 2
If I assign the variable to an object already in memory, 
the problem doesn't go away.
.   xyz = LocalADDRs
It doesn't matter that the test variable is never used. The 
problem persists, even if I add a second statement:
.   xyz = 2
.   if xyz == 2: pass
It doesn't matter where in the module the statement is 
placed, as long as it is module level, not inside a class 
or function.


----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 17:48

Message:
Logged In: YES 
user_id=676422

Some observations:
If I give the test variable a private name, the problem 
goes away.
.   _xyz = 2
If I assign the variable to an object already in memory, 
the problem doesn't go away.
.   xyz = LocalADDRs
It doesn't matter that the test variable is never used. The 
problem persists, even if I add a second statement:
.   xyz = 2
.   if xyz == 2: pass
It doesn't matter where in the module the statement is 
placed, as long as it is module level, not inside a class 
or function.


----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 13:32

Message:
Logged In: YES 
user_id=676422

The failure is not the specific output of doctest, but the 
fact that it *changes* when I add an unrelated variable 
xyz=2 in the module program.py.  I am not able to reproduce 
this failure with Tim's stripped down test_suite.py.

I agree the problem is not in IDLE.  I can do the same from 
a bash command line with
$ python2.4 test_suite.py
but not with 
$ python2.3 test_suite.py


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 12:14

Message:
Logged In: YES 
user_id=31435

I see exactly the same failure akuchling reported, on
Windows using current trunk, running from a command shell
(not IDLE -- didn't try IDLE).  The attached test_suite.py
throws away everything not needed to see the same failure;
in particular, it gets rid of doctest, the logging module,
and most of the functions in test_suite.py.

Reduced to this, I don't see a reason to suspect a Python
bug.  ci.IDrating is initialized to 100, and the

_envrcpt('zz1 at open-mail.org')

line produces (the expected)

CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 101, '']]

if you /leave ci.IDrating alone/.  However, if you do

ci.hello('zz_IP_192.168.0.8_mailout7.simple.tld')

first, that has a (apparently deliberate) side effect of
changing ci.IDrating to None, and then this path is /not/ taken:

# . . Whitelist pass
    if self.IDrating > whitelvl:
        rcptinfo[4] = 101  # ham > 100% to ignore later
spamscore       ###2e
        self.R.append(rcptinfo)

The 101 vanishes from the expected output then, and I get

CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 50, '']]

instead.

That exactly reproduces the only failure Andrew & I have
seen, and appears to be what the code is telling it to do
(via side effects on the shared `ci` instance).

----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 11:22

Message:
Logged In: YES 
user_id=676422

On my Redhat Linux machine, I see the failure in 2.4.1, but 
not in 2.3.4.

Trying to isolate the problem, I've commented out some 
blocks of unrelated code, but I can't get very far with 
this, because many of the deletions make the problem go 
away.  It's as if the problem depends on the exact position 
in memory of the test variable.

I did manage to delete the DNS queries, so now you can run 
the tests without intermittent failures due to DNS timeouts.
I'll keep the latest at http://www.open-
mail.org/test/test_0607nn.tgz

Thanks for your efforts.


----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-27 08:15

Message:
Logged In: YES 
user_id=11375

On a Linux machine, both 2.4.3 and SVN HEAD report 7 tests
passed, one failed.

For both versions, the failure is: 
Failed example:
    _envrcpt('zz1 at open-mail.org')
Expected:
    CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 101, '']]
Got:
    CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 50, '']]


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-26 23:59

Message:
Logged In: YES 
user_id=33168

Can you try with SVN head?  There was an unitialized read
that the doctests could trigger.  It has been fixed. 
Perhaps you are running into that?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529297&group_id=5470

From noreply at sourceforge.net  Wed Jul 26 19:26:59 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 26 Jul 2006 10:26:59 -0700
Subject: [ python-Bugs-1471938 ] curses mvwgetnstr build problem on Solaris 8
Message-ID: <E1G5n9v-0001SA-9m@sc8-sf-web1.sourceforge.net>

Bugs item #1471938, was opened at 2006-04-17 16:07
Message generated for change (Settings changed) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471938&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Paul Eggert (eggert)
>Assigned to: A.M. Kuchling (akuchling)
Summary: curses mvwgetnstr build problem on Solaris 8

Initial Comment:
The _curses extension doesn't build on Solaris 8
(64-bit) due to the following problem:

building '_curses' extension
cc -O -xarch=v9 -xcode=pic32 -DNDEBUG -O -I.
-I/w/fac.01/cs/eggert/seasnet/Python-2.5a1/./Include
-I/u/cs/fac/eggert/seasnet/prefix/include -I./Include
-I. -I/w/fac.01/cs/eggert/seasnet/Python-2.5a1/Include
-I/w/fac.01/cs/eggert/seasnet/Python-2.5a1 -c
/w/fac.01/cs/eggert/seasnet/Python-2.5a1/Modules/_cursesmodule.c
-o build/temp.solaris-2.8-sun4u-2.5/_cursesmodule.o
"/w/fac.01/cs/eggert/seasnet/Python-2.5a1/Modules/_cursesmodule.c",
line 822: warning: implicit function declaration:
mvwgetnstr
cc -O -xarch=v9 -G
build/temp.solaris-2.8-sun4u-2.5/_cursesmodule.o
-L/u/cs/fac/eggert/seasnet/prefix/lib -lcurses
-ltermcap -o build/lib.solaris-2.8-sun4u-2.5/_curses.so
*** WARNING: renaming "_curses" since importing it
failed: ld.so.1: python: fatal: relocation error: file
build/lib.solaris-2.8-sun4u-2.5/_curses.so: symbol
mvwgetnstr: referenced symbol not found
building '_curses_panel' extension

This problem occurs with both 2.4.3 and 2.5a1.

I'll attach the obvious patch.


----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-26 13:26

Message:
Logged In: YES 
user_id=11375

Thanks!  I've tried the patch on Linux, including the
STRICT_SYSV_CURSES code, and applied it to the 2.4 and 2.5
branches.


----------------------------------------------------------------------

Comment By: Paul Eggert (eggert)
Date: 2006-04-20 23:29

Message:
Logged In: YES 
user_id=17848

Sorry, I'm trying again to attach a file now.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-04-17 18:53

Message:
Logged In: YES 
user_id=21627

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=1471938&group_id=5470

From noreply at sourceforge.net  Fri Jul 28 02:01:11 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 27 Jul 2006 17:01:11 -0700
Subject: [ python-Bugs-1529297 ] unrelated variable messing up doctests
Message-ID: <E1G6Fmx-00076x-1c@sc8-sf-web5.sourceforge.net>

Bugs item #1529297, was opened at 2006-07-26 18: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=1529297&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: David MacQuigg (macquigg)
Assigned to: Nobody/Anonymous (nobody)
Summary: unrelated variable messing up doctests

Initial Comment:
Version 2.5b2 with IDLE 1.2b2 running on Windows XP 
Home, fully updated.

Unpack the attached zip file.
Open program.py, test_suite.py, in separate IDLE 
windows.  
Run test_suite.py.  
  8 passed and 0 failed.
Now add a variable at the top of program.py, any name 
will do.
  xyz = 2
Re-run test_suite.py.  
  7 passed and 1 failed !!

I haven't been able to isolate the problem, but it is 
repeatable.  Taking out blocks of unrelated statements 
changes the behavior.  Feels like a memory allocation 
error, or something strange.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-07-27 20:01

Message:
Logged In: YES 
user_id=31435

DocTestFinder has been changed to sort test names again, in
revs 50882 (on the trunk, for 2.5) and 50886 (on the 2.4
branch, for 2.4.4).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 19:21

Message:
Logged In: YES 
user_id=31435

I think I know what's happening here.  doctest was largely
rewritten for Python 2.4, and it lost a subtle intended
feature:  it used to (<= 2.3) sort tests by name before
running them, but in 2.4 started running them in whatever
order they happen to appear in the hash-code-based module
__dict__.

Changing the namespace in program.py in seemingly random
ways matters because test_suite.py starts with

from program import *

and so everything in program.py's module namespace
"pollutes" test_suite.py's namespace too.  That can change
the order tests run in.  And as I noted before, whether or
not the doctest for _envrcpt() passes or fails depends on
whether or not the doctests for _hello() run before them,
due to side effects on the shared `ci` instance.  Look at
your output carefully, and I expect you'll find that the
order of tests /does/ change depending on crap variable
names you stick in (or remove from) program.py.

If you're with me so far, try changing the end of
doctest.py's DocTestFinder.find() from

    return tests

to

    tests.sort()
    return tests


----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 17:48

Message:
Logged In: YES 
user_id=676422

Some observations:
If I give the test variable a private name, the problem 
goes away.
.   _xyz = 2
If I assign the variable to an object already in memory, 
the problem doesn't go away.
.   xyz = LocalADDRs
It doesn't matter that the test variable is never used. The 
problem persists, even if I add a second statement:
.   xyz = 2
.   if xyz == 2: pass
It doesn't matter where in the module the statement is 
placed, as long as it is module level, not inside a class 
or function.


----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 17:48

Message:
Logged In: YES 
user_id=676422

Some observations:
If I give the test variable a private name, the problem 
goes away.
.   _xyz = 2
If I assign the variable to an object already in memory, 
the problem doesn't go away.
.   xyz = LocalADDRs
It doesn't matter that the test variable is never used. The 
problem persists, even if I add a second statement:
.   xyz = 2
.   if xyz == 2: pass
It doesn't matter where in the module the statement is 
placed, as long as it is module level, not inside a class 
or function.


----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 13:32

Message:
Logged In: YES 
user_id=676422

The failure is not the specific output of doctest, but the 
fact that it *changes* when I add an unrelated variable 
xyz=2 in the module program.py.  I am not able to reproduce 
this failure with Tim's stripped down test_suite.py.

I agree the problem is not in IDLE.  I can do the same from 
a bash command line with
$ python2.4 test_suite.py
but not with 
$ python2.3 test_suite.py


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 12:14

Message:
Logged In: YES 
user_id=31435

I see exactly the same failure akuchling reported, on
Windows using current trunk, running from a command shell
(not IDLE -- didn't try IDLE).  The attached test_suite.py
throws away everything not needed to see the same failure;
in particular, it gets rid of doctest, the logging module,
and most of the functions in test_suite.py.

Reduced to this, I don't see a reason to suspect a Python
bug.  ci.IDrating is initialized to 100, and the

_envrcpt('zz1 at open-mail.org')

line produces (the expected)

CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 101, '']]

if you /leave ci.IDrating alone/.  However, if you do

ci.hello('zz_IP_192.168.0.8_mailout7.simple.tld')

first, that has a (apparently deliberate) side effect of
changing ci.IDrating to None, and then this path is /not/ taken:

# . . Whitelist pass
    if self.IDrating > whitelvl:
        rcptinfo[4] = 101  # ham > 100% to ignore later
spamscore       ###2e
        self.R.append(rcptinfo)

The 101 vanishes from the expected output then, and I get

CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 50, '']]

instead.

That exactly reproduces the only failure Andrew & I have
seen, and appears to be what the code is telling it to do
(via side effects on the shared `ci` instance).

----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 11:22

Message:
Logged In: YES 
user_id=676422

On my Redhat Linux machine, I see the failure in 2.4.1, but 
not in 2.3.4.

Trying to isolate the problem, I've commented out some 
blocks of unrelated code, but I can't get very far with 
this, because many of the deletions make the problem go 
away.  It's as if the problem depends on the exact position 
in memory of the test variable.

I did manage to delete the DNS queries, so now you can run 
the tests without intermittent failures due to DNS timeouts.
I'll keep the latest at http://www.open-
mail.org/test/test_0607nn.tgz

Thanks for your efforts.


----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-27 08:15

Message:
Logged In: YES 
user_id=11375

On a Linux machine, both 2.4.3 and SVN HEAD report 7 tests
passed, one failed.

For both versions, the failure is: 
Failed example:
    _envrcpt('zz1 at open-mail.org')
Expected:
    CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 101, '']]
Got:
    CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 50, '']]


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-26 23:59

Message:
Logged In: YES 
user_id=33168

Can you try with SVN head?  There was an unitialized read
that the doctests could trigger.  It has been fixed. 
Perhaps you are running into that?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529297&group_id=5470

From noreply at sourceforge.net  Fri Jul 28 02:46:11 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 27 Jul 2006 17:46:11 -0700
Subject: [ python-Bugs-1529297 ] unrelated variable messing up doctests
Message-ID: <E1G6GUV-00082R-VT@sc8-sf-web6.sourceforge.net>

Bugs item #1529297, was opened at 2006-07-26 15:02
Message generated for change (Comment added) made by macquigg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529297&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: David MacQuigg (macquigg)
Assigned to: Nobody/Anonymous (nobody)
Summary: unrelated variable messing up doctests

Initial Comment:
Version 2.5b2 with IDLE 1.2b2 running on Windows XP 
Home, fully updated.

Unpack the attached zip file.
Open program.py, test_suite.py, in separate IDLE 
windows.  
Run test_suite.py.  
  8 passed and 0 failed.
Now add a variable at the top of program.py, any name 
will do.
  xyz = 2
Re-run test_suite.py.  
  7 passed and 1 failed !!

I haven't been able to isolate the problem, but it is 
repeatable.  Taking out blocks of unrelated statements 
changes the behavior.  Feels like a memory allocation 
error, or something strange.


----------------------------------------------------------------------

>Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 17:46

Message:
Logged In: YES 
user_id=676422

That fixed it!!  Nice catch.

I've been aware for some time of the sensitivity to order 
in the doctests, but it has never been a problem until now, 
and I've been writing programs with doctests since 2.3.  
When I add a test, and it breaks a later test, it has 
always been easy to nail down the piece that changed.

This "behind the scenes" change of test order seems like 
the kind of problem that rarely occurs, but can cause 
serious problems when it does.

Thanks again for an excellent followup.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 17:01

Message:
Logged In: YES 
user_id=31435

DocTestFinder has been changed to sort test names again, in
revs 50882 (on the trunk, for 2.5) and 50886 (on the 2.4
branch, for 2.4.4).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 16:21

Message:
Logged In: YES 
user_id=31435

I think I know what's happening here.  doctest was largely
rewritten for Python 2.4, and it lost a subtle intended
feature:  it used to (<= 2.3) sort tests by name before
running them, but in 2.4 started running them in whatever
order they happen to appear in the hash-code-based module
__dict__.

Changing the namespace in program.py in seemingly random
ways matters because test_suite.py starts with

from program import *

and so everything in program.py's module namespace
"pollutes" test_suite.py's namespace too.  That can change
the order tests run in.  And as I noted before, whether or
not the doctest for _envrcpt() passes or fails depends on
whether or not the doctests for _hello() run before them,
due to side effects on the shared `ci` instance.  Look at
your output carefully, and I expect you'll find that the
order of tests /does/ change depending on crap variable
names you stick in (or remove from) program.py.

If you're with me so far, try changing the end of
doctest.py's DocTestFinder.find() from

    return tests

to

    tests.sort()
    return tests


----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 14:48

Message:
Logged In: YES 
user_id=676422

Some observations:
If I give the test variable a private name, the problem 
goes away.
.   _xyz = 2
If I assign the variable to an object already in memory, 
the problem doesn't go away.
.   xyz = LocalADDRs
It doesn't matter that the test variable is never used. The 
problem persists, even if I add a second statement:
.   xyz = 2
.   if xyz == 2: pass
It doesn't matter where in the module the statement is 
placed, as long as it is module level, not inside a class 
or function.


----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 14:48

Message:
Logged In: YES 
user_id=676422

Some observations:
If I give the test variable a private name, the problem 
goes away.
.   _xyz = 2
If I assign the variable to an object already in memory, 
the problem doesn't go away.
.   xyz = LocalADDRs
It doesn't matter that the test variable is never used. The 
problem persists, even if I add a second statement:
.   xyz = 2
.   if xyz == 2: pass
It doesn't matter where in the module the statement is 
placed, as long as it is module level, not inside a class 
or function.


----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 10:32

Message:
Logged In: YES 
user_id=676422

The failure is not the specific output of doctest, but the 
fact that it *changes* when I add an unrelated variable 
xyz=2 in the module program.py.  I am not able to reproduce 
this failure with Tim's stripped down test_suite.py.

I agree the problem is not in IDLE.  I can do the same from 
a bash command line with
$ python2.4 test_suite.py
but not with 
$ python2.3 test_suite.py


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 09:14

Message:
Logged In: YES 
user_id=31435

I see exactly the same failure akuchling reported, on
Windows using current trunk, running from a command shell
(not IDLE -- didn't try IDLE).  The attached test_suite.py
throws away everything not needed to see the same failure;
in particular, it gets rid of doctest, the logging module,
and most of the functions in test_suite.py.

Reduced to this, I don't see a reason to suspect a Python
bug.  ci.IDrating is initialized to 100, and the

_envrcpt('zz1 at open-mail.org')

line produces (the expected)

CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 101, '']]

if you /leave ci.IDrating alone/.  However, if you do

ci.hello('zz_IP_192.168.0.8_mailout7.simple.tld')

first, that has a (apparently deliberate) side effect of
changing ci.IDrating to None, and then this path is /not/ taken:

# . . Whitelist pass
    if self.IDrating > whitelvl:
        rcptinfo[4] = 101  # ham > 100% to ignore later
spamscore       ###2e
        self.R.append(rcptinfo)

The 101 vanishes from the expected output then, and I get

CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 50, '']]

instead.

That exactly reproduces the only failure Andrew & I have
seen, and appears to be what the code is telling it to do
(via side effects on the shared `ci` instance).

----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 08:22

Message:
Logged In: YES 
user_id=676422

On my Redhat Linux machine, I see the failure in 2.4.1, but 
not in 2.3.4.

Trying to isolate the problem, I've commented out some 
blocks of unrelated code, but I can't get very far with 
this, because many of the deletions make the problem go 
away.  It's as if the problem depends on the exact position 
in memory of the test variable.

I did manage to delete the DNS queries, so now you can run 
the tests without intermittent failures due to DNS timeouts.
I'll keep the latest at http://www.open-
mail.org/test/test_0607nn.tgz

Thanks for your efforts.


----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-27 05:15

Message:
Logged In: YES 
user_id=11375

On a Linux machine, both 2.4.3 and SVN HEAD report 7 tests
passed, one failed.

For both versions, the failure is: 
Failed example:
    _envrcpt('zz1 at open-mail.org')
Expected:
    CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 101, '']]
Got:
    CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 50, '']]


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-26 20:59

Message:
Logged In: YES 
user_id=33168

Can you try with SVN head?  There was an unitialized read
that the doctests could trigger.  It has been fixed. 
Perhaps you are running into that?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529297&group_id=5470

From noreply at sourceforge.net  Wed Jul 26 20:13:37 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 26 Jul 2006 11:13:37 -0700
Subject: [ python-Bugs-1529157 ] readline module description should mention
	raw_input()
Message-ID: <E1G5nt3-0002wI-VF@sc8-sf-web3.sourceforge.net>

Bugs item #1529157, was opened at 2006-07-26 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=1529157&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Thom Harp (thomharp)
Assigned to: Nobody/Anonymous (nobody)
Summary: readline module description should mention raw_input()

Initial Comment:
The description of the readline module in the library
reference should mention that it alters the behavior of
the input() and raw_input() functions.  Without this
change, it isn't obvious how to use readline to provide
a command line in applications.

The information requested *is* in the docs where
input() and raw_input() are described, but an
inexperienced python programmer, just learning his way
around the standard library, won't know that and may
conclude that the readline module exists only because
it's used for interactive python.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529157&group_id=5470

From noreply at sourceforge.net  Fri Jul 28 02:54:00 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 27 Jul 2006 17:54:00 -0700
Subject: [ python-Bugs-1529297 ] unrelated variable messing up doctests
Message-ID: <E1G6Gc4-0008Ef-2L@sc8-sf-web5.sourceforge.net>

Bugs item #1529297, was opened at 2006-07-26 18: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=1529297&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
>Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: David MacQuigg (macquigg)
Assigned to: Nobody/Anonymous (nobody)
Summary: unrelated variable messing up doctests

Initial Comment:
Version 2.5b2 with IDLE 1.2b2 running on Windows XP 
Home, fully updated.

Unpack the attached zip file.
Open program.py, test_suite.py, in separate IDLE 
windows.  
Run test_suite.py.  
  8 passed and 0 failed.
Now add a variable at the top of program.py, any name 
will do.
  xyz = 2
Re-run test_suite.py.  
  7 passed and 1 failed !!

I haven't been able to isolate the problem, but it is 
repeatable.  Taking out blocks of unrelated statements 
changes the behavior.  Feels like a memory allocation 
error, or something strange.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-07-27 20:53

Message:
Logged In: YES 
user_id=31435

Glad it solved your mystery!  Note that 2.4.4 and 2.5 /will/
sort the tests by name again (the code for that has already
been checked in) -- it was very intentional that it did that
before 2.4, and it was a bug that it stopped doing it in 2.4
through 2.4.3.  OTOH, you're the only one so far who noticed :-)

----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 20:46

Message:
Logged In: YES 
user_id=676422

That fixed it!!  Nice catch.

I've been aware for some time of the sensitivity to order 
in the doctests, but it has never been a problem until now, 
and I've been writing programs with doctests since 2.3.  
When I add a test, and it breaks a later test, it has 
always been easy to nail down the piece that changed.

This "behind the scenes" change of test order seems like 
the kind of problem that rarely occurs, but can cause 
serious problems when it does.

Thanks again for an excellent followup.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 20:01

Message:
Logged In: YES 
user_id=31435

DocTestFinder has been changed to sort test names again, in
revs 50882 (on the trunk, for 2.5) and 50886 (on the 2.4
branch, for 2.4.4).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 19:21

Message:
Logged In: YES 
user_id=31435

I think I know what's happening here.  doctest was largely
rewritten for Python 2.4, and it lost a subtle intended
feature:  it used to (<= 2.3) sort tests by name before
running them, but in 2.4 started running them in whatever
order they happen to appear in the hash-code-based module
__dict__.

Changing the namespace in program.py in seemingly random
ways matters because test_suite.py starts with

from program import *

and so everything in program.py's module namespace
"pollutes" test_suite.py's namespace too.  That can change
the order tests run in.  And as I noted before, whether or
not the doctest for _envrcpt() passes or fails depends on
whether or not the doctests for _hello() run before them,
due to side effects on the shared `ci` instance.  Look at
your output carefully, and I expect you'll find that the
order of tests /does/ change depending on crap variable
names you stick in (or remove from) program.py.

If you're with me so far, try changing the end of
doctest.py's DocTestFinder.find() from

    return tests

to

    tests.sort()
    return tests


----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 17:48

Message:
Logged In: YES 
user_id=676422

Some observations:
If I give the test variable a private name, the problem 
goes away.
.   _xyz = 2
If I assign the variable to an object already in memory, 
the problem doesn't go away.
.   xyz = LocalADDRs
It doesn't matter that the test variable is never used. The 
problem persists, even if I add a second statement:
.   xyz = 2
.   if xyz == 2: pass
It doesn't matter where in the module the statement is 
placed, as long as it is module level, not inside a class 
or function.


----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 17:48

Message:
Logged In: YES 
user_id=676422

Some observations:
If I give the test variable a private name, the problem 
goes away.
.   _xyz = 2
If I assign the variable to an object already in memory, 
the problem doesn't go away.
.   xyz = LocalADDRs
It doesn't matter that the test variable is never used. The 
problem persists, even if I add a second statement:
.   xyz = 2
.   if xyz == 2: pass
It doesn't matter where in the module the statement is 
placed, as long as it is module level, not inside a class 
or function.


----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 13:32

Message:
Logged In: YES 
user_id=676422

The failure is not the specific output of doctest, but the 
fact that it *changes* when I add an unrelated variable 
xyz=2 in the module program.py.  I am not able to reproduce 
this failure with Tim's stripped down test_suite.py.

I agree the problem is not in IDLE.  I can do the same from 
a bash command line with
$ python2.4 test_suite.py
but not with 
$ python2.3 test_suite.py


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 12:14

Message:
Logged In: YES 
user_id=31435

I see exactly the same failure akuchling reported, on
Windows using current trunk, running from a command shell
(not IDLE -- didn't try IDLE).  The attached test_suite.py
throws away everything not needed to see the same failure;
in particular, it gets rid of doctest, the logging module,
and most of the functions in test_suite.py.

Reduced to this, I don't see a reason to suspect a Python
bug.  ci.IDrating is initialized to 100, and the

_envrcpt('zz1 at open-mail.org')

line produces (the expected)

CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 101, '']]

if you /leave ci.IDrating alone/.  However, if you do

ci.hello('zz_IP_192.168.0.8_mailout7.simple.tld')

first, that has a (apparently deliberate) side effect of
changing ci.IDrating to None, and then this path is /not/ taken:

# . . Whitelist pass
    if self.IDrating > whitelvl:
        rcptinfo[4] = 101  # ham > 100% to ignore later
spamscore       ###2e
        self.R.append(rcptinfo)

The 101 vanishes from the expected output then, and I get

CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 50, '']]

instead.

That exactly reproduces the only failure Andrew & I have
seen, and appears to be what the code is telling it to do
(via side effects on the shared `ci` instance).

----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 11:22

Message:
Logged In: YES 
user_id=676422

On my Redhat Linux machine, I see the failure in 2.4.1, but 
not in 2.3.4.

Trying to isolate the problem, I've commented out some 
blocks of unrelated code, but I can't get very far with 
this, because many of the deletions make the problem go 
away.  It's as if the problem depends on the exact position 
in memory of the test variable.

I did manage to delete the DNS queries, so now you can run 
the tests without intermittent failures due to DNS timeouts.
I'll keep the latest at http://www.open-
mail.org/test/test_0607nn.tgz

Thanks for your efforts.


----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-27 08:15

Message:
Logged In: YES 
user_id=11375

On a Linux machine, both 2.4.3 and SVN HEAD report 7 tests
passed, one failed.

For both versions, the failure is: 
Failed example:
    _envrcpt('zz1 at open-mail.org')
Expected:
    CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 101, '']]
Got:
    CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 50, '']]


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-26 23:59

Message:
Logged In: YES 
user_id=33168

Can you try with SVN head?  There was an unitialized read
that the doctests could trigger.  It has been fixed. 
Perhaps you are running into that?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529297&group_id=5470

From noreply at sourceforge.net  Fri Jul 28 03:03:43 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 27 Jul 2006 18:03:43 -0700
Subject: [ python-Bugs-1529297 ] unrelated variable messing up doctests
Message-ID: <E1G6GlT-00040k-CT@sc8-sf-web2.sourceforge.net>

Bugs item #1529297, was opened at 2006-07-26 15:02
Message generated for change (Comment added) made by macquigg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529297&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
>Group: Python 2.5
>Status: Open
>Resolution: None
Priority: 5
Submitted By: David MacQuigg (macquigg)
Assigned to: Nobody/Anonymous (nobody)
Summary: unrelated variable messing up doctests

Initial Comment:
Version 2.5b2 with IDLE 1.2b2 running on Windows XP 
Home, fully updated.

Unpack the attached zip file.
Open program.py, test_suite.py, in separate IDLE 
windows.  
Run test_suite.py.  
  8 passed and 0 failed.
Now add a variable at the top of program.py, any name 
will do.
  xyz = 2
Re-run test_suite.py.  
  7 passed and 1 failed !!

I haven't been able to isolate the problem, but it is 
repeatable.  Taking out blocks of unrelated statements 
changes the behavior.  Feels like a memory allocation 
error, or something strange.


----------------------------------------------------------------------

>Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 18:03

Message:
Logged In: YES 
user_id=676422

I hope this is not too much to ask, but would it be 
possible to run the tests in the order they are written, 
rather than in alphabetical order?  This isn't a big deal, 
as long as the order is stable, but it would abide by the 
rule of least astonishment. :>)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 17:53

Message:
Logged In: YES 
user_id=31435

Glad it solved your mystery!  Note that 2.4.4 and 2.5 /will/
sort the tests by name again (the code for that has already
been checked in) -- it was very intentional that it did that
before 2.4, and it was a bug that it stopped doing it in 2.4
through 2.4.3.  OTOH, you're the only one so far who noticed :-)

----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 17:46

Message:
Logged In: YES 
user_id=676422

That fixed it!!  Nice catch.

I've been aware for some time of the sensitivity to order 
in the doctests, but it has never been a problem until now, 
and I've been writing programs with doctests since 2.3.  
When I add a test, and it breaks a later test, it has 
always been easy to nail down the piece that changed.

This "behind the scenes" change of test order seems like 
the kind of problem that rarely occurs, but can cause 
serious problems when it does.

Thanks again for an excellent followup.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 17:01

Message:
Logged In: YES 
user_id=31435

DocTestFinder has been changed to sort test names again, in
revs 50882 (on the trunk, for 2.5) and 50886 (on the 2.4
branch, for 2.4.4).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 16:21

Message:
Logged In: YES 
user_id=31435

I think I know what's happening here.  doctest was largely
rewritten for Python 2.4, and it lost a subtle intended
feature:  it used to (<= 2.3) sort tests by name before
running them, but in 2.4 started running them in whatever
order they happen to appear in the hash-code-based module
__dict__.

Changing the namespace in program.py in seemingly random
ways matters because test_suite.py starts with

from program import *

and so everything in program.py's module namespace
"pollutes" test_suite.py's namespace too.  That can change
the order tests run in.  And as I noted before, whether or
not the doctest for _envrcpt() passes or fails depends on
whether or not the doctests for _hello() run before them,
due to side effects on the shared `ci` instance.  Look at
your output carefully, and I expect you'll find that the
order of tests /does/ change depending on crap variable
names you stick in (or remove from) program.py.

If you're with me so far, try changing the end of
doctest.py's DocTestFinder.find() from

    return tests

to

    tests.sort()
    return tests


----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 14:48

Message:
Logged In: YES 
user_id=676422

Some observations:
If I give the test variable a private name, the problem 
goes away.
.   _xyz = 2
If I assign the variable to an object already in memory, 
the problem doesn't go away.
.   xyz = LocalADDRs
It doesn't matter that the test variable is never used. The 
problem persists, even if I add a second statement:
.   xyz = 2
.   if xyz == 2: pass
It doesn't matter where in the module the statement is 
placed, as long as it is module level, not inside a class 
or function.


----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 14:48

Message:
Logged In: YES 
user_id=676422

Some observations:
If I give the test variable a private name, the problem 
goes away.
.   _xyz = 2
If I assign the variable to an object already in memory, 
the problem doesn't go away.
.   xyz = LocalADDRs
It doesn't matter that the test variable is never used. The 
problem persists, even if I add a second statement:
.   xyz = 2
.   if xyz == 2: pass
It doesn't matter where in the module the statement is 
placed, as long as it is module level, not inside a class 
or function.


----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 10:32

Message:
Logged In: YES 
user_id=676422

The failure is not the specific output of doctest, but the 
fact that it *changes* when I add an unrelated variable 
xyz=2 in the module program.py.  I am not able to reproduce 
this failure with Tim's stripped down test_suite.py.

I agree the problem is not in IDLE.  I can do the same from 
a bash command line with
$ python2.4 test_suite.py
but not with 
$ python2.3 test_suite.py


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 09:14

Message:
Logged In: YES 
user_id=31435

I see exactly the same failure akuchling reported, on
Windows using current trunk, running from a command shell
(not IDLE -- didn't try IDLE).  The attached test_suite.py
throws away everything not needed to see the same failure;
in particular, it gets rid of doctest, the logging module,
and most of the functions in test_suite.py.

Reduced to this, I don't see a reason to suspect a Python
bug.  ci.IDrating is initialized to 100, and the

_envrcpt('zz1 at open-mail.org')

line produces (the expected)

CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 101, '']]

if you /leave ci.IDrating alone/.  However, if you do

ci.hello('zz_IP_192.168.0.8_mailout7.simple.tld')

first, that has a (apparently deliberate) side effect of
changing ci.IDrating to None, and then this path is /not/ taken:

# . . Whitelist pass
    if self.IDrating > whitelvl:
        rcptinfo[4] = 101  # ham > 100% to ignore later
spamscore       ###2e
        self.R.append(rcptinfo)

The 101 vanishes from the expected output then, and I get

CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 50, '']]

instead.

That exactly reproduces the only failure Andrew & I have
seen, and appears to be what the code is telling it to do
(via side effects on the shared `ci` instance).

----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 08:22

Message:
Logged In: YES 
user_id=676422

On my Redhat Linux machine, I see the failure in 2.4.1, but 
not in 2.3.4.

Trying to isolate the problem, I've commented out some 
blocks of unrelated code, but I can't get very far with 
this, because many of the deletions make the problem go 
away.  It's as if the problem depends on the exact position 
in memory of the test variable.

I did manage to delete the DNS queries, so now you can run 
the tests without intermittent failures due to DNS timeouts.
I'll keep the latest at http://www.open-
mail.org/test/test_0607nn.tgz

Thanks for your efforts.


----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-27 05:15

Message:
Logged In: YES 
user_id=11375

On a Linux machine, both 2.4.3 and SVN HEAD report 7 tests
passed, one failed.

For both versions, the failure is: 
Failed example:
    _envrcpt('zz1 at open-mail.org')
Expected:
    CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 101, '']]
Got:
    CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 50, '']]


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-26 20:59

Message:
Logged In: YES 
user_id=33168

Can you try with SVN head?  There was an unitialized read
that the doctests could trigger.  It has been fixed. 
Perhaps you are running into that?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529297&group_id=5470

From noreply at sourceforge.net  Fri Jul 28 03:31:12 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 27 Jul 2006 18:31:12 -0700
Subject: [ python-Bugs-1529297 ] unrelated variable messing up doctests
Message-ID: <E1G6HC4-0007I0-PL@sc8-sf-web1.sourceforge.net>

Bugs item #1529297, was opened at 2006-07-26 18: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=1529297&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: David MacQuigg (macquigg)
Assigned to: Nobody/Anonymous (nobody)
Summary: unrelated variable messing up doctests

Initial Comment:
Version 2.5b2 with IDLE 1.2b2 running on Windows XP 
Home, fully updated.

Unpack the attached zip file.
Open program.py, test_suite.py, in separate IDLE 
windows.  
Run test_suite.py.  
  8 passed and 0 failed.
Now add a variable at the top of program.py, any name 
will do.
  xyz = 2
Re-run test_suite.py.  
  7 passed and 1 failed !!

I haven't been able to isolate the problem, but it is 
repeatable.  Taking out blocks of unrelated statements 
changes the behavior.  Feels like a memory allocation 
error, or something strange.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-07-27 21:31

Message:
Logged In: YES 
user_id=31435

> would it be possible to run the tests in the order
> they are written, rather than in alphabetical order?

Sorry, that's impossible.  doctest never sees the source
code, it crawls through module and class __dict__s to find
objects with docstrings, and the order things appear in
those is undefined.

----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 21:03

Message:
Logged In: YES 
user_id=676422

I hope this is not too much to ask, but would it be 
possible to run the tests in the order they are written, 
rather than in alphabetical order?  This isn't a big deal, 
as long as the order is stable, but it would abide by the 
rule of least astonishment. :>)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 20:53

Message:
Logged In: YES 
user_id=31435

Glad it solved your mystery!  Note that 2.4.4 and 2.5 /will/
sort the tests by name again (the code for that has already
been checked in) -- it was very intentional that it did that
before 2.4, and it was a bug that it stopped doing it in 2.4
through 2.4.3.  OTOH, you're the only one so far who noticed :-)

----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 20:46

Message:
Logged In: YES 
user_id=676422

That fixed it!!  Nice catch.

I've been aware for some time of the sensitivity to order 
in the doctests, but it has never been a problem until now, 
and I've been writing programs with doctests since 2.3.  
When I add a test, and it breaks a later test, it has 
always been easy to nail down the piece that changed.

This "behind the scenes" change of test order seems like 
the kind of problem that rarely occurs, but can cause 
serious problems when it does.

Thanks again for an excellent followup.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 20:01

Message:
Logged In: YES 
user_id=31435

DocTestFinder has been changed to sort test names again, in
revs 50882 (on the trunk, for 2.5) and 50886 (on the 2.4
branch, for 2.4.4).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 19:21

Message:
Logged In: YES 
user_id=31435

I think I know what's happening here.  doctest was largely
rewritten for Python 2.4, and it lost a subtle intended
feature:  it used to (<= 2.3) sort tests by name before
running them, but in 2.4 started running them in whatever
order they happen to appear in the hash-code-based module
__dict__.

Changing the namespace in program.py in seemingly random
ways matters because test_suite.py starts with

from program import *

and so everything in program.py's module namespace
"pollutes" test_suite.py's namespace too.  That can change
the order tests run in.  And as I noted before, whether or
not the doctest for _envrcpt() passes or fails depends on
whether or not the doctests for _hello() run before them,
due to side effects on the shared `ci` instance.  Look at
your output carefully, and I expect you'll find that the
order of tests /does/ change depending on crap variable
names you stick in (or remove from) program.py.

If you're with me so far, try changing the end of
doctest.py's DocTestFinder.find() from

    return tests

to

    tests.sort()
    return tests


----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 17:48

Message:
Logged In: YES 
user_id=676422

Some observations:
If I give the test variable a private name, the problem 
goes away.
.   _xyz = 2
If I assign the variable to an object already in memory, 
the problem doesn't go away.
.   xyz = LocalADDRs
It doesn't matter that the test variable is never used. The 
problem persists, even if I add a second statement:
.   xyz = 2
.   if xyz == 2: pass
It doesn't matter where in the module the statement is 
placed, as long as it is module level, not inside a class 
or function.


----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 17:48

Message:
Logged In: YES 
user_id=676422

Some observations:
If I give the test variable a private name, the problem 
goes away.
.   _xyz = 2
If I assign the variable to an object already in memory, 
the problem doesn't go away.
.   xyz = LocalADDRs
It doesn't matter that the test variable is never used. The 
problem persists, even if I add a second statement:
.   xyz = 2
.   if xyz == 2: pass
It doesn't matter where in the module the statement is 
placed, as long as it is module level, not inside a class 
or function.


----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 13:32

Message:
Logged In: YES 
user_id=676422

The failure is not the specific output of doctest, but the 
fact that it *changes* when I add an unrelated variable 
xyz=2 in the module program.py.  I am not able to reproduce 
this failure with Tim's stripped down test_suite.py.

I agree the problem is not in IDLE.  I can do the same from 
a bash command line with
$ python2.4 test_suite.py
but not with 
$ python2.3 test_suite.py


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 12:14

Message:
Logged In: YES 
user_id=31435

I see exactly the same failure akuchling reported, on
Windows using current trunk, running from a command shell
(not IDLE -- didn't try IDLE).  The attached test_suite.py
throws away everything not needed to see the same failure;
in particular, it gets rid of doctest, the logging module,
and most of the functions in test_suite.py.

Reduced to this, I don't see a reason to suspect a Python
bug.  ci.IDrating is initialized to 100, and the

_envrcpt('zz1 at open-mail.org')

line produces (the expected)

CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 101, '']]

if you /leave ci.IDrating alone/.  However, if you do

ci.hello('zz_IP_192.168.0.8_mailout7.simple.tld')

first, that has a (apparently deliberate) side effect of
changing ci.IDrating to None, and then this path is /not/ taken:

# . . Whitelist pass
    if self.IDrating > whitelvl:
        rcptinfo[4] = 101  # ham > 100% to ignore later
spamscore       ###2e
        self.R.append(rcptinfo)

The 101 vanishes from the expected output then, and I get

CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 50, '']]

instead.

That exactly reproduces the only failure Andrew & I have
seen, and appears to be what the code is telling it to do
(via side effects on the shared `ci` instance).

----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 11:22

Message:
Logged In: YES 
user_id=676422

On my Redhat Linux machine, I see the failure in 2.4.1, but 
not in 2.3.4.

Trying to isolate the problem, I've commented out some 
blocks of unrelated code, but I can't get very far with 
this, because many of the deletions make the problem go 
away.  It's as if the problem depends on the exact position 
in memory of the test variable.

I did manage to delete the DNS queries, so now you can run 
the tests without intermittent failures due to DNS timeouts.
I'll keep the latest at http://www.open-
mail.org/test/test_0607nn.tgz

Thanks for your efforts.


----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-27 08:15

Message:
Logged In: YES 
user_id=11375

On a Linux machine, both 2.4.3 and SVN HEAD report 7 tests
passed, one failed.

For both versions, the failure is: 
Failed example:
    _envrcpt('zz1 at open-mail.org')
Expected:
    CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 101, '']]
Got:
    CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 50, '']]


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-26 23:59

Message:
Logged In: YES 
user_id=33168

Can you try with SVN head?  There was an unitialized read
that the doctests could trigger.  It has been fixed. 
Perhaps you are running into that?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529297&group_id=5470

From noreply at sourceforge.net  Fri Jul 28 04:20:00 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 27 Jul 2006 19:20:00 -0700
Subject: [ python-Bugs-1391608 ] missing module names in email package
Message-ID: <E1G6HxI-0007ba-6x@sc8-sf-web3.sourceforge.net>

Bugs item #1391608, was opened at 2005-12-27 21:04
Message generated for change (Comment added) made by bwarsaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1391608&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
>Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Gabriel Genellina (gagenellina)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: missing module names in email package

Initial Comment:
Documentation for modules inside the email package 
lacks reference to module name in title (and body too).
By example, there is no clue in 12.2.1 that the Message 
class being described is contained in the email.Message 
module. Or 12.2.2 doesnt menction that FeedParser, 
HeaderParser and Parser are all classes contained in 
module email.Parser. And so on.

Looking at other similar standard packages (like 
curses) seems that the module name should appear first 
in the title.


----------------------------------------------------------------------

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2006-07-27 22:19

Message:
Logged In: YES 
user_id=12800

This is actually handled in Python 2.5 (email 4.0) much
better, and I don't plan on backporting this to Python 2.4
(email 3.0).

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-04-26 19:16

Message:
Logged In: YES 
user_id=3066

Assigned to the email tsar.  This is complicated by the
dual-naming approach for Python 2.5.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1391608&group_id=5470

From noreply at sourceforge.net  Fri Jul 28 04:30:03 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 27 Jul 2006 19:30:03 -0700
Subject: [ python-Bugs-1513913 ] mimetools message's To field can't be changed
Message-ID: <E1G6I71-00044u-E7@sc8-sf-web3.sourceforge.net>

Bugs item #1513913, was opened at 2006-06-28 06:51
Message generated for change (Settings changed) made by bwarsaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513913&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Albert Strasheim (fullung2)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: mimetools message's To field can't be changed

Initial Comment:
Steps to reproduce:

>>> from email.MIMEText import MIMEText
>>> msg = MIMEText('')
>>> msg['To'] = 'foo at bar.com'
>>> msg['To']
'foo at bar.com'
>>> msg['To'] = 'foo at baz.com'
>>> msg['To']
'foo at bar.com' (should be @baz.com?)

Same problem exists in Python 2.4.3 and Python 2.5b1.

----------------------------------------------------------------------

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2006-07-27 22:29

Message:
Logged In: YES 
user_id=12800

Remember that you can add multiple headers to any message,
so in you're example you've added two To headers.  Also
remember that the dictionary interface will return one of
those multiple headers, but not all of them.  Use
msg.get_all('to') to see them all or del msg['to'] to delete
them all.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513913&group_id=5470

From noreply at sourceforge.net  Fri Jul 28 04:36:36 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 27 Jul 2006 19:36:36 -0700
Subject: [ python-Bugs-1481650 ] Docs on import of email.MIMExxx classes wrong
Message-ID: <E1G6IDM-0008BU-2i@sc8-sf-web5.sourceforge.net>

Bugs item #1481650, was opened at 2006-05-04 03:24
Message generated for change (Comment added) made by bwarsaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481650&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Hugh Gibson (hgibson50)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Docs on import of email.MIMExxx classes wrong

Initial Comment:
http://docs.python.org/lib/node588.html says: 

----------------------
Each of these classes should be imported from a module 
with the same name as the class, from within the email 
package. E.g.: 


import email.MIMEImage.MIMEImage

or 

from email.MIMEText import MIMEText
----------------------

However, here is a Python IDLE session showing that 
the first import format doesn't work:

----------------------
Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 
32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more 
information.

<snip>
    
IDLE 1.1.3      
>>> import email.MIMEImage.MIMEImage

Traceback (most recent call last):
  File "<pyshell#0>", line 1, in -toplevel-
    import email.MIMEImage.MIMEImage
ImportError: No module named MIMEImage
>>> 
----------------------

This method *does* work:

----------------------
>>> import email.MIMEImage
>>> 
----------------------

This got one of my inexperienced programmers tied up 
in knots!

Hugh

----------------------------------------------------------------------

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2006-07-27 22:36

Message:
Logged In: YES 
user_id=12800

r50890


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481650&group_id=5470

From noreply at sourceforge.net  Fri Jul 28 05:09:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 27 Jul 2006 20:09:05 -0700
Subject: [ python-Bugs-1529297 ] unrelated variable messing up doctests
Message-ID: <E1G6Iin-0005pZ-23@sc8-sf-web6.sourceforge.net>

Bugs item #1529297, was opened at 2006-07-26 15:02
Message generated for change (Comment added) made by macquigg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529297&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: David MacQuigg (macquigg)
Assigned to: Nobody/Anonymous (nobody)
Summary: unrelated variable messing up doctests

Initial Comment:
Version 2.5b2 with IDLE 1.2b2 running on Windows XP 
Home, fully updated.

Unpack the attached zip file.
Open program.py, test_suite.py, in separate IDLE 
windows.  
Run test_suite.py.  
  8 passed and 0 failed.
Now add a variable at the top of program.py, any name 
will do.
  xyz = 2
Re-run test_suite.py.  
  7 passed and 1 failed !!

I haven't been able to isolate the problem, but it is 
repeatable.  Taking out blocks of unrelated statements 
changes the behavior.  Feels like a memory allocation 
error, or something strange.


----------------------------------------------------------------------

>Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 20:09

Message:
Logged In: YES 
user_id=676422

I've got a workaround.  I changed the names of my test 
functions to _1connect, _2hello, _3envfrom, _4envrcpt, 
_5addheader, and _6eom.
Could we set the order explicitly, maybe
doctest.order = [connect, hello, envfrom, envrcpt, ... ]


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 18:31

Message:
Logged In: YES 
user_id=31435

> would it be possible to run the tests in the order
> they are written, rather than in alphabetical order?

Sorry, that's impossible.  doctest never sees the source
code, it crawls through module and class __dict__s to find
objects with docstrings, and the order things appear in
those is undefined.

----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 18:03

Message:
Logged In: YES 
user_id=676422

I hope this is not too much to ask, but would it be 
possible to run the tests in the order they are written, 
rather than in alphabetical order?  This isn't a big deal, 
as long as the order is stable, but it would abide by the 
rule of least astonishment. :>)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 17:53

Message:
Logged In: YES 
user_id=31435

Glad it solved your mystery!  Note that 2.4.4 and 2.5 /will/
sort the tests by name again (the code for that has already
been checked in) -- it was very intentional that it did that
before 2.4, and it was a bug that it stopped doing it in 2.4
through 2.4.3.  OTOH, you're the only one so far who noticed :-)

----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 17:46

Message:
Logged In: YES 
user_id=676422

That fixed it!!  Nice catch.

I've been aware for some time of the sensitivity to order 
in the doctests, but it has never been a problem until now, 
and I've been writing programs with doctests since 2.3.  
When I add a test, and it breaks a later test, it has 
always been easy to nail down the piece that changed.

This "behind the scenes" change of test order seems like 
the kind of problem that rarely occurs, but can cause 
serious problems when it does.

Thanks again for an excellent followup.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 17:01

Message:
Logged In: YES 
user_id=31435

DocTestFinder has been changed to sort test names again, in
revs 50882 (on the trunk, for 2.5) and 50886 (on the 2.4
branch, for 2.4.4).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 16:21

Message:
Logged In: YES 
user_id=31435

I think I know what's happening here.  doctest was largely
rewritten for Python 2.4, and it lost a subtle intended
feature:  it used to (<= 2.3) sort tests by name before
running them, but in 2.4 started running them in whatever
order they happen to appear in the hash-code-based module
__dict__.

Changing the namespace in program.py in seemingly random
ways matters because test_suite.py starts with

from program import *

and so everything in program.py's module namespace
"pollutes" test_suite.py's namespace too.  That can change
the order tests run in.  And as I noted before, whether or
not the doctest for _envrcpt() passes or fails depends on
whether or not the doctests for _hello() run before them,
due to side effects on the shared `ci` instance.  Look at
your output carefully, and I expect you'll find that the
order of tests /does/ change depending on crap variable
names you stick in (or remove from) program.py.

If you're with me so far, try changing the end of
doctest.py's DocTestFinder.find() from

    return tests

to

    tests.sort()
    return tests


----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 14:48

Message:
Logged In: YES 
user_id=676422

Some observations:
If I give the test variable a private name, the problem 
goes away.
.   _xyz = 2
If I assign the variable to an object already in memory, 
the problem doesn't go away.
.   xyz = LocalADDRs
It doesn't matter that the test variable is never used. The 
problem persists, even if I add a second statement:
.   xyz = 2
.   if xyz == 2: pass
It doesn't matter where in the module the statement is 
placed, as long as it is module level, not inside a class 
or function.


----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 14:48

Message:
Logged In: YES 
user_id=676422

Some observations:
If I give the test variable a private name, the problem 
goes away.
.   _xyz = 2
If I assign the variable to an object already in memory, 
the problem doesn't go away.
.   xyz = LocalADDRs
It doesn't matter that the test variable is never used. The 
problem persists, even if I add a second statement:
.   xyz = 2
.   if xyz == 2: pass
It doesn't matter where in the module the statement is 
placed, as long as it is module level, not inside a class 
or function.


----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 10:32

Message:
Logged In: YES 
user_id=676422

The failure is not the specific output of doctest, but the 
fact that it *changes* when I add an unrelated variable 
xyz=2 in the module program.py.  I am not able to reproduce 
this failure with Tim's stripped down test_suite.py.

I agree the problem is not in IDLE.  I can do the same from 
a bash command line with
$ python2.4 test_suite.py
but not with 
$ python2.3 test_suite.py


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 09:14

Message:
Logged In: YES 
user_id=31435

I see exactly the same failure akuchling reported, on
Windows using current trunk, running from a command shell
(not IDLE -- didn't try IDLE).  The attached test_suite.py
throws away everything not needed to see the same failure;
in particular, it gets rid of doctest, the logging module,
and most of the functions in test_suite.py.

Reduced to this, I don't see a reason to suspect a Python
bug.  ci.IDrating is initialized to 100, and the

_envrcpt('zz1 at open-mail.org')

line produces (the expected)

CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 101, '']]

if you /leave ci.IDrating alone/.  However, if you do

ci.hello('zz_IP_192.168.0.8_mailout7.simple.tld')

first, that has a (apparently deliberate) side effect of
changing ci.IDrating to None, and then this path is /not/ taken:

# . . Whitelist pass
    if self.IDrating > whitelvl:
        rcptinfo[4] = 101  # ham > 100% to ignore later
spamscore       ###2e
        self.R.append(rcptinfo)

The 101 vanishes from the expected output then, and I get

CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 50, '']]

instead.

That exactly reproduces the only failure Andrew & I have
seen, and appears to be what the code is telling it to do
(via side effects on the shared `ci` instance).

----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 08:22

Message:
Logged In: YES 
user_id=676422

On my Redhat Linux machine, I see the failure in 2.4.1, but 
not in 2.3.4.

Trying to isolate the problem, I've commented out some 
blocks of unrelated code, but I can't get very far with 
this, because many of the deletions make the problem go 
away.  It's as if the problem depends on the exact position 
in memory of the test variable.

I did manage to delete the DNS queries, so now you can run 
the tests without intermittent failures due to DNS timeouts.
I'll keep the latest at http://www.open-
mail.org/test/test_0607nn.tgz

Thanks for your efforts.


----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-27 05:15

Message:
Logged In: YES 
user_id=11375

On a Linux machine, both 2.4.3 and SVN HEAD report 7 tests
passed, one failed.

For both versions, the failure is: 
Failed example:
    _envrcpt('zz1 at open-mail.org')
Expected:
    CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 101, '']]
Got:
    CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 50, '']]


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-26 20:59

Message:
Logged In: YES 
user_id=33168

Can you try with SVN head?  There was an unitialized read
that the doctests could trigger.  It has been fixed. 
Perhaps you are running into that?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529297&group_id=5470

From noreply at sourceforge.net  Fri Jul 28 05:19:45 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 27 Jul 2006 20:19:45 -0700
Subject: [ python-Bugs-1414018 ] email.Utils.py: UnicodeError in RFC2322 header
Message-ID: <E1G6It7-0003bP-Lf@sc8-sf-web3.sourceforge.net>

Bugs item #1414018, was opened at 2006-01-24 15:19
Message generated for change (Comment added) made by bwarsaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1414018&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: A. Sagawa (qbin)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email.Utils.py: UnicodeError in RFC2322 header

Initial Comment:
Description:
collapse_rfc2231_value does not handle UnicodeError
exception. Therefore a header like this one can cause
UnicodeError in attempting unicode conversion.

---
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Disposition: attachment;
 filename*=iso-2022-jp''%1B%24BJs9p%3Dq%2D%21%1B%28B%2Etxt
---

Test script:
---
#! /usr/bin/env python
import sys
import email

msg = email.message_from_file(sys.stdin)
for part in msg.walk():
  print part.get_params()
  print part.get_filename()
---
run
% env LANG=ja_JP.eucJP ./test.py < attached_sample.eml

Background:
Character 0x2d21 is invalid in JIS X0208 but defined in
CP932 (Shift_JIS's superset by Microsoft).  Conversion
between Shift_JIS and ISO-2022-JP are computable
because both of them based on JIS X0208. So sometimes
CP932 characters appear in ISO-2022-JP encoded string,
typically produced by Windows MUA.
But Python's "ISO-2022-JP" means *pure* JIS X0208, thus
conversion is failed.

Workaround:
Convert to fallback_charset and/or skip invalid character.

----------------------------------------------------------------------

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2006-07-27 23:19

Message:
Logged In: YES 
user_id=12800

r50894 for Python 2.4/email 3.0.  This is already fixed in
Python 2.5/email 4.0


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1414018&group_id=5470

From noreply at sourceforge.net  Wed Jul 26 09:05:08 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 26 Jul 2006 00:05:08 -0700
Subject: [ python-Bugs-1528802 ] Turkish Character
Message-ID: <E1G5dS8-0003vK-3U@sc8-sf-web3.sourceforge.net>

Bugs item #1528802, was opened at 2006-07-26 10: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=1528802&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ahmet Bi?kinler (ahmetbiskinler)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Turkish Character

Initial Comment:
>>> print "May?s".upper()
>>> MAY?S
>>> import locale
>>> locale.setlocale(locale.LC_ALL,'Turkish_Turkey.1254')
>>> print "May?s".upper()
>>> MAY?S

>>> print "???i???".upper()
>>> ???I???


MAY?S     should be MAYIS
???I???   should be ??????I

but 
>>> "May?s".upper()
>>> "MAYIS"

is right





----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528802&group_id=5470

From noreply at sourceforge.net  Fri Jul 28 05:34:21 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 27 Jul 2006 20:34:21 -0700
Subject: [ python-Bugs-1529297 ] unrelated variable messing up doctests
Message-ID: <E1G6J7F-0002pL-Jb@sc8-sf-web5.sourceforge.net>

Bugs item #1529297, was opened at 2006-07-26 18: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=1529297&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: David MacQuigg (macquigg)
Assigned to: Nobody/Anonymous (nobody)
Summary: unrelated variable messing up doctests

Initial Comment:
Version 2.5b2 with IDLE 1.2b2 running on Windows XP 
Home, fully updated.

Unpack the attached zip file.
Open program.py, test_suite.py, in separate IDLE 
windows.  
Run test_suite.py.  
  8 passed and 0 failed.
Now add a variable at the top of program.py, any name 
will do.
  xyz = 2
Re-run test_suite.py.  
  7 passed and 1 failed !!

I haven't been able to isolate the problem, but it is 
repeatable.  Taking out blocks of unrelated statements 
changes the behavior.  Feels like a memory allocation 
error, or something strange.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-07-27 23:34

Message:
Logged In: YES 
user_id=31435

Renaming the tests isn't a workaround in the absence of
sorting:  nothing is guaranteed about __dict__ traversal
order, because nothing is defined about string hash codes.

You could suggest adding a way to force order as a new
feature request, but I won't look at it.  It should simply
never be necessary for /reasonable/ tests.  And, yes, that
means I think it's unreasonable to write tests that rely on
side effects across distinct tests occurring in a specific
order :-)

At this point I suggest you stop writing doctests in
function docstrings and use the newer doctest /file/
facilities instead.  Then you can have a file full of tests
run in exactly the order you want -- although it's still
dubious practice to rely on side effects across distinct
sections of tests.

If you have to force order across function docstring tests,
you'll have to build your doctest driver out of lower-level
doctest components.  That means, e.g., creating your own
instance of DocTestFinder, forcing the test order you want
in the list of test objects it creates, and feeding them
into a DocTestRunner instance.

----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 23:09

Message:
Logged In: YES 
user_id=676422

I've got a workaround.  I changed the names of my test 
functions to _1connect, _2hello, _3envfrom, _4envrcpt, 
_5addheader, and _6eom.
Could we set the order explicitly, maybe
doctest.order = [connect, hello, envfrom, envrcpt, ... ]


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 21:31

Message:
Logged In: YES 
user_id=31435

> would it be possible to run the tests in the order
> they are written, rather than in alphabetical order?

Sorry, that's impossible.  doctest never sees the source
code, it crawls through module and class __dict__s to find
objects with docstrings, and the order things appear in
those is undefined.

----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 21:03

Message:
Logged In: YES 
user_id=676422

I hope this is not too much to ask, but would it be 
possible to run the tests in the order they are written, 
rather than in alphabetical order?  This isn't a big deal, 
as long as the order is stable, but it would abide by the 
rule of least astonishment. :>)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 20:53

Message:
Logged In: YES 
user_id=31435

Glad it solved your mystery!  Note that 2.4.4 and 2.5 /will/
sort the tests by name again (the code for that has already
been checked in) -- it was very intentional that it did that
before 2.4, and it was a bug that it stopped doing it in 2.4
through 2.4.3.  OTOH, you're the only one so far who noticed :-)

----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 20:46

Message:
Logged In: YES 
user_id=676422

That fixed it!!  Nice catch.

I've been aware for some time of the sensitivity to order 
in the doctests, but it has never been a problem until now, 
and I've been writing programs with doctests since 2.3.  
When I add a test, and it breaks a later test, it has 
always been easy to nail down the piece that changed.

This "behind the scenes" change of test order seems like 
the kind of problem that rarely occurs, but can cause 
serious problems when it does.

Thanks again for an excellent followup.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 20:01

Message:
Logged In: YES 
user_id=31435

DocTestFinder has been changed to sort test names again, in
revs 50882 (on the trunk, for 2.5) and 50886 (on the 2.4
branch, for 2.4.4).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 19:21

Message:
Logged In: YES 
user_id=31435

I think I know what's happening here.  doctest was largely
rewritten for Python 2.4, and it lost a subtle intended
feature:  it used to (<= 2.3) sort tests by name before
running them, but in 2.4 started running them in whatever
order they happen to appear in the hash-code-based module
__dict__.

Changing the namespace in program.py in seemingly random
ways matters because test_suite.py starts with

from program import *

and so everything in program.py's module namespace
"pollutes" test_suite.py's namespace too.  That can change
the order tests run in.  And as I noted before, whether or
not the doctest for _envrcpt() passes or fails depends on
whether or not the doctests for _hello() run before them,
due to side effects on the shared `ci` instance.  Look at
your output carefully, and I expect you'll find that the
order of tests /does/ change depending on crap variable
names you stick in (or remove from) program.py.

If you're with me so far, try changing the end of
doctest.py's DocTestFinder.find() from

    return tests

to

    tests.sort()
    return tests


----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 17:48

Message:
Logged In: YES 
user_id=676422

Some observations:
If I give the test variable a private name, the problem 
goes away.
.   _xyz = 2
If I assign the variable to an object already in memory, 
the problem doesn't go away.
.   xyz = LocalADDRs
It doesn't matter that the test variable is never used. The 
problem persists, even if I add a second statement:
.   xyz = 2
.   if xyz == 2: pass
It doesn't matter where in the module the statement is 
placed, as long as it is module level, not inside a class 
or function.


----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 17:48

Message:
Logged In: YES 
user_id=676422

Some observations:
If I give the test variable a private name, the problem 
goes away.
.   _xyz = 2
If I assign the variable to an object already in memory, 
the problem doesn't go away.
.   xyz = LocalADDRs
It doesn't matter that the test variable is never used. The 
problem persists, even if I add a second statement:
.   xyz = 2
.   if xyz == 2: pass
It doesn't matter where in the module the statement is 
placed, as long as it is module level, not inside a class 
or function.


----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 13:32

Message:
Logged In: YES 
user_id=676422

The failure is not the specific output of doctest, but the 
fact that it *changes* when I add an unrelated variable 
xyz=2 in the module program.py.  I am not able to reproduce 
this failure with Tim's stripped down test_suite.py.

I agree the problem is not in IDLE.  I can do the same from 
a bash command line with
$ python2.4 test_suite.py
but not with 
$ python2.3 test_suite.py


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 12:14

Message:
Logged In: YES 
user_id=31435

I see exactly the same failure akuchling reported, on
Windows using current trunk, running from a command shell
(not IDLE -- didn't try IDLE).  The attached test_suite.py
throws away everything not needed to see the same failure;
in particular, it gets rid of doctest, the logging module,
and most of the functions in test_suite.py.

Reduced to this, I don't see a reason to suspect a Python
bug.  ci.IDrating is initialized to 100, and the

_envrcpt('zz1 at open-mail.org')

line produces (the expected)

CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 101, '']]

if you /leave ci.IDrating alone/.  However, if you do

ci.hello('zz_IP_192.168.0.8_mailout7.simple.tld')

first, that has a (apparently deliberate) side effect of
changing ci.IDrating to None, and then this path is /not/ taken:

# . . Whitelist pass
    if self.IDrating > whitelvl:
        rcptinfo[4] = 101  # ham > 100% to ignore later
spamscore       ###2e
        self.R.append(rcptinfo)

The 101 vanishes from the expected output then, and I get

CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 50, '']]

instead.

That exactly reproduces the only failure Andrew & I have
seen, and appears to be what the code is telling it to do
(via side effects on the shared `ci` instance).

----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 11:22

Message:
Logged In: YES 
user_id=676422

On my Redhat Linux machine, I see the failure in 2.4.1, but 
not in 2.3.4.

Trying to isolate the problem, I've commented out some 
blocks of unrelated code, but I can't get very far with 
this, because many of the deletions make the problem go 
away.  It's as if the problem depends on the exact position 
in memory of the test variable.

I did manage to delete the DNS queries, so now you can run 
the tests without intermittent failures due to DNS timeouts.
I'll keep the latest at http://www.open-
mail.org/test/test_0607nn.tgz

Thanks for your efforts.


----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-27 08:15

Message:
Logged In: YES 
user_id=11375

On a Linux machine, both 2.4.3 and SVN HEAD report 7 tests
passed, one failed.

For both versions, the failure is: 
Failed example:
    _envrcpt('zz1 at open-mail.org')
Expected:
    CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 101, '']]
Got:
    CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 50, '']]


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-26 23:59

Message:
Logged In: YES 
user_id=33168

Can you try with SVN head?  There was an unitialized read
that the doctests could trigger.  It has been fixed. 
Perhaps you are running into that?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529297&group_id=5470

From noreply at sourceforge.net  Fri Jul 28 06:35:49 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 27 Jul 2006 21:35:49 -0700
Subject: [ python-Bugs-1529998 ] bz2 lib missing from source distribution
Message-ID: <E1G6K4j-0006OA-7Q@sc8-sf-web6.sourceforge.net>

Bugs item #1529998, was opened at 2006-07-27 14:45
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529998&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
>Group: 3rd Party
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: james yoo (jyoo_abn)
Assigned to: Nobody/Anonymous (nobody)
Summary: bz2 lib missing from source distribution

Initial Comment:
python 2.4.3

got an import error trying to test PySqlite 

"No module named bz2"

checked my python dirs and yep, no bz2... I thought
that the bz2 module was part of the standard distribution?

checked the python source dir (python-2.4.3.tar.gz) and
no bz2.py in the Lib dir.

what gives?



----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-27 21:35

Message:
Logged In: YES 
user_id=33168

You'll need to ensure the bz2 dev headers and libraries are
installed to build/use the bz2 module in python.

----------------------------------------------------------------------

Comment By: james yoo (jyoo_abn)
Date: 2006-07-27 15:30

Message:
Logged In: YES 
user_id=1562754

actually sorry for the poor assumptions regarding the
existence of a bz2.py file... realize that there is a a
bz2module.c file and that my config.log had a bunch of fatal
ld errors... 

fyi: this is on sunOS 5.8, gcc-3.4.3..

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529998&group_id=5470

From noreply at sourceforge.net  Fri Jul 28 06:37:09 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 27 Jul 2006 21:37:09 -0700
Subject: [ python-Bugs-1529297 ] unrelated variable messing up doctests
Message-ID: <E1G6K61-0000gC-KO@sc8-sf-web6.sourceforge.net>

Bugs item #1529297, was opened at 2006-07-26 15:02
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529297&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: David MacQuigg (macquigg)
Assigned to: Nobody/Anonymous (nobody)
Summary: unrelated variable messing up doctests

Initial Comment:
Version 2.5b2 with IDLE 1.2b2 running on Windows XP 
Home, fully updated.

Unpack the attached zip file.
Open program.py, test_suite.py, in separate IDLE 
windows.  
Run test_suite.py.  
  8 passed and 0 failed.
Now add a variable at the top of program.py, any name 
will do.
  xyz = 2
Re-run test_suite.py.  
  7 passed and 1 failed !!

I haven't been able to isolate the problem, but it is 
repeatable.  Taking out blocks of unrelated statements 
changes the behavior.  Feels like a memory allocation 
error, or something strange.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-27 21:37

Message:
Logged In: YES 
user_id=33168

Closing again since the bug has been fixed.  If you want a
feature request, you can open a new one.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 20:34

Message:
Logged In: YES 
user_id=31435

Renaming the tests isn't a workaround in the absence of
sorting:  nothing is guaranteed about __dict__ traversal
order, because nothing is defined about string hash codes.

You could suggest adding a way to force order as a new
feature request, but I won't look at it.  It should simply
never be necessary for /reasonable/ tests.  And, yes, that
means I think it's unreasonable to write tests that rely on
side effects across distinct tests occurring in a specific
order :-)

At this point I suggest you stop writing doctests in
function docstrings and use the newer doctest /file/
facilities instead.  Then you can have a file full of tests
run in exactly the order you want -- although it's still
dubious practice to rely on side effects across distinct
sections of tests.

If you have to force order across function docstring tests,
you'll have to build your doctest driver out of lower-level
doctest components.  That means, e.g., creating your own
instance of DocTestFinder, forcing the test order you want
in the list of test objects it creates, and feeding them
into a DocTestRunner instance.

----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 20:09

Message:
Logged In: YES 
user_id=676422

I've got a workaround.  I changed the names of my test 
functions to _1connect, _2hello, _3envfrom, _4envrcpt, 
_5addheader, and _6eom.
Could we set the order explicitly, maybe
doctest.order = [connect, hello, envfrom, envrcpt, ... ]


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 18:31

Message:
Logged In: YES 
user_id=31435

> would it be possible to run the tests in the order
> they are written, rather than in alphabetical order?

Sorry, that's impossible.  doctest never sees the source
code, it crawls through module and class __dict__s to find
objects with docstrings, and the order things appear in
those is undefined.

----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 18:03

Message:
Logged In: YES 
user_id=676422

I hope this is not too much to ask, but would it be 
possible to run the tests in the order they are written, 
rather than in alphabetical order?  This isn't a big deal, 
as long as the order is stable, but it would abide by the 
rule of least astonishment. :>)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 17:53

Message:
Logged In: YES 
user_id=31435

Glad it solved your mystery!  Note that 2.4.4 and 2.5 /will/
sort the tests by name again (the code for that has already
been checked in) -- it was very intentional that it did that
before 2.4, and it was a bug that it stopped doing it in 2.4
through 2.4.3.  OTOH, you're the only one so far who noticed :-)

----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 17:46

Message:
Logged In: YES 
user_id=676422

That fixed it!!  Nice catch.

I've been aware for some time of the sensitivity to order 
in the doctests, but it has never been a problem until now, 
and I've been writing programs with doctests since 2.3.  
When I add a test, and it breaks a later test, it has 
always been easy to nail down the piece that changed.

This "behind the scenes" change of test order seems like 
the kind of problem that rarely occurs, but can cause 
serious problems when it does.

Thanks again for an excellent followup.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 17:01

Message:
Logged In: YES 
user_id=31435

DocTestFinder has been changed to sort test names again, in
revs 50882 (on the trunk, for 2.5) and 50886 (on the 2.4
branch, for 2.4.4).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 16:21

Message:
Logged In: YES 
user_id=31435

I think I know what's happening here.  doctest was largely
rewritten for Python 2.4, and it lost a subtle intended
feature:  it used to (<= 2.3) sort tests by name before
running them, but in 2.4 started running them in whatever
order they happen to appear in the hash-code-based module
__dict__.

Changing the namespace in program.py in seemingly random
ways matters because test_suite.py starts with

from program import *

and so everything in program.py's module namespace
"pollutes" test_suite.py's namespace too.  That can change
the order tests run in.  And as I noted before, whether or
not the doctest for _envrcpt() passes or fails depends on
whether or not the doctests for _hello() run before them,
due to side effects on the shared `ci` instance.  Look at
your output carefully, and I expect you'll find that the
order of tests /does/ change depending on crap variable
names you stick in (or remove from) program.py.

If you're with me so far, try changing the end of
doctest.py's DocTestFinder.find() from

    return tests

to

    tests.sort()
    return tests


----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 14:48

Message:
Logged In: YES 
user_id=676422

Some observations:
If I give the test variable a private name, the problem 
goes away.
.   _xyz = 2
If I assign the variable to an object already in memory, 
the problem doesn't go away.
.   xyz = LocalADDRs
It doesn't matter that the test variable is never used. The 
problem persists, even if I add a second statement:
.   xyz = 2
.   if xyz == 2: pass
It doesn't matter where in the module the statement is 
placed, as long as it is module level, not inside a class 
or function.


----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 14:48

Message:
Logged In: YES 
user_id=676422

Some observations:
If I give the test variable a private name, the problem 
goes away.
.   _xyz = 2
If I assign the variable to an object already in memory, 
the problem doesn't go away.
.   xyz = LocalADDRs
It doesn't matter that the test variable is never used. The 
problem persists, even if I add a second statement:
.   xyz = 2
.   if xyz == 2: pass
It doesn't matter where in the module the statement is 
placed, as long as it is module level, not inside a class 
or function.


----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 10:32

Message:
Logged In: YES 
user_id=676422

The failure is not the specific output of doctest, but the 
fact that it *changes* when I add an unrelated variable 
xyz=2 in the module program.py.  I am not able to reproduce 
this failure with Tim's stripped down test_suite.py.

I agree the problem is not in IDLE.  I can do the same from 
a bash command line with
$ python2.4 test_suite.py
but not with 
$ python2.3 test_suite.py


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 09:14

Message:
Logged In: YES 
user_id=31435

I see exactly the same failure akuchling reported, on
Windows using current trunk, running from a command shell
(not IDLE -- didn't try IDLE).  The attached test_suite.py
throws away everything not needed to see the same failure;
in particular, it gets rid of doctest, the logging module,
and most of the functions in test_suite.py.

Reduced to this, I don't see a reason to suspect a Python
bug.  ci.IDrating is initialized to 100, and the

_envrcpt('zz1 at open-mail.org')

line produces (the expected)

CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 101, '']]

if you /leave ci.IDrating alone/.  However, if you do

ci.hello('zz_IP_192.168.0.8_mailout7.simple.tld')

first, that has a (apparently deliberate) side effect of
changing ci.IDrating to None, and then this path is /not/ taken:

# . . Whitelist pass
    if self.IDrating > whitelvl:
        rcptinfo[4] = 101  # ham > 100% to ignore later
spamscore       ###2e
        self.R.append(rcptinfo)

The 101 vanishes from the expected output then, and I get

CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 50, '']]

instead.

That exactly reproduces the only failure Andrew & I have
seen, and appears to be what the code is telling it to do
(via side effects on the shared `ci` instance).

----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 08:22

Message:
Logged In: YES 
user_id=676422

On my Redhat Linux machine, I see the failure in 2.4.1, but 
not in 2.3.4.

Trying to isolate the problem, I've commented out some 
blocks of unrelated code, but I can't get very far with 
this, because many of the deletions make the problem go 
away.  It's as if the problem depends on the exact position 
in memory of the test variable.

I did manage to delete the DNS queries, so now you can run 
the tests without intermittent failures due to DNS timeouts.
I'll keep the latest at http://www.open-
mail.org/test/test_0607nn.tgz

Thanks for your efforts.


----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-27 05:15

Message:
Logged In: YES 
user_id=11375

On a Linux machine, both 2.4.3 and SVN HEAD report 7 tests
passed, one failed.

For both versions, the failure is: 
Failed example:
    _envrcpt('zz1 at open-mail.org')
Expected:
    CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 101, '']]
Got:
    CONTINUE [['zz1 at open-mail.org', 50, 2, 75, 50, '']]


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-26 20:59

Message:
Logged In: YES 
user_id=33168

Can you try with SVN head?  There was an unitialized read
that the doctests could trigger.  It has been fixed. 
Perhaps you are running into that?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529297&group_id=5470

From noreply at sourceforge.net  Fri Jul 28 06:53:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 27 Jul 2006 21:53:24 -0700
Subject: [ python-Bugs-1529871 ] distutils regression related to
	Distribution.run_command
Message-ID: <E1G6KLk-0000Tp-W6@sc8-sf-web5.sourceforge.net>

Bugs item #1529871, was opened at 2006-07-27 17:49
Message generated for change (Comment added) made by pje
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529871&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 6
Submitted By: Collin Winter (collinwinter)
Assigned to: Phillip J. Eby (pje)
Summary: distutils regression related to Distribution.run_command

Initial Comment:
The following used to work in Python 2.4.x but fails
under Python 2.5:

>>> import setuptools
>>> import distutils.core
>>> distutils.core._setup_stop_after = 'config'
>>> 
>>> import setup
>>> setup.dist.run_command('test')

Where setup.dist is an instance of
distutils.core.Distribution (which setuptools replaces
with setuptools.dist.Distribution).

Under Python 2.4.x, this code would execute setuptools'
test command. Under Python 2.5b2 (as of r50855), this
code results in the following exception:

/opt/dev/python/2.5/lib/python2.5/distutils/dist.py:263:
UserWarning: Unknown distribution option: 'test_suite'
  warnings.warn(msg)
Traceback (most recent call last):
  File "test.py", line 8, in <module>
    setup.dist.run_command('test')
  File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 992, in run_command
    cmd_obj = self.get_command_obj(command)
  File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 868, in get_command_obj
    klass = self.get_command_class(command)
  File
"/opt/dev/python/2.5/lib/python2.5/site-packages/setuptools/dist.py",
line 357, in get_command_class
    return _Distribution.get_command_class(self, command)
  File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 851, in get_command_class
    raise DistutilsModuleError("invalid command '%s'" %
command)
distutils.errors.DistutilsModuleError: invalid command
'test'

I'd greatly appreciate it if this regression could be
fixed before Python 2.5 is released.

----------------------------------------------------------------------

>Comment By: Phillip J. Eby (pje)
Date: 2006-07-28 04:53

Message:
Logged In: YES 
user_id=56214

Um, why is there a py2.4 egg on your python 2.5 path?

Setuptools configures itself according to the Python version
it is built with, so a 2.4 egg is not going to be correctly
configured for 2.5.  I don't know if this is related to your
problem or not, but I was unable to reproduce your problem
with a setuptools 0.7a1 checkout.  I was only able to
reproduce it with setuptools 0.6.


----------------------------------------------------------------------

Comment By: Collin Winter (collinwinter)
Date: 2006-07-27 22:12

Message:
Logged In: YES 
user_id=1344176

I've tried using setuptools 0.7a1 in conjunction with Python
2.5b2 (r50877), and the problem still exists. setuptools'
extension commands still do not work (tested: rotate, alias,
egg_info, bdist_egg, test), that is, 'python2.5 setup.py
test' still fails with "error: invalid command 'test'".

Also, the code snippet in the bug report does not work. I am
sure Python is picking up setuptools 0.7a1 because the path
/opt/dev/python/2.5/lib/python2.5/site-packages/setuptools-0.7a1dev_r50755-py2.4.egg/setuptools/dist.py
appears in the traceback.

----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2006-07-27 21:13

Message:
Logged In: YES 
user_id=56214

Problem source confirmed: reverting the PEP 302 breakage of
r46372 (need-for-speed import cache hack) fixes the problem.

setuptools 0.7a1 doesn't show any problems because it uses
2.5's "pkgutil" module if possible, and r46372 patches
pkgutil in a way that masks the problem, at least as far as
setuptools is concerned, for this one specific feature. 
(Other code in setuptools is affected in both 0.6 *and* 0.7,
and will require further workaround code to be written.)



----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2006-07-27 18:35

Message:
Logged In: YES 
user_id=56214

I can't reproduce this using setuptools 0.7a1 and the Python
2.5 trunk.  Please note that setuptools 0.6 does *not*
support Python 2.5; there were numerous changes needed and
there may still be additional changes needed.  Please try
using setuptools 0.7a1 and let me know what you find out. 
Thanks.


----------------------------------------------------------------------

Comment By: Collin Winter (collinwinter)
Date: 2006-07-27 18:34

Message:
Logged In: YES 
user_id=1344176

Further testing reveals that all of setuptools' extension
commands (tested: egg_info, bdist_egg, test, rotate, alias)
are broken under Python 2.5b2, even when called from the
command line, like so:

$ python2.5 setup.py egg_info

This produces an "error: invalid command: 'egg_info'" message.

----------------------------------------------------------------------

Comment By: Collin Winter (collinwinter)
Date: 2006-07-27 18:18

Message:
Logged In: YES 
user_id=1344176

Forgot to mention: I've tried this with setuptools 0.6a9 and
0.6c1. Python 2.4.x (2.4.1, 2.4.2 and 2.4.3 tested) with
both setuptools version worked fine, where Python 2.5b2
fails with both.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-27 18:03

Message:
Logged In: YES 
user_id=11375

Assigned to Phillip.  I don't see any obviously relevant
changes to distutils/dist.py, but maybe this problems stems
from changes to some other module.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529871&group_id=5470

From noreply at sourceforge.net  Fri Jul 28 06:53:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 27 Jul 2006 21:53:23 -0700
Subject: [ python-Bugs-1529269 ] Python 2.5b2 fails to build on Solaris 10
	(GCC Compiler)
Message-ID: <E1G6KLj-0008B1-29@sc8-sf-web3.sourceforge.net>

Bugs item #1529269, was opened at 2006-07-26 14:17
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529269&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido Ostkamp (ostkamp)
Assigned to: Thomas Heller (theller)
Summary: Python 2.5b2 fails to build on Solaris 10 (GCC Compiler)

Initial Comment:
Hello,

as promised here is the second report because of
problems with building Python 2.5b2 on Solaris 10
(Sparc). I have been using the GCC this time.

These are the problems (for full logs please see
attachments):

building '_ctypes' extension
gcc -shared
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules
/_ctypes/_ctypes.o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/
Modules/_ctypes/callbacks.o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Pyth
on-2.5b2/Modules/_ctypes/callproc.o
build/temp.solaris-2.10-sun4us-2.5/home/ostk
amp/Python-2.5b2/Modules/_ctypes/stgdict.o
build/temp.solaris-2.10-sun4us-2.5/ho
me/ostkamp/Python-2.5b2/Modules/_ctypes/cfield.o
build/temp.solaris-2.10-sun4us-
2.5/home/ostkamp/Python-2.5b2/Modules/_ctypes/malloc_closure.o
build/temp.solari
s-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/prep_cif.
o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules/_ctypes/l
ibffi/src/sparc/ffi.o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5
b2/Modules/_ctypes/libffi/src/sparc/v8.o
build/temp.solaris-2.10-sun4us-2.5/home
/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v9.o
-o build/lib.solaris
-2.10-sun4us-2.5/_ctypes.so
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol <unknow
n>: offset 0xfeedcca5 is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol <unknow
n>: offset 0xfeedccab is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol <unknow
n>: offset 0xfeedccaf is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol <unknow
n>: offset 0xfeedccb3 is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol <unknow
n>: offset 0xfeeeae06 is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol <unknow
n>: offset 0xfeeecaf6 is non-aligned
collect2: ld returned 1 exit status

building '_curses' extension
gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -I. -I/
home/ostkamp/Python-2.5b2/./Include -I./Include -I.
-I/home/ostkamp/Python-2.5b2
/Include -I/home/ostkamp/Python-2.5b2 -c
/home/ostkamp/Python-2.5b2/Modules/_cur
sesmodule.c -o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modu
les/_cursesmodule.o
/home/ostkamp/Python-2.5b2/Modules/_cursesmodule.c: In
function `PyCursesWindow_
GetStr':
/home/ostkamp/Python-2.5b2/Modules/_cursesmodule.c:822:
warning: implicit declar
ation of function `mvwgetnstr'
gcc -shared
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules
/_cursesmodule.o -lcurses -ltermcap -o
build/lib.solaris-2.10-sun4us-2.5/_curses
.so
*** WARNING: renaming "_curses" since importing it
failed: ld.so.1: python: fata
l: relocation error: file
build/lib.solaris-2.10-sun4us-2.5/_curses.so: symbol m
vwgetnstr: referenced symbol not found
building '_curses_panel' extension
gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -I. -I/
home/ostkamp/Python-2.5b2/./Include -I./Include -I.
-I/home/ostkamp/Python-2.5b2
/Include -I/home/ostkamp/Python-2.5b2 -c
/home/ostkamp/Python-2.5b2/Modules/_cur
ses_panel.c -o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modu
les/_curses_panel.o
gcc -shared
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules
/_curses_panel.o -lpanel -lcurses -ltermcap -o
build/lib.solaris-2.10-sun4us-2.5
/_curses_panel.so
*** WARNING: renaming "_curses_panel" since importing
it failed: No module named
 _curses
running build_scripts

Regards,

Guido

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-27 21:53

Message:
Logged In: YES 
user_id=33168

Hmmm, I thought this was the report from using sun studio
compiler.  Guido, are you sure you did a make clean in
between using different compilers?

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2006-07-27 10:23

Message:
Logged In: YES 
user_id=11105

I don't have access to a solaris 10 box myself (only the
sourceforge solaris 9 sparc machine).  I'm wondering why the
solaris 10 machine running the Python buildbot does not
report any problems, could it be that this is because it run
configure with '--with-pydebug' ?

Guido, can you please try this?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-26 20:21

Message:
Logged In: YES 
user_id=33168

Thomas can you check out the ctypes problems?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529269&group_id=5470

From noreply at sourceforge.net  Thu Jul 27 06:40:51 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 26 Jul 2006 21:40:51 -0700
Subject: [ python-Bugs-1191458 ] [AST] Failing tests
Message-ID: <E1G5xg3-0006CR-Ew@sc8-sf-web5.sourceforge.net>

Bugs item #1191458, was opened at 2005-04-27 20:30
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191458&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: AST
Status: Open
Resolution: None
>Priority: 9
Submitted By: Brett Cannon (bcannon)
Assigned to: Jeremy Hylton (jhylton)
Summary: [AST] Failing tests

Initial Comment:
This tracker item is to be used to keep track of what
tests are currently failing on the AST branch.  This is
somewhat important sinced there are so many failures it
can be hard to detect if a change fixed what it was
supposed to or actually managed to break more code.

When posting follow-ups of fixed tests, please re-list
the currently failing tests so as to make it simple to
reference the current state of things.

So, the current offenders are (from a straight
``regrtest.py`` run on my OS X box, which always has
test__locale fail so I removed it)::

    test_compile test_cookielib test_dis test_doctest
    test_future test_genexps test_inspect
test_itertools test_new
    test_peepholer test_scope test_socket test_sort
test_subprocess
    test_symtable test_syntax test_trace test_traceback
test_warnings
    test_zipfile

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2006-04-03 08:31

Message:
Logged In: YES 
user_id=31392

Just wanted to note that I have fixes for the failing tests
on my laptop.  Need to sync with the current trunk before I
can check in.


----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2005-10-25 15:03

Message:
Logged In: YES 
user_id=357491

Yep, all tests pass, so that just leaves the test_trace
tests that are currently commented out.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2005-10-23 21:51

Message:
Logged In: YES 
user_id=35752

I believe the only remaining broken tests are the ones
commented out in test_trace.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2005-10-07 11:46

Message:
Logged In: YES 
user_id=31392

test_dis update:

Fixed one of two failing tests.  test_dis() was easy. 
test_bug_708901() is harder.  The current AST only stores
line numbers for statements.  The test case is checking that
the lnotab can assign a single statement multiple line
numbers; in this case, the statement spans multiple lines
and the disassembled code should reflect that.  The fix is
probably to add line numbers to expressions, which requires
changing the AST definition and updating ast.c to assign
line numbers.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2005-10-07 11:01

Message:
Logged In: YES 
user_id=31392

Here's a quick status report on Linux + GCC 3.2.2 from today:

12 tests failed:
    test_dis test_doctest test_future test_genexps test_inspect
    test_new test_peepholer test_pwd test_scope test_subprocess
    test_symtable test_trace

7 skips unexpected on linux2:
    test_hotshot test_bsddb test_email test_parser
test_transformer
    test_email_codecs test_compiler

I'm going to trace into the details of why each of these
tests is failing.


----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2005-07-10 21:15

Message:
Logged In: YES 
user_id=357491

Scratch the "all open bugs" comment; didn't get to bug #1195576.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2005-07-10 21:13

Message:
Logged In: YES 
user_id=357491

After applying all patches associated with all open bugs,
the failing tests from ``./python.exe Lib/test/regrtest.py``
are:

14 tests failed:
    test_cookielib test_dis test_future test_genexps
test_inspect
    test_new test_peepholer test_scope test_subprocess
test_symtable
    test_syntax test_trace test_traceback test_warnings

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-05-28 04:40

Message:
Logged In: YES 
user_id=1038590

Fixing #1186353 (lambda argument unpacking) fixes test_sort and  
test_itertools: 
 
17 tests failed: 
    test_compile test_cookielib test_dis test_doctest test_future 
    test_genexps test_inspect test_new test_ossaudiodev 
test_peepholer 
    test_scope test_subprocess test_symtable test_syntax test_trace 
    test_traceback test_warnings 
 

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-05-28 01:33

Message:
Logged In: YES 
user_id=1038590

Bumped bug priority to 9 so it stays on top of the SF tracker. Also, we 
can't merge the AST branch until this bug is closed, so it is fairly 
important to close out these issues :) 
 
Running "./python Lib/test/regrtest.py -uall" 
 
Suse Linux 9.1: 
20 tests failed: 
    test_compile test_cookielib test_dis test_doctest test_future 
    test_genexps test_inspect test_itertools test_new test_ossaudiodev 
    test_peepholer test_scope test_sort test_subprocess 
test_symtable 
    test_syntax test_trace test_traceback test_warnings test_zipfile 
 
WIth the patch for 1186195 (genexp scoping) applied I get: 
 
19 tests failed: 
    test_compile test_cookielib test_dis test_doctest test_future 
    test_genexps test_inspect test_itertools test_new test_ossaudiodev 
    test_peepholer test_scope test_sort test_subprocess 
test_symtable 
    test_syntax test_trace test_traceback test_warnings 
 
The remaining test_genexps failures are due to assignment 
statements not checking for genexps as illegal targets. Running 
test_zipfile in verbose mode indicated genexp problems, so it makes 
sense that fixing the scoping eliminated those failures. 
 
I'm going to look at lambdas next, since they seem to be the culprits 
with respect to a few different test failures. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191458&group_id=5470

From noreply at sourceforge.net  Fri Jul 28 08:02:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 27 Jul 2006 23:02:25 -0700
Subject: [ python-Bugs-1530142 ] Mac Universal Build of Python confuses
	distutils
Message-ID: <E1G6LQX-0007uY-Ha@sc8-sf-web2.sourceforge.net>

Bugs item #1530142, was opened at 2006-07-28 16:02
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=1530142&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Jones (richard)
Assigned to: Nobody/Anonymous (nobody)
Summary: Mac Universal Build of Python confuses distutils

Initial Comment:
I'm sorry I can't provide a fully-detailed report 
here, but I'm not in a position to be able to 
reproduce the problem.

In short, I installed the Universal build of Python 
2.4.3 for the Mac downloaded from:

http://pythonmac.org/packages/py24-fat/index.html

I don't know whether this is the same as the download 
from:

http://www.python.org/download/releases/2.4.3/

Once installed, I attempted to build ctypes.

The build failed due to an assembly error (unknown 
instruction). I'm not familiar with the PPC or x86 
assembler code so couldn't do a thorough analysis.

I needed Python2.4 to work, so I found an older 
PPC-only installer and used that.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530142&group_id=5470

From noreply at sourceforge.net  Thu Jul 27 14:42:38 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 27 Jul 2006 05:42:38 -0700
Subject: [ python-Bugs-1519571 ] turtle.py Docs still incomplete
Message-ID: <E1G65CI-0001U8-6u@sc8-sf-web3.sourceforge.net>

Bugs item #1519571, was opened at 2006-07-09 10:49
Message generated for change (Settings changed) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519571&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Lingl (gregorlingl)
Assigned to: Martin v. L?wis (loewis)
Summary: turtle.py Docs still incomplete

Initial Comment:
There are three functions in turtle.py (which do not
occur as methods of Pen), which are still not
documented:

setup()
title()
done()

Regards,
Gregor

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519571&group_id=5470

From noreply at sourceforge.net  Fri Jul 28 08:26:33 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 27 Jul 2006 23:26:33 -0700
Subject: [ python-Bugs-1469557 ] FTP modue functions are not re-entrant,
	give odd exceptions
Message-ID: <E1G6Lnt-0003St-Jx@sc8-sf-web6.sourceforge.net>

Bugs item #1469557, was opened at 2006-04-13 02:13
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469557&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: brucepeterson (brucepeterson)
Assigned to: Nobody/Anonymous (nobody)
Summary: FTP modue functions are not re-entrant,give odd exceptions

Initial Comment:
 If I define a class using the Thread and FTP moudles, 
start a process which gathers FTP responses, 
additional calls to the class may have the responses 
of the thread instead of the main loop (or vice versa)
  This causes weird and unexpected exceptions from the 
ftplib.

  For instance I get the following error when the 
thread process does a pwd() function
error_reply: 213 34603008  

  The "213" reply is a response from the main process 
size() function

---------
Code
---------
from time import sleep
from threading import Thread

class ftpMachine(Thread, ftplib.FTP):
    def __init__(self, svr, user, passwd):
        Thread.__init__(self)
        ftplib.FTP.__init__(self, svr, user, passwd)
        
    def run(self):
        for x in xrange(20):
            output="Thread -"+str(self.nlst())[:30]
            print output
            sleep (0.0100)

def main():
    aCon = ftpMachine("LocalFTP", "user", "")
    aCon.start()
    for x in xrange(20):
        output = "Main -- " + str(aCon.size("File"))
        print output  
        sleep (0.010)

Workround:
  Rewrite code to create a third worker thread for 
response isolation?  Don't know that this would solve 
the problem.


---------------
Exception example
---------------

Exception in thread Thread-1:
Traceback (most recent call last):
  File "C:\Python24\lib\threading.py", line 442, in 
__bootstrap
    self.run()
  File "dualFTPIssue.py", line 17, in run
    output  = "Thread output " + str(self.nlst())[:30]
+" ..."
  File "C:\Python24\lib\ftplib.py", line 448, in nlst
    self.retrlines(cmd, files.append)
  File "C:\Python24\lib\ftplib.py", line 396, in 
retrlines
    conn = self.transfercmd(cmd)
  File "C:\Python24\lib\ftplib.py", line 345, in 
transfercmd
    return self.ntransfercmd(cmd, rest)[0]
  File "C:\Python24\lib\ftplib.py", line 321, in 
ntransfercmd
    host, port = self.makepasv()
  File "C:\Python24\lib\ftplib.py", line 299, in 
makepasv
    host, port = parse227(self.sendcmd('PASV'))
  File "C:\Python24\lib\ftplib.py", line 566, in 
parse227
    raise error_reply, resp
error_reply: 213 34603008

----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-28 08:26

Message:
Logged In: YES 
user_id=580910

I don't understand why you cannot use two connection resources. Are you 
running in a severely resource constrained environment?

Anyway, what you're doing right now is undefined behaviour. Unless explicitly 
stated otherwise classes in the stdlib aren't fully reentrant. You will therefore 
have to arrange some kind of exclusion mechanism. One way of doing that is 
to introduce a lock (probably wrapping the FTP client instead of using 
multiple inheritance in the progress). Another way it to introduce a 3th thread 
that performs the actual FTP operations and communicate with that using a 
queue. Please ask around on python-list/comp.lang.python if you need help 
with this.

BTW. I didn't close this bug, although I do understand why it was closed: the 
behaviour you describe isn't a bug but expected behaviour. 

----------------------------------------------------------------------

Comment By: brucepeterson (brucepeterson)
Date: 2006-07-27 23:39

Message:
Logged In: YES 
user_id=1500983

Unfortunately I can't start two instances of the FTP client 
as the separate instances use two conneciton resources.  I 
was hoping for a non-exception when a unexpsected response 
happens.  That would require re-working the module.
  For my workaround I set a time to determine when the 
transfer should complete instead of a querry.

  Thanks for your attention in this matter.

  Closing this bug as my case is an unusual one.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-13 13:54

Message:
Logged In: YES 
user_id=580910

IMHO this isn't a bug, your accessing a shared resource (the FTP connection) 
from two threads without locking. Most of python's libraries aren't safe for this 
kind of use.

BTW. The fact that you subclass form thread and ftplib.FTP is immaterial, you 
will get the same effect if you create an ftplib.FTP and then use it in two threads.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469557&group_id=5470

From noreply at sourceforge.net  Wed Jul 26 22:45:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 26 Jul 2006 13:45:25 -0700
Subject: [ python-Feature Requests-1528593 ] Printing: No print dialog or page
	setup
Message-ID: <E1G5qFx-0006Td-KR@sc8-sf-web5.sourceforge.net>

Feature Requests item #1528593, was opened at 2006-07-25 15:49
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1528593&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: IDLE
>Group: Python 2.6
Status: Open
Resolution: None
Priority: 3
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Printing: No print dialog or page setup

Initial Comment:
The printing solution for IDLE on OSX is lacking a page setup dialog, or 
even a print dialog. This means output will also be sent to the default 
printer.

If there is no default printer (which means the user hasn't defined a 
printer at all) the user will get a confusing message (lpr failed). BTW. the 
message is clear for technical users, but not for mac users that aren't unix 
saffy.

It would be nice if IDLE could interface with the Carbon/Cocoa print 
system using a real print dialog. That way users can select another than 
the default printer, change page settings and can even print to PDF.

I've filed this as a low-priority issue for 2.6 because there's no way this 
will get into 2.5 and it likey non-trivial as well.

BTW. this might be a feature-request rather than a bug.

----------------------------------------------------------------------

>Comment By: Kurt B. Kaiser (kbk)
Date: 2006-07-26 16:45

Message:
Logged In: YES 
user_id=149084

It's not just an OSX problem.  Printing in IDLE
is very rudimentary at this point.

Making this an RFE.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1528593&group_id=5470

From noreply at sourceforge.net  Fri Jul 28 08:28:21 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 27 Jul 2006 23:28:21 -0700
Subject: [ python-Bugs-1530142 ] Mac Universal Build of Python confuses
	distutils
Message-ID: <E1G6Lpd-0006gS-Nd@sc8-sf-web6.sourceforge.net>

Bugs item #1530142, was opened at 2006-07-28 08:02
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530142&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Jones (richard)
>Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: Mac Universal Build of Python confuses distutils

Initial Comment:
I'm sorry I can't provide a fully-detailed report 
here, but I'm not in a position to be able to 
reproduce the problem.

In short, I installed the Universal build of Python 
2.4.3 for the Mac downloaded from:

http://pythonmac.org/packages/py24-fat/index.html

I don't know whether this is the same as the download 
from:

http://www.python.org/download/releases/2.4.3/

Once installed, I attempted to build ctypes.

The build failed due to an assembly error (unknown 
instruction). I'm not familiar with the PPC or x86 
assembler code so couldn't do a thorough analysis.

I needed Python2.4 to work, so I found an older 
PPC-only installer and used that.


----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-28 08:28

Message:
Logged In: YES 
user_id=580910

Which version of ctypes did you try to build?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530142&group_id=5470

From noreply at sourceforge.net  Wed Jul 26 04:06:12 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 25 Jul 2006 19:06:12 -0700
Subject: [ python-Feature Requests-1528154 ] New sequences for Unicode groups
	and block ranges needed
Message-ID: <E1G5Ymq-0003Tc-1f@sc8-sf-web5.sourceforge.net>

Feature Requests item #1528154, was opened at 2006-07-25 15:44
Message generated for change (Comment added) made by gmarketer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1528154&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Regular Expressions
Group: None
Status: Open
Resolution: None
Priority: 6
Submitted By: gmarketer (gmarketer)
Assigned to: Nobody/Anonymous (nobody)
>Summary: New sequences for Unicode groups and block ranges needed

Initial Comment:
The special sequences consist of "\" and another
character need to be added to RE sintax to simplify the
finding of several Unicode classes like:
 * All uppercase letters
 * All lowercase letters


----------------------------------------------------------------------

>Comment By: gmarketer (gmarketer)
Date: 2006-07-26 13:06

Message:
Logged In: YES 
user_id=1334865

We need to process several strings in utf-8 and need to use
regular expressions to match pattern, for ex.:
r"[ANY_LANGUAGE_UPPERCASE_LETTER,0-9ANY_LANGUAGE_LOWERCASE_LETTER]+|NOT_ANY_LANGUAGE_CURRENCY"

We don't know how to implement this logic by our hands.

Also, I found this logic implemented in Microsoft dot NET
regular expressions:

\p{name}        Matches any character in the named character
class 'name'. Supported names are Unicode groups and block
ranges. For example Ll, Nd, Z, IsGreek, IsBoxDrawing, and Sc
(currency). 

\P{name}        Matches text not included in the named
character class 'name'. 

We need same logic in regular expressions.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2006-07-25 18:45

Message:
Logged In: YES 
user_id=38388

Could you make your request a little more specific ?

We already have catregories in the re module, so adding a
few more would be possible (patches are welcome !). However,
we do need to know why you need them and whether there are
other RE implementations that already have such special
matching characters, e.g. the Perl RE implementation.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1528154&group_id=5470

From noreply at sourceforge.net  Fri Jul 28 08:47:54 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 27 Jul 2006 23:47:54 -0700
Subject: [ python-Bugs-1530142 ] Mac Universal Build of Python confuses
	distutils
Message-ID: <E1G6M8Y-0006dp-Nj@sc8-sf-web6.sourceforge.net>

Bugs item #1530142, was opened at 2006-07-28 16:02
Message generated for change (Comment added) made by richard
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530142&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Jones (richard)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: Mac Universal Build of Python confuses distutils

Initial Comment:
I'm sorry I can't provide a fully-detailed report 
here, but I'm not in a position to be able to 
reproduce the problem.

In short, I installed the Universal build of Python 
2.4.3 for the Mac downloaded from:

http://pythonmac.org/packages/py24-fat/index.html

I don't know whether this is the same as the download 
from:

http://www.python.org/download/releases/2.4.3/

Once installed, I attempted to build ctypes.

The build failed due to an assembly error (unknown 
instruction). I'm not familiar with the PPC or x86 
assembler code so couldn't do a thorough analysis.

I needed Python2.4 to work, so I found an older 
PPC-only installer and used that.


----------------------------------------------------------------------

>Comment By: Richard Jones (richard)
Date: 2006-07-28 16:47

Message:
Logged In: YES 
user_id=6405

0.9.9.6

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-28 16:28

Message:
Logged In: YES 
user_id=580910

Which version of ctypes did you try to build?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530142&group_id=5470

From noreply at sourceforge.net  Fri Jul 28 13:28:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 28 Jul 2006 04:28:46 -0700
Subject: [ python-Bugs-1529269 ] Python 2.5b2 fails to build on Solaris 10
	(GCC Compiler)
Message-ID: <E1G6QWM-0007CD-BP@sc8-sf-web1.sourceforge.net>

Bugs item #1529269, was opened at 2006-07-26 23:17
Message generated for change (Comment added) made by ostkamp
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529269&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido Ostkamp (ostkamp)
Assigned to: Thomas Heller (theller)
Summary: Python 2.5b2 fails to build on Solaris 10 (GCC Compiler)

Initial Comment:
Hello,

as promised here is the second report because of
problems with building Python 2.5b2 on Solaris 10
(Sparc). I have been using the GCC this time.

These are the problems (for full logs please see
attachments):

building '_ctypes' extension
gcc -shared
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules
/_ctypes/_ctypes.o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/
Modules/_ctypes/callbacks.o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Pyth
on-2.5b2/Modules/_ctypes/callproc.o
build/temp.solaris-2.10-sun4us-2.5/home/ostk
amp/Python-2.5b2/Modules/_ctypes/stgdict.o
build/temp.solaris-2.10-sun4us-2.5/ho
me/ostkamp/Python-2.5b2/Modules/_ctypes/cfield.o
build/temp.solaris-2.10-sun4us-
2.5/home/ostkamp/Python-2.5b2/Modules/_ctypes/malloc_closure.o
build/temp.solari
s-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/prep_cif.
o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules/_ctypes/l
ibffi/src/sparc/ffi.o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5
b2/Modules/_ctypes/libffi/src/sparc/v8.o
build/temp.solaris-2.10-sun4us-2.5/home
/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v9.o
-o build/lib.solaris
-2.10-sun4us-2.5/_ctypes.so
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol <unknow
n>: offset 0xfeedcca5 is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol <unknow
n>: offset 0xfeedccab is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol <unknow
n>: offset 0xfeedccaf is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol <unknow
n>: offset 0xfeedccb3 is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol <unknow
n>: offset 0xfeeeae06 is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol <unknow
n>: offset 0xfeeecaf6 is non-aligned
collect2: ld returned 1 exit status

building '_curses' extension
gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -I. -I/
home/ostkamp/Python-2.5b2/./Include -I./Include -I.
-I/home/ostkamp/Python-2.5b2
/Include -I/home/ostkamp/Python-2.5b2 -c
/home/ostkamp/Python-2.5b2/Modules/_cur
sesmodule.c -o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modu
les/_cursesmodule.o
/home/ostkamp/Python-2.5b2/Modules/_cursesmodule.c: In
function `PyCursesWindow_
GetStr':
/home/ostkamp/Python-2.5b2/Modules/_cursesmodule.c:822:
warning: implicit declar
ation of function `mvwgetnstr'
gcc -shared
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules
/_cursesmodule.o -lcurses -ltermcap -o
build/lib.solaris-2.10-sun4us-2.5/_curses
.so
*** WARNING: renaming "_curses" since importing it
failed: ld.so.1: python: fata
l: relocation error: file
build/lib.solaris-2.10-sun4us-2.5/_curses.so: symbol m
vwgetnstr: referenced symbol not found
building '_curses_panel' extension
gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -I. -I/
home/ostkamp/Python-2.5b2/./Include -I./Include -I.
-I/home/ostkamp/Python-2.5b2
/Include -I/home/ostkamp/Python-2.5b2 -c
/home/ostkamp/Python-2.5b2/Modules/_cur
ses_panel.c -o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modu
les/_curses_panel.o
gcc -shared
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules
/_curses_panel.o -lpanel -lcurses -ltermcap -o
build/lib.solaris-2.10-sun4us-2.5
/_curses_panel.so
*** WARNING: renaming "_curses_panel" since importing
it failed: No module named
 _curses
running build_scripts

Regards,

Guido

----------------------------------------------------------------------

>Comment By: Guido Ostkamp (ostkamp)
Date: 2006-07-28 13:28

Message:
Logged In: YES 
user_id=1028306

@theller:
I have tried --with-pydebug, but it gives the same errors.
Please find logfile attached.

@nnorwitz:
I remove the Python-2.5b2 directory and execute a fresh
untar, configure etc. for each try. So there is no
interference with results from different compilers.

In case it matters, I checked for the GCC version used. I
think it came with the Solaris distribution and does use the
system-ld, not gnu-ld (see below for config output):

$ gcc -v 
Reading specs from
/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/specs
Configured with:
/gates/sfw10/builds/sfw10-gate/usr/src/cmd/gcc/gcc-3.4.3/configure
--prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as
--with-ld=/usr/ccs/bin/ld --without-gnu-ld
--enable-languages=c,c++ --enable-shared
Thread model: posix
gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath)

This is from package 

$ pkginfo -l SUNWgcc
   PKGINST:  SUNWgcc
      NAME:  gcc - The GNU C compiler
  CATEGORY:  system
      ARCH:  sparc
   VERSION:  11.10.0,REV=2005.01.08.05.16
   BASEDIR:  /
    VENDOR:  Sun Microsystems, Inc.
      DESC:  GNU C - The GNU C compiler 3.4.3
    PSTAMP:  sfw1020050108051924
  INSTDATE:  Mar 20 2006 14:30
   HOTLINE:  Please contact your local service provider
    STATUS:  completely installed
     FILES:      296 installed pathnames
                   6 shared pathnames
                   5 linked files
                  25 directories
                  33 executables
              104325 blocks used (approx)

Regards,

Guido

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-28 06:53

Message:
Logged In: YES 
user_id=33168

Hmmm, I thought this was the report from using sun studio
compiler.  Guido, are you sure you did a make clean in
between using different compilers?

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2006-07-27 19:23

Message:
Logged In: YES 
user_id=11105

I don't have access to a solaris 10 box myself (only the
sourceforge solaris 9 sparc machine).  I'm wondering why the
solaris 10 machine running the Python buildbot does not
report any problems, could it be that this is because it run
configure with '--with-pydebug' ?

Guido, can you please try this?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-27 05:21

Message:
Logged In: YES 
user_id=33168

Thomas can you check out the ctypes problems?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529269&group_id=5470

From noreply at sourceforge.net  Fri Jul 28 15:20:17 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 28 Jul 2006 06:20:17 -0700
Subject: [ python-Bugs-1530382 ] ssl object documentation lacks a couple of
	methods
Message-ID: <E1G6SGH-00068M-Tc@sc8-sf-web5.sourceforge.net>

Bugs item #1530382, was opened at 2006-07-28 15: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=1530382&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Lawrence Oluyede (rhymes)
Assigned to: Nobody/Anonymous (nobody)
Summary: ssl object documentation lacks a couple of methods

Initial Comment:
According to
http://docs.python.org/dev/lib/ssl-objects.html the SSL
Objects expose only write() and read() but they also
expose issuer() and server() methods.

See Modueles/_ssl.c from line 557 to 565

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530382&group_id=5470

From noreply at sourceforge.net  Fri Jul 28 15:35:29 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 28 Jul 2006 06:35:29 -0700
Subject: [ python-Bugs-1521491 ] file.seek() influelce write() when opened
	with a+ mode
Message-ID: <E1G6SUz-0002c8-6l@sc8-sf-web2.sourceforge.net>

Bugs item #1521491, was opened at 2006-07-12 22:04
Message generated for change (Comment added) made by rudnik_lior
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521491&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
>Status: Open
Resolution: None
Priority: 5
Submitted By: Lior (rudnik_lior)
Assigned to: Nobody/Anonymous (nobody)
Summary: file.seek() influelce write() when opened with a+ mode

Initial Comment:
Python 2.5b1 (r25b1:47027, Jun 20 2006, 09:31:33)

Assuming documentation is correct: (from seek() help
"Note that if the file is opened for appending (mode
'a' or 'a+'), any seek() operations will be undone at
the next write"

Doing the following is __not__ undoing the seek
operation after calling this a few times (Simplified
code snippet):

from __future__ import with_statement
with open(path,'a+') as f:
    f.seek(0,2) # go to end
    pos = f.tell() 
    f.seek(0,0)
    line = f.readline().strip()
    f.seek(0,2) # go to end, not effective if opened
with mode a/a+ (currently bug?)
    f.write("something")

Calling the above code repeatedly didnt increase the
file size beyond 166 bytes (in my code)



----------------------------------------------------------------------

>Comment By: Lior (rudnik_lior)
Date: 2006-07-28 13:35

Message:
Logged In: YES 
user_id=1364480

This issue is on windows XP.
Wasnt tested on other versions (only 2.5b1 and b2)

I expect the code to always write at the end according to
the documentation. However if I user file seek (opend as A+)
to read from begining of the file, the write also goes to
begining of file.

Note - in the code snippet, please remove the last
f.seek(0,2) to see the problem! (it should have been in a
comment)

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-07-13 07:43

Message:
Logged In: YES 
user_id=849994

I also cannot see any problem with the above code and can
append to a file indefinitely. What exactly are you
expecting the code to do, and what do you get? Which OS is this?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-13 06:29

Message:
Logged In: YES 
user_id=33168

This seems to work for me on Linux.  Maybe we are testing
differently.  What o/s and version are you using?  Does this
work with Python 2.4?  Can you attach a complete test case
that demonstrates this problem?

Thanks.

----------------------------------------------------------------------

Comment By: Lior (rudnik_lior)
Date: 2006-07-12 22:09

Message:
Logged In: YES 
user_id=1364480

Re-tried the code with empty file - it doesnt grow beyond
creating and writting at position 0 so it seems the seek
does influence the write position.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521491&group_id=5470

From noreply at sourceforge.net  Fri Jul 28 16:09:13 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 28 Jul 2006 07:09:13 -0700
Subject: [ python-Bugs-1525866 ] Bug in shutil.copytree on Windows
Message-ID: <E1G6T1d-0005Ut-SI@sc8-sf-web2.sourceforge.net>

Bugs item #1525866, was opened at 2006-07-20 13:00
Message generated for change (Comment added) made by mjfoord
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525866&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Foord (mjfoord)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bug in shutil.copytree on Windows

Initial Comment:
The problem is that the call to 'copystat(src, dst)'
was added to the shutil.copytree function, in svn
r38363 probably.  It will fail always on Windows, since
os.utime does not work on directories.

I guess that a patch similar to this one should fix it:

Index: shutil.py
===================================================================
--- shutil.py	(Revision 50710)
+++ shutil.py	(Arbeitskopie)
@@ -127,7 +127,12 @@
         # continue with other files
         except Error, err:
             errors.extend(err.args[0])
-    copystat(src, dst)
+    try:
+        copystat(src, dst)
+    except WindowsError:
+        pass
+    except OSError, err:
+        errors.extend(err.args[0])
     if errors:
         raise Error, errors

----------------------------------------------------------------------

>Comment By: Mike Foord (mjfoord)
Date: 2006-07-28 14:09

Message:
Logged In: YES 
user_id=1123892

The following should work as a test method for shutil.copytree

(Passes on my box against a patched version of shutil)

    def test_copytree_simple(self):
        src_dir = tempfile.mkdtemp()
        dst_dir = os.path.join(tempfile.mkdtemp(),
'destination')
        open(os.path.join(src_dir, 'test.txt'),
'w').write('123')
        os.mkdir(os.path.join(src_dir, 'test_dir'))
        open(os.path.join(src_dir, 'test_dir', 'test.txt'),
'w').write('456')
        #
        def testStat(src, dst):
            st_src = os.stat(src)
            st_dst = os.stat(dst)
            if hasattr(os, 'utime'):
                self.assertEqual((st_src.st_atime,
st_src.st_mtime), (st_dst.st_atime, st_dst.st_mtime))
            if hasattr(os, 'chmod'):
                # Should be equal anyway, should we change
permissions on one of the source files ?
               
self.assertEqual(stat.S_IMODE(st_src.st_mode),
stat.S_IMODE(st_dst.st_mode))
        #
        try:
            shutil.copytree(src_dir, dst_dir)
           
self.assertTrue(os.path.isfile(os.path.join(dst_dir,
'test.txt')))
           
self.assertTrue(os.path.isdir(os.path.join(dst_dir,
'test_dir')))
           
self.assertTrue(os.path.isfile(os.path.join(dst_dir,
'test_dir', 'test.txt')))
            self.assertEqual(open(os.path.join(dst_dir,
'test.txt')).read(), '123')
            self.assertEqual(open(os.path.join(dst_dir,
'test_dir', 'test.txt')).read(), '456')
           
        finally:
            try:
                os.remove(os.path.join(src_dir, 'test.txt'))
                os.remove(os.path.join(dst_dir, 'test.txt'))
                os.remove(os.path.join(src_dir, 'test_dir',
'test.txt'))
                os.remove(os.path.join(dst_dir, 'test_dir',
'test.txt'))
                os.removedirs(src_dir)
                os.removedirs(dst_dir)
            except:
                pass

Can turn the above into a patch tonight if needed.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-07-20 16:14

Message:
Logged In: YES 
user_id=21627

Can you also come up with a patch to the test suite?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525866&group_id=5470

From noreply at sourceforge.net  Fri Jul 28 16:14:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 28 Jul 2006 07:14:05 -0700
Subject: [ python-Bugs-1525866 ] Bug in shutil.copytree on Windows
Message-ID: <E1G6T6K-00076r-UA@sc8-sf-web2.sourceforge.net>

Bugs item #1525866, was opened at 2006-07-20 13:00
Message generated for change (Comment added) made by mjfoord
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525866&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Foord (mjfoord)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bug in shutil.copytree on Windows

Initial Comment:
The problem is that the call to 'copystat(src, dst)'
was added to the shutil.copytree function, in svn
r38363 probably.  It will fail always on Windows, since
os.utime does not work on directories.

I guess that a patch similar to this one should fix it:

Index: shutil.py
===================================================================
--- shutil.py	(Revision 50710)
+++ shutil.py	(Arbeitskopie)
@@ -127,7 +127,12 @@
         # continue with other files
         except Error, err:
             errors.extend(err.args[0])
-    copystat(src, dst)
+    try:
+        copystat(src, dst)
+    except WindowsError:
+        pass
+    except OSError, err:
+        errors.extend(err.args[0])
     if errors:
         raise Error, errors

----------------------------------------------------------------------

>Comment By: Mike Foord (mjfoord)
Date: 2006-07-28 14:14

Message:
Logged In: YES 
user_id=1123892

Nope - not quite right. Will fix tonight and upload a proper
patch.

Michael

----------------------------------------------------------------------

Comment By: Mike Foord (mjfoord)
Date: 2006-07-28 14:09

Message:
Logged In: YES 
user_id=1123892

The following should work as a test method for shutil.copytree

(Passes on my box against a patched version of shutil)

    def test_copytree_simple(self):
        src_dir = tempfile.mkdtemp()
        dst_dir = os.path.join(tempfile.mkdtemp(),
'destination')
        open(os.path.join(src_dir, 'test.txt'),
'w').write('123')
        os.mkdir(os.path.join(src_dir, 'test_dir'))
        open(os.path.join(src_dir, 'test_dir', 'test.txt'),
'w').write('456')
        #
        def testStat(src, dst):
            st_src = os.stat(src)
            st_dst = os.stat(dst)
            if hasattr(os, 'utime'):
                self.assertEqual((st_src.st_atime,
st_src.st_mtime), (st_dst.st_atime, st_dst.st_mtime))
            if hasattr(os, 'chmod'):
                # Should be equal anyway, should we change
permissions on one of the source files ?
               
self.assertEqual(stat.S_IMODE(st_src.st_mode),
stat.S_IMODE(st_dst.st_mode))
        #
        try:
            shutil.copytree(src_dir, dst_dir)
           
self.assertTrue(os.path.isfile(os.path.join(dst_dir,
'test.txt')))
           
self.assertTrue(os.path.isdir(os.path.join(dst_dir,
'test_dir')))
           
self.assertTrue(os.path.isfile(os.path.join(dst_dir,
'test_dir', 'test.txt')))
            self.assertEqual(open(os.path.join(dst_dir,
'test.txt')).read(), '123')
            self.assertEqual(open(os.path.join(dst_dir,
'test_dir', 'test.txt')).read(), '456')
           
        finally:
            try:
                os.remove(os.path.join(src_dir, 'test.txt'))
                os.remove(os.path.join(dst_dir, 'test.txt'))
                os.remove(os.path.join(src_dir, 'test_dir',
'test.txt'))
                os.remove(os.path.join(dst_dir, 'test_dir',
'test.txt'))
                os.removedirs(src_dir)
                os.removedirs(dst_dir)
            except:
                pass

Can turn the above into a patch tonight if needed.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-07-20 16:14

Message:
Logged In: YES 
user_id=21627

Can you also come up with a patch to the test suite?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525866&group_id=5470

From noreply at sourceforge.net  Thu Jul 27 06:38:37 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 26 Jul 2006 21:38:37 -0700
Subject: [ python-Bugs-1515471 ] wrong handling of character buffers in
	stringobject
Message-ID: <E1G5xdt-00012r-Sn@sc8-sf-web3.sourceforge.net>

Bugs item #1515471, was opened at 2006-07-01 02:41
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1515471&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
>Priority: 9
Submitted By: Georg Brandl (gbrandl)
Assigned to: Fredrik Lundh (effbot)
Summary: wrong handling of character buffers in stringobject

Initial Comment:
stringobject.c:

In string_replace, there is

	if (PyString_Check(from)) {
	  /* Can this be made a '!check' after the Unicode
check? */
	}
#ifdef Py_USING_UNICODE
	if (PyUnicode_Check(from))
		return PyUnicode_Replace((PyObject *)self,
					 from, to, count);
#endif
	else if (PyObject_AsCharBuffer(from, &tmp_s, &tmp_len))
		return NULL;

[the same check with "to"]

	return (PyObject *)replace((PyStringObject *) self,
				   (PyStringObject *) from,
				   (PyStringObject *) to, count);

This is not correct if from or to isn't a string
object, but a char buffer compatible object.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1515471&group_id=5470

From noreply at sourceforge.net  Fri Jul 28 17:04:04 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 28 Jul 2006 08:04:04 -0700
Subject: [ python-Bugs-1530448 ] ctypes build fails on Solaris 10
Message-ID: <E1G6Tsi-0006qj-72@sc8-sf-web3.sourceforge.net>

Bugs item #1530448, was opened at 2006-07-28 10: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=1530448&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Thomas Heller (theller)
Summary: ctypes build fails on Solaris 10

Initial Comment:
Thomas,

I tried to build Python from cvs (svn rev 50905) on
Solaris 10 today.
Compiler was gcc 3.4.  I got a text relocation error
when linking
ctypes.so:

/opt/app/g++lib6/gcc-3.4/bin/gcc -shared
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o
-L/usr/local/lib -o
build/lib.solaris-2.10-i86pc-2.5/_ctypes.so
Text relocation remains                         referenced
    against symbol                  offset      in file
ffi_closure_SYSV_inner              0x8e       
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o
ld: fatal: relocations remain against allocatable but
non-writable sections
collect2: ld returned 1 exit status

I tried configuring both with and without the
--with-system-ffi flag.
The error was the same in both cases.

If you need more information, let me know.

Skip


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530448&group_id=5470

From noreply at sourceforge.net  Thu Jul 27 06:43:58 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 26 Jul 2006 21:43:58 -0700
Subject: [ python-Bugs-1523610 ] PyArg_ParseTupleAndKeywords potential core
	dump
Message-ID: <E1G5xj4-0004h7-OK@sc8-sf-web3.sourceforge.net>

Bugs item #1523610, was opened at 2006-07-16 19:23
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1523610&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Pending
Resolution: Fixed
>Priority: 8
Submitted By: Eric Huss (ehuss)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyArg_ParseTupleAndKeywords potential core dump

Initial Comment:
After getting bit by bug 893549, I was noticing that
sometimes I was getting a core dump instead of a
TypeError when PyArg_ParseTupleAndKeywords was skipping
over a type the "skipitem" code does not understand.

There are about 4 problems I will describe (though they
are related, so it's probably not worth filing seperate
bugs).

The problem is that the "levels" variable is passed to
the seterror function uninitialized.  If levels does
not happen to contain any 0 elements, then the
iteration code in seterror will go crazy (I will get to
this in a moment).

In the one place where "skipitem" is called, you will
notice it immediately calls seterror() if it returned
an error message.  However, "levels" is not set by the
skipitem function, and thus seterror iterates over an
uninitialized value.  I suggest setting levels[0] = 0
somewhere in the beginning of the code, since the
expectations of setting the "levels" seems awefully
delicate.

(As a side note, there's no bounds checking on the
levels variable, either.  It seems unlikely that
someone will have 32 levels of nested variables, but I
think it points to a general problem with how the
variable is passed around.)

A second fix is to set levels[0] = 0 if setitem fails
before calling seterror().

Now, returning to the "seterror goes crazy" problem I
mentioned earlier, the following code in the seterror
function:

while (levels[i] > 0 && (int)(p-buf) < 220) {

should be:

while (levels[i] > 0 && (int)(p-buf) > 220) {

At least, that's what I'm assuming it is supposed to
be.  I think it should be clear why this is bad.

But wait, there's more!  The snprintf in seterror call
uses the incorrect size of buf.  The following line:

PyOS_snprintf(p, sizeof(buf) - (buf - p),

should be:

PyOS_snprintf(p, sizeof(buf) - (p - buf),

My particular platform (FreeBSD) puts a NUL character
at the end of the buffer.  However, since the size of
the buffer is computed incorrectly, this line of code
stomps on the stack (overwritting the levels value in
my case).

Let me know if you have any questions, or want any
sample code.


----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-07-26 01:04

Message:
Logged In: YES 
user_id=849994

Fixed the "levels[0] = 0" and the "p-buf" issue in rev.
50843.  Still waiting for input on python-dev about the
levels overflow, though I think it can be ignored.

----------------------------------------------------------------------

Comment By: Eric Huss (ehuss)
Date: 2006-07-16 19:28

Message:
Logged In: YES 
user_id=393416

Oops, skip the section about <220 being >220.  I've been
staring at it too long.  The rest of the issues should be
valid, though.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1523610&group_id=5470

From noreply at sourceforge.net  Fri Jul 28 18:19:09 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 28 Jul 2006 09:19:09 -0700
Subject: [ python-Bugs-1530448 ] ctypes build fails on Solaris 10
Message-ID: <E1G6V3N-00008d-99@sc8-sf-web5.sourceforge.net>

Bugs item #1530448, was opened at 2006-07-28 17:04
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530448&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Thomas Heller (theller)
Summary: ctypes build fails on Solaris 10

Initial Comment:
Thomas,

I tried to build Python from cvs (svn rev 50905) on
Solaris 10 today.
Compiler was gcc 3.4.  I got a text relocation error
when linking
ctypes.so:

/opt/app/g++lib6/gcc-3.4/bin/gcc -shared
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o
-L/usr/local/lib -o
build/lib.solaris-2.10-i86pc-2.5/_ctypes.so
Text relocation remains                         referenced
    against symbol                  offset      in file
ffi_closure_SYSV_inner              0x8e       
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o
ld: fatal: relocations remain against allocatable but
non-writable sections
collect2: ld returned 1 exit status

I tried configuring both with and without the
--with-system-ffi flag.
The error was the same in both cases.

If you need more information, let me know.

Skip


----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2006-07-28 18:19

Message:
Logged In: YES 
user_id=11105

Skip,

This looks *somewhat* like the problems reported in bugs
1529269 and 1528620 (although they have a sparc, and you
seem to have x86 solaris).

Hm, in the standalone ctypes setup script, I find this code
snippet:

if get_platform() in ["solaris-2.9-sun4u", "linux-x86_64"]:
    os.environ["CFLAGS"] = "-fPIC"

Can it be that -fPIC must be used, but is not specified?

It is also funny that the solaris buildbot does NOT seem to
have a problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530448&group_id=5470

From noreply at sourceforge.net  Fri Jul 28 19:02:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 28 Jul 2006 10:02:42 -0700
Subject: [ python-Bugs-1469557 ] FTP modue functions are not re-entrant,
	give odd exceptions
Message-ID: <E1G6VjW-0007RB-8N@sc8-sf-web3.sourceforge.net>

Bugs item #1469557, was opened at 2006-04-12 17:13
Message generated for change (Comment added) made by brucepeterson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469557&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: brucepeterson (brucepeterson)
Assigned to: Nobody/Anonymous (nobody)
Summary: FTP modue functions are not re-entrant,give odd exceptions

Initial Comment:
 If I define a class using the Thread and FTP moudles, 
start a process which gathers FTP responses, 
additional calls to the class may have the responses 
of the thread instead of the main loop (or vice versa)
  This causes weird and unexpected exceptions from the 
ftplib.

  For instance I get the following error when the 
thread process does a pwd() function
error_reply: 213 34603008  

  The "213" reply is a response from the main process 
size() function

---------
Code
---------
from time import sleep
from threading import Thread

class ftpMachine(Thread, ftplib.FTP):
    def __init__(self, svr, user, passwd):
        Thread.__init__(self)
        ftplib.FTP.__init__(self, svr, user, passwd)
        
    def run(self):
        for x in xrange(20):
            output="Thread -"+str(self.nlst())[:30]
            print output
            sleep (0.0100)

def main():
    aCon = ftpMachine("LocalFTP", "user", "")
    aCon.start()
    for x in xrange(20):
        output = "Main -- " + str(aCon.size("File"))
        print output  
        sleep (0.010)

Workround:
  Rewrite code to create a third worker thread for 
response isolation?  Don't know that this would solve 
the problem.


---------------
Exception example
---------------

Exception in thread Thread-1:
Traceback (most recent call last):
  File "C:\Python24\lib\threading.py", line 442, in 
__bootstrap
    self.run()
  File "dualFTPIssue.py", line 17, in run
    output  = "Thread output " + str(self.nlst())[:30]
+" ..."
  File "C:\Python24\lib\ftplib.py", line 448, in nlst
    self.retrlines(cmd, files.append)
  File "C:\Python24\lib\ftplib.py", line 396, in 
retrlines
    conn = self.transfercmd(cmd)
  File "C:\Python24\lib\ftplib.py", line 345, in 
transfercmd
    return self.ntransfercmd(cmd, rest)[0]
  File "C:\Python24\lib\ftplib.py", line 321, in 
ntransfercmd
    host, port = self.makepasv()
  File "C:\Python24\lib\ftplib.py", line 299, in 
makepasv
    host, port = parse227(self.sendcmd('PASV'))
  File "C:\Python24\lib\ftplib.py", line 566, in 
parse227
    raise error_reply, resp
error_reply: 213 34603008

----------------------------------------------------------------------

>Comment By: brucepeterson (brucepeterson)
Date: 2006-07-28 10:02

Message:
Logged In: YES 
user_id=1500983

I am running on a unit that limits the FTP connections to 4 
high bandwidth connections and normally uses a passive FTP 
transfer.
  The response from the passive FTP transfer could come at 
any time.  Also, by inspection, the FTP module throws an 
exception when an unexpected reply happens.  So when I'm 
querrying the size of the clip on the destination and 
instead get a transfer complete message from the passive 
FTP session, that transfer complete message causes the 
exception.
  To "fix" this issue would requre that when the FTP 
message queue is read, that pending requests (passive 
transfers) would be considered before returning immediate 
command responses (cwd, ls, size, etc.).  If I get a couple 
of days, I may rewrite the functions that read the FTP 
responses and submit the changes for consideration.

  For my current project, I have decided not to querry the 
transfer to see if it completes, but instead to do a simple 
wait before sending the next transfer.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-27 23:26

Message:
Logged In: YES 
user_id=580910

I don't understand why you cannot use two connection resources. Are you 
running in a severely resource constrained environment?

Anyway, what you're doing right now is undefined behaviour. Unless explicitly 
stated otherwise classes in the stdlib aren't fully reentrant. You will therefore 
have to arrange some kind of exclusion mechanism. One way of doing that is 
to introduce a lock (probably wrapping the FTP client instead of using 
multiple inheritance in the progress). Another way it to introduce a 3th thread 
that performs the actual FTP operations and communicate with that using a 
queue. Please ask around on python-list/comp.lang.python if you need help 
with this.

BTW. I didn't close this bug, although I do understand why it was closed: the 
behaviour you describe isn't a bug but expected behaviour. 

----------------------------------------------------------------------

Comment By: brucepeterson (brucepeterson)
Date: 2006-07-27 14:39

Message:
Logged In: YES 
user_id=1500983

Unfortunately I can't start two instances of the FTP client 
as the separate instances use two conneciton resources.  I 
was hoping for a non-exception when a unexpsected response 
happens.  That would require re-working the module.
  For my workaround I set a time to determine when the 
transfer should complete instead of a querry.

  Thanks for your attention in this matter.

  Closing this bug as my case is an unusual one.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-13 04:54

Message:
Logged In: YES 
user_id=580910

IMHO this isn't a bug, your accessing a shared resource (the FTP connection) 
from two threads without locking. Most of python's libraries aren't safe for this 
kind of use.

BTW. The fact that you subclass form thread and ftplib.FTP is immaterial, you 
will get the same effect if you create an ftplib.FTP and then use it in two threads.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469557&group_id=5470

From noreply at sourceforge.net  Fri Jul 28 20:07:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 28 Jul 2006 11:07:05 -0700
Subject: [ python-Bugs-1530559 ] struct.pack raises TypeError where it used to
	convert
Message-ID: <E1G6Wjp-0001Zt-IJ@sc8-sf-web1.sourceforge.net>

Bugs item #1530559, was opened at 2006-07-28 18: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=1530559&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Joe Wreschnig (piman)
Assigned to: Nobody/Anonymous (nobody)
Summary: struct.pack raises TypeError where it used to convert

Initial Comment:
piman at toybox:~$ python2.4 -c "import struct;
struct.pack('>H', 1.0)"
piman at toybox:~$ python2.5 -c "import struct;
struct.pack('>H', 1.0)"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python2.5/struct.py", line 63, in pack
    return o.pack(*args)
TypeError: unsupported operand type(s) for &: 'float'
and 'long'

This might have appeared as part of the struct
optimizations; if struct isn't going to convert anymore
for performance reasons, I think this should be
mentioned in the release notes. Though personally I
would prefer struct go back to converting its arguments.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530559&group_id=5470

From noreply at sourceforge.net  Fri Jul 28 20:10:44 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 28 Jul 2006 11:10:44 -0700
Subject: [ python-Feature Requests-1441072 ] No simple example for pickle
Message-ID: <E1G6WnM-0007uH-Jo@sc8-sf-web3.sourceforge.net>

Feature Requests item #1441072, was opened at 2006-03-01 16:49
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1441072&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Kent Johnson (kjohnson)
Assigned to: Nobody/Anonymous (nobody)
Summary: No simple example for pickle

Initial Comment:
The docs for pickle lack a simple example of typical
usage. The Example page has only an advanced example. I
suggest something like this be added to the Usage or
Examples page:

Here is a simple example that shows how to use pickle
to save and restore a dictionary:
 >>> import pickle
 >>> data = dict(a=1, b=2, c=[3,4,5], d='cheese')
 >>> f=open('data.pickle', 'wb')
 >>> pickle.dump(data, f)
 >>> f.close()
 >>>
 >>> f=open('data.pickle', 'rb')
 >>> data2=pickle.load(f)
 >>> f.close()
 >>> data2
{'a': 1, 'c': [3, 4, 5], 'b': 2, 'd': 'cheese'}


Kent

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-28 18:10

Message:
Logged In: YES 
user_id=849994

A simple example was added by Andrew in rev. 50903.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1441072&group_id=5470

From noreply at sourceforge.net  Fri Jul 28 20:48:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 28 Jul 2006 11:48:24 -0700
Subject: [ python-Feature Requests-1527597 ] New module: miniconf
Message-ID: <E1G6XNo-0006Oa-8S@sc8-sf-web3.sourceforge.net>

Feature Requests item #1527597, was opened at 2006-07-24 03:43
Message generated for change (Comment added) made by syfou
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1527597&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: S.Fourmanoit (syfou)
Assigned to: Nobody/Anonymous (nobody)
Summary: New module: miniconf

Initial Comment:
Find enclosed a new data persistence module: miniconf,
that basically allows the casual creation and reading
of configuration files and similar simple data sets.

I ended-up using part of this code in many projects I
did in Python (such as adesklets), and many other
fellow developers borrowed it from me, so I though it
could be nice to have it as a part of the standard library.

So I cleaned it up, re-factored it as a simple,
standalone module, and here it is, complete with
documentation and its test module.

Find enclosed a patch against svn trunck (Python 2.5b2,
revision 50794). It changes nothing to the tree,
besides adding a one-liner to Doc/lib/lib.tex to
reference the new documentation.

The module also works untouched on Python 2.4.3; I will
be glad to provide a patch against any other tree if
you want me too; all comments are of course welcomed. 


----------------------------------------------------------------------

>Comment By: S.Fourmanoit (syfou)
Date: 2006-07-28 14:48

Message:
Logged In: YES 
user_id=1175491

Updated patch, based on feedback from Armin Rigo. Also
distributed on the Python Cheese Shop as module version 1.2.0:

http://cheeseshop.python.org/pypi?:action=display&name=miniconf&version=1.2.0


----------------------------------------------------------------------

Comment By: S.Fourmanoit (syfou)
Date: 2006-07-27 01:57

Message:
Logged In: YES 
user_id=1175491

Updated patch, based on feedback from David Hopwood and
Phillip J. Eby. Also distributed on the Python Cheese Shop
as module version 1.1.0:

=http://cheeseshop.python.org/pypi?:action=display&name=miniconf&version=1.1.0


----------------------------------------------------------------------

Comment By: S.Fourmanoit (syfou)
Date: 2006-07-25 02:20

Message:
Logged In: YES 
user_id=1175491

Current miniconf entry on the Python Cheese Shop:

http://cheeseshop.python.org/pypi?:action=display&name=miniconf&version=1.0.1

Thanks for your diligent feedback so far; I will send a
short message to python-dev tomorrow.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-07-24 15:55

Message:
Logged In: YES 
user_id=849994

You'll at least have to raise this on the python-dev list.
It is most probable that you're then asked to let a user
base grow by making the module available e.g. via Cheese
Shop and report back at a time where 2.6 is nearing.

----------------------------------------------------------------------

Comment By: S.Fourmanoit (syfou)
Date: 2006-07-24 12:44

Message:
Logged In: YES 
user_id=1175491

> Have you published this on the Python Cheese Shop?

If did not; without being trivial, I felt this was both
generic and useful enough to be worth the inclusion into the
base library; I managed to miss the feature freeze on python
2.5 -- sorry about that... 

I don't mind submitting it to the Python Cheese Shop, if it
is the right track to have it eventually committed to Python
code base; miniconf having virtually no collateral impact on
the rest of the code, it is indeed perfectly suitable for
distribution as a standalone module for both the 2.4.x and
incoming 2.5.x Python interpreters.

I don't mind either waiting for the end of the feature
freeze, keeping the module up to date as needed against any
new code. I am foreign to the development cycle of Python --
do you know what will be the next window of opportunity?
Into the incoming 2.5 tree when it will be out of the
freeze? Into python 2.6? 

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-07-24 09:39

Message:
Logged In: YES 
user_id=849994

Have you published this on the Python Cheese Shop? This
might be the more appropriate way to make this module known
to other Python developers since there's no way to include
it in 2.5 any more.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1527597&group_id=5470

From noreply at sourceforge.net  Fri Jul 28 20:51:55 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 28 Jul 2006 11:51:55 -0700
Subject: [ python-Bugs-1530559 ] struct.pack raises TypeError where it used to
	convert
Message-ID: <E1G6XRD-0008RO-US@sc8-sf-web5.sourceforge.net>

Bugs item #1530559, was opened at 2006-07-28 18:07
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530559&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Joe Wreschnig (piman)
>Assigned to: Bob Ippolito (etrepum)
Summary: struct.pack raises TypeError where it used to convert

Initial Comment:
piman at toybox:~$ python2.4 -c "import struct;
struct.pack('>H', 1.0)"
piman at toybox:~$ python2.5 -c "import struct;
struct.pack('>H', 1.0)"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python2.5/struct.py", line 63, in pack
    return o.pack(*args)
TypeError: unsupported operand type(s) for &: 'float'
and 'long'

This might have appeared as part of the struct
optimizations; if struct isn't going to convert anymore
for performance reasons, I think this should be
mentioned in the release notes. Though personally I
would prefer struct go back to converting its arguments.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-28 18:51

Message:
Logged In: YES 
user_id=849994

Bob?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530559&group_id=5470

From noreply at sourceforge.net  Fri Jul 28 20:54:55 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 28 Jul 2006 11:54:55 -0700
Subject: [ python-Bugs-1521491 ] file.seek() influelce write() when opened
	with a+ mode
Message-ID: <E1G6XU7-00019K-2E@sc8-sf-web5.sourceforge.net>

Bugs item #1521491, was opened at 2006-07-12 22:04
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521491&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Lior (rudnik_lior)
>Assigned to: Tim Peters (tim_one)
Summary: file.seek() influelce write() when opened with a+ mode

Initial Comment:
Python 2.5b1 (r25b1:47027, Jun 20 2006, 09:31:33)

Assuming documentation is correct: (from seek() help
"Note that if the file is opened for appending (mode
'a' or 'a+'), any seek() operations will be undone at
the next write"

Doing the following is __not__ undoing the seek
operation after calling this a few times (Simplified
code snippet):

from __future__ import with_statement
with open(path,'a+') as f:
    f.seek(0,2) # go to end
    pos = f.tell() 
    f.seek(0,0)
    line = f.readline().strip()
    f.seek(0,2) # go to end, not effective if opened
with mode a/a+ (currently bug?)
    f.write("something")

Calling the above code repeatedly didnt increase the
file size beyond 166 bytes (in my code)



----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-28 18:54

Message:
Logged In: YES 
user_id=849994

Perhaps you can try in on Windows, Tim...

----------------------------------------------------------------------

Comment By: Lior (rudnik_lior)
Date: 2006-07-28 13:35

Message:
Logged In: YES 
user_id=1364480

This issue is on windows XP.
Wasnt tested on other versions (only 2.5b1 and b2)

I expect the code to always write at the end according to
the documentation. However if I user file seek (opend as A+)
to read from begining of the file, the write also goes to
begining of file.

Note - in the code snippet, please remove the last
f.seek(0,2) to see the problem! (it should have been in a
comment)

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-07-13 07:43

Message:
Logged In: YES 
user_id=849994

I also cannot see any problem with the above code and can
append to a file indefinitely. What exactly are you
expecting the code to do, and what do you get? Which OS is this?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-13 06:29

Message:
Logged In: YES 
user_id=33168

This seems to work for me on Linux.  Maybe we are testing
differently.  What o/s and version are you using?  Does this
work with Python 2.4?  Can you attach a complete test case
that demonstrates this problem?

Thanks.

----------------------------------------------------------------------

Comment By: Lior (rudnik_lior)
Date: 2006-07-12 22:09

Message:
Logged In: YES 
user_id=1364480

Re-tried the code with empty file - it doesnt grow beyond
creating and writting at position 0 so it seems the seek
does influence the write position.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521491&group_id=5470

From noreply at sourceforge.net  Fri Jul 28 21:31:14 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 28 Jul 2006 12:31:14 -0700
Subject: [ python-Bugs-1530559 ] struct.pack raises TypeError where it used to
	convert
Message-ID: <E1G6Y3G-00078i-HP@sc8-sf-web3.sourceforge.net>

Bugs item #1530559, was opened at 2006-07-28 14:07
Message generated for change (Comment added) made by etrepum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530559&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Joe Wreschnig (piman)
Assigned to: Bob Ippolito (etrepum)
Summary: struct.pack raises TypeError where it used to convert

Initial Comment:
piman at toybox:~$ python2.4 -c "import struct;
struct.pack('>H', 1.0)"
piman at toybox:~$ python2.5 -c "import struct;
struct.pack('>H', 1.0)"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python2.5/struct.py", line 63, in pack
    return o.pack(*args)
TypeError: unsupported operand type(s) for &: 'float'
and 'long'

This might have appeared as part of the struct
optimizations; if struct isn't going to convert anymore
for performance reasons, I think this should be
mentioned in the release notes. Though personally I
would prefer struct go back to converting its arguments.

----------------------------------------------------------------------

>Comment By: Bob Ippolito (etrepum)
Date: 2006-07-28 15:31

Message:
Logged In: YES 
user_id=139309

That wasn't really intentional, but the old behavior looks a bit suspect:

$ python2.4 -c "import struct; print repr(struct.pack('>H', 1.6))"
'\x00\x01'

We could change it to check for floats and do a DeprecationWarning?

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-07-28 14:51

Message:
Logged In: YES 
user_id=849994

Bob?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530559&group_id=5470

From noreply at sourceforge.net  Fri Jul 28 21:44:50 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 28 Jul 2006 12:44:50 -0700
Subject: [ python-Bugs-1530559 ] struct.pack raises TypeError where it used to
	convert
Message-ID: <E1G6YGQ-0002zn-Qa@sc8-sf-web2.sourceforge.net>

Bugs item #1530559, was opened at 2006-07-28 18:07
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530559&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Joe Wreschnig (piman)
Assigned to: Bob Ippolito (etrepum)
Summary: struct.pack raises TypeError where it used to convert

Initial Comment:
piman at toybox:~$ python2.4 -c "import struct;
struct.pack('>H', 1.0)"
piman at toybox:~$ python2.5 -c "import struct;
struct.pack('>H', 1.0)"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python2.5/struct.py", line 63, in pack
    return o.pack(*args)
TypeError: unsupported operand type(s) for &: 'float'
and 'long'

This might have appeared as part of the struct
optimizations; if struct isn't going to convert anymore
for performance reasons, I think this should be
mentioned in the release notes. Though personally I
would prefer struct go back to converting its arguments.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-28 19:44

Message:
Logged In: YES 
user_id=849994

I think that's a question for python-dev.

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2006-07-28 19:31

Message:
Logged In: YES 
user_id=139309

That wasn't really intentional, but the old behavior looks a bit suspect:

$ python2.4 -c "import struct; print repr(struct.pack('>H', 1.6))"
'\x00\x01'

We could change it to check for floats and do a DeprecationWarning?

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-07-28 18:51

Message:
Logged In: YES 
user_id=849994

Bob?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530559&group_id=5470

From noreply at sourceforge.net  Sat Jul 29 00:03:43 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 28 Jul 2006 15:03:43 -0700
Subject: [ python-Bugs-1530448 ] ctypes build fails on Solaris 10
Message-ID: <E1G6aQp-0006os-Bp@sc8-sf-web6.sourceforge.net>

Bugs item #1530448, was opened at 2006-07-28 10:04
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530448&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Thomas Heller (theller)
Summary: ctypes build fails on Solaris 10

Initial Comment:
Thomas,

I tried to build Python from cvs (svn rev 50905) on
Solaris 10 today.
Compiler was gcc 3.4.  I got a text relocation error
when linking
ctypes.so:

/opt/app/g++lib6/gcc-3.4/bin/gcc -shared
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o
-L/usr/local/lib -o
build/lib.solaris-2.10-i86pc-2.5/_ctypes.so
Text relocation remains                         referenced
    against symbol                  offset      in file
ffi_closure_SYSV_inner              0x8e       
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o
ld: fatal: relocations remain against allocatable but
non-writable sections
collect2: ld returned 1 exit status

I tried configuring both with and without the
--with-system-ffi flag.
The error was the same in both cases.

If you need more information, let me know.

Skip


----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2006-07-28 17:03

Message:
Logged In: YES 
user_id=44345

Yeah, you'd definitely need -fPIC on any brand of Solaris.  That test might be 
changed to

    plat = get_platform()
    if plat in (... buncha platforms ...) or "solaris" in plat:
        os.environ["CFLAGS"] = "-fPIC"

That doesn't seem to be what's happening in this case though.  I rm'd the .o 
files in .../Modules/_ctypes and tried again.  The compile commands *do* 
have -fPIC on them.  I don't think it's required on the link line.

S


----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2006-07-28 11:19

Message:
Logged In: YES 
user_id=11105

Skip,

This looks *somewhat* like the problems reported in bugs
1529269 and 1528620 (although they have a sparc, and you
seem to have x86 solaris).

Hm, in the standalone ctypes setup script, I find this code
snippet:

if get_platform() in ["solaris-2.9-sun4u", "linux-x86_64"]:
    os.environ["CFLAGS"] = "-fPIC"

Can it be that -fPIC must be used, but is not specified?

It is also funny that the solaris buildbot does NOT seem to
have a problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530448&group_id=5470

From noreply at sourceforge.net  Sat Jul 29 00:04:19 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 28 Jul 2006 15:04:19 -0700
Subject: [ python-Bugs-1529871 ] distutils regression related to
	Distribution.run_command
Message-ID: <E1G6aRP-0005Sj-Li@sc8-sf-web5.sourceforge.net>

Bugs item #1529871, was opened at 2006-07-27 17:49
Message generated for change (Comment added) made by pje
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529871&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 6
Submitted By: Collin Winter (collinwinter)
Assigned to: Phillip J. Eby (pje)
Summary: distutils regression related to Distribution.run_command

Initial Comment:
The following used to work in Python 2.4.x but fails
under Python 2.5:

>>> import setuptools
>>> import distutils.core
>>> distutils.core._setup_stop_after = 'config'
>>> 
>>> import setup
>>> setup.dist.run_command('test')

Where setup.dist is an instance of
distutils.core.Distribution (which setuptools replaces
with setuptools.dist.Distribution).

Under Python 2.4.x, this code would execute setuptools'
test command. Under Python 2.5b2 (as of r50855), this
code results in the following exception:

/opt/dev/python/2.5/lib/python2.5/distutils/dist.py:263:
UserWarning: Unknown distribution option: 'test_suite'
  warnings.warn(msg)
Traceback (most recent call last):
  File "test.py", line 8, in <module>
    setup.dist.run_command('test')
  File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 992, in run_command
    cmd_obj = self.get_command_obj(command)
  File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 868, in get_command_obj
    klass = self.get_command_class(command)
  File
"/opt/dev/python/2.5/lib/python2.5/site-packages/setuptools/dist.py",
line 357, in get_command_class
    return _Distribution.get_command_class(self, command)
  File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 851, in get_command_class
    raise DistutilsModuleError("invalid command '%s'" %
command)
distutils.errors.DistutilsModuleError: invalid command
'test'

I'd greatly appreciate it if this regression could be
fixed before Python 2.5 is released.

----------------------------------------------------------------------

>Comment By: Phillip J. Eby (pje)
Date: 2006-07-28 22:04

Message:
Logged In: YES 
user_id=56214

Fixed in r50916 on the trunk.

----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2006-07-28 04:53

Message:
Logged In: YES 
user_id=56214

Um, why is there a py2.4 egg on your python 2.5 path?

Setuptools configures itself according to the Python version
it is built with, so a 2.4 egg is not going to be correctly
configured for 2.5.  I don't know if this is related to your
problem or not, but I was unable to reproduce your problem
with a setuptools 0.7a1 checkout.  I was only able to
reproduce it with setuptools 0.6.


----------------------------------------------------------------------

Comment By: Collin Winter (collinwinter)
Date: 2006-07-27 22:12

Message:
Logged In: YES 
user_id=1344176

I've tried using setuptools 0.7a1 in conjunction with Python
2.5b2 (r50877), and the problem still exists. setuptools'
extension commands still do not work (tested: rotate, alias,
egg_info, bdist_egg, test), that is, 'python2.5 setup.py
test' still fails with "error: invalid command 'test'".

Also, the code snippet in the bug report does not work. I am
sure Python is picking up setuptools 0.7a1 because the path
/opt/dev/python/2.5/lib/python2.5/site-packages/setuptools-0.7a1dev_r50755-py2.4.egg/setuptools/dist.py
appears in the traceback.

----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2006-07-27 21:13

Message:
Logged In: YES 
user_id=56214

Problem source confirmed: reverting the PEP 302 breakage of
r46372 (need-for-speed import cache hack) fixes the problem.

setuptools 0.7a1 doesn't show any problems because it uses
2.5's "pkgutil" module if possible, and r46372 patches
pkgutil in a way that masks the problem, at least as far as
setuptools is concerned, for this one specific feature. 
(Other code in setuptools is affected in both 0.6 *and* 0.7,
and will require further workaround code to be written.)



----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2006-07-27 18:35

Message:
Logged In: YES 
user_id=56214

I can't reproduce this using setuptools 0.7a1 and the Python
2.5 trunk.  Please note that setuptools 0.6 does *not*
support Python 2.5; there were numerous changes needed and
there may still be additional changes needed.  Please try
using setuptools 0.7a1 and let me know what you find out. 
Thanks.


----------------------------------------------------------------------

Comment By: Collin Winter (collinwinter)
Date: 2006-07-27 18:34

Message:
Logged In: YES 
user_id=1344176

Further testing reveals that all of setuptools' extension
commands (tested: egg_info, bdist_egg, test, rotate, alias)
are broken under Python 2.5b2, even when called from the
command line, like so:

$ python2.5 setup.py egg_info

This produces an "error: invalid command: 'egg_info'" message.

----------------------------------------------------------------------

Comment By: Collin Winter (collinwinter)
Date: 2006-07-27 18:18

Message:
Logged In: YES 
user_id=1344176

Forgot to mention: I've tried this with setuptools 0.6a9 and
0.6c1. Python 2.4.x (2.4.1, 2.4.2 and 2.4.3 tested) with
both setuptools version worked fine, where Python 2.5b2
fails with both.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-27 18:03

Message:
Logged In: YES 
user_id=11375

Assigned to Phillip.  I don't see any obviously relevant
changes to distutils/dist.py, but maybe this problems stems
from changes to some other module.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529871&group_id=5470

From noreply at sourceforge.net  Sat Jul 29 05:21:28 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 28 Jul 2006 20:21:28 -0700
Subject: [ python-Bugs-1530559 ] struct.pack raises TypeError where it used to
	convert
Message-ID: <E1G6fOK-0007rK-LU@sc8-sf-web3.sourceforge.net>

Bugs item #1530559, was opened at 2006-07-28 11:07
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530559&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
>Priority: 9
Submitted By: Joe Wreschnig (piman)
Assigned to: Bob Ippolito (etrepum)
Summary: struct.pack raises TypeError where it used to convert

Initial Comment:
piman at toybox:~$ python2.4 -c "import struct;
struct.pack('>H', 1.0)"
piman at toybox:~$ python2.5 -c "import struct;
struct.pack('>H', 1.0)"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python2.5/struct.py", line 63, in pack
    return o.pack(*args)
TypeError: unsupported operand type(s) for &: 'float'
and 'long'

This might have appeared as part of the struct
optimizations; if struct isn't going to convert anymore
for performance reasons, I think this should be
mentioned in the release notes. Though personally I
would prefer struct go back to converting its arguments.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-28 20:21

Message:
Logged In: YES 
user_id=33168

I'd like to see a deprecation warning so old code continues
to work.  struct is way to loose and needs to be tightened
up, but that might not fully happen until py3k.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-07-28 12:44

Message:
Logged In: YES 
user_id=849994

I think that's a question for python-dev.

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2006-07-28 12:31

Message:
Logged In: YES 
user_id=139309

That wasn't really intentional, but the old behavior looks a bit suspect:

$ python2.4 -c "import struct; print repr(struct.pack('>H', 1.6))"
'\x00\x01'

We could change it to check for floats and do a DeprecationWarning?

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-07-28 11:51

Message:
Logged In: YES 
user_id=849994

Bob?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530559&group_id=5470

From noreply at sourceforge.net  Sat Jul 29 05:25:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 28 Jul 2006 20:25:23 -0700
Subject: [ python-Bugs-1530012 ] Literal strings use BS as octal escape
	character
Message-ID: <E1G6fS7-0001SA-HO@sc8-sf-web3.sourceforge.net>

Bugs item #1530012, was opened at 2006-07-27 15:08
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530012&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: brucepeterson (brucepeterson)
Assigned to: Nobody/Anonymous (nobody)
Summary: Literal strings use BS as octal escape character

Initial Comment:
Also in 2.4


  Using a literal to hard code a path.  My directory 
happened to start with a number and I couldn't open 
the file due to the bad directory name.  Found that 
the tripple quote was operating as documented.

  I would have at least expected the tripple double 
quotes to not have an escape character.  (Is this a 
pep?)  (From my reading of the Introduction, the 
triple double quotes should act like a raw string 
except that you can have a single double quote 
included in the string.)

-------------
code snippet:
-------------
dir1 = """C:\1stDirecotry"""
dir2 = '''C:\2ndDirecotry'''
dir3 = '''C:\9thDirecotry'''
print dir1, dir2, dir3

C:?stDirecotry C:?ndDirecotry C:\9thDirecotry

dir1's format was not expected, dir2's format might be 
expected.

>>> '''\1'''
'\x01'
>>> '''\9'''
'\\9'

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-28 20:25

Message:
Logged In: YES 
user_id=33168

Triple quotes are just like single or double quotes wrt
escaping.  You need to prefix the string with an r: 
r"C:\1stDirecotry" to get what you want.

This is probably documented in many places.  I'm not sure
where you looked or where you expected it to be documented.
 Can you suggest improvements?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530012&group_id=5470

From noreply at sourceforge.net  Sat Jul 29 09:45:56 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 29 Jul 2006 00:45:56 -0700
Subject: [ python-Bugs-1112549 ] cgi.FieldStorage memory usage can spike in
	line-oriented ops
Message-ID: <E1G6jWG-0002KK-7J@sc8-sf-web3.sourceforge.net>

Bugs item #1112549, was opened at 2005-01-30 13:40
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112549&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
>Priority: 8
Submitted By: Chris McDonough (chrism)
Assigned to: Nobody/Anonymous (nobody)
Summary: cgi.FieldStorage memory usage can spike in line-oriented ops

Initial Comment:
Various parts of cgi.FieldStorage call its
"read_lines_to_outerboundary", "read_lines" and
"skip_lines" methods.    These methods use the
"readline" method of the file object that represents an
input stream.  The input stream is typically data
supplied by an untrusted source (such as a user
uploading a file from a web browser).  The input data
is not required by the RFC 822/1521/1522/1867
specifications to contain any newline characters.  For
example, it is within the bounds of the specification
to supply a a multipart/form-data input stream with a
"file-data" part that consists of a 2GB string composed
entirely of "x" characters (which happens to be
something I did that led me to noticing this bug).

The simplest fix is to make use of the "size" argument
of the readline method of the file object where it is
used within all parts of FieldStorage that make use of
it.  A patch against the Python 2.3.4 cgi.py module
that does this is attached.

----------------------------------------------------------------------

Comment By: Chris McDonough (chrism)
Date: 2006-07-27 21:42

Message:
Logged In: YES 
user_id=32974

The files I've just uploaded are revisions to the cgi and test_cgi modules for the 
current state of the SVN trunk.  If someone could apply these, it would be 
appreciated, or give me access and I'll be happy to.

FTR, this is a bug which exposes systems which use the cgi.FieldStorage class 
(most Python web frameworks do) to a denial of service potential.

----------------------------------------------------------------------

Comment By: Chris McDonough (chrism)
Date: 2005-04-03 04:00

Message:
Logged In: YES 
user_id=32974

FYI, I'd be happy to do the merging here if you wanted to
give me checkin access.

----------------------------------------------------------------------

Comment By: Chris McDonough (chrism)
Date: 2005-04-03 03:42

Message:
Logged In: YES 
user_id=32974

An updated test_cgi.py is attached.  I test both the
readline behavior and add a test for basic multipart parsing. 

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2005-04-01 04:48

Message:
Logged In: YES 
user_id=6380

Can I tweak you into uploading a unit test?

----------------------------------------------------------------------

Comment By: Chris McDonough (chrism)
Date: 2005-04-01 02:56

Message:
Logged In: YES 
user_id=32974

Re: parse_multipart..  yes, it looks like there's no use
fixing that as it just turns around and puts the line into a
list.. it is vulnerable but just by virtue of its non-use of
a tempfile, it appears doomed anyway for large requests.  I
don't know of anything that uses it.
 
Good catch wrt boundary recognition bug, I'm uploading
another patch.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2005-03-31 22:13

Message:
Logged In: YES 
user_id=6380

Methinks that the fix isn't quite right: it would
incorrectly recognize as a boundary a very long line
starting with "--" followed by the appropriate random string
at offset 2**16. This could probably be taken care of by
adding a flag that is true initially and after that keeps
track of whether the previous line ended in \n.

Also, there's a call to fp.readline() in parse_multipart()
that you didn't patch -- it wouldn't help because that code
is saving the lines in a list anyway, but isn't that code
vulnerable as well? Or is it not used?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112549&group_id=5470

From noreply at sourceforge.net  Sat Jul 29 10:51:40 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 29 Jul 2006 01:51:40 -0700
Subject: [ python-Bugs-835255 ] new.function() docs out of date
Message-ID: <E1G6kXs-000127-H0@sc8-sf-web1.sourceforge.net>

Bugs item #835255, was opened at 2003-11-03 20:26
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835255&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Jeremy Hylton (jhylton)
Summary: new.function() docs out of date

Initial Comment:
The argument list for new.function() has grown to
accomodate new runtime features (closure info, for
example), but the docs have not kept up.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-29 08:51

Message:
Logged In: YES 
user_id=849994

Documented closure argument in rev. 50922, 50923.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-11-20 13:01

Message:
Logged In: YES 
user_id=3066

Assigned to Jeremy since he made the changes and can explain
what the new arguments are for.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835255&group_id=5470

From noreply at sourceforge.net  Sat Jul 29 11:34:02 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 29 Jul 2006 02:34:02 -0700
Subject: [ python-Bugs-1441397 ] compiler module loses docstrings
Message-ID: <E1G6lCs-0005iH-G0@sc8-sf-web3.sourceforge.net>

Bugs item #1441397, was opened at 2006-03-02 00:52
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1441397&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Nobody/Anonymous (nobody)
Summary: compiler module loses docstrings

Initial Comment:
this is svn head:

>>> import compiler
>>> compiler.transformer.parse("'doc'")
Module(None, Stmt([Discard(Const('doc'))]))

this is 2.4:

>>> import compiler
>>> compiler.transformer.parse("'doc'")
Module('doc', Stmt([]))

I think the problem may be rooted in the parser module rather than the 
compiler module itself.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-29 09:34

Message:
Logged In: YES 
user_id=849994

The bug was transformer._doc_nodes missing or_test.
Fixed in rev. 50924, including test.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1441397&group_id=5470

From noreply at sourceforge.net  Sat Jul 29 12:30:43 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 29 Jul 2006 03:30:43 -0700
Subject: [ python-Bugs-1014230 ] optparse: parser.remove_option("-h")
	inconsistency
Message-ID: <E1G6m5j-0008B6-0V@sc8-sf-web3.sourceforge.net>

Bugs item #1014230, was opened at 2004-08-23 10:04
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014230&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: strop (strop)
>Assigned to: Greg Ward (gward)
Summary: optparse: parser.remove_option("-h") inconsistency

Initial Comment:
remove_option("-h") method of OptionParser has a strange 
behaviour : it can't be removed from 2 different OptionParser 
objects. 
It may be due to the fact that the help option seems to be a 
unique object. 
Even if this can be "solved" by addind add_help_option=0 to 
OptionParser constructor parameters, it seems to be an 
inconsistency wrt remove_option method 
 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014230&group_id=5470

From noreply at sourceforge.net  Sat Jul 29 12:36:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 29 Jul 2006 03:36:42 -0700
Subject: [ python-Bugs-1246405 ] Segmentation fault when importing expat from
	xml.parser
Message-ID: <E1G6mBW-0002g4-Kh@sc8-sf-web3.sourceforge.net>

Bugs item #1246405, was opened at 2005-07-27 23:07
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246405&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: XML
Group: Python 2.4
>Status: Pending
>Resolution: Fixed
Priority: 5
Submitted By: Jean-Pierre (jean-pierre24)
Assigned to: Nobody/Anonymous (nobody)
Summary: Segmentation fault when importing expat from xml.parser

Initial Comment:
 Hello,

I have a strange segmentation fault when importing
expat from xml.parsers in the following program (I
removed all that is un-necessary to reproduce the bug,
which is why the code may look odd).

I've also posted this bug on wxPython bug lists because
I'm not sure if it's related to Python or wxPython, but
anyway the backtrace told me that the segmentation
fault occurs when importing expat.

import wx
import wx.html

class MainFrame(wx.Frame):
def __init__(self, prnt):
wx.Frame.__init__(self, parent=prnt)
wx.html.HtmlWindow(wx.Window(self, -1), -1)
print "debug 1"
from xml.parsers import expat
print "debug 2"

class BoaApp(wx.App):
def OnInit(self):
wx.InitAllImageHandlers()
MainFrame(None)
return True

app = BoaApp()

The segmentation fault occurs between 'debug 1' and
'debug 2'. If I try to remove anything else, it doesn't
happen.
I have confirmed the bug on SunOS 5.8, on linux Red Hat
Enterprise Server 3 and linux Advanced Server 3.
I'm working with Python 2.4.1 and wxPython 2.6.1.0
Here is in attached file, the backtrace from gdb.

Feel free to ask me any additional information...


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-29 10:36

Message:
Logged In: YES 
user_id=849994

Patch 1295808 should have fixed this. Can you try it with
Python 2.5b2?

----------------------------------------------------------------------

Comment By: Bernhard Herzog (bernhard)
Date: 2005-12-01 13:51

Message:
Logged In: YES 
user_id=2369

Could this be the same problem as bug 1075984 ?
URL:
https://sourceforge.net/tracker/index.php?func=detail&aid=1075984&group_id=5470&atid=105470


----------------------------------------------------------------------

Comment By: Jean-Pierre (jean-pierre24)
Date: 2005-10-06 20:23

Message:
Logged In: YES 
user_id=1247525

Yes I can try with different version of wx, but it will take
time.
Anyway for today here is in attachment the valgrind output
on linux x86.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-05 03:34

Message:
Logged In: YES 
user_id=33168

I don't have the problem with Python 2.3.4 and wx 2.5.5.1.

Are you able to try different versions of wxPython?  I
notice that wx 2.6.2 is available.  Are you able to run
under valgrind or purify?

If you run under valgrind, be sure to specify
--suppressions=Misc/valgrind-python.supp
The file is in the Python distribution.  You can download it
through SourceForge ViewCVS.

----------------------------------------------------------------------

Comment By: Jean-Pierre (jean-pierre24)
Date: 2005-10-04 22:05

Message:
Logged In: YES 
user_id=1247525

Link is :
http://sourceforge.net/tracker/index.php?func=detail&aid=1246397&group_id=9863&atid=109863

Unfortunately, absolutely nothing has happened since I
reported the bug.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-04 05:10

Message:
Logged In: YES 
user_id=33168

Can you provide a link to the wx bug report?  Has anything
happend with it?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246405&group_id=5470

From noreply at sourceforge.net  Sat Jul 29 12:39:51 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 29 Jul 2006 03:39:51 -0700
Subject: [ python-Bugs-1075984 ] Memory fault pyexpat.so on SGI
Message-ID: <E1G6mEZ-0004Ea-LH@sc8-sf-web3.sourceforge.net>

Bugs item #1075984, was opened at 2004-11-30 13:13
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075984&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: XML
Group: Python 2.4
>Status: Pending
>Resolution: Fixed
Priority: 5
Submitted By: Maik Hertha (mhertha)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Memory fault pyexpat.so on SGI

Initial Comment:
I build the latest RC1 of python 2.4.
System SGI Fuel IP35, Irix 6.5.26m

cc -version
MIPSpro Compilers: Version 7.3.1.3m

- make tests passes test_pyexpat without error
- running this code leads to a core dump

-- code ---
import xml.dom.minidom
doc = xml.dom.minidom.parseString(fstream)

<<< core dump >>>
--- runing python -v test.py
#
/opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc
matches
/opt/python24c1/lib/python2.4/xml/dom/expatbuilder.py
import xml.dom.expatbuilder # precompiled from
/opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc
import xml.parsers # directory
/opt/python24c1/lib/python2.4/xml/parsers
#
/opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc
matches
/opt/python24c1/lib/python2.4/xml/parsers/__init__.py
import xml.parsers # precompiled from
/opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc
# /opt/python24c1/lib/python2.4/xml/parsers/expat.pyc
matches /opt/python24c1/lib/python2.4/xml/parsers/expat.py
import xml.parsers.expat # precompiled from
/opt/python24c1/lib/python2.4/xml/parsers/expat.pyc
dlopen("/opt/python24c1/lib/python2.4/lib-dynload/pyexpat.so",
2);
Memory fault(coredump)

- running this code from an interactive session leads
not to a coredump

I need some assistance howto provide further debug
information.

--maik./

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-29 10:39

Message:
Logged In: YES 
user_id=849994

This should be addressed by patch #1295808.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-10-02 08:24

Message:
Logged In: YES 
user_id=21627

I think the problem will occur whenever somebody loads
libexpat.so with dlopen and RTLD_GLOBAL. IMO, this should be
avoided. I can't see in which of these different reports
this really is the case, but in those cases, this much looks
like a third-party bug.

If you import pyexpat first, it looks fine, since it will
resolve the symbols against its own copy, without exporting
them. Then, the later usage of libexpat cannot mistakenly go
into pyexpat because Python loaded this with RTLD_LOCAL.
However, it still may crash later when symbols are resolved
lazily, as more expat symbols might be needed when using
pyexpat, so different symbols might go to different libraries.

Linking pyexpat with -Bsymbolic (where available) should
also solve the problem.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-30 06:01

Message:
Logged In: YES 
user_id=33168

The problem seems to be related (same?) as bug #1295808. 
Does the patch there fix these problems?

----------------------------------------------------------------------

Comment By: Steve Juranich (sjuranic)
Date: 2005-07-19 16:22

Message:
Logged In: YES 
user_id=1315245

FWIW, this same problem crops up when using Python & VTK
together (which also ships with its own version of expat). 
bos's workaround will make things work, though.

----------------------------------------------------------------------

Comment By: Bernhard Herzog (bernhard)
Date: 2005-03-29 18:11

Message:
Logged In: YES 
user_id=2369

I ran into this problem as well on a debian GNU/Linux system
on x86 hardware.  It occurs both with pygtk 2.4 and wxPython
2.5 both built against gtk 2.4.

bos' patch at least solves the immediate problem of the
segmentation fault.  It may be a good idea to print a
warning message if some of the error codes cannot be
translated to strings, though.


----------------------------------------------------------------------

Comment By: Bryan O'Sullivan (bos)
Date: 2005-02-04 23:16

Message:
Logged In: YES 
user_id=28380

With the GNU linker, you can pass in -Bstatic to force it to resolve the symbols in the local shared library, instead of globally. This also works on Irix. I don't know about other Unixes.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-02-02 10:35

Message:
Logged In: YES 
user_id=6656

It's a nasty one, I'll give you that.

Fred, what do you think of bos's patch?  It solves the immediate issue, 
but I'm not sure it's a complete fix.

It seems to me that it would be better to resolve the expat symbols at 
builf time, but I don't know how to arrange for that.

----------------------------------------------------------------------

Comment By: Bryan O'Sullivan (bos)
Date: 2005-02-02 06:09

Message:
Logged In: YES 
user_id=28380

By the way, this is not an SGI-specific bug. This will bite any Unix system with a modern sysv-style dynamic linker. The priority of this bug should be higher, IMO.

----------------------------------------------------------------------

Comment By: Bryan O'Sullivan (bos)
Date: 2005-02-01 07:53

Message:
Logged In: YES 
user_id=28380

I've been bitten by the same bug. In my case, the problem was with Qt, not GTK.

It's not actually necessary to check the expat version; just see if XML_ErrorString actually returns anything.

Here's the patch I use for this problem:

--- python/Modules/pyexpat.c        2005-01-06 16:26:13 -08:00
+++ python/Modules/pyexpat.c  2005-01-31 23:46:36 -08:00
@@ -1936,9 +1936,12 @@
     }
 #endif

-#define MYCONST(name) \
-    PyModule_AddStringConstant(errors_module, #name, \
-                               (char*)XML_ErrorString(name))
+#define MYCONST(name)                           \
+    { \
+        char *_v = (char*)XML_ErrorString(name); \
+        if (_v) \
+            PyModule_AddStringConstant(errors_module, #name, _v); \
+    }

     MYCONST(XML_ERROR_NO_MEMORY);
     MYCONST(XML_ERROR_SYNTAX);


----------------------------------------------------------------------

Comment By: Stephen Watson (kerofin)
Date: 2004-12-13 13:46

Message:
Logged In: YES 
user_id=471223

pyexpat initializes using its internal copy of expat. 
libexpat.so is still mapped in (after pyexpat has
initilized), but gdb finds the python copy of
XML_ErrorString and other functions.

I suspect that this will be a problem if the system version
of expat is newer than Python's.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-12-13 13:01

Message:
Logged In: YES 
user_id=6656

1) Good sleuthing.
2) Argh!
3) What happens if you import pyexpat before pygtk?

----------------------------------------------------------------------

Comment By: Stephen Watson (kerofin)
Date: 2004-12-13 09:29

Message:
Logged In: YES 
user_id=471223

I've looked at the program that was dumping core and the
sequence is this:

1) Program imports pygtk, which links in the GTK libraries
2) Program loads SVG image which links in librsvg.so which
in turn links in /usr/local/lib/libexpat.so
3) Program imports pyexpat.
4) pyexpat calls XML_ErrorString, but as ld.so has already
linked in XML_ErrorString from /usr/local/lib/libexpat.so it
calls that version, not the one in pyexpat.so.  
5) pyexpat looks up an error defined by the later version of
expat it is expecting and gets a NULL pointer from the
earlier version it has.  It attempts to use it without
checking (strlen) and dumps core.

----------------------------------------------------------------------

Comment By: Stephen Watson (kerofin)
Date: 2004-12-10 17:01

Message:
Logged In: YES 
user_id=471223

Maybe it compiled against its own copy of expat, but pulled
in the system's copy when run?  

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-12-10 16:52

Message:
Logged In: YES 
user_id=6656

Uh, Python includes its own copy of expat, and I really
thought we were supposed to prefer our own version over
anything found on the system...

----------------------------------------------------------------------

Comment By: Stephen Watson (kerofin)
Date: 2004-12-10 16:46

Message:
Logged In: YES 
user_id=471223

I also got a core dump importing pyexpat on Solaris (SPARC)
and somebody else reported it on a *BSD system.

It appears to be a problem with older versions of expat not
being tested for.  I used gdb to trace it down to line 1972
in pyexpat.c where it attempts to define the first constant
from 1.95.8.  I had expat 1.95.7.  After upgrading to 1.95.8
it worked fine, as did the *BSD system. 

I think Python needs to check the expat version, as it does
elsewhere in the file, before defining those constants. 

I am still puzzelled over how it managed to compile
pyexpat.c in the first place...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075984&group_id=5470

From noreply at sourceforge.net  Sat Jul 29 12:41:26 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 29 Jul 2006 03:41:26 -0700
Subject: [ python-Bugs-1437785 ] Problems w/ expat 1.95.7 vs. Python 2.4
Message-ID: <E1G6mG6-0004G3-DQ@sc8-sf-web2.sourceforge.net>

Bugs item #1437785, was opened at 2006-02-23 23:59
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1437785&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: XML
Group: Python 2.4
>Status: Pending
>Resolution: Fixed
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problems w/ expat 1.95.7 vs. Python 2.4

Initial Comment:
This may apply to the trunk as well...

Today I finished installing 2.4.2 and all our local libraries at work.
Trying out the main application I use I discovered Python segfaulting
when trying to import pyexpat.  It turned out that during the import
an earlier module (gtk.glade) also wanted libexpat.  Apparently pyexpat
was expecting to get Expat 1.95.8 (what's delivered with Python) but
got 1.95.7 instead (what we had installed and what was already linked
with all our other Expat-using code).

The solution was rather simple.  I just commented out those constants
in the pyexpat initialization that were marked as 1.95.8.  Fortunately
there was a comment identifying the version dependency.

Is there some way that Python's build process can detect the Expat
version and conditionally include/exclude bits that are for later
versions?


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-29 10:41

Message:
Logged In: YES 
user_id=849994

Should be fixed by patch #1295808.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2006-03-03 20:15

Message:
Logged In: YES 
user_id=44345

Martin, I'm sorry.  If I understood it better I'd explain it
better.
Tell me if this helps.  We have expat 1.95.7 installed. We
have C++
libraries that link with that version and are wrapped for
use with
Python using SWIG.  Python 2.4 comes with 1.95.8. 
Apparently setup.py
finds that and compiles pyexpat against it.  In the pyexpat init
function I see this block of constant initialization:

    /* Added in Expat 1.95.8. */
    MYCONST(XML_ERROR_UNDECLARING_PREFIX);
    MYCONST(XML_ERROR_INCOMPLETE_PE);
    MYCONST(XML_ERROR_XML_DECL);
    MYCONST(XML_ERROR_TEXT_DECL);
    MYCONST(XML_ERROR_PUBLICID);
    MYCONST(XML_ERROR_SUSPENDED);
    MYCONST(XML_ERROR_NOT_SUSPENDED);
    MYCONST(XML_ERROR_ABORTED);
    MYCONST(XML_ERROR_FINISHED);
    MYCONST(XML_ERROR_SUSPEND_PE);

If they are left in there, Python reliably segfaults at the
first of
those lines.  When I exclude those lines, everything works
fine.  If I
run ldd over pyexpat.so I don't see that libexpat is dynamically
linked in:

    % ldd pyexpat.so
	    libgcc_s.so.1 =>        
/opt/lang/gcc-3.3.2/lib/libgcc_s.so.1
	    libc.so.1 =>     /lib/libc.so.1
	    libm.so.2 =>     /lib/libm.so.2

I thus have a statically linked version of libexpat 1.95.8 which
appears to be exporting symbols:

    % nm -p pyexpat.so  | egrep XML
    0000042312 T XML_DefaultCurrent
    0000042380 T XML_ErrorString
    0000042428 T XML_ExpatVersion
    0000042452 T XML_ExpatVersionInfo
    0000039164 T XML_ExternalEntityParserCreate
    0000042232 T XML_FreeContentModel
    0000040580 T XML_GetBase
    0000041584 T XML_GetBuffer
    ...

Elsewhere I have a C++ library that is dynamically linked to
1.95.7,
so I essentially have libexpat linked into the system twice.

Does that seem like a reasonable description of our setup? 
If so, I
can understand that trying to use (for example)
XML_ERROR_UNDECLARING_PREFIX (which is new to 1.95.8) with
symbols
from libexpat 1.95.7 might create problems.  I don't see how
it could
cause problems during constant initialization, but it does,
quite
reliably.  You're much more savvy about these things than I
am.  Maybe
you can see how this would happen.

How do we tell Python's build process not to use the bundled
1.95.8?
My local C++ gurus tell me they are not willing to rebuild
everything
with 1.95.8 just to make pyexpat happy.  If we tell it that,
then
those constant initialization lines need to be conditionally
exposed
to the compiler so that it works to compile with libexpat
1.95.7.



----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-03-03 17:44

Message:
Logged In: YES 
user_id=21627

I don't understand the problem. The build process should have picked-up
the Python-provided expat, and should have ignored the system-installed
one in all places (compiling, linking, running).

What was the specific sequence of commands that you entered, what
what the output you got, and what output would you have expected instead?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1437785&group_id=5470

From noreply at sourceforge.net  Sat Jul 29 12:51:27 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 29 Jul 2006 03:51:27 -0700
Subject: [ python-Bugs-883495 ] python crash in pyexpat's
	XmlInitUnknownEncodingNS
Message-ID: <E1G6mPn-0001OU-3r@sc8-sf-web3.sourceforge.net>

Bugs item #883495, was opened at 2004-01-24 07:15
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=883495&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.3
>Status: Closed
Resolution: Works For Me
Priority: 7
Submitted By: Matthias Klose (doko)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: python crash in pyexpat's XmlInitUnknownEncodingNS

Initial Comment:
[forwarded from http://bugs.debian.org/229281]

seen with 2.3.3, works with 2.2.3 and 2.1.3 (after
fixing the 2.1 incompatibilities). The pyexpat code
used is the one direct from the distribution, no
external library.

The attached testcase demonstrates a bug in,
apparently, /usr/lib/python2.3/lib-dynload/pyexpat.so.
Here's the bug in gdb: 
 
Program received signal SIGSEGV, Segmentation fault. 
[Switching to Thread 16384 (LWP 28350)] 
0x40566800 in XmlInitUnknownEncodingNS () 
   from /usr/lib/python2.3/lib-dynload/pyexpat.so 
 
To try it youself, run "make" in the testcase
directory. I apoligise for the size of this testcase; I
would have whitteled it down to something simpler, but
I am not a python programmer. I also apoligise if the
bug is really in some library that python uses; I only
went back as far as pyexpat.so. 
 
Some developers on IRC feel this may be exploitable.
Talk with Scott James Remnant <scott at netsplit.com>, who
also has some idea of the encoding problems in the rss
file that are causing the crash. 


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-29 10:51

Message:
Logged In: YES 
user_id=849994

Doesn't occur in 2.3.5, 2.4 head and SVN head. The patch
doesn't apply to expat 2.0 anymore. => Closing.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-30 05:14

Message:
Logged In: YES 
user_id=33168

Martin, this seems to work in Python 2.3.4, 2.4.2 and CVS. 
Has it been fixed and can it be closed?

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-04-20 19:44

Message:
Logged In: YES 
user_id=21627

The parser crashes because it invokes GetBuffer inside
Parser, when Python is providing the next chunk of input,
which reallocs the buffer to a different location. However,
eventPtr is not updated inside GetBuffer (and neither is
positionPtr). As a result, the next access to eventPtr (in
XML_GetCurrentLineNumber, invoked from set_error), will
cause a segfault.

It is not clear to me why these pointers are not adjusted
when the buffer is reallocated. However, a consistent fix
appears to be to update the eventPtr close to the place
where positionPtr is initialized, which is done in the
attached patch exp.diff, which fixes this test case.

Fred, can you please review this patch?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=883495&group_id=5470

From noreply at sourceforge.net  Sat Jul 29 16:25:08 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 29 Jul 2006 07:25:08 -0700
Subject: [ python-Bugs-1529157 ] readline module description should mention
	raw_input()
Message-ID: <E1G6pka-00025C-E9@sc8-sf-web3.sourceforge.net>

Bugs item #1529157, was opened at 2006-07-26 14:13
Message generated for change (Settings changed) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529157&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Thom Harp (thomharp)
>Assigned to: A.M. Kuchling (akuchling)
Summary: readline module description should mention raw_input()

Initial Comment:
The description of the readline module in the library
reference should mention that it alters the behavior of
the input() and raw_input() functions.  Without this
change, it isn't obvious how to use readline to provide
a command line in applications.

The information requested *is* in the docs where
input() and raw_input() are described, but an
inexperienced python programmer, just learning his way
around the standard library, won't know that and may
conclude that the readline module exists only because
it's used for interactive python.

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-29 10:25

Message:
Logged In: YES 
user_id=11375

I've added a mention to the first paragraph of the module's
docs. Thanks for the suggestion!


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529157&group_id=5470

From noreply at sourceforge.net  Sat Jul 29 16:41:16 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 29 Jul 2006 07:41:16 -0700
Subject: [ python-Bugs-1519571 ] turtle.py Docs still incomplete
Message-ID: <E1G6q0C-0008AI-Lt@sc8-sf-web5.sourceforge.net>

Bugs item #1519571, was opened at 2006-07-09 10:49
Message generated for change (Settings changed) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519571&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Lingl (gregorlingl)
>Assigned to: A.M. Kuchling (akuchling)
Summary: turtle.py Docs still incomplete

Initial Comment:
There are three functions in turtle.py (which do not
occur as methods of Pen), which are still not
documented:

setup()
title()
done()

Regards,
Gregor

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519571&group_id=5470

From noreply at sourceforge.net  Sat Jul 29 16:46:41 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 29 Jul 2006 07:46:41 -0700
Subject: [ python-Bugs-1519571 ] turtle.py Docs still incomplete
Message-ID: <E1G6q5R-0003Gl-Fq@sc8-sf-web3.sourceforge.net>

Bugs item #1519571, was opened at 2006-07-09 10:49
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519571&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Lingl (gregorlingl)
Assigned to: A.M. Kuchling (akuchling)
Summary: turtle.py Docs still incomplete

Initial Comment:
There are three functions in turtle.py (which do not
occur as methods of Pen), which are still not
documented:

setup()
title()
done()

Regards,
Gregor

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-29 10:46

Message:
Logged In: YES 
user_id=11375

I've added documentation for these methods in rev. 50932. 
Thanks for pointing out the omission!


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519571&group_id=5470

From noreply at sourceforge.net  Sat Jul 29 17:12:30 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 29 Jul 2006 08:12:30 -0700
Subject: [ python-Bugs-1414697 ] inconsistency in help(set)
Message-ID: <E1G6qUQ-0003nY-V0@sc8-sf-web6.sourceforge.net>

Bugs item #1414697, was opened at 2006-01-25 10:43
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1414697&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Gregory Petrosyan (gregory_p)
Assigned to: Raymond Hettinger (rhettinger)
Summary: inconsistency in help(set)

Initial Comment:
>>> help(set)

Help on class set in module __builtin__:

class set(object)
 |  set(iterable) --> set object
 |
 |  Build an unordered collection.
 |
 |  Methods defined here:
 |      ...


It would be better for docstring to be """Build an
unordered collection with no duplicate elements.""" 
instead of """Build an unordered collection."""

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-29 11:12

Message:
Logged In: YES 
user_id=11375

Thanks for your suggestion; I've added 'unordered collection
of unique elements' in rev. 50934.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1414697&group_id=5470

From noreply at sourceforge.net  Sat Jul 29 17:35:54 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 29 Jul 2006 08:35:54 -0700
Subject: [ python-Bugs-1530382 ] ssl object documentation lacks a couple of
	methods
Message-ID: <E1G6qr4-00016K-52@sc8-sf-web2.sourceforge.net>

Bugs item #1530382, was opened at 2006-07-28 09:20
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530382&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Lawrence Oluyede (rhymes)
>Assigned to: A.M. Kuchling (akuchling)
Summary: ssl object documentation lacks a couple of methods

Initial Comment:
According to
http://docs.python.org/dev/lib/ssl-objects.html the SSL
Objects expose only write() and read() but they also
expose issuer() and server() methods.

See Modueles/_ssl.c from line 557 to 565

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-29 11:35

Message:
Logged In: YES 
user_id=11375

I've documented these methods in rev. 50935.  Thanks for
pointing out this omission!



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530382&group_id=5470

From noreply at sourceforge.net  Sat Jul 29 17:41:16 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 29 Jul 2006 08:41:16 -0700
Subject: [ python-Bugs-1504456 ] xmlcore needs to be documented
Message-ID: <E1G6qwG-0003Yx-QT@sc8-sf-web2.sourceforge.net>

Bugs item #1504456, was opened at 2006-06-11 15:50
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504456&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
>Status: Closed
>Resolution: Rejected
Priority: 6
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: xmlcore needs to be documented

Initial Comment:
The change from the "xml" package to the "xmlcore"
package needs to be documented for Python 2.5.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-29 11:41

Message:
Logged In: YES 
user_id=3066

The switch from "xml" to "xmlcore" is being revoked; this no
longer applies.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-17 01:48

Message:
Logged In: YES 
user_id=3066

I've added a brief mention of the xmlcore package in the
chapter intro.  Each module reference section needs to have
something added still.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-06-20 09:20

Message:
Logged In: YES 
user_id=11375

I've added this to rev. 47044 of the "What's New".

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504456&group_id=5470

From noreply at sourceforge.net  Sat Jul 29 18:13:12 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 29 Jul 2006 09:13:12 -0700
Subject: [ python-Bugs-1528258 ] urllib2 data argument
Message-ID: <E1G6rRA-0004rQ-VV@sc8-sf-web6.sourceforge.net>

Bugs item #1528258, was opened at 2006-07-25 05:13
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528258&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: paul rubin (phr)
>Assigned to: A.M. Kuchling (akuchling)
Summary: urllib2 data argument

Initial Comment:
urllib2.Request takes constructor args (url, data,
headers, ...) where data and headers are optional. 
data is described as a string which, if supplied,
causes urlopen to process the request as a POST rather
than a GET.  And there's no way to set headers without
passing a value for data.  So if you want to send a GET
with special headers, the docs leave you scratching
your head.

The solution is to pass None instead of a string for
data.  The doc should say that.

In general the urllib2 docs are somewhat dependent on
the urllib docs.  Some refactoring would be good.

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-29 12:13

Message:
Logged In: YES 
user_id=11375

I've added None as a value for 'data in rev. 50939.  Thanks
for pointing this out!


----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2006-07-25 05:13

Message:
Logged In: YES 
user_id=72053

Forgot to mention, this is Python 2.4.1.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528258&group_id=5470

From noreply at sourceforge.net  Sat Jul 29 19:04:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 29 Jul 2006 10:04:05 -0700
Subject: [ python-Bugs-1513611 ] xml.sax.ParseException weirdness in python
	2.5b1
Message-ID: <E1G6sEP-0006bf-EC@sc8-sf-web6.sourceforge.net>

Bugs item #1513611, was opened at 2006-06-27 17:06
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513611&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: XML
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 9
Submitted By: Marien Zwart (marienz)
Assigned to: Nobody/Anonymous (nobody)
Summary: xml.sax.ParseException weirdness in python 2.5b1

Initial Comment:
There is something weird going on with xml.sax
exceptions, probably related to the xml/xmlcore shuffle:

from xml.sax import make_parser, SAXParseException
from StringIO import StringIO

parser = make_parser()

try:
    parser.parse(StringIO('invalid'))
except SAXParseException:
    print 'caught it!'

On python 2.4.3 this prints "caught it!". On python
2.5b1 the exception is not caught, because it is a
different  exception: an
xmlcore.sax._exceptions.SAXParseException. Printing the
SAXParseException imported from xml.sax gives "<class
'xml.sax._exceptions.SAXParseException'>".

Stumbled on this running the logilab-common (see
logilab.org) tests with python 2.5b1, but it seems
likely other code will be affected.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-29 13:04

Message:
Logged In: YES 
user_id=3066

The xmlcore package has been reverted as of revision 50941.

This problem report no longer applies, but a test has been
added as part of the removal of the xmlcore package to
ensure this does not re-surface.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-26 23:31

Message:
Logged In: YES 
user_id=33168

I think Martin is of the same opinion.  This needs to be
resolved soon.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-26 23:03

Message:
Logged In: YES 
user_id=3066

I've managed to come up with a patch that solves this
specific issue, but it really deals with the symptom and not
the real problems.

While I think the "xmlcore" package was the right idea, I'm
not convinced it can be correctly implemented without
enormous effort at this time.  Given the release schedule,
it doesn't make sense to jump through those hoops.  The
previous hackery that made allowed the PyXML distribution to
"replace" the standard library version of the "xml" package
worked only because there was only one public name for
whichever was being used.  Moving to the "xmlcore" package
proved to be more than that hack could support.

I think the right thing to do for Python 2.5 is to revert
the changes that added the "xmlcore" package.  Further
investigation into a better approach can be made for Python 2.6.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-26 22:36

Message:
Logged In: YES 
user_id=3066

The patch attached contains the wrong bug number, but it
really is for this issue.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-26 22:01

Message:
Logged In: YES 
user_id=3066

Patch #1519796 does not do anything for this, based on the
current trunk.  I've attached a diff containing a test case.

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-07-10 03:37

Message:
Logged In: YES 
user_id=1326842

This bug is simmilar to http://python.org/sf/1511497.
It is caused by absolute imports in xmlcore.sax.expatreader.
Patch #1519796 ( http://python.org/sf/1519796 )
should fix it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513611&group_id=5470

From noreply at sourceforge.net  Sat Jul 29 19:07:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 29 Jul 2006 10:07:25 -0700
Subject: [ python-Bugs-1511497 ] xml.sax.expatreader is missing
Message-ID: <E1G6sHd-0004ZX-At@sc8-sf-web6.sourceforge.net>

Bugs item #1511497, was opened at 2006-06-23 14:14
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1511497&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: XML
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 9
Submitted By: Wummel (calvin)
Assigned to: Nobody/Anonymous (nobody)
Summary: xml.sax.expatreader is missing

Initial Comment:
Hi,

when testing the new Python 2.5 subversion tree I
encountered this behaviour:
$ python2.5
Python 2.5b1 (trunk:47065, Jun 22 2006, 20:56:23) 
[GCC 4.1.2 20060613 (prerelease) (Debian 4.1.1-5)] on
linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import xml.sax.expatreader
>>> print xml.sax.expatreader
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute
'expatreader'
>>> 

So the import went ok, but using the attribute gave an
error. This is very strange. Python 2.4 did not have
this behaviour.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-29 13:07

Message:
Logged In: YES 
user_id=3066

The xmlcore package has been renamed back to the original
xml as of revision 50941.

A test for this condition has been added as part of that change.

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-07-10 03:38

Message:
Logged In: YES 
user_id=1326842

See patch #1519796:
http://python.org/sf/1519796

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-06-26 18:52

Message:
Logged In: YES 
user_id=1326842

I see the same behaviour with the official Python 2.5
beta 1 Windows installer. The interesting thing is that
the expatreader module is present in sys.modules:

Python 2.5b1 (r25b1:47027, Jun 20 2006, 09:31:33)
[MSC v.1310 32 bit (Intel)] on win32
...
>>> import xml.sax.expatreader
>>> xml.sax.expatreader
Traceback (most recent call last):
  ...
AttributeError: 'module' object has no attribute 'expatreader'
>>> import sys
>>> sys.modules['xml.sax.expatreader']
<module 'xml.sax.expatreader' from
'...\lib\xmlcore\sax\expatreader.pyc'>

All of the other modules in xml package can be imported
without any trouble.
I don't understand what is the real problem here,
but it goes away if you import xmlcore.sax package
before expatreader:

[restart python]
>>> import xmlcore.sax
>>> import xml.sax.expatreader
>>> xml.sax.expatreader
<module 'xml.sax.expatreader' from
'...\lib\xmlcore\sax\expatreader.pyc'>

The simplest fix would be to use at least one absolute
import in ...\lib\xmlcore\sax\__init__.py, for example
you could change line 22:

from xmlreader import InputSource

to:

from xmlcore.sax.xmlreader import InputSource

but that might just hide the real bug.

----------------------------------------------------------------------

Comment By: Wummel (calvin)
Date: 2006-06-26 14:15

Message:
Logged In: YES 
user_id=9205

I built Python directly from the SVN trunk repository with
$ ./configure && make altinstall
I attached the pyconfig.h that was generated. If you need
more info, feel free to ask.

After building and installing, I started up python2.5 and
executed "import xml.sax.expatreader" and then "print
xml.sax.expatreader", and nothing else.

Another thing I tried is "import from", which works.
But importing xml.sax.expatreader directly, as noted above,
does not work.

Here is the log with the "import from" test:
Python 2.5b1 (trunk:47090, Jun 25 2006, 09:59:02) 
[GCC 4.1.2 20060613 (prerelease) (Debian 4.1.1-5)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> from xml.sax import expatreader
>>> print expatreader
<module 'xml.sax.expatreader' from
'/usr/local/lib/python2.5/xmlcore/sax/expatreader.pyc'>
>>> print xml.sax.expatreader
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'expatreader'


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-06-24 06:39

Message:
Logged In: YES 
user_id=21627

How precisely did you test it? What configure options did
you set up, what commands did you provide to build Python?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1511497&group_id=5470

From noreply at sourceforge.net  Sat Jul 29 19:13:19 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 29 Jul 2006 10:13:19 -0700
Subject: [ python-Bugs-1476845 ] Finish PEP 343 terminology cleanup
Message-ID: <E1G6sNL-0002AS-1V@sc8-sf-web5.sourceforge.net>

Bugs item #1476845, was opened at 2006-04-26 07:57
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1476845&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Nick Coghlan (ncoghlan)
Assigned to: Nick Coghlan (ncoghlan)
Summary: Finish PEP 343 terminology cleanup

Initial Comment:
test_with.py was missed in the PEP 343 terminology
cleanup for Python alpha 2

PEP 343 itself still needs to be updated, too.

Creating this tracker item to record items needed to
finish the terminology cleanup post-alpha 2.

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-29 13:13

Message:
Logged In: YES 
user_id=11375

Nick, does anything still need to be done for this?  What
terminology needs to be fixed in test_with.py?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1476845&group_id=5470

From noreply at sourceforge.net  Sat Jul 29 19:24:48 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 29 Jul 2006 10:24:48 -0700
Subject: [ python-Bugs-1465014 ] CSV regression in 2.5a1: multi-line cells
Message-ID: <E1G6sYS-0007co-3W@sc8-sf-web3.sourceforge.net>

Bugs item #1465014, was opened at 2006-04-05 11:14
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465014&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
Status: Open
Resolution: Rejected
Priority: 5
Submitted By: David Goodger (goodger)
Assigned to: Skip Montanaro (montanaro)
Summary: CSV regression in 2.5a1: multi-line cells

Initial Comment:
Running the attached csv_test.py under Python 2.4.2
(Windows XP SP1) produces:

>c:\apps\python24\python.exe ./csv_test.py
['one', '2', 'three (line 1)\n(line 2)']

Note that the third item in the row contains a newline
between "(line 1)" and "(line 2)".

With Python 2.5a1, I get:

>c:\apps\python25\python.exe ./csv_test.py
['one', '2', 'three (line 1)(line 2)']

Notice the missing newline, which is significant.  The
CSV module under 2.5a1 seems to lose data.


----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-29 13:24

Message:
Logged In: YES 
user_id=11375

I looked at this bug report, but I have no idea of exactly
what behaviour has changed or what needs to be described.


----------------------------------------------------------------------

Comment By: Andrew McNamara (andrewmcnamara)
Date: 2006-06-22 23:34

Message:
Logged In: YES 
user_id=698599

Yep, your point about adding a comment to the documentation 
is fair. Skip, do you want to take my words and massage 
them into a form suitable for the docs?

----------------------------------------------------------------------

Comment By: David Goodger (goodger)
Date: 2006-06-22 23:13

Message:
Logged In: YES 
user_id=7733

I didn't realize that the previous behavior was buggy; I
thought that the current behavior was a side-effect.  The
2.5 behavior did cause a small problem in Docutils, but it's
already been fixed.  I just wanted to ensure that no
regression was creeping in to 2.5.

Thanks for the explanation!  Perhaps it could be added to
the docs in some form?

Marking the bug report closed.

----------------------------------------------------------------------

Comment By: Andrew McNamara (andrewmcnamara)
Date: 2006-06-22 20:27

Message:
Logged In: YES 
user_id=698599

The previous behaviour caused considerable problems, 
particularly on platforms that did not use the unix line-
ending conventions, or with files that originated on those 
platforms - users were finding mysterious newlines where 
they didn't expect them.

Quoted fields exist to allow characters that would otherwise 
be considered part of the syntax to appear within the field. 
 So yes, quoted fields are a special case, and necessarily 
so.

The current behaviour puts the control back in the hands of 
the user of the module: if literal newlines are important 
within a field, they need to read their file in a way that 
preserves the newlines. The old behaviour would introduce 
spurious characters into quoted fields, with no way for the 
user to control that behaviour.

I'm sorry that the change causes you problems. With a format 
that's as loosely defined as CSV, it's an unfortunate fact 
of life that there are going to be conflicting requirements. 

----------------------------------------------------------------------

Comment By: David Goodger (goodger)
Date: 2006-06-22 14:17

Message:
Logged In: YES 
user_id=7733

I see what you're saying, but I disagree.  In Python 2.4,
csv.reader did not require newlines, but in Python 2.5 it
does.  That's a significant behavioral change.  In the
stdlib csv "Module Contents" docs for csv.reader, it says:
"csvfile can be any object which supports the iterator
protocol and returns a string each time its next method is
called."  It doesn't mention newline-terminated strings.

In any case, the behavior is inconsistent: newlines are not
required to terminate row-ending strings, but only strings
which end inside cells split across rows.  Why the discrepancy?

----------------------------------------------------------------------

Comment By: Andrew McNamara (andrewmcnamara)
Date: 2006-06-20 19:17

Message:
Logged In: YES 
user_id=698599

I think your problem is with str.splitlines(), rather than 
the csv.reader: splitlines ate the newline. If you pass it 
True as an argument, it will retain the end-of-line 
character in the resulting strings.

----------------------------------------------------------------------

Comment By: David Goodger (goodger)
Date: 2006-05-02 17:04

Message:
Logged In: YES 
user_id=7733

Assigned to Andrew McNamara, since his change appears to
have caused this regression (revision 38290 on
Modules/_csv.c).

----------------------------------------------------------------------

Comment By: David Goodger (goodger)
Date: 2006-05-02 16:58

Message:
Logged In: YES 
user_id=7733

Further investigation has revealed that the regression only
affects iterator I/O, not file I/O.  The attached
csv_test.py demonstrates.  Run with Python 2.5 to get:

results from file I/O:
[['one', '2', 'three (line 1)\n(line 2)']]

results from iterator I/O:
[['one', '2', 'three (line 1)(line 2)']]

----------------------------------------------------------------------

Comment By: David Goodger (goodger)
Date: 2006-04-05 11:44

Message:
Logged In: YES 
user_id=7733

This bug seems to be a side effect of revision 38290 on
Modules/_csv.c, which was prompted by bug 967934
(http://www.python.org/sf/967934).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465014&group_id=5470

From noreply at sourceforge.net  Sat Jul 29 19:27:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 29 Jul 2006 10:27:05 -0700
Subject: [ python-Bugs-1429053 ] set documentation deficiencies
Message-ID: <E1G6saf-0000Ff-4Y@sc8-sf-web3.sourceforge.net>

Bugs item #1429053, was opened at 2006-02-10 07:07
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1429053&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Keith Briggs (kbriggs)
>Assigned to: A.M. Kuchling (akuchling)
Summary: set documentation deficiencies

Initial Comment:
http://www.python.org/doc/current/lib/types-set.html
has a dead link: "Module sets".

Also, there does not seem to be any documentation on
how to construct a set.   Does set()==set([])?   What
is allowed  as an argument to set()?  Any iterable?

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-29 13:27

Message:
Logged In: YES 
user_id=11375

This bug seems to be fixed; closing.


----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-13 14:29

Message:
Logged In: YES 
user_id=1188172

The new location of the devel docs is
http://docs.python.org/dev.

----------------------------------------------------------------------

Comment By: Keith Briggs (kbriggs)
Date: 2006-02-13 07:12

Message:
Logged In: YES 
user_id=888261

Where is it fixed?  I see all the same problems at
http://www.python.org/dev/doc/devel/lib/types-set.html.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-10 11:21

Message:
Logged In: YES 
user_id=1188172

This is all already corrected, except for the empty set thing.

----------------------------------------------------------------------

Comment By: Keith Briggs (kbriggs)
Date: 2006-02-10 10:53

Message:
Logged In: YES 
user_id=888261

Furthermore, the operations update etc. are mutations of s,
so wouldn't the definitions

s.update(t)  	s |= t  	return set s with elements added from t
s.intersection_update(t) 	s &= t 	return set s keeping only
elements also found in t
s.difference_update(t) 	s -= t 	return set s after removing
elements found in t
s.symmetric_difference_update(t) 	s ^= t 	return set s with
elements from s or t but not both

be better as 

s.update(t)  	s |= t  	add elements from t to s

etc.?
I'm not sure what the word "return" is doing here.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1429053&group_id=5470

From noreply at sourceforge.net  Sat Jul 29 19:45:04 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 29 Jul 2006 10:45:04 -0700
Subject: [ python-Bugs-1530959 ] distutils doesn't notice --with-pydebug
Message-ID: <E1G6ss4-0000Cm-5q@sc8-sf-web3.sourceforge.net>

Bugs item #1530959, was opened at 2006-07-29 13: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=1530959&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Collin Winter (collinwinter)
Assigned to: Nobody/Anonymous (nobody)
Summary: distutils doesn't notice --with-pydebug

Initial Comment:
As it stands (as of r50921), building a C extension
module first with a debug build of Python (built with
--with-pydebug), then with a regular Python build
(without --with-pydebug) does not cause distutils to
recompile the extension module as it should. This leads
to undefined symbol errors at runtime when the module
is loaded.

The attached patch against
Lib/distutils/command/build.py causes
distutils.command.build to append '-pydebug' to the
platform-specific directory name  (e.g.,
'linux-i686-2.5') if Python was compiled with
--with-pydebug.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530959&group_id=5470

From noreply at sourceforge.net  Sat Jul 29 21:57:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 29 Jul 2006 12:57:23 -0700
Subject: [ python-Bugs-1531003 ] __weaklist__ in typeobject.c
Message-ID: <E1G6uw7-0004CS-Kt@sc8-sf-web3.sourceforge.net>

Bugs item #1531003, was opened at 2006-07-29 15:57
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=1531003&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Nobody/Anonymous (nobody)
Summary: __weaklist__ in typeobject.c

Initial Comment:
typeobject.c:subtype_getweakref mentions __weaklist__
in an exception message that looks like it should refer
to __weakref__.  This exists in both 2.4 and the trunk.

Fixing this should be just a matter of changing the
message text; I don't see any other references to
__weaklist__.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531003&group_id=5470

From noreply at sourceforge.net  Sat Jul 29 22:05:43 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 29 Jul 2006 13:05:43 -0700
Subject: [ python-Bugs-1193966 ] Weakref types documentation bugs
Message-ID: <E1G6v4B-00085H-3w@sc8-sf-web3.sourceforge.net>

Bugs item #1193966, was opened at 2005-05-02 14:31
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193966&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Barry A. Warsaw (bwarsaw)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Weakref types documentation bugs

Initial Comment:
This page (section 3.3.3 of the library reference manual):

http://www.python.org/doc/current/lib/weakref-extension.html#weakref-extension

contains a description of what you need to do to make
your extension types weakrefable.  There are a few
problems with this page.

First, it really belongs in the C API and/or extending
and embedding documentation, not in the library
reference manual.

Second, the page describes having to set
Py_TPFLAGS_HAVE_WEAKREFS in tp_flags, but that's
unnecessary because Py_TPFLAGS_HAVE_WEAKREFS is already
in Py_TPFLAGS_DEFAULT.


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-29 16:05

Message:
Logged In: YES 
user_id=3066

Fixed in revision 50952.  The referenced section has been
moved to the Extending & Embedding manual.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193966&group_id=5470

From noreply at sourceforge.net  Sat Jul 29 22:07:39 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 29 Jul 2006 13:07:39 -0700
Subject: [ python-Bugs-1465014 ] CSV regression in 2.5a1: multi-line cells
Message-ID: <E1G6v63-0001HE-Kq@sc8-sf-web6.sourceforge.net>

Bugs item #1465014, was opened at 2006-04-05 10:14
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465014&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
>Status: Pending
>Resolution: Fixed
Priority: 5
Submitted By: David Goodger (goodger)
Assigned to: Skip Montanaro (montanaro)
Summary: CSV regression in 2.5a1: multi-line cells

Initial Comment:
Running the attached csv_test.py under Python 2.4.2
(Windows XP SP1) produces:

>c:\apps\python24\python.exe ./csv_test.py
['one', '2', 'three (line 1)\n(line 2)']

Note that the third item in the row contains a newline
between "(line 1)" and "(line 2)".

With Python 2.5a1, I get:

>c:\apps\python25\python.exe ./csv_test.py
['one', '2', 'three (line 1)(line 2)']

Notice the missing newline, which is significant.  The
CSV module under 2.5a1 seems to lose data.


----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2006-07-29 15:07

Message:
Logged In: YES 
user_id=44345

I checked in a change to libcsv.tex (revision 50953).  It adds a versionchanged 
bit to the reader doc that explains why the behavior changed in 2.5.  Andrew & 
Andrew, please check my work.  Sorry for the delay taking care of this.

Skip


----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-29 12:24

Message:
Logged In: YES 
user_id=11375

I looked at this bug report, but I have no idea of exactly
what behaviour has changed or what needs to be described.


----------------------------------------------------------------------

Comment By: Andrew McNamara (andrewmcnamara)
Date: 2006-06-22 22:34

Message:
Logged In: YES 
user_id=698599

Yep, your point about adding a comment to the documentation 
is fair. Skip, do you want to take my words and massage 
them into a form suitable for the docs?

----------------------------------------------------------------------

Comment By: David Goodger (goodger)
Date: 2006-06-22 22:13

Message:
Logged In: YES 
user_id=7733

I didn't realize that the previous behavior was buggy; I
thought that the current behavior was a side-effect.  The
2.5 behavior did cause a small problem in Docutils, but it's
already been fixed.  I just wanted to ensure that no
regression was creeping in to 2.5.

Thanks for the explanation!  Perhaps it could be added to
the docs in some form?

Marking the bug report closed.

----------------------------------------------------------------------

Comment By: Andrew McNamara (andrewmcnamara)
Date: 2006-06-22 19:27

Message:
Logged In: YES 
user_id=698599

The previous behaviour caused considerable problems, 
particularly on platforms that did not use the unix line-
ending conventions, or with files that originated on those 
platforms - users were finding mysterious newlines where 
they didn't expect them.

Quoted fields exist to allow characters that would otherwise 
be considered part of the syntax to appear within the field. 
 So yes, quoted fields are a special case, and necessarily 
so.

The current behaviour puts the control back in the hands of 
the user of the module: if literal newlines are important 
within a field, they need to read their file in a way that 
preserves the newlines. The old behaviour would introduce 
spurious characters into quoted fields, with no way for the 
user to control that behaviour.

I'm sorry that the change causes you problems. With a format 
that's as loosely defined as CSV, it's an unfortunate fact 
of life that there are going to be conflicting requirements. 

----------------------------------------------------------------------

Comment By: David Goodger (goodger)
Date: 2006-06-22 13:17

Message:
Logged In: YES 
user_id=7733

I see what you're saying, but I disagree.  In Python 2.4,
csv.reader did not require newlines, but in Python 2.5 it
does.  That's a significant behavioral change.  In the
stdlib csv "Module Contents" docs for csv.reader, it says:
"csvfile can be any object which supports the iterator
protocol and returns a string each time its next method is
called."  It doesn't mention newline-terminated strings.

In any case, the behavior is inconsistent: newlines are not
required to terminate row-ending strings, but only strings
which end inside cells split across rows.  Why the discrepancy?

----------------------------------------------------------------------

Comment By: Andrew McNamara (andrewmcnamara)
Date: 2006-06-20 18:17

Message:
Logged In: YES 
user_id=698599

I think your problem is with str.splitlines(), rather than 
the csv.reader: splitlines ate the newline. If you pass it 
True as an argument, it will retain the end-of-line 
character in the resulting strings.

----------------------------------------------------------------------

Comment By: David Goodger (goodger)
Date: 2006-05-02 16:04

Message:
Logged In: YES 
user_id=7733

Assigned to Andrew McNamara, since his change appears to
have caused this regression (revision 38290 on
Modules/_csv.c).

----------------------------------------------------------------------

Comment By: David Goodger (goodger)
Date: 2006-05-02 15:58

Message:
Logged In: YES 
user_id=7733

Further investigation has revealed that the regression only
affects iterator I/O, not file I/O.  The attached
csv_test.py demonstrates.  Run with Python 2.5 to get:

results from file I/O:
[['one', '2', 'three (line 1)\n(line 2)']]

results from iterator I/O:
[['one', '2', 'three (line 1)(line 2)']]

----------------------------------------------------------------------

Comment By: David Goodger (goodger)
Date: 2006-04-05 10:44

Message:
Logged In: YES 
user_id=7733

This bug seems to be a side effect of revision 38290 on
Modules/_csv.c, which was prompted by bug 967934
(http://www.python.org/sf/967934).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465014&group_id=5470

From noreply at sourceforge.net  Sat Jul 29 22:15:07 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 29 Jul 2006 13:15:07 -0700
Subject: [ python-Bugs-960860 ] botched html for index subheadings
Message-ID: <E1G6vDH-00064a-KW@sc8-sf-web2.sourceforge.net>

Bugs item #960860, was opened at 2004-05-26 10:17
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=960860&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: botched html for index subheadings

Initial Comment:
In the index, if a topic has subtopics, it should be listed 
as """
<dt>topic
<dd><dl><dt>subtopic1
             <dt>subtopic2
       </dl>
"""

In some cases (such as the reference manual entries for 
module, or object(continued)), it is correct.  In other 
cases (such as the entries for name, or the first column 
of object), the "<dd><dl>...</dl>" wrapper is left out, so 
that the subentries appear to be normal entries that just 
happen to be out of alphabetical order.


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-29 16:15

Message:
Logged In: YES 
user_id=3066

This appears to be fine in the 2.4.3 and development
versions of the documentation.  If I'm missing something,
please be specific about what you think is wrong.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=960860&group_id=5470

From noreply at sourceforge.net  Sat Jul 29 22:21:03 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 29 Jul 2006 13:21:03 -0700
Subject: [ python-Bugs-1531016 ] Comman not allowed at the end of argument
	list for **argumen
Message-ID: <E1G6vJ1-0000Re-26@sc8-sf-web2.sourceforge.net>

Bugs item #1531016, was opened at 2006-07-29 20: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=1531016&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Roman Suzi (rnd0110)
Assigned to: Nobody/Anonymous (nobody)
Summary: Comman not allowed at the end of argument list for **argumen

Initial Comment:
This tells it all:

>>> str('sdfd', **a,)
  File "<stdin>", line 1
    str('sdfd', **a,)
                   ^
SyntaxError: invalid syntax

>>> str('sdfd', *a,)
  File "<stdin>", line 1
    str('sdfd', *a,)
                   ^
SyntaxError: invalid syntax

While the docs tell otherwise:

http://docs.python.org/ref/calls.html

While having arguments after ** doesn't make sense,
comma after ANY kinds of arguments seem to be more
consistent.




----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531016&group_id=5470

From noreply at sourceforge.net  Sat Jul 29 22:22:03 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 29 Jul 2006 13:22:03 -0700
Subject: [ python-Bugs-1531016 ] Comma not allowed at the end of argument list
	for **argument
Message-ID: <E1G6vJz-0006dT-UE@sc8-sf-web5.sourceforge.net>

Bugs item #1531016, was opened at 2006-07-29 20:21
Message generated for change (Settings changed) made by rnd0110
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531016&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.4
Status: Open
Resolution: None
>Priority: 2
Submitted By: Roman Suzi (rnd0110)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Comma not allowed at the end of argument list for **argument

Initial Comment:
This tells it all:

>>> str('sdfd', **a,)
  File "<stdin>", line 1
    str('sdfd', **a,)
                   ^
SyntaxError: invalid syntax

>>> str('sdfd', *a,)
  File "<stdin>", line 1
    str('sdfd', *a,)
                   ^
SyntaxError: invalid syntax

While the docs tell otherwise:

http://docs.python.org/ref/calls.html

While having arguments after ** doesn't make sense,
comma after ANY kinds of arguments seem to be more
consistent.




----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531016&group_id=5470

From noreply at sourceforge.net  Sat Jul 29 22:40:41 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 29 Jul 2006 13:40:41 -0700
Subject: [ python-Bugs-1163367 ] correct/clarify documentation for super
Message-ID: <E1G6vc1-00072y-Hn@sc8-sf-web5.sourceforge.net>

Bugs item #1163367, was opened at 2005-03-14 18:39
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163367&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Steven Bethard (bediviere)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: correct/clarify documentation for super

Initial Comment:
The current documentation for super is confusing.  For
instance, it says that it returns "the superclass of
type" which is incorrect; it actually returns the next
type in type's MRO.  Well, to be truthful, it doesn't
even do that; it returns a proxy object which makes
that type's attributes available, but that's just
another reason to fix the documentation.

I suggest changing the wording to something like:

"""super(type[, object-or-type])

Return an object that exposes the attributes available
through the type's superclasses, without exposing the
attributes of the type itself.  Attributes will be
looked up using the normal resolution order, omitting
the first class in the MRO (that is, the type itself).

If the second argument is present, it should either be
an instance of object, in which case
isinstance(object-or-type, type) must be true, or it
should be an instance of type, in which case
issubclass(object-or-type, type) must be true.  The
typical use for this form of super is to call a
cooperative superclass method:

class C(B):
    def meth(self, arg):
        super(C, self).meth(arg)

If the second argument to super is omitted, the super
object returned will not expose any attributes
directly.  However,  attributes will be accessible
whenever the descriptor machinery is invoked, e.g.
though explicit invocation of __get__.

Note that super is undefined for implicit lookups using
statements or operators such as "super(C, self)[name]".
 These must be spelled out with their explicit lookup,
e.g. "super(C, self).__getitem__(name)". New in version
2.2. 
"""

It's not perfect and I welcome suggestions for
re-wording, but I think it's substantially more
accurate about what super actually does.  It also moves
the "second argument omitted" situation to the end,
since this is a vastly more uncommon use case.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-29 16:40

Message:
Logged In: YES 
user_id=3066

I'm not sure what the paragraph following the \end{verbatim}
means.  Can someone clarify?

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-20 12:06

Message:
Logged In: YES 
user_id=1188172

See also Bug #973579 (which I closed as duplicate) for
alternative wording.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163367&group_id=5470

From noreply at sourceforge.net  Sat Jul 29 23:17:28 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 29 Jul 2006 14:17:28 -0700
Subject: [ python-Bugs-960860 ] botched html for index subheadings
Message-ID: <E1G6wBc-00086V-JS@sc8-sf-web5.sourceforge.net>

Bugs item #960860, was opened at 2004-05-26 14:17
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=960860&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
>Status: Pending
Resolution: None
Priority: 5
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: botched html for index subheadings

Initial Comment:
In the index, if a topic has subtopics, it should be listed 
as """
<dt>topic
<dd><dl><dt>subtopic1
             <dt>subtopic2
       </dl>
"""

In some cases (such as the reference manual entries for 
module, or object(continued)), it is correct.  In other 
cases (such as the entries for name, or the first column 
of object), the "<dd><dl>...</dl>" wrapper is left out, so 
that the subentries appear to be normal entries that just 
happen to be out of alphabetical order.


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-29 20:15

Message:
Logged In: YES 
user_id=3066

This appears to be fine in the 2.4.3 and development
versions of the documentation.  If I'm missing something,
please be specific about what you think is wrong.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=960860&group_id=5470

From noreply at sourceforge.net  Sun Jul 30 06:56:06 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 29 Jul 2006 21:56:06 -0700
Subject: [ python-Bugs-1495229 ] W3C <-> Python DOM type mapping docs need
	updating
Message-ID: <E1G73LS-0000wZ-PP@sc8-sf-web1.sourceforge.net>

Bugs item #1495229, was opened at 2006-05-25 19:33
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495229&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Brown (mike_j_brown)
Assigned to: Martin v. L?wis (loewis)
Summary: W3C <-> Python DOM type mapping docs need updating

Initial Comment:
I believe the information at
http://docs.python.org/lib/dom-type-mapping.html is
outdated; most if not all boolean return values, at
least in minidom, are handled as BooleanType, not
IntegerType. This should be standard.

Sorry, I don't have a patch to submit for this. Should
be an easy fix though.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-30 00:56

Message:
Logged In: YES 
user_id=3066

My position on this is that:

1) The docs are not wrong.

2) The docs should be updated to indicate that bool values
are returned where appropriate.

3) It is reasonable that Python developers know the
relationship between bool and int.  That is not something
that can reasonably change in Python 2.x.  It seems unlikely
to change for Python 3000.

4) The strict application of the IDL mapping really hasn't
helped in creating a good DOM-like interface for Python.

Dealing with the last item isn't within scope for handling
this issue.


----------------------------------------------------------------------

Comment By: Mike Brown (mike_j_brown)
Date: 2006-06-03 17:01

Message:
Logged In: YES 
user_id=371366

If answer #1 is chosen and the others rejected, then the
docs remain misleading, since the average reader just wants
to know what types to expect from an implementation (or
should code into their implementation), and shouldn't be
expected to know the relationship between Booleans and
integers. Is it even reasonable to expect that this
relationship will always be true? In any case, I'd rather
see it made explicit as to why minidom doesn't seem, at
first, to respect the type mapping, at least in current
implementations. It could be as simple as adding Andrew's
comment, phrased as "This DOM mapping is derived from the
IDL mapping for Python, which predates the introduction of
BooleanType, which is currently a subtype of IntegerType.
Implementations may use either type." or some such.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-06-03 16:42

Message:
Logged In: YES 
user_id=11375

Martin, you probably need to make a pronouncement on this.  The DOM 
mapping is supposed to be derived from the IDL mapping for Python, which 
predates Booleans, but methods such as hasChildNodes() return True/False.
I can see at least three answers:

1) Booleans are subtypes of integers, so the docs are not wrong.

2) The docs are wrong and should say Boolean.

3) The methods should be returning regular 0 and 1, not True and False, and 
should be changed.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495229&group_id=5470

From noreply at sourceforge.net  Sun Jul 30 09:03:17 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Jul 2006 00:03:17 -0700
Subject: [ python-Bugs-1515471 ] wrong handling of character buffers in
	stringobject
Message-ID: <E1G75KX-0001FY-36@sc8-sf-web1.sourceforge.net>

Bugs item #1515471, was opened at 2006-07-01 02:41
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1515471&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 9
Submitted By: Georg Brandl (gbrandl)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: wrong handling of character buffers in stringobject

Initial Comment:
stringobject.c:

In string_replace, there is

	if (PyString_Check(from)) {
	  /* Can this be made a '!check' after the Unicode
check? */
	}
#ifdef Py_USING_UNICODE
	if (PyUnicode_Check(from))
		return PyUnicode_Replace((PyObject *)self,
					 from, to, count);
#endif
	else if (PyObject_AsCharBuffer(from, &tmp_s, &tmp_len))
		return NULL;

[the same check with "to"]

	return (PyObject *)replace((PyStringObject *) self,
				   (PyStringObject *) from,
				   (PyStringObject *) to, count);

This is not correct if from or to isn't a string
object, but a char buffer compatible object.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-30 00:03

Message:
Logged In: YES 
user_id=33168

Committed revision 50970.

Georg, let me know if you find any more issues.  I didn't
look for other places where a buffer wasn't handled
properly.  Thanks.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1515471&group_id=5470

From noreply at sourceforge.net  Sun Jul 30 09:25:39 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Jul 2006 00:25:39 -0700
Subject: [ python-Bugs-1495229 ] W3C <-> Python DOM type mapping docs need
	updating
Message-ID: <E1G75gB-0007R1-Qj@sc8-sf-web5.sourceforge.net>

Bugs item #1495229, was opened at 2006-05-26 01:33
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495229&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Brown (mike_j_brown)
Assigned to: Martin v. L?wis (loewis)
Summary: W3C <-> Python DOM type mapping docs need updating

Initial Comment:
I believe the information at
http://docs.python.org/lib/dom-type-mapping.html is
outdated; most if not all boolean return values, at
least in minidom, are handled as BooleanType, not
IntegerType. This should be standard.

Sorry, I don't have a patch to submit for this. Should
be an easy fix though.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2006-07-30 09:25

Message:
Logged In: YES 
user_id=21627

I agree with Fred that the documentation is not wrong as it
stands. As this section is meant to apply not only to
minidom, but to all Python DOM implementations, I don't
think the specification can be changed. minidom would
probably still comply (except perhaps for the "specified"
attribute), but other implementations might comply anymore.

If clarification is needed, it should go beyond boolean:
What is "IntegerType"? There is no type with that name in
Python, and, indeed, "unsigned long" cannot alway map to
types.IntType; unsigned long long (used for DOMTimeStamp)
and unsigned short don't get mapped at all in the table.

I think the intention is this: for the "proper" IDL integer
types (short, long, long long, +unsigned), both Python int
and long can be used. For boolean, int, long, and bool can
be used; on input, any non-zero value counts as true, and on
output, only 0 or 1 should be returned (where bool(0) is
False and bool(1) is True).

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-30 06:56

Message:
Logged In: YES 
user_id=3066

My position on this is that:

1) The docs are not wrong.

2) The docs should be updated to indicate that bool values
are returned where appropriate.

3) It is reasonable that Python developers know the
relationship between bool and int.  That is not something
that can reasonably change in Python 2.x.  It seems unlikely
to change for Python 3000.

4) The strict application of the IDL mapping really hasn't
helped in creating a good DOM-like interface for Python.

Dealing with the last item isn't within scope for handling
this issue.


----------------------------------------------------------------------

Comment By: Mike Brown (mike_j_brown)
Date: 2006-06-03 23:01

Message:
Logged In: YES 
user_id=371366

If answer #1 is chosen and the others rejected, then the
docs remain misleading, since the average reader just wants
to know what types to expect from an implementation (or
should code into their implementation), and shouldn't be
expected to know the relationship between Booleans and
integers. Is it even reasonable to expect that this
relationship will always be true? In any case, I'd rather
see it made explicit as to why minidom doesn't seem, at
first, to respect the type mapping, at least in current
implementations. It could be as simple as adding Andrew's
comment, phrased as "This DOM mapping is derived from the
IDL mapping for Python, which predates the introduction of
BooleanType, which is currently a subtype of IntegerType.
Implementations may use either type." or some such.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-06-03 22:42

Message:
Logged In: YES 
user_id=11375

Martin, you probably need to make a pronouncement on this.  The DOM 
mapping is supposed to be derived from the IDL mapping for Python, which 
predates Booleans, but methods such as hasChildNodes() return True/False.
I can see at least three answers:

1) Booleans are subtypes of integers, so the docs are not wrong.

2) The docs are wrong and should say Boolean.

3) The methods should be returning regular 0 and 1, not True and False, and 
should be changed.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495229&group_id=5470

From noreply at sourceforge.net  Sun Jul 30 12:46:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Jul 2006 03:46:24 -0700
Subject: [ python-Bugs-878908 ] suspect documentation of operator.isNumberType
Message-ID: <E1G78oS-00022c-W6@sc8-sf-web2.sourceforge.net>

Bugs item #878908, was opened at 2004-01-17 17:05
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=878908&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Colin J. Williams (cjwhrh)
Assigned to: Nobody/Anonymous (nobody)
Summary: suspect documentation of operator.isNumberType 

Initial Comment:
The docs appear to draw a distinction between
containers and simple classes.  I had expected the
NumberType to include IntType, LongType, FloatType,
ComplexType and, perhaps BoolType, but no others.

The attached script shows that it includes the
BoolType, but it also includes the numarray.array.

On the other hand, it does not include array.array.

This is to suggest that either the docs be clarified or
a probably bug be reported.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-01-18 04:49

Message:
Logged In: YES 
user_id=31435

Sorry, I don't understand your point.  bool is a subtype of int, 
so of course it "acts like a number".  numarray isn't part of 
the Python core, so the core Python docs have nothing to 
say about it.  It seems reasonable to me for a numarray.array 
to say it's numeric, because it supports numeric operations 
(for example, you can add 1 to a numeric.array, and it 
broadcasts the scalar; you cannot add 1 to an array.array -- 
there's nothing number-like about array.arrays).

More formally, numarray.array fills in the type object's 
tp_as_number slot at the C level, while array.array does not.  
That's the only clue Python has as to whether a type 
is "number-like", and is (almost) the only thing the 
implementation of isNumberType looks at.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=878908&group_id=5470

From noreply at sourceforge.net  Sun Jul 30 12:53:47 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Jul 2006 03:53:47 -0700
Subject: [ python-Bugs-1002453 ] Wrong documentation of __radd__ etc.
Message-ID: <E1G78vb-0000nL-RZ@sc8-sf-web1.sourceforge.net>

Bugs item #1002453, was opened at 2004-08-03 07:25
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002453&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Hallvard B Furuseth (hfuru)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wrong documentation of __radd__ etc.

Initial Comment:
Info node 'Emulating numeric types' says:

  __radd__(self, other)
  __rsub__(self, other)
  ...
  These functions are only called if the left operand
  does not support the corresponding operation.

Not so. Info node 'Coercion rules' lists one exception:

  if the left operand is an instance of a built-in
  type or a new-style class, and the right operand is
  an instance of a proper subclass of that type or
  class, the right operand's `__rop__()' method is
  tried _before_ the left operand's `__op__()' method.

...and one time where above the text is misleading:

  When either operand type defines a coercion, this
  coercion is called before that type's `__op__()' or
  `__rop__()' method is called, but no sooner.  If the
  coercion returns an object of a different type for
  the operand whose coercion is invoked, part of the
  process is redone using the new object.

Thus, Python can call __rop__(self, other) even if
self.__op__ exists:  If one does `x - y' where
y.__coerce__(x) coerces x to y's class, y.__rsub__(x)
is called instead of (coerced x).__sub__(y).  I think
this should be documented in the 'Emulating numeric
types' node.  Unless Python is changed to redo the
choice between __op__, __rop__ and __iop__ after
coercion.

I think it would also be good to explain in that Info
node what __op__ and __rop__ can do if they do not
support the operation with the supplied arguments, but
the other argument might support it.  It seems obvious
that self.__op__(other) can simply attempt to call
other.__rop__(self) and let that fail if it is not
supported.  However, the above rules seem to mean that
self.__rop__(other) might want to call
other.__op__(self) too, which could lead to infinite
recursion.  Are there some special times where it can
do that, and other times where it should not?


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-30 10:53

Message:
Logged In: YES 
user_id=849994

A note was added to __rop__ documentation a while ago.

----------------------------------------------------------------------

Comment By: Andrew Durdin (adurdin)
Date: 2004-09-08 09:52

Message:
Logged In: YES 
user_id=625864

> I think it would also be good to explain in that Info
> node what __op__ and __rop__ can do if they do not
> support the operation with the supplied arguments

In that case I believe they should just return NotImplemented.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002453&group_id=5470

From noreply at sourceforge.net  Sun Jul 30 13:02:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Jul 2006 04:02:25 -0700
Subject: [ python-Bugs-1071248 ] Documented grammar for List displays
	incorrect (testlist)
Message-ID: <E1G793x-0000Mt-Av@sc8-sf-web3.sourceforge.net>

Bugs item #1071248, was opened at 2004-11-22 20:26
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071248&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Later
Priority: 5
Submitted By: Lenard Lindstrom (kermode)
Assigned to: Jeremy Hylton (jhylton)
Summary: Documented grammar for List displays incorrect (testlist)

Initial Comment:
In section 5.2.4 of the Python Reference Manual for
Pythons 2.4 and 2.3 the definition

testlist ::= test ( "," test )* [ "," ]

should be

testlist ::= test [ ( "," test )+ [ "," ] ]

to conform with the definition of testlist_safe in the
Grammar definition file. In other words, a trailing
comma is not permitted if there is only one test in
testlist.


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-30 11:02

Message:
Logged In: YES 
user_id=849994

This is subsumed by patch #1489771.

----------------------------------------------------------------------

Comment By: Lenard Lindstrom (kermode)
Date: 2004-12-17 00:00

Message:
Logged In: YES 
user_id=663274

Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more
information.
>>> [x for x in 1,]
  File "<stdin>", line 1
    [x for x in 1,]
                  ^
SyntaxError: invalid syntax
>>> [x for x in 1,2,]
[1, 2]
>>> for x in 1,:
...     print x
...
1
>>>


----------------------------------------------------------------------

Comment By: engelbert gruber (grubert)
Date: 2004-12-15 08:50

Message:
Logged In: YES 
user_id=147070

but

>>> testlist = 1,
>>> testlist
(1,)

so testlist = 1 does not produce a list

testlist ::= one "," ( another "," )* [and [","]]

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071248&group_id=5470

From noreply at sourceforge.net  Sun Jul 30 13:04:17 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Jul 2006 04:04:17 -0700
Subject: [ python-Bugs-766842 ] Installing documentation doesn't make it show
	up
Message-ID: <E1G795l-000645-37@sc8-sf-web1.sourceforge.net>

Bugs item #766842, was opened at 2003-07-06 21:42
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766842&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: None
>Status: Pending
>Resolution: Out of Date
Priority: 3
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: Installing documentation doesn't make it show up

Initial Comment:
If you're installing the full Python documentation through 
Package Manager, but you've already run the IDE previously 
(the common case) the new documentation doesn't show up 
in the Apple Help Viewer. It does show up when you remove 
your help preferences.

Probably a bug in the registration code in PythonIDE.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-30 11:04

Message:
Logged In: YES 
user_id=849994

Should be obsolete as PythonIDE is deprecated...

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-07-21 21:07

Message:
Logged In: YES 
user_id=45365

The IDE registration code turns out to be fine, so the problem is 
probably that if you do AHRegisterHelpBook() for an app for which 
you've done so before the call is simply ignored, in stead of the 
app being re-examined. This makes the problem difficult to fix 
right now.

A possible fix would be to put the &quot;MacPython Help&quot; and &quot;Python 
Documentation&quot; into two different apps (the former in the IDE and 
the latter in Python.app?), but that's too much work for now. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766842&group_id=5470

From noreply at sourceforge.net  Sun Jul 30 13:09:00 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Jul 2006 04:09:00 -0700
Subject: [ python-Bugs-1002398 ] os.path.sameopenfile documentation wrong.
Message-ID: <E1G79AK-0001pA-0c@sc8-sf-web5.sourceforge.net>

Bugs item #1002398, was opened at 2004-08-03 03:35
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002398&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jeremy Fincher (jemfinch)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.sameopenfile documentation wrong.

Initial Comment:
At http://docs.python.org/lib/module-os.path.html it very clearly 
states this:

sameopenfile(fp1, fp2)

Return True if the file objects fp1 and fp2 refer to the same file. 
The two file objects may represent different file descriptors. 
Availability: Macintosh, Unix.

However, on my OSX box, the source to posixpath.py clearly says 
otherwise:

def sameopenfile(fp1, fp2):
    """Test whether two open file objects reference the same file"""
    s1 = os.fstat(fp1)
    s2 = os.fstat(fp2)
    return samestat(s1, s2)

I.e., sameopenfile accepts two integer filenos, not two file objects.  
Running it gives this exception:

  File "/System/Library/Frameworks/Python.framework/Versions/
2.3/lib/python2.3/site-packages/supybot/plugins/Tail.py", line 77, 
in samefile
    return os.path.sameopenfile(fd1, fd2)
  File "/System/Library/Frameworks/Python.framework/Versions/
2.3/lib/python2.3/posixpath.py", line 220, in sameopenfile
    s1 = os.fstat(fp1)
TypeError: an integer is required

Perhaps the (much more useful) documented behavior can be 
retained, and two if statements added to the definition of 
sameopenfile:

if not isinstance(fp1, int): fp1 = fp1.fileno()
if not isinstance(fp2, int): fp2 = fp2.fileno()

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-30 11:08

Message:
Logged In: YES 
user_id=849994

The function is not needed so often to warrant a
implementation change.

Fixed the docs in rev. 50974, 50975 (2.4).

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-08 21:48

Message:
Logged In: YES 
user_id=1188172

The question is, should we fix the docs or the
implementation? Or add the suggested hybrid-solution
(drawback: no other function that deals with files currently
allows file objects and descriptors).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002398&group_id=5470

From noreply at sourceforge.net  Sun Jul 30 13:11:09 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Jul 2006 04:11:09 -0700
Subject: [ python-Bugs-1381717 ] mode 't' not documented as posssible mode for
	file built-in
Message-ID: <E1G79CP-0002tI-Q3@sc8-sf-web5.sourceforge.net>

Bugs item #1381717, was opened at 2005-12-15 15:37
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1381717&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Simo Salminen (ssalmine)
Assigned to: Nobody/Anonymous (nobody)
Summary: mode 't' not documented as posssible mode for file built-in

Initial Comment:
At http://docs.python.org/lib/built-in-funcs.html,
'file' function parameter 'mode' accepts 't' (for text
mode). 

This is not documented. It is mentioned in file object
description
(http://docs.python.org/lib/bltin-file-objects.html).

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-30 11:11

Message:
Logged In: YES 
user_id=849994

I believe there's nothing more to do here.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-12-15 21:36

Message:
Logged In: YES 
user_id=1188172

I removed the reference to "t" from the docs of file.seek()
in rev 41703,41704.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-12-15 16:08

Message:
Logged In: YES 
user_id=31435

This is more involved than you might like.  In general,
open(path, mode) passes the mode string to the platform C
library's file-opening function, and using anything other
than standard C mode letters ("w", "b", "r", "a", "+") is
platform-dependent.  "t" is not a standard C mode letter, so
whether it has any meaning, and exactly what it means if it
_does_ mean something, depends entirely on the platform C
library.

Using "t" to force text mode is a Microsoft-specific
gimmick, so if "t" is documented at all, it should be
plastered with warnings about its platform-specific nature.
 Even on a Microsoft platform, "t" is basically silly:  text
mode is the default mode (C defines this) -- it's what you
get if you don't pass "b".  The only reason Microsoft
supports "t" is because MS has _another_ non-standard option
to tell its C runtime to use binary mode by default, and if
you use that non-standard option then you also need to use
the non-standard "t" mode letter to force a file to open in
text mode.

In short, the docs should change to spell out what the
standard C modes are, and note that at the cost of
portability you can also pass whichever non-standard mode
extensions your platform happens to support.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1381717&group_id=5470

From noreply at sourceforge.net  Sun Jul 30 13:16:45 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Jul 2006 04:16:45 -0700
Subject: [ python-Bugs-780714 ] infinite __str__ recursion in thread causes
	seg fault
Message-ID: <E1G79Hp-0004eo-Hp@sc8-sf-web6.sourceforge.net>

Bugs item #780714, was opened at 2003-07-31 08:37
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780714&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.3
>Status: Pending
>Resolution: Fixed
Priority: 5
Submitted By: Stefan Gregory (stefan_gregory)
Assigned to: Nobody/Anonymous (nobody)
Summary: infinite __str__ recursion in thread causes seg fault

Initial Comment:
The following code reliably produces a segmentation
fault under Solaris8 in Python2.3, Python2.2,
Python2.1.3 and Python1.5. It produces a Bus Error when
run on Python2.2 under OSX. Clearly it should produce a
Python RuntimeError.

import thread, time

class Frog:

    def __str__(self):
        return str(self)

f = Frog()
thread.start_new_thread(str,(f,))
time.sleep(1000)

This problem manifests in scenarios such as when you
have 2 publishing objects (such as HTMLgen objects) A
and B and you put A inside B and B inside A and each
objects __str__ method calls its childrens __str__
methods and voila! (I hope this might be the reason my
Zope server has been intermitently crashing for the
past year or so though I have not found any recursive
structures yet.)

With Python2.3 gdb reports:

vgetargskeywords (args=0x1bdaf0, keywords=0x0,
format=0xd2579 &quot;0:str&quot;, kwlist=0xf7b4c,
p_va=0xfed0C02c) at Python/getargs.c:1167

Though with Python2.1 it dies at line 330 in getargs.c.



----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-30 11:16

Message:
Logged In: YES 
user_id=849994

Under 2.5, I get a runtime error now, so this might be fixed.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-08-05 19:22

Message:
Logged In: YES 
user_id=357491

Forgot to mention that Modules/threadmodule.c has 
thread_PyThread_start_new_thread which uses Python/
thread_*.h's PyThread_start_new_thread for executing threads;  
the '*' is replaced with the threading library used on your 
platform.  OS X should use thread_pthread.h (I think).

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-08-05 19:19

Message:
Logged In: YES 
user_id=357491

If you run ``str(Frog())`` instead of a bunch of threads you do get 
a RuntimeError.  Looks like this bus error has something to do 
with thread.start_new_thread and not 'str'.  It might be that since 
it runs using pthreads it does not have the built-in recursion limit 
check that the Python interpreter has.  Anyone with more 
experience with the 'thread' module have any ideas?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780714&group_id=5470

From noreply at sourceforge.net  Sun Jul 30 13:29:35 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Jul 2006 04:29:35 -0700
Subject: [ python-Feature Requests-1166378 ] No os.spawn*p* on Windows
Message-ID: <E1G79UF-0004kb-VQ@sc8-sf-web2.sourceforge.net>

Feature Requests item #1166378, was opened at 2005-03-19 03:41
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1166378&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Python Library
>Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris Palmer (chris_palmer)
Assigned to: Nobody/Anonymous (nobody)
Summary: No os.spawn*p* on Windows

Initial Comment:
You have the other spawn* functions, and exec*p*, but
no spawn*p*. It exists on Linux. These functions should
either exist everywhere or nowhere.

----------------------------------------------------------------------

Comment By: Christos Georgiou (tzot)
Date: 2005-03-21 09:17

Message:
Logged In: YES 
user_id=539787

This bug is *not* a bug, so it should be closed, and an
entry made in RFE (Request For Enhancements) aka wishlist.
Google has many pointers.  See for example
http://mail.python.org/pipermail/python-dev/2003-April/034473.html
.
Patches are welcome (either code or documentation).

----------------------------------------------------------------------

Comment By: Chris Palmer (chris_palmer)
Date: 2005-03-20 20:43

Message:
Logged In: YES 
user_id=1242303

Okay, I read the page you point to. It provides no
explanation, just a statement of the fact I had already
discovered. An explanation would be nice.

Don't you think it's strange that these three conditions
should hold:

1. os.exec*p* are supported on Windows;
2. Windows systems have a PATH environment variable with the
same meaning and use as UNIX; and yet
3. os.spawn*p* are not supported on Windows?

If there's some difference to how the environment is treated
or used between exec* and spawn* on Windows, wouldn't it be
easy to emulate the PATH-searching feature?

My options are to emulate the PATH-searching feature myself
and ignore os.spawn*p* on all platforms, or to use it when
it's present and only emulate it on Windows. The first
option is ridiculous, the second is ridiculous and ugly.

If you won't emulate the spawn*p* behavior -- it's three
lines of Python! -- it would help if you could at least
explain why, technically.

Thanks.

----------------------------------------------------------------------

Comment By: Christos Georgiou (tzot)
Date: 2005-03-20 10:02

Message:
Logged In: YES 
user_id=539787

This is documented (see
http://docs.python.org/lib/os-process.html). Python lib has
many places where underlying platform controls availability
of functionality.
Suggest closing of this bug or converting it to wishlist item.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1166378&group_id=5470

From noreply at sourceforge.net  Sun Jul 30 13:30:09 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Jul 2006 04:30:09 -0700
Subject: [ python-Bugs-1193180 ] Strange os.path.exists() results with invalid
	chars
Message-ID: <E1G79Un-0001iK-0A@sc8-sf-web5.sourceforge.net>

Bugs item #1193180, was opened at 2005-04-30 23:13
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193180&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.4
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Daniele Varrazzo (dvarrazzo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Strange os.path.exists() results with invalid chars

Initial Comment:
Hi,

when there are invalid chars in a filename, os.path.exists
() behaves oddly, returning True.

The bug appears on win32 system, not on unix ones. 
Thus is probably related to some weird windows api call 
and doesn't maybe worth fixing.

Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import os
>>> f = file("a_b", "w")
>>> f.close()
>>> os.listdir(".")
['a_b']
>>> os.path.exists("a<b")
True
>>> os.path.exists("a>b")
True

And, even more strange...

>>> os.path.exists("a<")
True
>>> os.path.exists("a>")
False

Better answers would have been:
  * False
  * raise ValueError


----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-05-31 09:56

Message:
Logged In: YES 
user_id=1188172

I think Python just uses the Win32 system call, so there
isn't much Python can do about it.

----------------------------------------------------------------------

Comment By: engelbert gruber (grubert)
Date: 2005-05-23 06:52

Message:
Logged In: YES 
user_id=147070

testing with perl: print -e "a<"; returns True/1 too

----------------------------------------------------------------------

Comment By: Jarek Zgoda (zgoda)
Date: 2005-05-02 12:04

Message:
Logged In: YES 
user_id=92222

Same for Python 2.3.5.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193180&group_id=5470

From noreply at sourceforge.net  Sun Jul 30 13:32:03 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Jul 2006 04:32:03 -0700
Subject: [ python-Bugs-1488934 ] file.write + closed pipe = no error
Message-ID: <E1G79Wd-0004H2-Ut@sc8-sf-web3.sourceforge.net>

Bugs item #1488934, was opened at 2006-05-15 16:10
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488934&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Erik Demaine (edemaine)
>Assigned to: A.M. Kuchling (akuchling)
Summary: file.write + closed pipe = no error

Initial Comment:
I am writing a Python script on Linux that gets called
via ssh (ssh hostname script.py) and I would like it to
know when its stdout gets closed because the ssh
connection gets killed.  I assumed that it would
suffice to write to stdout, and that I would get an
error if stdout was no longer connected to anything. 
This is not the case, however.  I believe it is because
of incorrect error checking in Objects/fileobject.c's
file_write.

Consider this example:

while True:
__print 'Hello'
__time.sleep (1)

If this program is run via ssh and then the ssh
connection dies, the program continues running forever
(or at least, over 10 hours).  No exceptions are thrown.

In contrast, this example does die as soon as the ssh
connection dies (within one second):

while True:
__os.write (1, 'Hello')
__time.sleep (1)

I claim that this is because os.write does proper error
checking, but file.write seems not to.  I was surprised
to find this intricacy in fwrite().  Consider the
attached C program, test.c.  (Warning: If you run it,
it will create a file /tmp/hello, and it will keep
running until you kill it.)  While the ssh connection
remains open, fwrite() reports a length of 6 bytes
written, ferror() reports no error, and errno remains
0.  Once the ssh connection dies, fwrite() still
reports a length of 6 bytes written (surprise!), but
ferror(stdout) reports an error, and errno changes to 5
(EIO).  So apparently one cannot tell from the return
value of fwrite() alone whether the write actually
succeeded; it seems necessary to call ferror() to
determine whether the write caused an error.

I think the only change necessary is on line 2443 of
file_write() in Objects/fileobject.c (in svn version
46003):

2441        n2 = fwrite(s, 1, n, f->f_fp);
2442        Py_END_ALLOW_THREADS
2443        if (n2 != n) {
2444                PyErr_SetFromErrno(PyExc_IOError);
2445                clearerr(f->f_fp);

I am not totally sure whether the "n2 != n" condition
should be changed to "n2 != n || ferror (f->f_fp)" or
simply "ferror (f->f_fp)", but I believe that the
condition should be changed to one of these
possibilities.  The current behavior is wrong.

Incidentally, you'll notice that the C code has to turn
off signal SIGPIPE (like Python does) in order to not
die right away.  However, I could not get Python to die
by re-enabling SIGPIPE.  I tried "signal.signal
(signal.SIGPIPE, signal.SIG_DFL)" and "signal.signal
(signal.SIGPIPE, lambda x, y: sys.exit ())" and neither
one caused death of the script when the ssh connection
died.  Perhaps I'm not using the signal module correctly?

I am on Linux 2.6.11 on a two-CPU Intel Pentium 4, and
I am running the latest Subversion version of Python,
but my guess is that this error transcends most if not
all versions of Python.

----------------------------------------------------------------------

Comment By: Erik Demaine (edemaine)
Date: 2006-07-02 12:35

Message:
Logged In: YES 
user_id=265183

A simple test case is this Python script (fleshed out from
previous example), also attached:

import sys, time
while True:
__print 'Hello'
__sys.stdout.flush ()
__time.sleep (1)

Save as blah.py on machine foo, run 'ssh foo python blah.py'
on machine bar--you will see 'Hello' every second--then, in
another shell on bar, kill the ssh process on bar.  blah.py
should still be running on foo.  ('foo' and 'bar' can
actually be the same machine.)

The example from the original bug report that uses
os.write() instead of print was an example that *does* work.


----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-06-03 20:16

Message:
Logged In: YES 
user_id=11375

I agree with your analysis, and think your suggested fixes are correct.

However, I'm unable to construct a small test case that exercises this bug.  I 
can't even replicate the problem with SSH; when I run a remote script with 
SSH and then kill SSH with Ctrl-C, the write() gets a -1.  Are you terminating 
SSH in some other way?  (I'd really like to have a test case for this problem 
before committing the fix.)


----------------------------------------------------------------------

Comment By: Erik Demaine (edemaine)
Date: 2006-05-15 16:26

Message:
Logged In: YES 
user_id=265183

One more thing: fwrite() is used in a couple of other
places, and I think the same comment applies to them.  They are:

- file_writelines() in Objects/fileobject.c
- w_string() in Python/marshal.c doesn't seem to have any
error checking?  (At least no ferror() call in marhsal.c...)
- string_print() in Objects/stringobject.c doesn't seem to
have any error checking (but I'm not quite sure what this
means in Python land).
- flush_data() in Modules/_hotshot.c
- array_tofile() in Modules/arraymodule.c
- write_file() in Modules/cPickle.c
- putshort(), putlong(), writeheader(), writetab() [and the
functions that call them] in Modules/rgbimgmodule.c
- svc_writefile() in Modules/svmodule.c

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488934&group_id=5470

From noreply at sourceforge.net  Sun Jul 30 13:34:21 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Jul 2006 04:34:21 -0700
Subject: [ python-Feature Requests-1276768 ] dirutils.mkpath (verbose option
	does not work)
Message-ID: <E1G79Yr-00034N-LO@sc8-sf-web6.sourceforge.net>

Feature Requests item #1276768, was opened at 2005-08-30 15:59
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1276768&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Distutils
>Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: gorilla_killa (gorilla_killa)
Assigned to: Nobody/Anonymous (nobody)
Summary: dirutils.mkpath (verbose option does not work)

Initial Comment:
The Verbose option does not work.

Looked at the python script for dir_utils.py and the
verbose parameter is not used in the code.

Please fix this simple bug.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-30 06:29

Message:
Logged In: YES 
user_id=33168

Can you provide a patch which behaves as you expect?  Thanks.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1276768&group_id=5470

From noreply at sourceforge.net  Sun Jul 30 13:36:18 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Jul 2006 04:36:18 -0700
Subject: [ python-Bugs-1153417 ] os.remove error on Solaris
Message-ID: <E1G79ak-0003Ym-2h@sc8-sf-web1.sourceforge.net>

Bugs item #1153417, was opened at 2005-02-28 11:44
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153417&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Richard Philips (rphilips)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.remove error on Solaris

Initial Comment:
According to the documentation, when os.remove is
applied to a directory, OSError should be raised.

On Solaris, this is not the case: the directory is
removed BUT the link count on the parent directory does
NOT change.  File system corruption is the result.

Python details:
Python 2.3.4 (#3, Jun 18 2004, 10:14:55)
[GCC 3.2.2] on sunos5

Solaris details:

Number of CPUs is        2
CPU Type is              sparcv9+vis2
CPU Speed is             750 MHz
App Architecture is      sparc
Kernel Architecture is   sun4u
Kernel Bit Size is       64
OS Name is               SunOS
OS Version is            5.8
OS Distribution is       Solaris 8 7/01 s28s_u5wos_08 SPARC
Libc Name is             libc
Libc Version is          1
Kernel Version is        SunOS Release 5.8 Version
Generic_108528-20 64-bit


 

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-30 11:36

Message:
Logged In: YES 
user_id=849994

I don't think Python should do anything other than calling
the system's unlink().

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-03 22:50

Message:
Logged In: YES 
user_id=21627

This seems to be a bug report, not a patch, so I'm
reclassifying it.

Is there any chance that you tried os.remove as a superuser?
Python invokes unlink; according to the OS man page, unlink
gives EPERM when the file to remove is a directory.

I consider this a bug in the operating system: it should not
be possible, not even for the superuser, to corrupt the file
system using standard system calls. I don't know what the
rationale is for this behaviour.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153417&group_id=5470

From noreply at sourceforge.net  Sun Jul 30 13:40:08 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Jul 2006 04:40:08 -0700
Subject: [ python-Bugs-1101667 ] popen3 on windows loses environment variables
Message-ID: <E1G79eS-0001Wl-3V@sc8-sf-web2.sourceforge.net>

Bugs item #1101667, was opened at 2005-01-13 14:33
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1101667&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: June Kim (juneaftn)
Assigned to: Nobody/Anonymous (nobody)
Summary: popen3 on windows loses environment variables

Initial Comment:
see the following test code:

#test_popen3_1.py
import os
FILENAME='c:\temp\test_popen3_2.py'
os.environ['FOOBAR']='foobar'
print os.environ['FOOBAR']
fs=os.popen3("c:\python24\python -u %s"%
FILENAME,'b')
print fs[1].read()

#c:\temp\test_popen3_2.py
print "from test_popen3_2.py"
import os;print os.environ['FOOBAR']

Running test_popen3_1.py is expected to print out:
foobar
from test_popen3_2.py
foobar

But it doesn't print the last foobar. It correctly prints 
out when run on python 2.3.

If the FILENAME is set to a relative path, as when you 
are in the c:\temp directory and the FILENAME is set to 
test_popen3_2.py, the code works correct.

Tests run on windows XP, SP1.

This bug is related to the cgi bug #1100235.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-30 11:40

Message:
Logged In: YES 
user_id=849994

This was fixed in rev. 38397.

----------------------------------------------------------------------

Comment By: June Kim (juneaftn)
Date: 2005-01-27 07:16

Message:
Logged In: YES 
user_id=116941

Now I got it. The reason is os.py in python2.4 has changed
so that the _Environ(UserDict.IterableUserDict) has lost its
update method -- there was on in python2.3.

To rectify the problem you just copy and paste the update
method from python2.3 os.py.

--- os.py       Thu Jan 27 07:09:38 2005
+++ os_new.py   Thu Jan 27 07:10:44 2005
@@ -435,6 +435,9 @@
                 return key.upper() in self.data
             def get(self, key, failobj=None):
                 return self.data.get(key.upper(), failobj)
+            def update(self, dict):
+                for k, v in dict.items():
+                    self[k] = v
             def copy(self):
                 return dict(self)

@@ -446,6 +449,9 @@
             def __setitem__(self, key, item):
                 putenv(key, item)
                 self.data[key] = item
+            def update(self, dict):
+                for k, v in dict.items():
+                    self[k] = v
             try:
                 unsetenv
             except NameError:


----------------------------------------------------------------------

Comment By: June Kim (juneaftn)
Date: 2005-01-27 07:00

Message:
Logged In: YES 
user_id=116941

Oh, stupid me. The full path filename included '\t'. It
should've been escaped. Then the example code works with 2.3
and 2.4.

The real problem seems to be with os.environ.

I have reassured this problem exists on some XP SP1 boxes.

The test code is...

#test_popen3_1.py
import os
FILENAME='test_popen3_2.py'
env={};env['ENVIRON_UPDATE']='123';os.environ.update(env)
os.environ['ENVIRON_DIRECT_SETTING']='123'
cmdline='c:\python24\python.exe -u %s'%FILENAME
fs=os.popen3(cmdline,'b')
print fs[1].read()

#test_popen3_2.py
import os
if os.environ.has_key('ENVIRON_UPDATE'):print 'os.env.update
worked'
else:print 'os.env.update failed'
if os.environ.has_key('ENVIRON_DIRECT_SETTING'):print
'os.env assignment worked'
else:print 'os.env assignment failed'

Put these two files in the same path and run
test_popen3_1.py with python2.4 and python2.3.

Following is the result I got:

C:\test>\python23\python test_popen3_1.py
os.env.update worked
os.env assignment worked


C:\test>\python24\python test_popen3_1.py
os.env.update failed
os.env assignment worked

As you see the environment varaible that's updated with
os.environ.update has failed to get passed to popen3ed process.

This is the reason CGIHTTPServer.py fails to deliver
QUERY_STRING and etc. -- they are updated with
os.environ.update(env).


----------------------------------------------------------------------

Comment By: AGunn (ompeag)
Date: 2005-01-26 21:21

Message:
Logged In: YES 
user_id=1155133

I've tried recreating this problem and have had no luck.  I've 
tried three versions of python:  2.3, 2.4, and the current 
build version (2.5 something?).  I've also tried both absolute 
and relative paths.  All tests print out the second 'foobar' just 
fine.  I, too, am running XP, SP1.  

Any chance there's something special about how you are 
running the executables?  Say from a cygwin environment or 
something?

----------------------------------------------------------------------

Comment By: June Kim (juneaftn)
Date: 2005-01-13 14:36

Message:
Logged In: YES 
user_id=116941

Sorry. I got confused. When FILENAME is absolute, popen3 
loses the environment variables, whereas it is relative, 
popen3 works fine.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1101667&group_id=5470

From noreply at sourceforge.net  Sun Jul 30 13:53:45 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Jul 2006 04:53:45 -0700
Subject: [ python-Bugs-1476845 ] Finish PEP 343 terminology cleanup
Message-ID: <E1G79rd-0000je-Ij@sc8-sf-web6.sourceforge.net>

Bugs item #1476845, was opened at 2006-04-26 21:57
Message generated for change (Comment added) made by ncoghlan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1476845&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nick Coghlan (ncoghlan)
Assigned to: Nick Coghlan (ncoghlan)
Summary: Finish PEP 343 terminology cleanup

Initial Comment:
test_with.py was missed in the PEP 343 terminology
cleanup for Python alpha 2

PEP 343 itself still needs to be updated, too.

Creating this tracker item to record items needed to
finish the terminology cleanup post-alpha 2.

----------------------------------------------------------------------

>Comment By: Nick Coghlan (ncoghlan)
Date: 2006-07-30 21:53

Message:
Logged In: YES 
user_id=1038590

This all got dealt with when __context__() was removed. I
believe I left the bug report open with the intent of
closing it once we were happy that what went in to the first
beta was what we wanted to stick with for 2.5.

I'd say we've reached that point :)

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-30 03:13

Message:
Logged In: YES 
user_id=11375

Nick, does anything still need to be done for this?  What
terminology needs to be fixed in test_with.py?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1476845&group_id=5470

From noreply at sourceforge.net  Sun Jul 30 15:01:01 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Jul 2006 06:01:01 -0700
Subject: [ python-Bugs-1525866 ] Bug in shutil.copytree on Windows
Message-ID: <E1G7Auj-0006DD-Qg@sc8-sf-web3.sourceforge.net>

Bugs item #1525866, was opened at 2006-07-20 15:00
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525866&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Mike Foord (mjfoord)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bug in shutil.copytree on Windows

Initial Comment:
The problem is that the call to 'copystat(src, dst)'
was added to the shutil.copytree function, in svn
r38363 probably.  It will fail always on Windows, since
os.utime does not work on directories.

I guess that a patch similar to this one should fix it:

Index: shutil.py
===================================================================
--- shutil.py	(Revision 50710)
+++ shutil.py	(Arbeitskopie)
@@ -127,7 +127,12 @@
         # continue with other files
         except Error, err:
             errors.extend(err.args[0])
-    copystat(src, dst)
+    try:
+        copystat(src, dst)
+    except WindowsError:
+        pass
+    except OSError, err:
+        errors.extend(err.args[0])
     if errors:
         raise Error, errors

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2006-07-30 15:01

Message:
Logged In: YES 
user_id=21627

Thanks for the patch. Committed as r50977.

----------------------------------------------------------------------

Comment By: Mike Foord (mjfoord)
Date: 2006-07-28 16:14

Message:
Logged In: YES 
user_id=1123892

Nope - not quite right. Will fix tonight and upload a proper
patch.

Michael

----------------------------------------------------------------------

Comment By: Mike Foord (mjfoord)
Date: 2006-07-28 16:09

Message:
Logged In: YES 
user_id=1123892

The following should work as a test method for shutil.copytree

(Passes on my box against a patched version of shutil)

    def test_copytree_simple(self):
        src_dir = tempfile.mkdtemp()
        dst_dir = os.path.join(tempfile.mkdtemp(),
'destination')
        open(os.path.join(src_dir, 'test.txt'),
'w').write('123')
        os.mkdir(os.path.join(src_dir, 'test_dir'))
        open(os.path.join(src_dir, 'test_dir', 'test.txt'),
'w').write('456')
        #
        def testStat(src, dst):
            st_src = os.stat(src)
            st_dst = os.stat(dst)
            if hasattr(os, 'utime'):
                self.assertEqual((st_src.st_atime,
st_src.st_mtime), (st_dst.st_atime, st_dst.st_mtime))
            if hasattr(os, 'chmod'):
                # Should be equal anyway, should we change
permissions on one of the source files ?
               
self.assertEqual(stat.S_IMODE(st_src.st_mode),
stat.S_IMODE(st_dst.st_mode))
        #
        try:
            shutil.copytree(src_dir, dst_dir)
           
self.assertTrue(os.path.isfile(os.path.join(dst_dir,
'test.txt')))
           
self.assertTrue(os.path.isdir(os.path.join(dst_dir,
'test_dir')))
           
self.assertTrue(os.path.isfile(os.path.join(dst_dir,
'test_dir', 'test.txt')))
            self.assertEqual(open(os.path.join(dst_dir,
'test.txt')).read(), '123')
            self.assertEqual(open(os.path.join(dst_dir,
'test_dir', 'test.txt')).read(), '456')
           
        finally:
            try:
                os.remove(os.path.join(src_dir, 'test.txt'))
                os.remove(os.path.join(dst_dir, 'test.txt'))
                os.remove(os.path.join(src_dir, 'test_dir',
'test.txt'))
                os.remove(os.path.join(dst_dir, 'test_dir',
'test.txt'))
                os.removedirs(src_dir)
                os.removedirs(dst_dir)
            except:
                pass

Can turn the above into a patch tonight if needed.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-07-20 18:14

Message:
Logged In: YES 
user_id=21627

Can you also come up with a patch to the test suite?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525866&group_id=5470

From noreply at sourceforge.net  Sun Jul 30 15:31:41 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Jul 2006 06:31:41 -0700
Subject: [ python-Bugs-1257728 ] error message incorrectly claims Visual C++
	is required
Message-ID: <E1G7BOP-0001sx-Eg@sc8-sf-web6.sourceforge.net>

Bugs item #1257728, was opened at 2005-08-12 17:28
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257728&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Zooko O'Whielacronx (zooko)
Assigned to: Nobody/Anonymous (nobody)
Summary: error message incorrectly claims Visual C++ is required

Initial Comment:
Thank you for the excellent distutils tool!

Two problems:

First, this error message is emitted on win32, but it
appears to be incorrect, inasmuch as the Microsoft
compiler is not actually required:

"""
error: Python was built with version 7.1 of Visual
Studio, and extensions need to be built with the same
version of the compiler, but it isn't installed.
Error: Subprocess exited with result 1 for project core
"""

Second, the usage of distutils is somewhat confusing,
as the following line emits that error message:

./setup.py build -c mingw32; ./setup.py install

but the following line, which I intuitively believed to
be equivalent at first, works to compile and install
the package:

./setup.py build -c mingw32 install

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2006-07-30 15:31

Message:
Logged In: YES 
user_id=21627

Thanks for the suggestion; I committed something similar as
r50979 and r50980.

----------------------------------------------------------------------

Comment By: Zooko O'Whielacronx (zooko)
Date: 2006-07-25 23:10

Message:
Logged In: YES 
user_id=52562

How about:

"""
error: Python was built with version 7.1 of Visual
Studio, and extensions need to be built with a compiler that
can generate compatible binaries.  Some versions of gcc can
produce compatible binaries if given the "-mno-cygwin" flag.
 Distutils will pass the "-mno-cygwin" flag to gcc if
distutils is given the "-c mingw32" flag to the "build" command.

Error: Subprocess exited with result 1 for project core
"""

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-07-24 15:00

Message:
Logged In: YES 
user_id=21627

What would you like to say the error message instead?

----------------------------------------------------------------------

Comment By: Zooko O'Whielacronx (zooko)
Date: 2006-03-31 13:35

Message:
Logged In: YES 
user_id=52562

Changing this from category Distutils to category Windows.

----------------------------------------------------------------------

Comment By: Zooko O'Whielacronx (zooko)
Date: 2005-11-23 19:51

Message:
Logged In: YES 
user_id=52562

Whoo!  Progress!  Now it no longer spuriously claims that
Visual C++ is required for building extensions for Python,
and instead it spuriously claims that the .NET SDK is
required for building extensions for Python!

"""
error: The .NET Framework SDK needs to be installed before
building extensions for Python.
"""

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257728&group_id=5470

From noreply at sourceforge.net  Sun Jul 30 16:12:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Jul 2006 07:12:24 -0700
Subject: [ python-Bugs-1439538 ] test -e is not portable (Solaris 2.7)
Message-ID: <E1G7C1o-0001bN-3q@sc8-sf-web6.sourceforge.net>

Bugs item #1439538, was opened at 2006-02-27 11:51
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1439538&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: H?vard Tveite (havatv)
Assigned to: Martin v. L?wis (loewis)
Summary: test -e is not portable (Solaris 2.7)

Initial Comment:
I was adviced by Barry Warsaw to file a bug on this.

I tried to install Python 2.4.2 (and 2.3.5) on Solaris
2.7, but configure failed.
The Solaris 2.7 sh does not support "test -e".
"test -e" is used two times in configure.

The use of "test -e" is not recommended for "Portable
Shell Programming":
<URL:
http://www.gnu.org/software/autoconf/manual/autoconf-2.57/html_chapter/autoconf_10.html
>

I replaced "test -e" with "test -r", and it seems to work
(configure finishes OK, and the files are found), but
I do not know if this is the correct way to do it.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2006-07-30 16:12

Message:
Logged In: YES 
user_id=21627

test -r seems to be the portable way, although it tests for
a slightly different property (read access, instead of mere
file presence).

For autoconf, the best way is to use AC_CHECK_FILE, which
then expands to test -r. Fixed in r50982 and r50983.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-07-24 15:49

Message:
Logged In: YES 
user_id=849994

Martin, is the replacement correct?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1439538&group_id=5470

From noreply at sourceforge.net  Sun Jul 30 21:13:06 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Jul 2006 12:13:06 -0700
Subject: [ python-Bugs-1531349 ] Reflected (swapped) operations overridden by
	subclasses
Message-ID: <E1G7Gio-0007ke-6P@sc8-sf-web2.sourceforge.net>

Bugs item #1531349, was opened at 2006-07-31 02: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=1531349&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrei Polushin (polushin)
Assigned to: Nobody/Anonymous (nobody)
Summary: Reflected (swapped) operations overridden by subclasses

Initial Comment:
In Python 2.5b2 Documentation:
   Python Reference Manual
   Section 3.4.7 Emulating numeric types
   <http://docs.python.org/dev/ref/numeric-types.html>

Note to description of __radd__, __rsub__, etc.
specifies that "this method will be called before the
right operand's non-reflected method."

Should replace RIGHT with LEFT here. The correct phrase
is "this method will be called before the LEFT
operand's non-reflected method."

For example, reader should clearly understand that
"RIGHT.__radd__ will be called before the LEFT.__add__"
in case when type(RIGHT) is subclass of type(LEFT).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531349&group_id=5470

From noreply at sourceforge.net  Sun Jul 30 22:23:45 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Jul 2006 13:23:45 -0700
Subject: [ python-Bugs-1531349 ] Reflected (swapped) operations overridden by
	subclasses
Message-ID: <E1G7HpB-00080E-Ci@sc8-sf-web6.sourceforge.net>

Bugs item #1531349, was opened at 2006-07-30 19:13
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531349&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Andrei Polushin (polushin)
Assigned to: Nobody/Anonymous (nobody)
Summary: Reflected (swapped) operations overridden by subclasses

Initial Comment:
In Python 2.5b2 Documentation:
   Python Reference Manual
   Section 3.4.7 Emulating numeric types
   <http://docs.python.org/dev/ref/numeric-types.html>

Note to description of __radd__, __rsub__, etc.
specifies that "this method will be called before the
right operand's non-reflected method."

Should replace RIGHT with LEFT here. The correct phrase
is "this method will be called before the LEFT
operand's non-reflected method."

For example, reader should clearly understand that
"RIGHT.__radd__ will be called before the LEFT.__add__"
in case when type(RIGHT) is subclass of type(LEFT).

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-30 20:23

Message:
Logged In: YES 
user_id=849994

Fixed in rev. 50990, 50991 (2.4). Thanks!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531349&group_id=5470

From noreply at sourceforge.net  Sun Jul 30 23:06:09 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Jul 2006 14:06:09 -0700
Subject: [ python-Bugs-1531405 ] format_exception raises if str(exception)
	raises
Message-ID: <E1G7IUD-0001GS-P8@sc8-sf-web3.sourceforge.net>

Bugs item #1531405, was opened at 2006-07-30 17: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=1531405&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Jp Calderone (kuran)
Assigned to: Nobody/Anonymous (nobody)
Summary: format_exception raises if str(exception) raises

Initial Comment:
Previously format_exception_only used _some_str() to
find the string representation of an exception.  In
current trunk at HEAD that code has been factored into
_format_final_exc_line and changed in two ways: it now
calls str(exception) twice instead of once and in one
of those cases, it calls str() directly rather than
through _some_str, which does exception handling.

The end result of this is that application-level code
which uses the traceback module to format exceptions
which previously could not raise exceptions now can
raise exceptions.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531405&group_id=5470

From noreply at sourceforge.net  Sun Jul 30 23:07:12 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Jul 2006 14:07:12 -0700
Subject: [ python-Bugs-1531405 ] format_exception raises if str(exception)
	raises
Message-ID: <E1G7IVE-0001ma-Qw@sc8-sf-web3.sourceforge.net>

Bugs item #1531405, was opened at 2006-07-30 17:06
Message generated for change (Settings changed) made by kuran
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531405&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
>Priority: 9
Submitted By: Jp Calderone (kuran)
Assigned to: Nobody/Anonymous (nobody)
Summary: format_exception raises if str(exception) raises

Initial Comment:
Previously format_exception_only used _some_str() to
find the string representation of an exception.  In
current trunk at HEAD that code has been factored into
_format_final_exc_line and changed in two ways: it now
calls str(exception) twice instead of once and in one
of those cases, it calls str() directly rather than
through _some_str, which does exception handling.

The end result of this is that application-level code
which uses the traceback module to format exceptions
which previously could not raise exceptions now can
raise exceptions.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531405&group_id=5470

From noreply at sourceforge.net  Sun Jul 30 23:37:34 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Jul 2006 14:37:34 -0700
Subject: [ python-Bugs-1531415 ] parsetok.c emits warnings by writing to stderr
Message-ID: <E1G7Iyc-0007g9-Fk@sc8-sf-web2.sourceforge.net>

Bugs item #1531415, was opened at 2006-07-30 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=1531415&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Jp Calderone (kuran)
Assigned to: Nobody/Anonymous (nobody)
Summary: parsetok.c emits warnings by writing to stderr

Initial Comment:
Warnings should be emitted with the warning system, via
PyErr_Warn.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531415&group_id=5470

From noreply at sourceforge.net  Mon Jul 31 04:42:03 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Jul 2006 19:42:03 -0700
Subject: [ python-Bugs-1465014 ] CSV regression in 2.5a1: multi-line cells
Message-ID: <E1G7NjH-0003ST-63@sc8-sf-web6.sourceforge.net>

Bugs item #1465014, was opened at 2006-04-06 01:14
Message generated for change (Comment added) made by andrewmcnamara
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465014&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
Status: Pending
Resolution: Fixed
Priority: 5
Submitted By: David Goodger (goodger)
Assigned to: Skip Montanaro (montanaro)
Summary: CSV regression in 2.5a1: multi-line cells

Initial Comment:
Running the attached csv_test.py under Python 2.4.2
(Windows XP SP1) produces:

>c:\apps\python24\python.exe ./csv_test.py
['one', '2', 'three (line 1)\n(line 2)']

Note that the third item in the row contains a newline
between "(line 1)" and "(line 2)".

With Python 2.5a1, I get:

>c:\apps\python25\python.exe ./csv_test.py
['one', '2', 'three (line 1)(line 2)']

Notice the missing newline, which is significant.  The
CSV module under 2.5a1 seems to lose data.


----------------------------------------------------------------------

>Comment By: Andrew McNamara (andrewmcnamara)
Date: 2006-07-31 12:41

Message:
Logged In: YES 
user_id=698599

I've changed the comment again in changeset 50993 - 
hopefully this attempt describes the difference more fully. 
Let me know what you think.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2006-07-30 06:07

Message:
Logged In: YES 
user_id=44345

I checked in a change to libcsv.tex (revision 50953).  It adds a versionchanged 
bit to the reader doc that explains why the behavior changed in 2.5.  Andrew & 
Andrew, please check my work.  Sorry for the delay taking care of this.

Skip


----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-30 03:24

Message:
Logged In: YES 
user_id=11375

I looked at this bug report, but I have no idea of exactly
what behaviour has changed or what needs to be described.


----------------------------------------------------------------------

Comment By: Andrew McNamara (andrewmcnamara)
Date: 2006-06-23 13:34

Message:
Logged In: YES 
user_id=698599

Yep, your point about adding a comment to the documentation 
is fair. Skip, do you want to take my words and massage 
them into a form suitable for the docs?

----------------------------------------------------------------------

Comment By: David Goodger (goodger)
Date: 2006-06-23 13:13

Message:
Logged In: YES 
user_id=7733

I didn't realize that the previous behavior was buggy; I
thought that the current behavior was a side-effect.  The
2.5 behavior did cause a small problem in Docutils, but it's
already been fixed.  I just wanted to ensure that no
regression was creeping in to 2.5.

Thanks for the explanation!  Perhaps it could be added to
the docs in some form?

Marking the bug report closed.

----------------------------------------------------------------------

Comment By: Andrew McNamara (andrewmcnamara)
Date: 2006-06-23 10:27

Message:
Logged In: YES 
user_id=698599

The previous behaviour caused considerable problems, 
particularly on platforms that did not use the unix line-
ending conventions, or with files that originated on those 
platforms - users were finding mysterious newlines where 
they didn't expect them.

Quoted fields exist to allow characters that would otherwise 
be considered part of the syntax to appear within the field. 
 So yes, quoted fields are a special case, and necessarily 
so.

The current behaviour puts the control back in the hands of 
the user of the module: if literal newlines are important 
within a field, they need to read their file in a way that 
preserves the newlines. The old behaviour would introduce 
spurious characters into quoted fields, with no way for the 
user to control that behaviour.

I'm sorry that the change causes you problems. With a format 
that's as loosely defined as CSV, it's an unfortunate fact 
of life that there are going to be conflicting requirements. 

----------------------------------------------------------------------

Comment By: David Goodger (goodger)
Date: 2006-06-23 04:17

Message:
Logged In: YES 
user_id=7733

I see what you're saying, but I disagree.  In Python 2.4,
csv.reader did not require newlines, but in Python 2.5 it
does.  That's a significant behavioral change.  In the
stdlib csv "Module Contents" docs for csv.reader, it says:
"csvfile can be any object which supports the iterator
protocol and returns a string each time its next method is
called."  It doesn't mention newline-terminated strings.

In any case, the behavior is inconsistent: newlines are not
required to terminate row-ending strings, but only strings
which end inside cells split across rows.  Why the discrepancy?

----------------------------------------------------------------------

Comment By: Andrew McNamara (andrewmcnamara)
Date: 2006-06-21 09:17

Message:
Logged In: YES 
user_id=698599

I think your problem is with str.splitlines(), rather than 
the csv.reader: splitlines ate the newline. If you pass it 
True as an argument, it will retain the end-of-line 
character in the resulting strings.

----------------------------------------------------------------------

Comment By: David Goodger (goodger)
Date: 2006-05-03 07:04

Message:
Logged In: YES 
user_id=7733

Assigned to Andrew McNamara, since his change appears to
have caused this regression (revision 38290 on
Modules/_csv.c).

----------------------------------------------------------------------

Comment By: David Goodger (goodger)
Date: 2006-05-03 06:58

Message:
Logged In: YES 
user_id=7733

Further investigation has revealed that the regression only
affects iterator I/O, not file I/O.  The attached
csv_test.py demonstrates.  Run with Python 2.5 to get:

results from file I/O:
[['one', '2', 'three (line 1)\n(line 2)']]

results from iterator I/O:
[['one', '2', 'three (line 1)(line 2)']]

----------------------------------------------------------------------

Comment By: David Goodger (goodger)
Date: 2006-04-06 01:44

Message:
Logged In: YES 
user_id=7733

This bug seems to be a side effect of revision 38290 on
Modules/_csv.c, which was prompted by bug 967934
(http://www.python.org/sf/967934).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465014&group_id=5470

From noreply at sourceforge.net  Mon Jul 31 05:13:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Jul 2006 20:13:05 -0700
Subject: [ python-Bugs-1465014 ] CSV regression in 2.5a1: multi-line cells
Message-ID: <E1G7ODJ-0002ld-51@sc8-sf-web1.sourceforge.net>

Bugs item #1465014, was opened at 2006-04-05 10:14
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465014&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
Status: Pending
Resolution: Fixed
Priority: 5
Submitted By: David Goodger (goodger)
Assigned to: Skip Montanaro (montanaro)
Summary: CSV regression in 2.5a1: multi-line cells

Initial Comment:
Running the attached csv_test.py under Python 2.4.2
(Windows XP SP1) produces:

>c:\apps\python24\python.exe ./csv_test.py
['one', '2', 'three (line 1)\n(line 2)']

Note that the third item in the row contains a newline
between "(line 1)" and "(line 2)".

With Python 2.5a1, I get:

>c:\apps\python25\python.exe ./csv_test.py
['one', '2', 'three (line 1)(line 2)']

Notice the missing newline, which is significant.  The
CSV module under 2.5a1 seems to lose data.


----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2006-07-30 22:13

Message:
Logged In: YES 
user_id=44345

I'll see your 50993 and raise you a 50998.  Just minor tweaks.  Hopefully we can 
close this puppy, though a small example to make the idea concrete might be 
worthwhile.


----------------------------------------------------------------------

Comment By: Andrew McNamara (andrewmcnamara)
Date: 2006-07-30 21:41

Message:
Logged In: YES 
user_id=698599

I've changed the comment again in changeset 50993 - 
hopefully this attempt describes the difference more fully. 
Let me know what you think.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2006-07-29 15:07

Message:
Logged In: YES 
user_id=44345

I checked in a change to libcsv.tex (revision 50953).  It adds a versionchanged 
bit to the reader doc that explains why the behavior changed in 2.5.  Andrew & 
Andrew, please check my work.  Sorry for the delay taking care of this.

Skip


----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-29 12:24

Message:
Logged In: YES 
user_id=11375

I looked at this bug report, but I have no idea of exactly
what behaviour has changed or what needs to be described.


----------------------------------------------------------------------

Comment By: Andrew McNamara (andrewmcnamara)
Date: 2006-06-22 22:34

Message:
Logged In: YES 
user_id=698599

Yep, your point about adding a comment to the documentation 
is fair. Skip, do you want to take my words and massage 
them into a form suitable for the docs?

----------------------------------------------------------------------

Comment By: David Goodger (goodger)
Date: 2006-06-22 22:13

Message:
Logged In: YES 
user_id=7733

I didn't realize that the previous behavior was buggy; I
thought that the current behavior was a side-effect.  The
2.5 behavior did cause a small problem in Docutils, but it's
already been fixed.  I just wanted to ensure that no
regression was creeping in to 2.5.

Thanks for the explanation!  Perhaps it could be added to
the docs in some form?

Marking the bug report closed.

----------------------------------------------------------------------

Comment By: Andrew McNamara (andrewmcnamara)
Date: 2006-06-22 19:27

Message:
Logged In: YES 
user_id=698599

The previous behaviour caused considerable problems, 
particularly on platforms that did not use the unix line-
ending conventions, or with files that originated on those 
platforms - users were finding mysterious newlines where 
they didn't expect them.

Quoted fields exist to allow characters that would otherwise 
be considered part of the syntax to appear within the field. 
 So yes, quoted fields are a special case, and necessarily 
so.

The current behaviour puts the control back in the hands of 
the user of the module: if literal newlines are important 
within a field, they need to read their file in a way that 
preserves the newlines. The old behaviour would introduce 
spurious characters into quoted fields, with no way for the 
user to control that behaviour.

I'm sorry that the change causes you problems. With a format 
that's as loosely defined as CSV, it's an unfortunate fact 
of life that there are going to be conflicting requirements. 

----------------------------------------------------------------------

Comment By: David Goodger (goodger)
Date: 2006-06-22 13:17

Message:
Logged In: YES 
user_id=7733

I see what you're saying, but I disagree.  In Python 2.4,
csv.reader did not require newlines, but in Python 2.5 it
does.  That's a significant behavioral change.  In the
stdlib csv "Module Contents" docs for csv.reader, it says:
"csvfile can be any object which supports the iterator
protocol and returns a string each time its next method is
called."  It doesn't mention newline-terminated strings.

In any case, the behavior is inconsistent: newlines are not
required to terminate row-ending strings, but only strings
which end inside cells split across rows.  Why the discrepancy?

----------------------------------------------------------------------

Comment By: Andrew McNamara (andrewmcnamara)
Date: 2006-06-20 18:17

Message:
Logged In: YES 
user_id=698599

I think your problem is with str.splitlines(), rather than 
the csv.reader: splitlines ate the newline. If you pass it 
True as an argument, it will retain the end-of-line 
character in the resulting strings.

----------------------------------------------------------------------

Comment By: David Goodger (goodger)
Date: 2006-05-02 16:04

Message:
Logged In: YES 
user_id=7733

Assigned to Andrew McNamara, since his change appears to
have caused this regression (revision 38290 on
Modules/_csv.c).

----------------------------------------------------------------------

Comment By: David Goodger (goodger)
Date: 2006-05-02 15:58

Message:
Logged In: YES 
user_id=7733

Further investigation has revealed that the regression only
affects iterator I/O, not file I/O.  The attached
csv_test.py demonstrates.  Run with Python 2.5 to get:

results from file I/O:
[['one', '2', 'three (line 1)\n(line 2)']]

results from iterator I/O:
[['one', '2', 'three (line 1)(line 2)']]

----------------------------------------------------------------------

Comment By: David Goodger (goodger)
Date: 2006-04-05 10:44

Message:
Logged In: YES 
user_id=7733

This bug seems to be a side effect of revision 38290 on
Modules/_csv.c, which was prompted by bug 967934
(http://www.python.org/sf/967934).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465014&group_id=5470

From noreply at sourceforge.net  Mon Jul 31 05:25:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Jul 2006 20:25:42 -0700
Subject: [ python-Bugs-1163367 ] correct/clarify documentation for super
Message-ID: <E1G7OPW-00054z-TN@sc8-sf-web5.sourceforge.net>

Bugs item #1163367, was opened at 2005-03-14 16:39
Message generated for change (Comment added) made by bediviere
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163367&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Steven Bethard (bediviere)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: correct/clarify documentation for super

Initial Comment:
The current documentation for super is confusing.  For
instance, it says that it returns "the superclass of
type" which is incorrect; it actually returns the next
type in type's MRO.  Well, to be truthful, it doesn't
even do that; it returns a proxy object which makes
that type's attributes available, but that's just
another reason to fix the documentation.

I suggest changing the wording to something like:

"""super(type[, object-or-type])

Return an object that exposes the attributes available
through the type's superclasses, without exposing the
attributes of the type itself.  Attributes will be
looked up using the normal resolution order, omitting
the first class in the MRO (that is, the type itself).

If the second argument is present, it should either be
an instance of object, in which case
isinstance(object-or-type, type) must be true, or it
should be an instance of type, in which case
issubclass(object-or-type, type) must be true.  The
typical use for this form of super is to call a
cooperative superclass method:

class C(B):
    def meth(self, arg):
        super(C, self).meth(arg)

If the second argument to super is omitted, the super
object returned will not expose any attributes
directly.  However,  attributes will be accessible
whenever the descriptor machinery is invoked, e.g.
though explicit invocation of __get__.

Note that super is undefined for implicit lookups using
statements or operators such as "super(C, self)[name]".
 These must be spelled out with their explicit lookup,
e.g. "super(C, self).__getitem__(name)". New in version
2.2. 
"""

It's not perfect and I welcome suggestions for
re-wording, but I think it's substantially more
accurate about what super actually does.  It also moves
the "second argument omitted" situation to the end,
since this is a vastly more uncommon use case.

----------------------------------------------------------------------

>Comment By: Steven Bethard (bediviere)
Date: 2006-07-30 21:25

Message:
Logged In: YES 
user_id=945502

If you're talking about the following: 
"""
Note that \function{super} is implemented as part of the
binding process for explicit dotted attribute lookups such
as \samp{super(C, self).__getitem__(name)}.  Accordingly,
\function{super} is undefined for implicit lookups using
statements or operators such as \samp{super(C, self)[name]}. 
""" 
I believe it's trying to say that super works as if it only
overrode __getattr__. Hence ``sup.XXX`` works, but not
``sup[...]``, ``sup(...)``, etc.  That first sentence seems
mostly unnecessary to me.  As long as we say that the
__XXX__ methods must be spelled out explicitly, I think
we've got our bases covered.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-29 14:40

Message:
Logged In: YES 
user_id=3066

I'm not sure what the paragraph following the \end{verbatim}
means.  Can someone clarify?

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-20 10:06

Message:
Logged In: YES 
user_id=1188172

See also Bug #973579 (which I closed as duplicate) for
alternative wording.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163367&group_id=5470

From noreply at sourceforge.net  Mon Jul 31 05:38:29 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Jul 2006 20:38:29 -0700
Subject: [ python-Feature Requests-1531505 ] distutils 'register' command and
	windows home directories
Message-ID: <E1G7Obt-0004I4-4L@sc8-sf-web2.sourceforge.net>

Feature Requests item #1531505, was opened at 2006-07-30 20:38
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=1531505&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Submitted By: Josiah Carlson (josiahcarlson)
Assigned to: Nobody/Anonymous (nobody)
Summary: distutils 'register' command and windows home directories

Initial Comment:
The current version of the Distutils 'register' command
does not support Windows 2k or XP home directories, as
it checks for 'HOME' in os.environ .  This is suffient
for posix platforms, but for Windows 2k and XP,
generally 'home directories' are specified via the
environment variable 'USERPROFILE', or can be
constructed from 'HOMEDRIVE' and 'HOMEPATH'.

A simple fix would be to create two functions:
has_home() and get_home(), whose purposes are to
determine whether a home directory exists for the
current platform, and to get the home directory for the
current platform, respectively.

A sample implementation of both functions is as follows
(replace the leading commas with spaces).

keys = ['HOME', 'USERPROFILE']

def has_home():
,,,,for i in keys:
,,,,,,,,if i in os.environ:
,,,,,,,,,,,,return 1
,,,,return 0

def get_home():
,,,,for i in keys:
,,,,,,,,if i in os.environ:
,,,,,,,,,,,,return os.environ[i]


Once those definitions are made, then the two relevant
portions of
distutils.command.register.register.set_metadata() can
be updated to use these two functions.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1531505&group_id=5470

From noreply at sourceforge.net  Mon Jul 31 05:58:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Jul 2006 20:58:42 -0700
Subject: [ python-Bugs-1163367 ] correct/clarify documentation for super
Message-ID: <E1G7OvS-00068x-E1@sc8-sf-web3.sourceforge.net>

Bugs item #1163367, was opened at 2005-03-14 18:39
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163367&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Steven Bethard (bediviere)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: correct/clarify documentation for super

Initial Comment:
The current documentation for super is confusing.  For
instance, it says that it returns "the superclass of
type" which is incorrect; it actually returns the next
type in type's MRO.  Well, to be truthful, it doesn't
even do that; it returns a proxy object which makes
that type's attributes available, but that's just
another reason to fix the documentation.

I suggest changing the wording to something like:

"""super(type[, object-or-type])

Return an object that exposes the attributes available
through the type's superclasses, without exposing the
attributes of the type itself.  Attributes will be
looked up using the normal resolution order, omitting
the first class in the MRO (that is, the type itself).

If the second argument is present, it should either be
an instance of object, in which case
isinstance(object-or-type, type) must be true, or it
should be an instance of type, in which case
issubclass(object-or-type, type) must be true.  The
typical use for this form of super is to call a
cooperative superclass method:

class C(B):
    def meth(self, arg):
        super(C, self).meth(arg)

If the second argument to super is omitted, the super
object returned will not expose any attributes
directly.  However,  attributes will be accessible
whenever the descriptor machinery is invoked, e.g.
though explicit invocation of __get__.

Note that super is undefined for implicit lookups using
statements or operators such as "super(C, self)[name]".
 These must be spelled out with their explicit lookup,
e.g. "super(C, self).__getitem__(name)". New in version
2.2. 
"""

It's not perfect and I welcome suggestions for
re-wording, but I think it's substantially more
accurate about what super actually does.  It also moves
the "second argument omitted" situation to the end,
since this is a vastly more uncommon use case.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-30 23:58

Message:
Logged In: YES 
user_id=3066

That explanation doesn't deal with the difference between
the 1- and 2-argument signatures.  It can be cleaned up
pretty heavily.  I'll see if I can come up with a decent
comment about 1-argument calls to super().

----------------------------------------------------------------------

Comment By: Steven Bethard (bediviere)
Date: 2006-07-30 23:25

Message:
Logged In: YES 
user_id=945502

If you're talking about the following: 
"""
Note that \function{super} is implemented as part of the
binding process for explicit dotted attribute lookups such
as \samp{super(C, self).__getitem__(name)}.  Accordingly,
\function{super} is undefined for implicit lookups using
statements or operators such as \samp{super(C, self)[name]}. 
""" 
I believe it's trying to say that super works as if it only
overrode __getattr__. Hence ``sup.XXX`` works, but not
``sup[...]``, ``sup(...)``, etc.  That first sentence seems
mostly unnecessary to me.  As long as we say that the
__XXX__ methods must be spelled out explicitly, I think
we've got our bases covered.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-29 16:40

Message:
Logged In: YES 
user_id=3066

I'm not sure what the paragraph following the \end{verbatim}
means.  Can someone clarify?

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-20 12:06

Message:
Logged In: YES 
user_id=1188172

See also Bug #973579 (which I closed as duplicate) for
alternative wording.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163367&group_id=5470

From noreply at sourceforge.net  Mon Jul 31 06:14:33 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Jul 2006 21:14:33 -0700
Subject: [ python-Bugs-1465014 ] CSV regression in 2.5a1: multi-line cells
Message-ID: <E1G7PAn-0003EY-Bg@sc8-sf-web6.sourceforge.net>

Bugs item #1465014, was opened at 2006-04-06 01:14
Message generated for change (Comment added) made by andrewmcnamara
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465014&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
Status: Pending
Resolution: Fixed
Priority: 5
Submitted By: David Goodger (goodger)
Assigned to: Skip Montanaro (montanaro)
Summary: CSV regression in 2.5a1: multi-line cells

Initial Comment:
Running the attached csv_test.py under Python 2.4.2
(Windows XP SP1) produces:

>c:\apps\python24\python.exe ./csv_test.py
['one', '2', 'three (line 1)\n(line 2)']

Note that the third item in the row contains a newline
between "(line 1)" and "(line 2)".

With Python 2.5a1, I get:

>c:\apps\python25\python.exe ./csv_test.py
['one', '2', 'three (line 1)(line 2)']

Notice the missing newline, which is significant.  The
CSV module under 2.5a1 seems to lose data.


----------------------------------------------------------------------

>Comment By: Andrew McNamara (andrewmcnamara)
Date: 2006-07-31 14:14

Message:
Logged In: YES 
user_id=698599

Yep, your changes are reasonable. I considered adding an 
example, but couldn't think of anything that illustrated 
the point without confusing the reader further.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2006-07-31 13:13

Message:
Logged In: YES 
user_id=44345

I'll see your 50993 and raise you a 50998.  Just minor tweaks.  Hopefully we can 
close this puppy, though a small example to make the idea concrete might be 
worthwhile.


----------------------------------------------------------------------

Comment By: Andrew McNamara (andrewmcnamara)
Date: 2006-07-31 12:41

Message:
Logged In: YES 
user_id=698599

I've changed the comment again in changeset 50993 - 
hopefully this attempt describes the difference more fully. 
Let me know what you think.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2006-07-30 06:07

Message:
Logged In: YES 
user_id=44345

I checked in a change to libcsv.tex (revision 50953).  It adds a versionchanged 
bit to the reader doc that explains why the behavior changed in 2.5.  Andrew & 
Andrew, please check my work.  Sorry for the delay taking care of this.

Skip


----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-30 03:24

Message:
Logged In: YES 
user_id=11375

I looked at this bug report, but I have no idea of exactly
what behaviour has changed or what needs to be described.


----------------------------------------------------------------------

Comment By: Andrew McNamara (andrewmcnamara)
Date: 2006-06-23 13:34

Message:
Logged In: YES 
user_id=698599

Yep, your point about adding a comment to the documentation 
is fair. Skip, do you want to take my words and massage 
them into a form suitable for the docs?

----------------------------------------------------------------------

Comment By: David Goodger (goodger)
Date: 2006-06-23 13:13

Message:
Logged In: YES 
user_id=7733

I didn't realize that the previous behavior was buggy; I
thought that the current behavior was a side-effect.  The
2.5 behavior did cause a small problem in Docutils, but it's
already been fixed.  I just wanted to ensure that no
regression was creeping in to 2.5.

Thanks for the explanation!  Perhaps it could be added to
the docs in some form?

Marking the bug report closed.

----------------------------------------------------------------------

Comment By: Andrew McNamara (andrewmcnamara)
Date: 2006-06-23 10:27

Message:
Logged In: YES 
user_id=698599

The previous behaviour caused considerable problems, 
particularly on platforms that did not use the unix line-
ending conventions, or with files that originated on those 
platforms - users were finding mysterious newlines where 
they didn't expect them.

Quoted fields exist to allow characters that would otherwise 
be considered part of the syntax to appear within the field. 
 So yes, quoted fields are a special case, and necessarily 
so.

The current behaviour puts the control back in the hands of 
the user of the module: if literal newlines are important 
within a field, they need to read their file in a way that 
preserves the newlines. The old behaviour would introduce 
spurious characters into quoted fields, with no way for the 
user to control that behaviour.

I'm sorry that the change causes you problems. With a format 
that's as loosely defined as CSV, it's an unfortunate fact 
of life that there are going to be conflicting requirements. 

----------------------------------------------------------------------

Comment By: David Goodger (goodger)
Date: 2006-06-23 04:17

Message:
Logged In: YES 
user_id=7733

I see what you're saying, but I disagree.  In Python 2.4,
csv.reader did not require newlines, but in Python 2.5 it
does.  That's a significant behavioral change.  In the
stdlib csv "Module Contents" docs for csv.reader, it says:
"csvfile can be any object which supports the iterator
protocol and returns a string each time its next method is
called."  It doesn't mention newline-terminated strings.

In any case, the behavior is inconsistent: newlines are not
required to terminate row-ending strings, but only strings
which end inside cells split across rows.  Why the discrepancy?

----------------------------------------------------------------------

Comment By: Andrew McNamara (andrewmcnamara)
Date: 2006-06-21 09:17

Message:
Logged In: YES 
user_id=698599

I think your problem is with str.splitlines(), rather than 
the csv.reader: splitlines ate the newline. If you pass it 
True as an argument, it will retain the end-of-line 
character in the resulting strings.

----------------------------------------------------------------------

Comment By: David Goodger (goodger)
Date: 2006-05-03 07:04

Message:
Logged In: YES 
user_id=7733

Assigned to Andrew McNamara, since his change appears to
have caused this regression (revision 38290 on
Modules/_csv.c).

----------------------------------------------------------------------

Comment By: David Goodger (goodger)
Date: 2006-05-03 06:58

Message:
Logged In: YES 
user_id=7733

Further investigation has revealed that the regression only
affects iterator I/O, not file I/O.  The attached
csv_test.py demonstrates.  Run with Python 2.5 to get:

results from file I/O:
[['one', '2', 'three (line 1)\n(line 2)']]

results from iterator I/O:
[['one', '2', 'three (line 1)(line 2)']]

----------------------------------------------------------------------

Comment By: David Goodger (goodger)
Date: 2006-04-06 01:44

Message:
Logged In: YES 
user_id=7733

This bug seems to be a side effect of revision 38290 on
Modules/_csv.c, which was prompted by bug 967934
(http://www.python.org/sf/967934).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465014&group_id=5470

From noreply at sourceforge.net  Mon Jul 31 06:29:53 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Jul 2006 21:29:53 -0700
Subject: [ python-Bugs-1163367 ] correct/clarify documentation for super
Message-ID: <E1G7PPd-00056r-Mx@sc8-sf-web3.sourceforge.net>

Bugs item #1163367, was opened at 2005-03-14 18:39
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163367&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Steven Bethard (bediviere)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: correct/clarify documentation for super

Initial Comment:
The current documentation for super is confusing.  For
instance, it says that it returns "the superclass of
type" which is incorrect; it actually returns the next
type in type's MRO.  Well, to be truthful, it doesn't
even do that; it returns a proxy object which makes
that type's attributes available, but that's just
another reason to fix the documentation.

I suggest changing the wording to something like:

"""super(type[, object-or-type])

Return an object that exposes the attributes available
through the type's superclasses, without exposing the
attributes of the type itself.  Attributes will be
looked up using the normal resolution order, omitting
the first class in the MRO (that is, the type itself).

If the second argument is present, it should either be
an instance of object, in which case
isinstance(object-or-type, type) must be true, or it
should be an instance of type, in which case
issubclass(object-or-type, type) must be true.  The
typical use for this form of super is to call a
cooperative superclass method:

class C(B):
    def meth(self, arg):
        super(C, self).meth(arg)

If the second argument to super is omitted, the super
object returned will not expose any attributes
directly.  However,  attributes will be accessible
whenever the descriptor machinery is invoked, e.g.
though explicit invocation of __get__.

Note that super is undefined for implicit lookups using
statements or operators such as "super(C, self)[name]".
 These must be spelled out with their explicit lookup,
e.g. "super(C, self).__getitem__(name)". New in version
2.2. 
"""

It's not perfect and I welcome suggestions for
re-wording, but I think it's substantially more
accurate about what super actually does.  It also moves
the "second argument omitted" situation to the end,
since this is a vastly more uncommon use case.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-31 00:29

Message:
Logged In: YES 
user_id=3066

Ok, after playing around a bit with the 1-arg variation and
the 2nd-arg-is-a-type variation, I don't have a clue as to
how either would be used.

It someone can explain either of both of those, please post
an explanation here, and I'll do any LaTeX conversions needed.

I've attached what I have so far as a patch.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-30 23:58

Message:
Logged In: YES 
user_id=3066

That explanation doesn't deal with the difference between
the 1- and 2-argument signatures.  It can be cleaned up
pretty heavily.  I'll see if I can come up with a decent
comment about 1-argument calls to super().

----------------------------------------------------------------------

Comment By: Steven Bethard (bediviere)
Date: 2006-07-30 23:25

Message:
Logged In: YES 
user_id=945502

If you're talking about the following: 
"""
Note that \function{super} is implemented as part of the
binding process for explicit dotted attribute lookups such
as \samp{super(C, self).__getitem__(name)}.  Accordingly,
\function{super} is undefined for implicit lookups using
statements or operators such as \samp{super(C, self)[name]}. 
""" 
I believe it's trying to say that super works as if it only
overrode __getattr__. Hence ``sup.XXX`` works, but not
``sup[...]``, ``sup(...)``, etc.  That first sentence seems
mostly unnecessary to me.  As long as we say that the
__XXX__ methods must be spelled out explicitly, I think
we've got our bases covered.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-29 16:40

Message:
Logged In: YES 
user_id=3066

I'm not sure what the paragraph following the \end{verbatim}
means.  Can someone clarify?

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-20 12:06

Message:
Logged In: YES 
user_id=1188172

See also Bug #973579 (which I closed as duplicate) for
alternative wording.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163367&group_id=5470

From noreply at sourceforge.net  Mon Jul 31 07:02:09 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Jul 2006 22:02:09 -0700
Subject: [ python-Bugs-1163367 ] correct/clarify documentation for super
Message-ID: <E1G7Pur-0004Wt-RO@sc8-sf-web2.sourceforge.net>

Bugs item #1163367, was opened at 2005-03-14 16:39
Message generated for change (Comment added) made by bediviere
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163367&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Steven Bethard (bediviere)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: correct/clarify documentation for super

Initial Comment:
The current documentation for super is confusing.  For
instance, it says that it returns "the superclass of
type" which is incorrect; it actually returns the next
type in type's MRO.  Well, to be truthful, it doesn't
even do that; it returns a proxy object which makes
that type's attributes available, but that's just
another reason to fix the documentation.

I suggest changing the wording to something like:

"""super(type[, object-or-type])

Return an object that exposes the attributes available
through the type's superclasses, without exposing the
attributes of the type itself.  Attributes will be
looked up using the normal resolution order, omitting
the first class in the MRO (that is, the type itself).

If the second argument is present, it should either be
an instance of object, in which case
isinstance(object-or-type, type) must be true, or it
should be an instance of type, in which case
issubclass(object-or-type, type) must be true.  The
typical use for this form of super is to call a
cooperative superclass method:

class C(B):
    def meth(self, arg):
        super(C, self).meth(arg)

If the second argument to super is omitted, the super
object returned will not expose any attributes
directly.  However,  attributes will be accessible
whenever the descriptor machinery is invoked, e.g.
though explicit invocation of __get__.

Note that super is undefined for implicit lookups using
statements or operators such as "super(C, self)[name]".
 These must be spelled out with their explicit lookup,
e.g. "super(C, self).__getitem__(name)". New in version
2.2. 
"""

It's not perfect and I welcome suggestions for
re-wording, but I think it's substantially more
accurate about what super actually does.  It also moves
the "second argument omitted" situation to the end,
since this is a vastly more uncommon use case.

----------------------------------------------------------------------

>Comment By: Steven Bethard (bediviere)
Date: 2006-07-30 23:02

Message:
Logged In: YES 
user_id=945502

The two-arg type form is intended for use with classmethods,
e.g.::

>>> class C(object):
...     @classmethod
...     def f(cls):
...         print 'C.f'
...         
>>> class D(C):
...     @classmethod
...     def f(cls):
...         super(D, cls).f()
...         print 'D.f'
...         
>>> D.f()
C.f
D.f

I do make use of this occasionally, so I do think it should
be documented.

The one-arg form is intended to be used as a class attribute::

>>> class C(object):
...     def f(self):
...         print 'C.f'
... 
>>> class D(C):
...      def f(self):
...          self.super.f()
...          print 'D.f'
... 
>>> D.super = super(D)
>>> D().f()
C.f
D.f

I don't know that we should really be advertising this
one-arg form though.  It requires modifying a class outside
the definition or using some metaclass hackery to be usable.
 And it's misleading because it won't work, for example,
with classmethods:

>>> class C(object):
...     @classmethod
...     def f(cls):
...         print 'C.f'
... 
>>> class D(C):
...     @classmethod
...     def f(cls):
...         cls.super.f()
...         print 'D.f'
... 
>>> D.super = super(D)
>>> D().f()
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
  File "<interactive input>", line 4, in f
AttributeError: 'super' object has no attribute 'f'

That's why I tried to gloss over it lightly.  Personally I'd
prefer that the one-arg form was just deprecated.  It
introduces a lot more problems than it solves.

But if it has to be documented, it should probably say
something like "A super object created with a single
argument produces a descriptor object. This descriptor
object makes the superclass methods available on the object
returned by its __get__ method. The superclass methods are
only available when __get__ is called with an instance (not
a class)."


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-30 22:29

Message:
Logged In: YES 
user_id=3066

Ok, after playing around a bit with the 1-arg variation and
the 2nd-arg-is-a-type variation, I don't have a clue as to
how either would be used.

It someone can explain either of both of those, please post
an explanation here, and I'll do any LaTeX conversions needed.

I've attached what I have so far as a patch.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-30 21:58

Message:
Logged In: YES 
user_id=3066

That explanation doesn't deal with the difference between
the 1- and 2-argument signatures.  It can be cleaned up
pretty heavily.  I'll see if I can come up with a decent
comment about 1-argument calls to super().

----------------------------------------------------------------------

Comment By: Steven Bethard (bediviere)
Date: 2006-07-30 21:25

Message:
Logged In: YES 
user_id=945502

If you're talking about the following: 
"""
Note that \function{super} is implemented as part of the
binding process for explicit dotted attribute lookups such
as \samp{super(C, self).__getitem__(name)}.  Accordingly,
\function{super} is undefined for implicit lookups using
statements or operators such as \samp{super(C, self)[name]}. 
""" 
I believe it's trying to say that super works as if it only
overrode __getattr__. Hence ``sup.XXX`` works, but not
``sup[...]``, ``sup(...)``, etc.  That first sentence seems
mostly unnecessary to me.  As long as we say that the
__XXX__ methods must be spelled out explicitly, I think
we've got our bases covered.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-29 14:40

Message:
Logged In: YES 
user_id=3066

I'm not sure what the paragraph following the \end{verbatim}
means.  Can someone clarify?

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-20 10:06

Message:
Logged In: YES 
user_id=1188172

See also Bug #973579 (which I closed as duplicate) for
alternative wording.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163367&group_id=5470

From noreply at sourceforge.net  Mon Jul 31 09:01:22 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 31 Jul 2006 00:01:22 -0700
Subject: [ python-Bugs-1163367 ] correct/clarify documentation for super
Message-ID: <E1G7RmE-0006It-Dj@sc8-sf-web1.sourceforge.net>

Bugs item #1163367, was opened at 2005-03-14 18:39
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163367&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Steven Bethard (bediviere)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: correct/clarify documentation for super

Initial Comment:
The current documentation for super is confusing.  For
instance, it says that it returns "the superclass of
type" which is incorrect; it actually returns the next
type in type's MRO.  Well, to be truthful, it doesn't
even do that; it returns a proxy object which makes
that type's attributes available, but that's just
another reason to fix the documentation.

I suggest changing the wording to something like:

"""super(type[, object-or-type])

Return an object that exposes the attributes available
through the type's superclasses, without exposing the
attributes of the type itself.  Attributes will be
looked up using the normal resolution order, omitting
the first class in the MRO (that is, the type itself).

If the second argument is present, it should either be
an instance of object, in which case
isinstance(object-or-type, type) must be true, or it
should be an instance of type, in which case
issubclass(object-or-type, type) must be true.  The
typical use for this form of super is to call a
cooperative superclass method:

class C(B):
    def meth(self, arg):
        super(C, self).meth(arg)

If the second argument to super is omitted, the super
object returned will not expose any attributes
directly.  However,  attributes will be accessible
whenever the descriptor machinery is invoked, e.g.
though explicit invocation of __get__.

Note that super is undefined for implicit lookups using
statements or operators such as "super(C, self)[name]".
 These must be spelled out with their explicit lookup,
e.g. "super(C, self).__getitem__(name)". New in version
2.2. 
"""

It's not perfect and I welcome suggestions for
re-wording, but I think it's substantially more
accurate about what super actually does.  It also moves
the "second argument omitted" situation to the end,
since this is a vastly more uncommon use case.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-31 03:01

Message:
Logged In: YES 
user_id=3066

Thanks Steven; that helps a lot!

I've attached a revised version of my patch that describes
both 2-arg forms; I'll see about refining it further after
I've had a bit of sleep, and time to play with the 1-arg form.

----------------------------------------------------------------------

Comment By: Steven Bethard (bediviere)
Date: 2006-07-31 01:02

Message:
Logged In: YES 
user_id=945502

The two-arg type form is intended for use with classmethods,
e.g.::

>>> class C(object):
...     @classmethod
...     def f(cls):
...         print 'C.f'
...         
>>> class D(C):
...     @classmethod
...     def f(cls):
...         super(D, cls).f()
...         print 'D.f'
...         
>>> D.f()
C.f
D.f

I do make use of this occasionally, so I do think it should
be documented.

The one-arg form is intended to be used as a class attribute::

>>> class C(object):
...     def f(self):
...         print 'C.f'
... 
>>> class D(C):
...      def f(self):
...          self.super.f()
...          print 'D.f'
... 
>>> D.super = super(D)
>>> D().f()
C.f
D.f

I don't know that we should really be advertising this
one-arg form though.  It requires modifying a class outside
the definition or using some metaclass hackery to be usable.
 And it's misleading because it won't work, for example,
with classmethods:

>>> class C(object):
...     @classmethod
...     def f(cls):
...         print 'C.f'
... 
>>> class D(C):
...     @classmethod
...     def f(cls):
...         cls.super.f()
...         print 'D.f'
... 
>>> D.super = super(D)
>>> D().f()
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
  File "<interactive input>", line 4, in f
AttributeError: 'super' object has no attribute 'f'

That's why I tried to gloss over it lightly.  Personally I'd
prefer that the one-arg form was just deprecated.  It
introduces a lot more problems than it solves.

But if it has to be documented, it should probably say
something like "A super object created with a single
argument produces a descriptor object. This descriptor
object makes the superclass methods available on the object
returned by its __get__ method. The superclass methods are
only available when __get__ is called with an instance (not
a class)."


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-31 00:29

Message:
Logged In: YES 
user_id=3066

Ok, after playing around a bit with the 1-arg variation and
the 2nd-arg-is-a-type variation, I don't have a clue as to
how either would be used.

It someone can explain either of both of those, please post
an explanation here, and I'll do any LaTeX conversions needed.

I've attached what I have so far as a patch.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-30 23:58

Message:
Logged In: YES 
user_id=3066

That explanation doesn't deal with the difference between
the 1- and 2-argument signatures.  It can be cleaned up
pretty heavily.  I'll see if I can come up with a decent
comment about 1-argument calls to super().

----------------------------------------------------------------------

Comment By: Steven Bethard (bediviere)
Date: 2006-07-30 23:25

Message:
Logged In: YES 
user_id=945502

If you're talking about the following: 
"""
Note that \function{super} is implemented as part of the
binding process for explicit dotted attribute lookups such
as \samp{super(C, self).__getitem__(name)}.  Accordingly,
\function{super} is undefined for implicit lookups using
statements or operators such as \samp{super(C, self)[name]}. 
""" 
I believe it's trying to say that super works as if it only
overrode __getattr__. Hence ``sup.XXX`` works, but not
``sup[...]``, ``sup(...)``, etc.  That first sentence seems
mostly unnecessary to me.  As long as we say that the
__XXX__ methods must be spelled out explicitly, I think
we've got our bases covered.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-29 16:40

Message:
Logged In: YES 
user_id=3066

I'm not sure what the paragraph following the \end{verbatim}
means.  Can someone clarify?

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-20 12:06

Message:
Logged In: YES 
user_id=1188172

See also Bug #973579 (which I closed as duplicate) for
alternative wording.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163367&group_id=5470

From noreply at sourceforge.net  Mon Jul 31 12:14:07 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 31 Jul 2006 03:14:07 -0700
Subject: [ python-Bugs-1525447 ] Build fails on OS X with case sensitive fs
Message-ID: <E1G7Uml-0007kf-HM@sc8-sf-web1.sourceforge.net>

Bugs item #1525447, was opened at 2006-07-19 19:24
Message generated for change (Comment added) made by gdm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525447&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: Fixed
Priority: 6
Submitted By: gideon may (gdm)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: Build fails on OS X with case sensitive fs

Initial Comment:
When compiling python from svn on a Mac OS X with a 
case sensitive file system I get the following build
error:

running build
running build_ext
db.h: found (4, 3) in /opt/local/include/db4
db lib: using (4, 3) db-4.3
sqlite: found /usr/include/sqlite3.h
/usr/include/sqlite3.h: version 3.1.3
Traceback (most recent call last):
  File "./setup.py", line 1507, in <module>
    main()
.
.
  File "./setup.py", line 1088, in addMacExtension
    raise RuntimeError("%s not found" % name)
RuntimeError: MacOS not found
make: *** [sharedmods] Error 1




It can be fixed by either renaming the file:
  Mac/Modules/macosmodule.c 
to
  Mac/Modules/MacOSmodule.c 

or applying the following patch :
Index: setup.py
===================================================================
--- setup.py    (revision 50687)
+++ setup.py    (working copy)
@@ -1101,7 +1101,7 @@
             carbon_kwds = {'extra_compile_args':
carbon_extra_compile_args,
                            'extra_link_args':
['-framework', 'Carbon'],
                           }
-            CARBON_EXTS = ['ColorPicker', 'gestalt',
'MacOS', 'Nav',
+            CARBON_EXTS = ['ColorPicker', 'gestalt',
'macos', 'Nav',
                            'OSATerminology', 'icglue',
                            # All these are in subdirs
                            '_AE', '_AH', '_App',
'_CarbonEvt', '_Cm', '_Ctl',


Cheers,

Gideon



----------------------------------------------------------------------

>Comment By: gideon may (gdm)
Date: 2006-07-31 12:14

Message:
Logged In: YES 
user_id=117359

The rename works for me. I've been able to compile with and without
the --enable-framework configure option and both versions can import
and use MacOS correctly.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-25 21:21

Message:
Logged In: YES 
user_id=580910

I've implemented the rename I suggested earlier in revision 50832.

Could you please confirm that this does actually solve your problem?

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-23 20:11

Message:
Logged In: YES 
user_id=580910

Could you please test if renaming Mac/Modules/macosmodule.c to Mac/
Modules/MacOS.c solves your problem?  With that rename the build still works 
for me, but I don't have a case-sensitive filesystem.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-23 11:31

Message:
Logged In: YES 
user_id=580910

The patch is incorrect, as this would rename user visible name of the python 
extension ('import MacOS' would stop working). 

The rename would be correct.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525447&group_id=5470

From noreply at sourceforge.net  Mon Jul 31 12:54:57 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 31 Jul 2006 03:54:57 -0700
Subject: [ python-Bugs-1530448 ] ctypes build fails on Solaris 10
Message-ID: <E1G7VQH-0007Hd-1f@sc8-sf-web1.sourceforge.net>

Bugs item #1530448, was opened at 2006-07-28 17:04
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530448&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Thomas Heller (theller)
Summary: ctypes build fails on Solaris 10

Initial Comment:
Thomas,

I tried to build Python from cvs (svn rev 50905) on
Solaris 10 today.
Compiler was gcc 3.4.  I got a text relocation error
when linking
ctypes.so:

/opt/app/g++lib6/gcc-3.4/bin/gcc -shared
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o
-L/usr/local/lib -o
build/lib.solaris-2.10-i86pc-2.5/_ctypes.so
Text relocation remains                         referenced
    against symbol                  offset      in file
ffi_closure_SYSV_inner              0x8e       
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o
ld: fatal: relocations remain against allocatable but
non-writable sections
collect2: ld returned 1 exit status

I tried configuring both with and without the
--with-system-ffi flag.
The error was the same in both cases.

If you need more information, let me know.

Skip


----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2006-07-31 12:54

Message:
Logged In: YES 
user_id=11105

Skip, do you have *any* idea what might be wrong, or could
you even come up with a patch?

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2006-07-29 00:03

Message:
Logged In: YES 
user_id=44345

Yeah, you'd definitely need -fPIC on any brand of Solaris.  That test might be 
changed to

    plat = get_platform()
    if plat in (... buncha platforms ...) or "solaris" in plat:
        os.environ["CFLAGS"] = "-fPIC"

That doesn't seem to be what's happening in this case though.  I rm'd the .o 
files in .../Modules/_ctypes and tried again.  The compile commands *do* 
have -fPIC on them.  I don't think it's required on the link line.

S


----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2006-07-28 18:19

Message:
Logged In: YES 
user_id=11105

Skip,

This looks *somewhat* like the problems reported in bugs
1529269 and 1528620 (although they have a sparc, and you
seem to have x86 solaris).

Hm, in the standalone ctypes setup script, I find this code
snippet:

if get_platform() in ["solaris-2.9-sun4u", "linux-x86_64"]:
    os.environ["CFLAGS"] = "-fPIC"

Can it be that -fPIC must be used, but is not specified?

It is also funny that the solaris buildbot does NOT seem to
have a problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530448&group_id=5470

From noreply at sourceforge.net  Mon Jul 31 12:58:20 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 31 Jul 2006 03:58:20 -0700
Subject: [ python-Bugs-1531662 ] Build fails on MacOSX with missing symbol
Message-ID: <E1G7VTY-0004SH-Ec@sc8-sf-web3.sourceforge.net>

Bugs item #1531662, was opened at 2006-07-31 12: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=1531662&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: gideon may (gdm)
Assigned to: Nobody/Anonymous (nobody)
Summary: Build fails on MacOSX with missing symbol

Initial Comment:
When compiling the latest svn version on MacOS, the build
fails with the following error in libpython2.5.a:
ld: Undefined symbols:
_init_types
libtool: internal link edit command failed

When I add Modules/_typesmodule.c to Modules/Setup.dist
everything is hunky-dory, but am not sure if this is the correct place 
since python seems to compile ok on Linux without the addition

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531662&group_id=5470

From noreply at sourceforge.net  Mon Jul 31 13:38:02 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 31 Jul 2006 04:38:02 -0700
Subject: [ python-Bugs-1531662 ] Build fails on MacOSX with missing symbol
Message-ID: <E1G7W5y-0004Kr-17@sc8-sf-web6.sourceforge.net>

Bugs item #1531662, was opened at 2006-07-31 10:58
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531662&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
>Priority: 7
Submitted By: gideon may (gdm)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Build fails on MacOSX with missing symbol

Initial Comment:
When compiling the latest svn version on MacOS, the build
fails with the following error in libpython2.5.a:
ld: Undefined symbols:
_init_types
libtool: internal link edit command failed

When I add Modules/_typesmodule.c to Modules/Setup.dist
everything is hunky-dory, but am not sure if this is the correct place 
since python seems to compile ok on Linux without the addition

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531662&group_id=5470

From noreply at sourceforge.net  Mon Jul 31 16:11:12 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 31 Jul 2006 07:11:12 -0700
Subject: [ python-Bugs-1531775 ] HTTPSConnection request hangs
Message-ID: <E1G7YUC-0001jF-Kp@sc8-sf-web3.sourceforge.net>

Bugs item #1531775, was opened at 2006-07-31 17: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=1531775&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Noam Taich (grolich)
Assigned to: Nobody/Anonymous (nobody)
Summary: HTTPSConnection request hangs

Initial Comment:
with python 2.3 and above there is a problem with
HTTPSConnection that comes to life in the following code:

conn = HTTPSConnection(server,port)
conn.connect()
conn.request('POST', '/', data, headers)

This works fine, unless the remote host closes
unexpectedly (unexpectedly for the client. say, reboot
-fn or reset button)

sometimes (not always) when that happens, python gets
stuck on the conn.request command, it never returns or
raises an eyebrow (or an exception...) even after the
remote host is back online. 

problem only happens once every many such occurences

the remote host is running apache (which is really used
a proxy to a python http server on the same remote
machine).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531775&group_id=5470

From noreply at sourceforge.net  Mon Jul 31 18:11:36 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 31 Jul 2006 09:11:36 -0700
Subject: [ python-Bugs-1514540 ] String Methods 2.3.6.1 not in TOC
Message-ID: <E1G7aMi-0004De-TW@sc8-sf-web5.sourceforge.net>

Bugs item #1514540, was opened at 2006-06-29 14:22
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514540&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Terry J. Reedy (tjreedy)
>Assigned to: A.M. Kuchling (akuchling)
Summary: String Methods 2.3.6.1 not in TOC

Initial Comment:
Quoting from c.l.p thread Python Docs Bug:
"One long-standing irritation I have with the table 
of contents for the Python Library Reference 
<http://docs.python.org/lib/lib.html>, is that 
there is one very important section, "String Methods" 
<http://docs.python.org/lib/string-methods.html>, 
which does not appear there. That's because it is 
section 2.3.6.1, and the table of contents 
only goes to 3 levels."

I am third to agree.  To not change rule, perhaps 
this section could be lifted to third level.  It 
really is one that people need to refer back to.


----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-31 12:11

Message:
Logged In: YES 
user_id=11375

For 2.5, I've moved the standard types to be a chapter of
their own instead of a section.  This should fix the problem.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514540&group_id=5470

From noreply at sourceforge.net  Mon Jul 31 18:17:48 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 31 Jul 2006 09:17:48 -0700
Subject: [ python-Bugs-984952 ] PEP 307 pickle extensions not documented
Message-ID: <E1G7aSi-00009W-Fp@sc8-sf-web1.sourceforge.net>

Bugs item #984952, was opened at 2004-07-04 11:45
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984952&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Greg Chapman (glchapman)
>Assigned to: A.M. Kuchling (akuchling)
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.

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-31 12:17

Message:
Logged In: YES 
user_id=11375

Presumably this bug can now be closed.


----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2004-08-07 12:25

Message:
Logged In: YES 
user_id=11375

I've included a bunch of material from PEP 307 in the CVS HEAD version 
of the pickle docs. 

I haven't tried to include all the material on old-style classes using 
protocols 0,1.  The details are lengthy; someone who knows 
more about the pickle module should decide if they're important enough
to be in the docs or not.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984952&group_id=5470

From noreply at sourceforge.net  Mon Jul 31 18:22:32 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 31 Jul 2006 09:22:32 -0700
Subject: [ python-Bugs-848556 ] 4.2.6 (re) Examples: float regexp exponential
	on failure
Message-ID: <E1G7aXI-0000Gj-Jc@sc8-sf-web3.sourceforge.net>

Bugs item #848556, was opened at 2003-11-24 15:01
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=848556&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Lukasz Pankowski (lupan)
>Assigned to: A.M. Kuchling (akuchling)
Summary: 4.2.6 (re) Examples: float regexp exponential on failure

Initial Comment:
When using given regexp for floats

[-+]?(\d+(\.\d*)?|\d*\.\d+)([eE][-+]?\d+)?

'0.5' will match both alternatives on failure, which
makes exponential number of matches on failure if
matching multiple float numbers  '0.5 0.5 0.5' using
one regexp which fail at the end (attached test script).

If replaced with slightly less verbose (without '\d*'
after '|'):

[-+]?(\d+(\.\d*)?|\.\d+)([eE][-+]?\d+)?

'0.5' fails on the second branch and the exponential
effect does not occur.


----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-31 12:22

Message:
Logged In: YES 
user_id=11375

The suggested change seems reasonable, so I've applied it. 
Thanks!


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-02 02:43

Message:
Logged In: YES 
user_id=33168

Gustavo, are you still interested in re issues?  This is
actually a doc issue (I think it's only a doc issue).  Any
comments?  I can make a change if you want me to, just let
me know what to do.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=848556&group_id=5470

From noreply at sourceforge.net  Mon Jul 31 18:33:26 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 31 Jul 2006 09:33:26 -0700
Subject: [ python-Bugs-779976 ] docs missing 'trace' module
Message-ID: <E1G7ahq-0004K5-EZ@sc8-sf-web3.sourceforge.net>

Bugs item #779976, was opened at 2003-07-29 22:05
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779976&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Dalke (dalke)
Assigned to: Jeremy Hylton (jhylton)
Summary: docs missing 'trace' module

Initial Comment:
The 'trace' module is new in Python 2.3.  There is no 
mention of it in the module listing at http://www.python.org/
doc/2.3/modindex.html nor is it documented in the 
&quot;undocumented modules&quot; chapter at http://www.python.org/
doc/2.3/lib/undoc.html .

(You would think as one of the coauthors for that module 
that I could be of help, but it's been about 4 years since I 
looked at it.  :)


----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-31 12:33

Message:
Logged In: YES 
user_id=11375

I've updated the scripts/README in preparation for the 2.5b3
release.


----------------------------------------------------------------------

Comment By: Peter Hansen (phansen)
Date: 2003-12-09 14:19

Message:
Logged In: YES 
user_id=567267

A trivial related note: Tools/Scripts/README.txt still lists 
trace.py as though it were still there and not in Lib instead.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-10-16 09:17

Message:
Logged In: YES 
user_id=6656

&lt;prod&gt;

Armin and I were talking about factoring out the
co_lnotab-frobbing code and were being hampered by not
knowing what the code was trying to do...

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-09-09 17:00

Message:
Logged In: YES 
user_id=3066

Jeremy made this a module, so he's volunteered to write the
LaTeX docs.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779976&group_id=5470

From noreply at sourceforge.net  Mon Jul 31 18:53:53 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 31 Jul 2006 09:53:53 -0700
Subject: [ python-Bugs-1531862 ] subprocess.Popen(cmd, stdout=sys.stdout) fails
Message-ID: <E1G7b1d-0008BC-CT@sc8-sf-web6.sourceforge.net>

Bugs item #1531862, was opened at 2006-07-31 11: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=1531862&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: John A Meinel (jfmeinel)
Assigned to: Nobody/Anonymous (nobody)
Summary: subprocess.Popen(cmd, stdout=sys.stdout) fails

Initial Comment:
I'm currently using subprocess.Popen() to run a
command, and I allow the caller to specify where the
output should go.

One valid output is to send it to sys.stdout (fileno == 1)

The subprocess module seems to unconditionally close
stdout if a file handle is passed (even if it stdout).

Compare:
python -c "import subprocess,sys; \
  subprocess.Popen(['echo', 'hello'])"

versus
python -c "import subprocess,sys; \
  subprocess.Popen(['echo', 'hello'], stdout=sys.stdout)"

or even
python -c "import subprocess,sys; \
  subprocess.Popen(['echo', 'hello'], stdout=1)"

The first one prints 'hello' as expected.

The latter two give an error:
echo: write error: Bad file descriptor

Attached is a possible patch to subprocess.py

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531862&group_id=5470

From noreply at sourceforge.net  Mon Jul 31 18:54:10 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 31 Jul 2006 09:54:10 -0700
Subject: [ python-Bugs-1531862 ] subprocess.Popen(cmd, stdout=sys.stdout) fails
Message-ID: <E1G7b1u-0003PW-EO@sc8-sf-web2.sourceforge.net>

Bugs item #1531862, was opened at 2006-07-31 11:53
Message generated for change (Settings changed) made by jfmeinel
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531862&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: John A Meinel (jfmeinel)
>Assigned to: Gustavo Niemeyer (niemeyer)
Summary: subprocess.Popen(cmd, stdout=sys.stdout) fails

Initial Comment:
I'm currently using subprocess.Popen() to run a
command, and I allow the caller to specify where the
output should go.

One valid output is to send it to sys.stdout (fileno == 1)

The subprocess module seems to unconditionally close
stdout if a file handle is passed (even if it stdout).

Compare:
python -c "import subprocess,sys; \
  subprocess.Popen(['echo', 'hello'])"

versus
python -c "import subprocess,sys; \
  subprocess.Popen(['echo', 'hello'], stdout=sys.stdout)"

or even
python -c "import subprocess,sys; \
  subprocess.Popen(['echo', 'hello'], stdout=1)"

The first one prints 'hello' as expected.

The latter two give an error:
echo: write error: Bad file descriptor

Attached is a possible patch to subprocess.py

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531862&group_id=5470

From noreply at sourceforge.net  Mon Jul 31 19:25:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 31 Jul 2006 10:25:46 -0700
Subject: [ python-Bugs-1525447 ] Build fails on OS X with case sensitive fs
Message-ID: <E1G7bWU-0006ag-CW@sc8-sf-web2.sourceforge.net>

Bugs item #1525447, was opened at 2006-07-19 19:24
Message generated for change (Settings changed) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525447&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
>Status: Closed
Resolution: Fixed
Priority: 6
Submitted By: gideon may (gdm)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: Build fails on OS X with case sensitive fs

Initial Comment:
When compiling python from svn on a Mac OS X with a 
case sensitive file system I get the following build
error:

running build
running build_ext
db.h: found (4, 3) in /opt/local/include/db4
db lib: using (4, 3) db-4.3
sqlite: found /usr/include/sqlite3.h
/usr/include/sqlite3.h: version 3.1.3
Traceback (most recent call last):
  File "./setup.py", line 1507, in <module>
    main()
.
.
  File "./setup.py", line 1088, in addMacExtension
    raise RuntimeError("%s not found" % name)
RuntimeError: MacOS not found
make: *** [sharedmods] Error 1




It can be fixed by either renaming the file:
  Mac/Modules/macosmodule.c 
to
  Mac/Modules/MacOSmodule.c 

or applying the following patch :
Index: setup.py
===================================================================
--- setup.py    (revision 50687)
+++ setup.py    (working copy)
@@ -1101,7 +1101,7 @@
             carbon_kwds = {'extra_compile_args':
carbon_extra_compile_args,
                            'extra_link_args':
['-framework', 'Carbon'],
                           }
-            CARBON_EXTS = ['ColorPicker', 'gestalt',
'MacOS', 'Nav',
+            CARBON_EXTS = ['ColorPicker', 'gestalt',
'macos', 'Nav',
                            'OSATerminology', 'icglue',
                            # All these are in subdirs
                            '_AE', '_AH', '_App',
'_CarbonEvt', '_Cm', '_Ctl',


Cheers,

Gideon



----------------------------------------------------------------------

Comment By: gideon may (gdm)
Date: 2006-07-31 12:14

Message:
Logged In: YES 
user_id=117359

The rename works for me. I've been able to compile with and without
the --enable-framework configure option and both versions can import
and use MacOS correctly.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-25 21:21

Message:
Logged In: YES 
user_id=580910

I've implemented the rename I suggested earlier in revision 50832.

Could you please confirm that this does actually solve your problem?

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-23 20:11

Message:
Logged In: YES 
user_id=580910

Could you please test if renaming Mac/Modules/macosmodule.c to Mac/
Modules/MacOS.c solves your problem?  With that rename the build still works 
for me, but I don't have a case-sensitive filesystem.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-23 11:31

Message:
Logged In: YES 
user_id=580910

The patch is incorrect, as this would rename user visible name of the python 
extension ('import MacOS' would stop working). 

The rename would be correct.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525447&group_id=5470

From noreply at sourceforge.net  Mon Jul 31 21:43:09 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 31 Jul 2006 12:43:09 -0700
Subject: [ python-Bugs-1531662 ] Build fails on MacOSX with missing symbol
Message-ID: <E1G7dfR-0008CT-4h@sc8-sf-web1.sourceforge.net>

Bugs item #1531662, was opened at 2006-07-31 12:58
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531662&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 7
Submitted By: gideon may (gdm)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Build fails on MacOSX with missing symbol

Initial Comment:
When compiling the latest svn version on MacOS, the build
fails with the following error in libpython2.5.a:
ld: Undefined symbols:
_init_types
libtool: internal link edit command failed

When I add Modules/_typesmodule.c to Modules/Setup.dist
everything is hunky-dory, but am not sure if this is the correct place 
since python seems to compile ok on Linux without the addition

----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-31 21:43

Message:
Logged In: YES 
user_id=580910

Did you build a unix or framework install?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531662&group_id=5470

From noreply at sourceforge.net  Mon Jul 31 21:58:15 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 31 Jul 2006 12:58:15 -0700
Subject: [ python-Bugs-1531963 ] SocketServer.TCPServer returns different ports
Message-ID: <E1G7du3-0002Mj-NV@sc8-sf-web2.sourceforge.net>

Bugs item #1531963, was opened at 2006-07-31 19: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=1531963&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: hakker.de (hakker_de)
Assigned to: Nobody/Anonymous (nobody)
Summary: SocketServer.TCPServer returns different ports

Initial Comment:
Providing 0 as a port in __init__ of 
SocketServer.TCPServer leads to different values for 
port in server_address and socket.getsockname().

Example:
import SocketServer
s = SocketServer.TCPServer(("0.0.0.0", 0), Handler)
s.server_address
-> ('0.0.0.0', 0)
s.socket.getsockname()
-> ('0.0.0.0', 39129)

s.server_address should also contain 39129 as the 
port number for the free port found.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531963&group_id=5470

From noreply at sourceforge.net  Mon Jul 31 21:58:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 31 Jul 2006 12:58:46 -0700
Subject: [ python-Bugs-1531662 ] Build fails on MacOSX with missing symbol
Message-ID: <E1G7duY-0004YC-S2@sc8-sf-web1.sourceforge.net>

Bugs item #1531662, was opened at 2006-07-31 12:58
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531662&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 7
Submitted By: gideon may (gdm)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Build fails on MacOSX with missing symbol

Initial Comment:
When compiling the latest svn version on MacOS, the build
fails with the following error in libpython2.5.a:
ld: Undefined symbols:
_init_types
libtool: internal link edit command failed

When I add Modules/_typesmodule.c to Modules/Setup.dist
everything is hunky-dory, but am not sure if this is the correct place 
since python seems to compile ok on Linux without the addition

----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-31 21:58

Message:
Logged In: YES 
user_id=580910

I cannot reproduce this with the current head (svnversion says 51008). Did you 
do a clean build? Maybe some junk from a previous build caused problems.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-31 21:43

Message:
Logged In: YES 
user_id=580910

Did you build a unix or framework install?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531662&group_id=5470