From noreply at sourceforge.net  Wed Mar  1 01:08:17 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 28 Feb 2006 16:08:17 -0800
Subject: [ python-Bugs-1438537 ] modules search in help() crashes on
	insufficient file perms
Message-ID: <E1FEEt7-0005jS-SG@sc8-sf-web4-b.sourceforge.net>

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

Please note that this 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: A. Coder (hauptbeuteltier)
Assigned to: Nobody/Anonymous (nobody)
Summary: modules search in help() crashes on insufficient file perms

Initial Comment:
In the python interpreter, in the interactive online
help, typing <code>modules &lt;keyword&gt;</code>
throws a permission denied error (Errno 13) and dumps
the user back to the main interpreter if the user has
insufficient permission to read any .py file from the
site-packages directory.


Example:
~:$ ls -l /usr/lib/python2.4/site-packages/pygtk.py
-rw-r-----  1 root root 2619 2005-02-20 14:18
/usr/lib/python2.4/site-packages/pygtk.py
~:$ python
>>> help()

help> modules html

Here is a list of matching modules.  Enter any module
name to get more help.

HTMLParser - A parser for HTML and XHTML.
htmlentitydefs - HTML character entity references.
htmllib - HTML 2.0 parser.
markupbase - Shared support for scanning document type
declarations in HTML and XHTML.
pydoc - Generate Python documentation in HTML or text
for interactive use.
test.test_htmllib 
test.test_htmlparser - Tests for HTMLParser.py.
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.4/site.py", line 328, in __call__
    return pydoc.help(*args, **kwds)
  File "/usr/lib/python2.4/pydoc.py", line 1650, in
__call__
    self.interact()
  File "/usr/lib/python2.4/pydoc.py", line 1668, in
interact
    self.help(request)
  File "/usr/lib/python2.4/pydoc.py", line 1686, in help
    self.listmodules(split(request)[1])
  File "/usr/lib/python2.4/pydoc.py", line 1790, in
listmodules
    apropos(key)
  File "/usr/lib/python2.4/pydoc.py", line 1900, in apropos
    ModuleScanner().run(callback, key)
  File "/usr/lib/python2.4/pydoc.py", line 1886, in run
    desc = synopsis(path) or ''
  File "/usr/lib/python2.4/pydoc.py", line 182, in synopsis
    file = open(filename)
IOError: [Errno 13] Permission denied:
'/usr/lib/python2.4/site-packages/tageditor.py'
>>>

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

Comment By: splitscreen (splitscreen)
Date: 2006-03-01 00:08

Message:
Logged In: YES 
user_id=1126061

Patch #1440660 fixes this.

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

Comment By: Grant Olson (logistix)
Date: 2006-02-28 21:55

Message:
Logged In: YES 
user_id=699438

I personally don't have commit rights, but yes, it's
generally easiest if you post the patch to Patch manager and
put a cross reference note on the bug.  Developers usually
give working patches precidence over bugs.

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

Comment By: splitscreen (splitscreen)
Date: 2006-02-28 15:54

Message:
Logged In: YES 
user_id=1126061

Yeah, I've modified it to tell the user which file caused
the problem.

Want the patch posting to the Patch Manager?

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

Comment By: Grant Olson (logistix)
Date: 2006-02-26 23:32

Message:
Logged In: YES 
user_id=699438

That patch sounds pretty-much right, but I think it should
print some feedback to stderr instead of silently swallowing
the exception.

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

Comment By: splitscreen (splitscreen)
Date: 2006-02-25 12:34

Message:
Logged In: YES 
user_id=1126061

Could this just be silently skipped? i.e returning None if
the user does not have the corrept permissions to access a
particular file?

Just wrap the 'file = open(filename)' in pydoc.py: line 182
in a try: except block returning None if there's an error
(such as permission denied).

I have written a patch I can supply if anyone wants it and
if this is the Right Thing To Do (TM).


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

Comment By: A. Coder (hauptbeuteltier)
Date: 2006-02-25 09:44

Message:
Logged In: YES 
user_id=1420716

My apologies. The tageditor.py file had the same permissions
for my test as pygtk.py. The particular file is irrelevant
in this case, it only matters that a user has insufficient
permissions for any file in the site-packages directory.

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

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

From noreply at sourceforge.net  Wed Mar  1 05:34:49 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 28 Feb 2006 20:34:49 -0800
Subject: [ python-Bugs-518846 ] exception cannot be new-style class
Message-ID: <E1FEJ33-0005FX-Uh@sc8-sf-web2.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Type/class unification
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Magnus Heino (magnusheino)
Assigned to: Guido van Rossum (gvanrossum)
Summary: exception cannot be new-style class

Initial Comment:
[magnus at gills magnus]$ python2.2
Python 2.2 (#1, Jan 26 2002, 14:27:24)
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2
Type &quot;help&quot;, &quot;copyright&quot;, &quot;credits&quot; or &quot;license&quot; for more information.
&gt;&gt;&gt; class foo(object):
...     pass
...
&gt;&gt;&gt; raise foo()
Traceback (most recent call last):
  File &quot;&lt;stdin&gt;&quot;, line 1, in ?
TypeError: exceptions must be strings, classes, or instances, not foo
&gt;&gt;&gt;


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

>Comment By: Brett Cannon (bcannon)
Date: 2006-02-28 20:34

Message:
Logged In: YES 
user_id=357491

rev. 42711 (PEP 352 implementation) made built-in exceptions
new-style.

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

Comment By: Robey Pointer (robey1)
Date: 2004-12-17 12:46

Message:
Logged In: YES 
user_id=1179122

(I wish we could do this in email instead of cluttering up
an already-messy bug...)

Forget about throwing non-Exception-based objects: it's a
red herring.  The bug to focus on is the title: "exception
cannot be new-style class".

Bottom line:  This subclass of Exception can not be raised
in python 2.3:

class MyException (Exception, object): pass

pje's comment below from (2002-07-11 13:12) is a nice
summary of how to solve it.


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

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

Message:
Logged In: YES 
user_id=21627

This statement, as literally made, is incorrect:

>>> class X(Exception):
...   pass
...
>>> e=X()
>>> type(e)
<type 'instance'>
>>> raise e
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
__main__.X: <__main__.X instance at 0x401f2b4c>

In this example, type(e) works, and x is an object which has
Exception among its base classes. Still, I can throw x,
despite your claim that I cannot.

Even if I interpret your statement more literally (i.e. that
you are talking about objects for which type(e) is a
new-style class): Why do you think this statement explains
there is a bug?

As for why it is a new feature: it currently doesn't work,
and anybody trying it will quickly find out that it doesn't
work. The language reference says it doesn't work. The
TypeError you get says it doesn't work. So that it doesn't
work is clearly intentional; changing it will be a new feature.

Notice that it is very difficult to implement this feature,
as something needs to happen with strings and subtypes of
str. Currently, string exceptions are caught by identity. If
arbitrary objects can be used as exceptions, then strings
should also be caught by type, not by identity; this is a
backwards-incompatible change.

A clean solution would be to deprecate string exceptions in
2.5, completely ban them in 2.6, and allow arbitrary objects
to act as exceptions in 2.7. 

Please do read the entire thread of this RFE.

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

Comment By: Robey Pointer (robey1)
Date: 2004-12-15 15:39

Message:
Logged In: YES 
user_id=1179122

Let me try to rephrase the problem so that it's obvious that
this is a bug, and not a feature:

'type(e)' on an exception will not work in 2.3, and cannot
be made to work from within python code.  There's no way to
throw an exception (ie an object with Exception in its
ancestor list) that 'type(e)' will work on. :(


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

Comment By: Martin v. L??wis (loewis)
Date: 2004-12-15 13:59

Message:
Logged In: YES 
user_id=21627

Whatever the solution to this problem, it is for sure that
2.4.x won't see it, because it will be a new feature.

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

Comment By: Robey Pointer (robey1)
Date: 2004-12-15 13:08

Message:
Logged In: YES 
user_id=1179122

This caused me an hour of debugging a few nights ago.  When
using unified types, it's very confusing to find that not
only does Exception not follow new-style object semantics,
but it *can't*.  Doing the obvious hack:

class MyException (Exception, object):
    pass

does not work!  The interpreter (2.3) refuses to let you
raise a unified-type object.  And if you subclass
exclusively from Exception, type(obj) returns 'instance'
instead of the class (due to being an old-style object).

Please fix this for 2.4!


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

Comment By: Facundo Batista (facundobatista)
Date: 2004-11-24 18:05

Message:
Logged In: YES 
user_id=752496

Reproduced the bug in Py2.3. I think that this is a bug, at
least because we "encourage" users to derive exceptions from
Exception, so they should be able to not do it.

The moment we say that they "must" derive from Exception,
this can be closed (of course, this is my *very* personal
opinion, ;)

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

Comment By: Phillip J. Eby (pje)
Date: 2002-07-11 13:12

Message:
Logged In: YES 
user_id=56214

Just to make things even more interesting, the current
'raise' code *will* let you raise a new-style instance that
derives from 'tuple'...  of course, what it actually raises
is the first element of said tuple-like thing.

It seems to me that the very first thing that should be
checked is whether the first argument to 'raise' is an
instance of Exception, and if so, take its type and go from
there.  This would support both old and new-style instances
of Exception subclasses, and I believe is the recommended
approach to using 'raise'.  (I.e., raise an instance of
something that subclasses Exception.)  All the other items
like strings, tuples, etc., should be checked *after* a
check for the &quot;standard&quot; approach, yes?


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

Comment By: Walter D?rwald (doerwalter)
Date: 2002-07-11 10:07

Message:
Logged In: YES 
user_id=89016

test.py is a little script that executes various test cases.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2002-07-11 09:12

Message:
Logged In: YES 
user_id=89016

What about the following patch (diff.txt):

It allows new style objects as exceptions and makes catching
exceptions by basetype possible:
    class newint(int):
        pass
    try:
        raise newint(42)
    except int, exc:
        print exc

With this patch subinstances of str become raisable and will
be caught be type not identity. This could be changed to
explicitely forbid str subinstances.

And
  raise type(None), None
becomes ambiguous: It is interpreted as
  raise type(None)
i.e. it raises the type(None) object as an exception, not
the object None (which is of type type(None))

As soon as Exception is a new style class we could limit the
allowed objects to (sub)instances of Exception.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-05 16:07

Message:
Logged In: YES 
user_id=6380

Sorry, HEAPTYPE is not the proper way to check for a
new-style class; it would exclude any new-style classes
defined by C code.  I also think that if you want to do this
it should done properly, and allow &quot;raise C, C()&quot; as well.

At best there's agreement that it's not worth trying to fix
Python to allow new-style classes as exceptions when we're
also trying to encourage that exceptions derive from
Exception.

If your module declares its exceptions as deriving from
Exception, a __metaclass__ = type should not have any effect
on the exceptions you declare.  So I'm not sure what your
problem is?

Here's another idea for a patch: a new-style class is
allowed as long as it also inherits from Exception.  (This
is possible!)

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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-04-05 15:49

Message:
Logged In: YES 
user_id=31392

I don't realize there was agreement on this.  (I didn't 
follow the discussion closely.)  I don't understand why 
exceptions need to pass an isinstance() test on Exception.  
It didn't used to be this way, and it makes it hard to 
convert a module using __metaclass__ = type.


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

Comment By: Martin v. L??wis (loewis)
Date: 2002-04-05 15:44

Message:
Logged In: YES 
user_id=21627

I thought the agreement was that this is not a bug: You
cannot really expect exceptions to work unless you inherit
from Exception.

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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-04-05 15:38

Message:
Logged In: YES 
user_id=31392

Martin, I think the attached patch is sufficient.  It checks
object type's for Py_TPFLAGS_HEAPTYPE.  I believe this is
the current way to spell &quot;new-style class&quot; although the
spelling is odd if that's the meaning &lt;0.2 wink&gt;.

If this patch makes sense to you, I'll flesh it out with
some test cases and check it in.


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

Comment By: Martin v. L??wis (loewis)
Date: 2002-02-17 15:44

Message:
Logged In: YES 
user_id=21627

Interesting. I think we need to deprecate, then remove
string exception before allowing arbitrary objects as
exceptions. Or we could allow strings to be caught either by
__builtin__.str, or by an identical string.

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

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

From noreply at sourceforge.net  Wed Mar  1 05:35:18 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 28 Feb 2006 20:35:18 -0800
Subject: [ python-Bugs-1012952 ] Standard exceptions are hostile to Unicode
Message-ID: <E1FEJ3W-00067S-0w@sc8-sf-web3.sourceforge.net>

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

Please note that this 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: Fixed
Priority: 5
Submitted By: Marius Gedminas (mgedmin)
Assigned to: Nobody/Anonymous (nobody)
Summary: Standard exceptions are hostile to Unicode

Initial Comment:
>>> e = ValueError(u"\u2639")
>>> str(e)
  ...
UnicodeEncodeError: 'ascii' codec can't encode
character u'\u2639' in position 0: ordinal not in
range(128)
>>> unicode(e)
  ...
UnicodeEncodeError: 'ascii' codec can't encode
character u'\u2639' in position 0: ordinal not in
range(128)

Please add a __unicode__ method to Exception.  I
suggest the following semantics:

class UnicodeAwareException(Exception):

    def __unicode__(self):
        return u" ".join(map(unicode, self.args))


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

>Comment By: Brett Cannon (bcannon)
Date: 2006-02-28 20:35

Message:
Logged In: YES 
user_id=357491

Rev. 42711 (PEP 352) adds a proper __unicode__ to the
built-in exceptions.

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

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

From noreply at sourceforge.net  Wed Mar  1 10:04:35 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 01 Mar 2006 01:04:35 -0800
Subject: [ python-Bugs-1440831 ] UnicodeWriter: "utf-8" hardcoded instead of
	self.encoding
Message-ID: <E1FENG7-0005tG-GG@sc8-sf-web6.sourceforge.net>

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

Please note that this 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: Rodrigo Daunoravicius (rodelrod)
Assigned to: Nobody/Anonymous (nobody)
Summary: UnicodeWriter: "utf-8" hardcoded instead of self.encoding

Initial Comment:
In the Python Library Reference, 12.20.5 Examples.
In the UnicodeReader/UnicodeWriter example.

class UnicodeWriter:
...
|    def writerow(self, row):
|    |    self.writer.writerow([s.encode("utf-8") for s
in row])

should be:

class UnicodeWriter:
...
|    def writerow(self, row):
|    |    self.writer.writerow([s.encode(self.encoding)
for s in row])

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

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

From noreply at sourceforge.net  Wed Mar  1 17:49:40 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 01 Mar 2006 08:49:40 -0800
Subject: [ python-Bugs-1441072 ] No simple example for pickle
Message-ID: <E1FEUWC-000212-Sb@sc8-sf-web6.sourceforge.net>

Bugs item #1441072, was opened at 2006-03-01 16:49
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=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: Python 2.4
Status: Open
Resolution: None
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

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

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

From noreply at sourceforge.net  Wed Mar  1 21:19:39 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 01 Mar 2006 12:19:39 -0800
Subject: [ python-Bugs-1441264 ] set update method description is incorrect
Message-ID: <E1FEXnP-0006V8-RV@sc8-sf-web3.sourceforge.net>

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

Please note that this 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: Richard King (rickbking)
Assigned to: Nobody/Anonymous (nobody)
Summary: set update method description is incorrect

Initial Comment:
Update is described as returning the set with the new 
members, but it only updates the set and returns None.

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

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

From noreply at sourceforge.net  Thu Mar  2 01:39:13 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 01 Mar 2006 16:39:13 -0800
Subject: [ python-Bugs-1323369 ] getwindowsversion() constants in sys module
Message-ID: <E1FEbqb-0004MR-TX@sc8-sf-web4-b.sourceforge.net>

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

Please note that this 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: Tony Meyer (anadelonbrin)
Assigned to: Nobody/Anonymous (nobody)
Summary: getwindowsversion() constants in sys module

Initial Comment:
In the documentation for the sys.getwindowsversion()
function, it says that the 'platform' value may be one
of four constants (specifying them by name).

However, these constants are not in the sys module
(they are in win32con from pywin32).

It would be better if either the documentation said
that the constants were available in win32con if
pywin32 is installed, or if the constants were added to
the sys module.

I personally think the latter is better since it's a
single line of code, and makes the getwindowsversion()
function more useful, but I'm not sure whether people
will want to clutter the sys module with four constants.

I'm happy to provide a patch for either behaviour, if
an appropriate developer will choose one.

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

>Comment By: Tony Meyer (anadelonbrin)
Date: 2006-03-02 13:39

Message:
Logged In: YES 
user_id=552329

This is certainly an improvement, but IMO it would be good
to also explain that these constants are in win32con (if
they aren't to be provided in the core).  It's better to
have code that refers to win32con than have everyone
defining these constants themselves.

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

Comment By: Georg Brandl (gbrandl)
Date: 2006-02-21 01:15

Message:
Logged In: YES 
user_id=849994

I added the numeric values to the docs in rev. 42516, 42517.

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

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

From noreply at sourceforge.net  Thu Mar  2 01:52:49 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 01 Mar 2006 16:52:49 -0800
Subject: [ python-Bugs-1441397 ] compiler module loses docstrings
Message-ID: <E1FEc3l-0005ja-BP@sc8-sf-web2.sourceforge.net>

Bugs item #1441397, was opened at 2006-03-02 00: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=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: None
Group: None
Status: Open
Resolution: None
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.

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

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

From noreply at sourceforge.net  Thu Mar  2 02:20:13 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 01 Mar 2006 17:20:13 -0800
Subject: [ python-Bugs-1441408 ] svn head compiler fails to spot extended
	slicing
Message-ID: <E1FEcUH-0008Se-JA@sc8-sf-web6.sourceforge.net>

Bugs item #1441408, was opened at 2006-03-02 01: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=1441408&group_id=5470

Please note that this 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: Michael Hudson (mwh)
Assigned to: Nobody/Anonymous (nobody)
Summary: svn head compiler fails to spot extended slicing

Initial Comment:
This is Python SVN HEAD:

>>> dis.dis(compile("x[::]", '', 'single'))
  1           0 LOAD_NAME                0 (x)
              3 SLICE+0             
              4 PRINT_EXPR          
              5 LOAD_CONST               0 (None)
              8 RETURN_VALUE        

This is Python 2.4:

>>> dis.dis(compile("x[::]", '', 'single'))
  1           0 LOAD_NAME                0 (x)
              3 LOAD_CONST               0 (None)
              6 LOAD_CONST               0 (None)
              9 LOAD_CONST               0 (None)
             12 BUILD_SLICE              3
             15 BINARY_SUBSCR       
             16 PRINT_EXPR          
             17 LOAD_CONST               0 (None)
             20 RETURN_VALUE        


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

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

From noreply at sourceforge.net  Thu Mar  2 02:26:14 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 01 Mar 2006 17:26:14 -0800
Subject: [ python-Bugs-1441408 ] svn head compiler fails to spot extended
	slicing
Message-ID: <E1FEca6-0004s1-9p@sc8-sf-web1.sourceforge.net>

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

Please note that this 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: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Nobody/Anonymous (nobody)
Summary: svn head compiler fails to spot extended slicing

Initial Comment:
This is Python SVN HEAD:

>>> dis.dis(compile("x[::]", '', 'single'))
  1           0 LOAD_NAME                0 (x)
              3 SLICE+0             
              4 PRINT_EXPR          
              5 LOAD_CONST               0 (None)
              8 RETURN_VALUE        

This is Python 2.4:

>>> dis.dis(compile("x[::]", '', 'single'))
  1           0 LOAD_NAME                0 (x)
              3 LOAD_CONST               0 (None)
              6 LOAD_CONST               0 (None)
              9 LOAD_CONST               0 (None)
             12 BUILD_SLICE              3
             15 BINARY_SUBSCR       
             16 PRINT_EXPR          
             17 LOAD_CONST               0 (None)
             20 RETURN_VALUE        


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

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

From noreply at sourceforge.net  Thu Mar  2 02:26:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 01 Mar 2006 17:26:05 -0800
Subject: [ python-Bugs-1441397 ] compiler module loses docstrings
Message-ID: <E1FEcZx-0007Bn-Pl@sc8-sf-web4-b.sourceforge.net>

Bugs item #1441397, was opened at 2006-03-02 00:52
Message generated for change (Settings changed) made by mwh
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: Open
Resolution: None
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.

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

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

From noreply at sourceforge.net  Thu Mar  2 07:39:21 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 01 Mar 2006 22:39:21 -0800
Subject: [ python-Bugs-1441486 ] yet another svn head compiler change
Message-ID: <E1FEhT7-000744-DL@sc8-sf-web1.sourceforge.net>

Bugs item #1441486, was opened at 2006-03-02 06: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=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: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Nobody/Anonymous (nobody)
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


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

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

From noreply at sourceforge.net  Thu Mar  2 09:28:00 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 02 Mar 2006 00:28:00 -0800
Subject: [ python-Bugs-1441530 ] socket read() can cause MemoryError in Windows
Message-ID: <E1FEjAG-0000AU-2O@sc8-sf-web3.sourceforge.net>

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

Please note that this message 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: taukki (taukki)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket read() can cause MemoryError in Windows

Initial Comment:
When a big mail (>10MB) is fetched MemoryError may
result (reproduced in Windows XP/2003, Python 2.41):

Traceback (most recent call last):
  File "t5.py", line 9, in ?
    data = f.read(26872159)
  File "c:\python24\lib\socket.py", line 307, in read
    data = self._sock.recv(recv_size)
MemoryError

The problem is not actually in imaplib (though it
requests the whole mail in one read), but probably in
combination of socket core code and the implementation
of read() function (he way it buffers the received data
in a list?). I can easily reproduce the problem e.g
with these snippets:

------------CLIENT----------------->
import socket
import time

s = socket.socket()

s.connect(("127.0.0.1", 8037))
f = s.makefile("r", 200000)
while 1:
  data = f.read(26872159) # Using smaller value here  
helps, 100000 seems to work forever...
  #data = s.recv(26872159) # THIS WORKS OK
  print len(data)

---------SERVER--------------------->
import SocketServer
import time

PORT = 8037
time.sleep(0.2)

s = "X" * 1823
class
TimeRequestHandler(SocketServer.StreamRequestHandler):
    def handle(self):
      for x in range(200000):
        self.wfile.write(s)
        print x


server = SocketServer.TCPServer(("", PORT),
TimeRequestHandler)
print "listening on port", PORT
server.serve_forever()





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

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

From noreply at sourceforge.net  Thu Mar  2 17:44:09 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 02 Mar 2006 08:44:09 -0800
Subject: [ python-Bugs-1441864 ] Omission in docs for urllib2.urlopen()
Message-ID: <E1FEquP-0007JA-W3@sc8-sf-web3.sourceforge.net>

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

Please note that this 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: Kent Johnson (kjohnson)
Assigned to: Nobody/Anonymous (nobody)
Summary: Omission in docs for urllib2.urlopen()

Initial Comment:
The docs for urllib2.urlopen() don't explicitly say
that if the data parameter is provided then it will do
a POST. I suggest replacing the second paragraph
(beginning with "data should be a string") with this text:

In HTTP requests, the optional data argument may be
given to specify a POST request (normally the request
type is GET). The data argument must be in standard
application/x-www-form-urlencoded format, for example
one returned from urllib.urlencode().


Kent

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

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

From noreply at sourceforge.net  Thu Mar  2 18:17:54 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 02 Mar 2006 09:17:54 -0800
Subject: [ python-Bugs-1441884 ] A (treaded) Python crash only on dual core
	machines
Message-ID: <E1FErR4-000660-Lt@sc8-sf-web1.sourceforge.net>

Bugs item #1441884, was opened at 2006-03-02 18: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=1441884&group_id=5470

Please note that this 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.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Robert Kiendl (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: A (treaded) Python crash only on dual core machines

Initial Comment:
There is a strange freeze/crash only on dual core machines:

I have a python app (Python 2.3.5 /Pythonwin build 203
/ Windows) running with no stability problems on normal
machines (Or a crash is so rare, that absolutely nobody
obverses it, though the overall majority of users uses
single core machines). Threads, network &
pythonwin/win32ui all in use.

Yet, from 3 users, _all_ using a Dual Processor System
(XEON, amd x2 3800+) computer, I have reports, that the
application freezes hard and/or crashes with a kind of
random stack dump (operating system). I cannot
experiment with those machines.

I found no hints other than:

http://groups.google.de/group/comp.lang.python/browse_frm/thread/64ca033e1a7f6c61/719b147e870bd5e6

http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=480325

.. both discussions remaining in uncertainty.

Are there (known) problems with Python/Pythonwin
specifically for dual core's  (py2.3.5 / pywin203) ?

What could I do to find the problem?

Robert


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

PS: there is very little C extension-code (SWIG)
involved, yet I looked over that so often, I guess its
save:


//

#include "stdafx.h"
#include "commctrl.h"
#include "ext.h"

BOOL APIENTRY DllMain( HANDLE hModule,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved
                     )
{
    return TRUE;
}

class CAllowThreads {
public:
    PyThreadState *_save; \
    CAllowThreads() {
            _save = PyEval_SaveThread();
    }
    ~CAllowThreads() {
        PyEval_RestoreThread(_save);
    }
};

PyObject* PyListView_GetSubItemRect(
    HWND hwndLV,
    int iItem,
    int iSubItem,
    int code
//    LPRECT lpRect
)
{
    RECT r;
    {
      CAllowThreads _t;
      ListView_GetSubItemRect(
        hwndLV,
        iItem,
        iSubItem,
        code,
        &r );
    }
    return Py_BuildValue("iiii",
r.left,r.top,r.right,r.bottom);

}

int GetStringAddr(const char* s) {
    return (int)s;
}

int PlaySoundResource(int resid, HMODULE hmod)
{
    CAllowThreads _t;
    return PlaySound(MAKEINTRESOURCE(resid), hmod,
SND_RESOURCE);
}

int PlaySoundFile(const char* fname, int flag)
{
    CAllowThreads _t;
    return PlaySound(fname, NULL, flag);
}

PyObject* py_ToolTipRelayMsg(  PyObject* self,
PyObject* args )
{
    MSG msg;
    HWND hwTT;
   
if(!PyArg_ParseTuple(args,"i(iiiii(ii)):ToolTipRelayMsg",
                         &hwTT,

&msg.hwnd,&msg.message,&msg.wParam,&msg.lParam,&msg.time,
                         &msg.pt, ((int*)&msg.pt)+1) )
        return NULL;

    
    {
      CAllowThreads _t;
      SendMessage(hwTT,TTM_RELAYEVENT,0,(LPARAM)&msg);
    }

    Py_INCREF( Py_None );
    return Py_None;
}

---

"GetStringAddress" is used only once like this (leades
to correct NUL termination I think):

self.sb.SendMessage(commctrl.SB_SETTEXT,iPane,extension.GetStringAddr(text))

--- swig:
static PyObject *_wrap_GetStringAddr(PyObject *self,
PyObject *args) {
    PyObject *resultobj;
    char *arg0 ;
    int result ;

    if(!PyArg_ParseTuple(args,(char
*)"s:GetStringAddr",&arg0)) return NULL;
    result = (int )GetStringAddr((char const *)arg0);
    resultobj = PyInt_FromLong((long)result);
    return resultobj;
} 

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

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

From noreply at sourceforge.net  Thu Mar  2 20:29:45 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 02 Mar 2006 11:29:45 -0800
Subject: [ python-Bugs-1441984 ] Multiple simultaneous sendtos on AF_UNIX
	socket broken.
Message-ID: <E1FEtUf-0007cP-7u@sc8-sf-web4-b.sourceforge.net>

Bugs item #1441984, was opened at 2006-03-02 19: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=1441984&group_id=5470

Please note that this message 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: Brian Brunswick (bdbrunswick)
Assigned to: Nobody/Anonymous (nobody)
Summary: Multiple simultaneous sendtos on AF_UNIX socket broken.

Initial Comment:
Using the same AF_UNIX socket to do multiple
simultaneous calls to sendto from different threads,
the messages get their to address mixed up.

This is because of the use of a static per-socket
buffer s->sock_addr in Modules/socketmodule.c function
getsockaddrarg. It needs to be per thread.


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

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

From noreply at sourceforge.net  Thu Mar  2 21:04:35 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 02 Mar 2006 12:04:35 -0800
Subject: [ python-Bugs-1442012 ] Traceback in pydoc
Message-ID: <E1FEu2N-0000k1-Sd@sc8-sf-web5.sourceforge.net>

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

Please note that this 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: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
Summary: Traceback in pydoc

Initial Comment:
On some objects I have, calling 'help(obj)' raises an
exception.  Python 2.4.2, Windows XP.

This is the traceback, together with some info from
pdb.pm():

>>> help(r)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\Python24\lib\site.py", line 328, in __call__
    return pydoc.help(*args, **kwds)
  File "c:\python24\lib\pydoc.py", line 1647, in __call__
    self.help(request)
  File "c:\python24\lib\pydoc.py", line 1691, in help
    else: doc(request, 'Help on %s:')
  File "c:\python24\lib\pydoc.py", line 1475, in doc
    pager(title % desc + '\n\n' + text.document(object,
name))
  File "c:\python24\lib\pydoc.py", line 296, in document
    if inspect.isclass(object): return self.docclass(*args)
  File "c:\python24\lib\pydoc.py", line 1193, in docclass
    lambda t: t[1] == 'method')
  File "c:\python24\lib\pydoc.py", line 1143, in spill
    name, mod, object))
  File "c:\python24\lib\pydoc.py", line 301, in document
    return self.docother(*args)
  File "c:\python24\lib\pydoc.py", line 1290, in docother
    chop = maxlen - len(line)
TypeError: unsupported operand type(s) for -:
'_compointer_meta' and 'int'
>>> import pdb
>>> pdb.pm()
> c:\python24\lib\pydoc.py(1290)docother()
-> chop = maxlen - len(line)
(Pdb) args
self = <pydoc.TextDoc instance at 0x00CC0DA0>
object = <comtypes.named_property object at 0x00CA9390>
name = Item
mod = None
maxlen = <class 'comtypes.POINTER(IROIList)'>
doc = None
(Pdb) where
  <stdin>(1)?()
  c:\python24\lib\site.py(328)__call__()
-> return pydoc.help(*args, **kwds)
  c:\python24\lib\pydoc.py(1647)__call__()
-> self.help(request)
  c:\python24\lib\pydoc.py(1691)help()
-> else: doc(request, 'Help on %s:')
  c:\python24\lib\pydoc.py(1477)doc()
-> print value
  c:\python24\lib\pydoc.py(299)document()
-> pass
  c:\python24\lib\pydoc.py(1193)docclass()
-> lambda t: t[1] == 'method')
  c:\python24\lib\pydoc.py(1143)spill()
-> name, mod, object))
  c:\python24\lib\pydoc.py(301)document()
-> return self.docother(*args)
> c:\python24\lib\pydoc.py(1290)docother()
-> chop = maxlen - len(line)
(Pdb)


The problem seems to be that the TextDoc.docother
method is called with unexpected arguments.

The signature is 
docother(object, name, mod, maxlen, doc)

but it is called with the object to document as the
'maxlen' parameter.

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

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

From noreply at sourceforge.net  Fri Mar  3 15:45:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 03 Mar 2006 06:45:24 -0800
Subject: [ python-Bugs-1442493 ] IDLE shell window gets very slow when
	displaying long lines
Message-ID: <E1FFBX2-0001bd-UQ@sc8-sf-web5.sourceforge.net>

Bugs item #1442493, was opened at 2006-03-03 14: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=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.


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

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

From noreply at sourceforge.net  Fri Mar  3 18:44:47 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 03 Mar 2006 09:44:47 -0800
Subject: [ python-Bugs-1437785 ] Problems w/ expat 1.95.7 vs. Python 2.4
Message-ID: <E1FFEKd-0004FD-Sm@sc8-sf-web5.sourceforge.net>

Bugs item #1437785, was opened at 2006-02-24 00:59
Message generated for change (Comment added) made by loewis
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: Open
Resolution: None
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: Martin v. L??wis (loewis)
Date: 2006-03-03 18: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  Fri Mar  3 18:48:55 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 03 Mar 2006 09:48:55 -0800
Subject: [ python-Bugs-1432525 ] os.listdir doesn't release GIL
Message-ID: <E1FFEOd-0005he-0Y@sc8-sf-web2.sourceforge.net>

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

Please note that this 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: Jonathan Ellis (ellisj)
>Assigned to: Georg Brandl (gbrandl)
Summary: os.listdir doesn't release GIL

Initial Comment:
posix_listdir in posixmodule.c does not release the
global interpreter lock, blocking all other threads for
the duration of the call.

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

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

Message:
Logged In: YES 
user_id=21627

The patch looks fine. Please apply.

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

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-18 12:13

Message:
Logged In: YES 
user_id=1188172

Attaching a patch. Please check.

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

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

From noreply at sourceforge.net  Fri Mar  3 18:50:43 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 03 Mar 2006 09:50:43 -0800
Subject: [ python-Bugs-1421664 ] [win32] stderr atty encoding not set
Message-ID: <E1FFEQN-0003q4-Ug@sc8-sf-web1.sourceforge.net>

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

Please note that this message 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: 6
Submitted By: Snaury (snaury)
>Assigned to: Martin v. L??wis (loewis)
Summary: [win32] stderr atty encoding not set

Initial Comment:
When starting python console application under windows,
output of unicode strings to console fails because of
ansi encoding. I found that in file
Python-2.4.2/Python/sysmodule, _PySys_Init functions,
setting encoding on stderr was forgotten:

#ifdef MS_WINDOWS
	if(isatty(_fileno(stdin))){
		sprintf(buf, "cp%d", GetConsoleCP());
		if (!PyFile_SetEncoding(sysin, buf))
			return NULL;
	}
	if(isatty(_fileno(stdout))) {
		sprintf(buf, "cp%d", GetConsoleOutputCP());
		if (!PyFile_SetEncoding(sysout, buf))
			return NULL;
	}
#endif

I think the following lines should be added:

	if(isatty(_fileno(stderr))) {
		sprintf(buf, "cp%d", GetConsoleOutputCP());
		if (!PyFile_SetEncoding(syserr, buf))
			return NULL;
	}

Otherwise it's inconsistant, as if we set it to sysout,
why not on syserr? And, for example, this code will not
work properly:

    #!/usr/bin/env python
    # -*- encoding: mbcs -*-
    import sys
    reload(sys) # bring setdefaultencoding back!
    sys.setdefaultencoding("mbcs")
    sys.stderr.write(u"<native text>\n")

Instead of native text garbage will be printed (if you
change it to sys.stdout, proper text displayed), and
there is no way I know to properly determine and set
encoding just for stderr (file.encoding is read-only,
after all).

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

Comment By: Snaury (snaury)
Date: 2006-02-01 18:29

Message:
Logged In: YES 
user_id=1197042

Ooops, sorry, in the example it should be:

print >>sys.stderr, u"<native text>"

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

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

From noreply at sourceforge.net  Fri Mar  3 18:40:56 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 03 Mar 2006 09:40:56 -0800
Subject: [ python-Bugs-1441884 ] A (treaded) Python crash only on dual core
	machines
Message-ID: <E1FFEGu-0006kj-7w@sc8-sf-web3.sourceforge.net>

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

Please note that this 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.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Robert Kiendl (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: A (treaded) Python crash only on dual core machines

Initial Comment:
There is a strange freeze/crash only on dual core machines:

I have a python app (Python 2.3.5 /Pythonwin build 203
/ Windows) running with no stability problems on normal
machines (Or a crash is so rare, that absolutely nobody
obverses it, though the overall majority of users uses
single core machines). Threads, network &
pythonwin/win32ui all in use.

Yet, from 3 users, _all_ using a Dual Processor System
(XEON, amd x2 3800+) computer, I have reports, that the
application freezes hard and/or crashes with a kind of
random stack dump (operating system). I cannot
experiment with those machines.

I found no hints other than:

http://groups.google.de/group/comp.lang.python/browse_frm/thread/64ca033e1a7f6c61/719b147e870bd5e6

http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=480325

.. both discussions remaining in uncertainty.

Are there (known) problems with Python/Pythonwin
specifically for dual core's  (py2.3.5 / pywin203) ?

What could I do to find the problem?

Robert


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

PS: there is very little C extension-code (SWIG)
involved, yet I looked over that so often, I guess its
save:


//

#include "stdafx.h"
#include "commctrl.h"
#include "ext.h"

BOOL APIENTRY DllMain( HANDLE hModule,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved
                     )
{
    return TRUE;
}

class CAllowThreads {
public:
    PyThreadState *_save; \
    CAllowThreads() {
            _save = PyEval_SaveThread();
    }
    ~CAllowThreads() {
        PyEval_RestoreThread(_save);
    }
};

PyObject* PyListView_GetSubItemRect(
    HWND hwndLV,
    int iItem,
    int iSubItem,
    int code
//    LPRECT lpRect
)
{
    RECT r;
    {
      CAllowThreads _t;
      ListView_GetSubItemRect(
        hwndLV,
        iItem,
        iSubItem,
        code,
        &r );
    }
    return Py_BuildValue("iiii",
r.left,r.top,r.right,r.bottom);

}

int GetStringAddr(const char* s) {
    return (int)s;
}

int PlaySoundResource(int resid, HMODULE hmod)
{
    CAllowThreads _t;
    return PlaySound(MAKEINTRESOURCE(resid), hmod,
SND_RESOURCE);
}

int PlaySoundFile(const char* fname, int flag)
{
    CAllowThreads _t;
    return PlaySound(fname, NULL, flag);
}

PyObject* py_ToolTipRelayMsg(  PyObject* self,
PyObject* args )
{
    MSG msg;
    HWND hwTT;
   
if(!PyArg_ParseTuple(args,"i(iiiii(ii)):ToolTipRelayMsg",
                         &hwTT,

&msg.hwnd,&msg.message,&msg.wParam,&msg.lParam,&msg.time,
                         &msg.pt, ((int*)&msg.pt)+1) )
        return NULL;

    
    {
      CAllowThreads _t;
      SendMessage(hwTT,TTM_RELAYEVENT,0,(LPARAM)&msg);
    }

    Py_INCREF( Py_None );
    return Py_None;
}

---

"GetStringAddress" is used only once like this (leades
to correct NUL termination I think):

self.sb.SendMessage(commctrl.SB_SETTEXT,iPane,extension.GetStringAddr(text))

--- swig:
static PyObject *_wrap_GetStringAddr(PyObject *self,
PyObject *args) {
    PyObject *resultobj;
    char *arg0 ;
    int result ;

    if(!PyArg_ParseTuple(args,(char
*)"s:GetStringAddr",&arg0)) return NULL;
    result = (int )GetStringAddr((char const *)arg0);
    resultobj = PyInt_FromLong((long)result);
    return resultobj;
} 

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

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

Message:
Logged In: YES 
user_id=21627

You don't provide complete source code for anybody to try to reproduce this 
problem. My guess is that you are calling into the Python runtime without 
holding the global interpreter lock. This can easily create all sorts of problems.

Never release the GIL unless you are absolutely certain that no Python code will 
be executed; neither directly nor indirectly. Don't invoke Python API in a thread 
(e.g. while processing a Windows message) without acquiring the GIL first.

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

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

From noreply at sourceforge.net  Fri Mar  3 21:15:57 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 03 Mar 2006 12:15:57 -0800
Subject: [ python-Bugs-1437785 ] Problems w/ expat 1.95.7 vs. Python 2.4
Message-ID: <E1FFGgv-0006GX-3J@sc8-sf-web2.sourceforge.net>

Bugs item #1437785, was opened at 2006-02-23 17:59
Message generated for change (Comment added) made by montanaro
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: Open
Resolution: None
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: Skip Montanaro (montanaro)
Date: 2006-03-03 14: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 11: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  Fri Mar  3 23:42:44 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 03 Mar 2006 14:42:44 -0800
Subject: [ python-Bugs-1442767 ] docs for os.statvfs miss f_bsize parameter
Message-ID: <E1FFIyy-0008NI-Nn@sc8-sf-web3.sourceforge.net>

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

Please note that this 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: Chris Cogdon (chriscog)
Assigned to: Nobody/Anonymous (nobody)
Summary: docs for os.statvfs miss f_bsize parameter

Initial Comment:
The documentation for os.statvfs miss the f_bsize
parameter.

On (for example) os-file-dir.html, it lists the
parameters as follows:

f_frsize, f_blocks, f_bfree, f_bavail ... (and so on).

it SHOULD be:

f_bsize, f_frsize, f_blocks, f_bfree, f_bavail ...

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

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

From noreply at sourceforge.net  Sat Mar  4 00:13:34 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 03 Mar 2006 15:13:34 -0800
Subject: [ python-Bugs-1442767 ] docs for os.statvfs miss f_bsize parameter
Message-ID: <E1FFJSo-0007Yq-I6@sc8-sf-web5.sourceforge.net>

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

Please note that this 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: Chris Cogdon (chriscog)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: docs for os.statvfs miss f_bsize parameter

Initial Comment:
The documentation for os.statvfs miss the f_bsize
parameter.

On (for example) os-file-dir.html, it lists the
parameters as follows:

f_frsize, f_blocks, f_bfree, f_bavail ... (and so on).

it SHOULD be:

f_bsize, f_frsize, f_blocks, f_bfree, f_bavail ...

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-03 15:13

Message:
Logged In: YES 
user_id=33168

Thanks!  Fixed.

Committed revision 42820.
Committed revision 42821.


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

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

From noreply at sourceforge.net  Sat Mar  4 04:15:19 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 03 Mar 2006 19:15:19 -0800
Subject: [ python-Bugs-1442874 ] handling comments with markupbase and
	HTMLParser
Message-ID: <E1FFNEl-0004bk-8k@sc8-sf-web1.sourceforge.net>

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

Please note that this message 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: Daniel (danielx_)
Assigned to: Nobody/Anonymous (nobody)
Summary: handling comments with markupbase and HTMLParser

Initial Comment:
If the following webpage is correct about the
definition of a comment, HTMLParser.HTMLParser reports
valid (albiet strange) comments as being erroenous:

http://www.htmlhelp.com/reference/wilbur/misc/comment.html

This site gives '<!>' as an example of a valid html
comment. See attachment for what happens at the
console. A similar thing happens with other
(pathalogical) form of comments.

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

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

From noreply at sourceforge.net  Sat Mar  4 04:17:04 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 03 Mar 2006 19:17:04 -0800
Subject: [ python-Bugs-1442874 ] handling comments with markupbase and
	HTMLParser
Message-ID: <E1FFNGS-0004iJ-0u@sc8-sf-web1.sourceforge.net>

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

Please note that this message 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: 3
Submitted By: Daniel (danielx_)
Assigned to: Nobody/Anonymous (nobody)
Summary: handling comments with markupbase and HTMLParser

Initial Comment:
If the following webpage is correct about the
definition of a comment, HTMLParser.HTMLParser reports
valid (albiet strange) comments as being erroenous:

http://www.htmlhelp.com/reference/wilbur/misc/comment.html

This site gives '<!>' as an example of a valid html
comment. See attachment for what happens at the
console. A similar thing happens with other
(pathalogical) form of comments.

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

>Comment By: Daniel (danielx_)
Date: 2006-03-03 19:17

Message:
Logged In: YES 
user_id=1383230

Sorry, I'm unfamiliar with the bug reporting system and my
attachment doesn't seem to have attached.

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

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

From noreply at sourceforge.net  Sat Mar  4 04:23:01 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 3 Mar 2006 19:23:01 -0800
Subject: [ python-Feature Requests-1423082 ] lib-deprecated
Message-ID: <200603040323.k243N1nb030958@sc8-sf-db2-new-b.sourceforge.net>

Feature Requests item #1423082, was opened at 02/02/06 16:20
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1423082&group_id=5470

Please note that this message 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: None
Priority: 5
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: lib-deprecated

Initial Comment:
obsolete modules are moved to lib-old.

deprecated modules remain in the library.

This makes the search for a relevant library more 
difficult. People browsing the code may not realize 
that they are deprecated.  (Example, I found no notice 
of deprecation within the code for rfc822.)  Even when 
the notice is there, the modules add to the number of 
alternatives, which hurts One-Obvious-Way-To-Do-It.

If these modules were moved to a deprecated directory, 
these problems would be greatly reduced.  (Ensure 
backwards compatibility by leaving the deprecated 
directory on the search path.) 

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

>Comment By: SourceForge Robot (sf-robot)
Date: 03/03/06 19:23

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 (birkenfeld)
Date: 02/17/06 04:03

Message:
Logged In: YES 
user_id=1188172

I think it's common practise to add a DeprecationWarning to
those modules which are deprecated since one or two
releases. That should be enough reminder.

You should be reading the docs anyway :)

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

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

From noreply at sourceforge.net  Sat Mar  4 08:26:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 03 Mar 2006 23:26:46 -0800
Subject: [ python-Bugs-1442937 ] Bad Coroutine link
Message-ID: <E1FFRA6-0003Sh-LS@sc8-sf-web5.sourceforge.net>

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

Please note that this 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: Paddy McCarthy (paddy3118)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bad Coroutine link

Initial Comment:
Page http://docs.python.org/dev/whatsnew/node4.html
See also box.
www.sidhe.org link should be to:

  http://www.sidhe.org/~dan/blog/archives/000178.html

notice the squiggle, (tilde)?, '~' before dan above.

Cheers.

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

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

From noreply at sourceforge.net  Sun Mar  5 00:31:57 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 04 Mar 2006 15:31:57 -0800
Subject: [ python-Bugs-1442937 ] Bad Coroutine link
Message-ID: <E1FFgE9-00040S-OZ@sc8-sf-web2.sourceforge.net>

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

Please note that this 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: Paddy McCarthy (paddy3118)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: Bad Coroutine link

Initial Comment:
Page http://docs.python.org/dev/whatsnew/node4.html
See also box.
www.sidhe.org link should be to:

  http://www.sidhe.org/~dan/blog/archives/000178.html

notice the squiggle, (tilde)?, '~' before dan above.

Cheers.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-04 15:31

Message:
Logged In: YES 
user_id=33168

Thanks!

Committed revision 42843.


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

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

From noreply at sourceforge.net  Sun Mar  5 02:06:45 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 04 Mar 2006 17:06:45 -0800
Subject: [ python-Bugs-1384175 ] random module - Provider DLL failed to
	initialize correctly
Message-ID: <E1FFhht-00018B-0G@sc8-sf-web4-b.sourceforge.net>

Bugs item #1384175, was opened at 2005-12-18 01:18
Message generated for change (Comment added) made by ghazel
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: Greg Hazel (ghazel)
Date: 2006-03-05 01: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 07: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 11: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  Sun Mar  5 04:22:34 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 4 Mar 2006 19:22:34 -0800
Subject: [ python-Bugs-1376400 ] test_struct crashed, py2.3.5, solaris 10
Message-ID: <200603050322.k253MY3Y029750@sc8-sf-db2-new-b.sourceforge.net>

Bugs item #1376400, was opened at 12/08/05 08: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=1376400&group_id=5470

Please note that this 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.3
>Status: Closed
Resolution: None
Priority: 5
Submitted By: rrogans (rrogans)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_struct crashed, py2.3.5, solaris 10

Initial Comment:
Hi,

I am building python 2.3.5 on solaris 10 using gcc 
3.3.2. Run I perform the test I get one test failure - 
test_struct crashes.

Rgds,

Richard

>>>>>>>>>>>>

trying std qQ on 1471797217424382203 == 
0x146CDFC575FD18FBL
trying std qQ on 1471797217424382204 == 
0x146CDFC575FD18FCL
trying std qQ on 1471797217424382205 == 
0x146CDFC575FD18FDL
test test_struct crashed -- exceptions.OverflowError: 
math range error
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 394, in runtest
    the_package = __import__(abstest, globals(), locals
(), [])
  File "/home/richardr/app/Python-
2.3.5/Lib/test/test_struct.py", line 439, in ?
    test_705836()
  File "/home/richardr/app/Python-
2.3.5/Lib/test/test_struct.py", line 424, in 
test_705836
    big = math.ldexp(big, 127 - 23)
OverflowError: math range error
1 test failed:
    test_struct

<<<<<<<<<<<

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

>Comment By: SourceForge Robot (sf-robot)
Date: 03/04/06 19:22

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 (birkenfeld)
Date: 02/18/06 16:59

Message:
Logged In: YES 
user_id=1188172

To the OP: Can you provide information whether this happens
with Python 2.4?

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

Comment By: Martin v. L??wis (loewis)
Date: 12/27/05 16:06

Message:
Logged In: YES 
user_id=21627

Also, Python 2.3 is no longer maintained. So unless this
problem also shows up with 2.4, we are unlikely to take any
action.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 12/11/05 12:15

Message:
Logged In: YES 
user_id=33168

Could you try disabling optimization and rebuilding python?
 Also, depending on which compiler you are using, ensure
that you are using strict math.  Sometimes the option is
-ieee I think.

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

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

From noreply at sourceforge.net  Sun Mar  5 05:18:31 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 04 Mar 2006 20:18:31 -0800
Subject: [ python-Bugs-1443328 ] Pickle protocol 2 fails on private slots.
Message-ID: <E1FFkhT-0002mJ-AI@sc8-sf-web1.sourceforge.net>

Bugs item #1443328, was opened at 2006-03-05 04: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=1443328&group_id=5470

Please note that this message 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: Daniele Varrazzo (dvarrazzo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Pickle protocol 2 fails on private slots.

Initial Comment:
The pickling protocol 2 can manage new style objects
defining __slots__ and without __dict__. Anyway it
fails when one of the slots is "private".

>>> class C1(object):
	__slots__ = ["__priv"]
	def __init__(self):
		self.__priv = 42
	def get_priv(self):
		return self.__priv

>>> C1().get_priv()
42
>>> import pickle
>>> pickle.loads(pickle.dumps(C1(), 2)).get_priv()

Traceback (most recent call last):
  File "<pyshell#258>", line 1, in -toplevel-
    pickle.loads(pickle.dumps(C1(), 2)).get_priv()
  File "<pyshell#255>", line 6, in get_priv
    return self.__priv
AttributeError: _C1__priv

of course redefining __getstate__ and __setstate__
bypasses the problem.

the cPickle module shows the same issue.

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

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

From noreply at sourceforge.net  Sun Mar  5 14:50:20 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 05 Mar 2006 05:50:20 -0800
Subject: [ python-Bugs-1443504 ] locale.getpreferredencoding() dies when
	setlocale fails
Message-ID: <E1FFtcq-0005jJ-9v@sc8-sf-web6.sourceforge.net>

Bugs item #1443504, was opened at 2006-03-05 08:50
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1443504&group_id=5470

Please note that this message 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: Catherine Devlin (catherinedevlin)
Assigned to: Nobody/Anonymous (nobody)
Summary: locale.getpreferredencoding() dies when setlocale fails

Initial Comment:
I'm on Ubuntu 5.10, with Python 2.4.2-0ubuntu2, and
when I open a terminal window and run python, I get

>>> import locale
>>> locale.getpreferredencoding()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.4/locale.py", line 417, in
getpreferredencoding
    setlocale(LC_CTYPE, "")
  File "/usr/lib/python2.4/locale.py", line 381, in
setlocale
    return _setlocale(category, locale)
locale.Error: unsupported locale setting

However, if I su - root - or even su right back to my
own account (catherine) ! - then everything works.

This is of concern (to me, anyway) because this error
crashes bzr. 

I chose "Esperanto" as my language when setting up
Ubuntu.  (No, I wasn't trying to be funny - I really do
speak Esperanto!)  That may be why I found the problem,
but I don't think this is simply a problem with flawed
Esperanto support in Ubuntu - because the routine works
after su is used, and because
locale.nl_langinfo(CODESET) works fine (please read on).

Anyway, within locale.getpreferredencoding(), line 417
- setlocale(LC_CTYPE, "") - seems to be the problem...

>>> locale.setlocale(locale.LC_CTYPE)
'C'
>>> locale.setlocale(locale.LC_CTYPE, "")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.4/locale.py", line 381, in
setlocale
    return _setlocale(category, locale)
locale.Error: unsupported locale setting
>>> locale.setlocale(locale.LC_CTYPE, None)
'C'

This makes me wonder if setlocale(LC_TYPE, "") is
really so very necessary.  It seems to be there to prep
for the nl_langinfo call, but it doesn't actually seem
strictly necessary for that call to work.

>>> locale.nl_langinfo(locale.CODESET)
'ANSI_X3.4-1968'

... I get that result whether before or after calling
setlocale, and I get it under any account (including
root, where setlocale does not raise an exception).

Thus, as far as I can tell, it isn't really necessary
to set setlocale(LC_CTYPE, "") or die trying, and
accepting the nl_langinfo result without a 
successful setlocale(LC_CTYPE, "") would be preferable
to raising an unhandled exception.  I suggest that
setlocale(LC_TYPE, "") be enclosed in a try block.

                try:
                    setlocale(LC_CTYPE, "")
                except:
                    None

Since I don't really understand what it's doing in the
first place, I don't know if this is really a good patch.

Thanks!

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

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

From noreply at sourceforge.net  Mon Mar  6 00:33:04 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 05 Mar 2006 15:33:04 -0800
Subject: [ python-Bugs-1441408 ] svn head compiler fails to spot extended
	slicing
Message-ID: <E1FG2im-0006nb-Cn@sc8-sf-web3.sourceforge.net>

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

Please note that this 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: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Nobody/Anonymous (nobody)
Summary: svn head compiler fails to spot extended slicing

Initial Comment:
This is Python SVN HEAD:

>>> dis.dis(compile("x[::]", '', 'single'))
  1           0 LOAD_NAME                0 (x)
              3 SLICE+0             
              4 PRINT_EXPR          
              5 LOAD_CONST               0 (None)
              8 RETURN_VALUE        

This is Python 2.4:

>>> dis.dis(compile("x[::]", '', 'single'))
  1           0 LOAD_NAME                0 (x)
              3 LOAD_CONST               0 (None)
              6 LOAD_CONST               0 (None)
              9 LOAD_CONST               0 (None)
             12 BUILD_SLICE              3
             15 BINARY_SUBSCR       
             16 PRINT_EXPR          
             17 LOAD_CONST               0 (None)
             20 RETURN_VALUE        


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

Comment By: Grant Olson (logistix)
Date: 2006-03-05 17:33

Message:
Logged In: YES 
user_id=699438

This only happens when you have implicit slice values. 
x[1:2:3] works fine.  I'm finishing up a patch and will post
to sf shortly.


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

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

From noreply at sourceforge.net  Mon Mar  6 02:44:58 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 05 Mar 2006 17:44:58 -0800
Subject: [ python-Bugs-1436532 ] length of unicode string changes print
	behaviour
Message-ID: <E1FG4mQ-0006FN-6U@sc8-sf-web3.sourceforge.net>

Bugs item #1436532, was opened at 2006-02-22 04:45
Message generated for change (Comment added) made by tjreedy
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: Kurt B. Kaiser (kbk)
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: 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  Mon Mar  6 03:00:29 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 05 Mar 2006 18:00:29 -0800
Subject: [ python-Bugs-1437051 ] "continue" in .pdbrc has no effect
Message-ID: <E1FG51R-0005dk-R5@sc8-sf-web2.sourceforge.net>

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

Please note that this message 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: Coolheads Consulting (coolheads)
Assigned to: Nobody/Anonymous (nobody)
Summary: "continue" in .pdbrc has no effect

Initial Comment:
I'm using Python 2.4.2 under Debian Woody; uname -a:
Linux bruno 2.4.23 i686 GNU/Linux

The documentation for pdb says that commands in .pdbrc
will be executed just as if they were typed in at the
pdb prompt.  However, "c", "cont", and "continue" have
no effect.  It would be nice if this would work.

I discovered this problem because I need to be able to
call Python scripts from within a Makefile, and it is
convenient, when one of them goes awry (say, because of
a key error exception), to already be in the debugger
when such exceptions are raised.  However, I can't call
a Python script with the debugger from a makefile because
execution always stops at the beginning of the script,
waiting for a "continue" to be typed in at the prompt.
 I thought I could solve the problem with a "continue"
in the .pdbrc in the local directory.  However, every way I
can think of to say "continue", including aliasing it,
has no effect in the .pdbrc.  Is there another way to
accomplish what I'm trying to do?

Steve Newcomb
srn at coolheads.com


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

>Comment By: Terry J. Reedy (tjreedy)
Date: 2006-03-05 21:00

Message:
Logged In: YES 
user_id=593130

I wonder whether the .pdbrc is being read and executed 
when you think it is.  Is the problem actually specific 
to 'continue'?  If you put 'list' in the file, do you get 
a listing?

It might help if you gave the exact command line you use 
to start the Python script.

I don't know if this is really a bug.  You might get 
answers about 'another way' on python-
list/comp.lang.python.  (I don't know ;-)

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

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

From noreply at sourceforge.net  Mon Mar  6 03:26:49 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 05 Mar 2006 18:26:49 -0800
Subject: [ python-Bugs-1437614 ] can't send files via ftp on my MacOS X 10.3.9
Message-ID: <E1FG5Qv-0000K0-FA@sc8-sf-web3.sourceforge.net>

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

Please note that this message 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: Li Quid (liquid333)
Assigned to: Nobody/Anonymous (nobody)
Summary: can't send files via ftp on my MacOS X 10.3.9

Initial Comment:

When trying to do a simple ftp upload using Python
2.3's ftplib, it fails and I get a socket error.  The
exact error is (61, 'Connection refused').  This
happens to me in all my scripts that use the ftplib on
MacOS 10.3.9, but not in scripts on my Windows box. 
I've attached the small, simple source code.

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

>Comment By: Terry J. Reedy (tjreedy)
Date: 2006-03-05 21:26

Message:
Logged In: YES 
user_id=593130

This could be a problem in your specific machine and its 
setup, the specific OS version, the specific target (maybe 
nyx doesn't like MACs), or the specific Python version.

I would start by installing 2.4.2 and see if there have 
maybe been helpful changes to its socket code.  And try to 
find another Mac box.  And then ask on python-
list/comp.lang.python for other experiences with Max, OSX, 
sockets, and maybe ftp.  Since the error message comes 
from the OS blaming nyx, I think more likely than not that 
this is not a Python bug.

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

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

From noreply at sourceforge.net  Mon Mar  6 04:01:54 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 05 Mar 2006 19:01:54 -0800
Subject: [ python-Bugs-1437699 ] robotparser crashes if robots.txt contains
	non-ASCII
Message-ID: <E1FG5ys-0002RM-6Y@sc8-sf-web3.sourceforge.net>

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

Please note that this 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: osvenskan (osvenskan)
Assigned to: M.-A. Lemburg (lemburg)
Summary: robotparser crashes if robots.txt contains non-ASCII

Initial Comment:
One-line summary: If the robotparser module encounters
a robots.txt file that contains non-ASCII characters
AND I pass a Unicode user agent string to can_fetch(),
that function crashes with a TypeError under Python
2.4. Under Python 2.3, the error is a UnicodeDecodeError. 

More detail:
When one calls can_fetch(MyUserAgent, url), the
robotparser module compares  the UserAgent to each user
agent described in the robots.txt file. If
isinstance(MyUserAgent, str) == True then the
comparison does not raise an error regardless of the
contents of robots.txt. However, if
isinstance(MyUserAgent, unicode) == True, then Python
implicitly tries to convert the contents of the
robots.txt file to Unicode before comparing it to
MyUserAgent. By default, Python assumes a US-ASCII
encoding when converting, so if the contents of
robots.txt aren't ASCII, the conversion fails. In other
words, this works:
MyRobotParser.can_fetch('foobot', url)
but this fails:
MyRobotParser.can_fetch(u'foobot', url)

I recreated this with Python 2.4.1 on FreeBSD 6 and
Python 2.3 under Darwin/OS X. I'll attach examples from
both. The URLs that I use in the attachments are from
my Web site and will remain live. They reference
robots.txt files which contain an umlaut-ed 'a' (0xe4
in iso-8859-1). They're served up using a special
.htaccess file that adds a Content-Type header which
correctly identifies the encoding used for each file.
Here's the contents of the .htaccess file:

AddCharset iso-8859-1 .iso8859-1
AddCharset utf-8 .utf8


A suggested solution:
AFAICT, the construction of robots.txt is still defined
by "a consensus on 30 June 1994 on the robots mailing
list" [http://www.robotstxt.org/wc/norobots.html] and a
1996 draft proposal
[http://www.robotstxt.org/wc/norobots-rfc.html] that
has never evolved into a formal standard. Neither of
these mention character sets or encodings which is no
surprise considering that they date back to the days
when the Internet was poor but happy and we considered
even ASCII a luxury and we were grateful to have it.
("ASCII? We used to dream of having ASCII. We only had
one bit, and it was a zero. We lived in a shoebox in
the middle of the road..." etc.) A backwards-compatible
yet forward-looking solution would be to have the
robotparser module respect the Content-Type header sent
with robots.txt. If no such header is present,
robotparser should try to decode it using iso-8859-1
per section 3.7.1 of the HTTP 1.1 spec
(http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7.1)
which says, 'When no explicit charset parameter is
provided by the sender, media subtypes of the "text"
type are defined to have a default charset value of
"ISO-8859-1" when received via HTTP. Data in character
sets other than "ISO-8859-1" or its subsets MUST be
labeled with an appropriate charset value.' Section
3.6.1 of the HTTP 1.0 spec says the same. Since
ISO-8859-1 is a superset of US-ASCII, robots.txt files
that are pure ASCII won't be affected by the change.






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

>Comment By: Terry J. Reedy (tjreedy)
Date: 2006-03-05 22:01

Message:
Logged In: YES 
user_id=593130

To me, this is not a bug report but at best an RFE.  The 
reported behavior is what I would expect.  I read both 
module doc and the referenced web page and further links.  
The doc does not mention Unicode as allowed and the 300 
registered UserAgents at
http://www.robotstxt.org/wc/active/html/index.html
all have ascii names.

So I recomment closing this as a bug report but will give 
ML a chance to respond.  If switched instead to Feature 
Request, I would think it would need some 'in the wild' 
evidence of need.

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

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

From noreply at sourceforge.net  Mon Mar  6 04:18:47 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 05 Mar 2006 19:18:47 -0800
Subject: [ python-Bugs-1438537 ] modules search in help() crashes on
	insufficient file perms
Message-ID: <E1FG6FD-0001Dw-2G@sc8-sf-web4-b.sourceforge.net>

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

Please note that this 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: A. Coder (hauptbeuteltier)
Assigned to: Nobody/Anonymous (nobody)
Summary: modules search in help() crashes on insufficient file perms

Initial Comment:
In the python interpreter, in the interactive online
help, typing <code>modules &lt;keyword&gt;</code>
throws a permission denied error (Errno 13) and dumps
the user back to the main interpreter if the user has
insufficient permission to read any .py file from the
site-packages directory.


Example:
~:$ ls -l /usr/lib/python2.4/site-packages/pygtk.py
-rw-r-----  1 root root 2619 2005-02-20 14:18
/usr/lib/python2.4/site-packages/pygtk.py
~:$ python
>>> help()

help> modules html

Here is a list of matching modules.  Enter any module
name to get more help.

HTMLParser - A parser for HTML and XHTML.
htmlentitydefs - HTML character entity references.
htmllib - HTML 2.0 parser.
markupbase - Shared support for scanning document type
declarations in HTML and XHTML.
pydoc - Generate Python documentation in HTML or text
for interactive use.
test.test_htmllib 
test.test_htmlparser - Tests for HTMLParser.py.
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.4/site.py", line 328, in __call__
    return pydoc.help(*args, **kwds)
  File "/usr/lib/python2.4/pydoc.py", line 1650, in
__call__
    self.interact()
  File "/usr/lib/python2.4/pydoc.py", line 1668, in
interact
    self.help(request)
  File "/usr/lib/python2.4/pydoc.py", line 1686, in help
    self.listmodules(split(request)[1])
  File "/usr/lib/python2.4/pydoc.py", line 1790, in
listmodules
    apropos(key)
  File "/usr/lib/python2.4/pydoc.py", line 1900, in apropos
    ModuleScanner().run(callback, key)
  File "/usr/lib/python2.4/pydoc.py", line 1886, in run
    desc = synopsis(path) or ''
  File "/usr/lib/python2.4/pydoc.py", line 182, in synopsis
    file = open(filename)
IOError: [Errno 13] Permission denied:
'/usr/lib/python2.4/site-packages/tageditor.py'
>>>

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

>Comment By: Terry J. Reedy (tjreedy)
Date: 2006-03-05 22:18

Message:
Logged In: YES 
user_id=593130

I am tempted to say that the restricted file permission is 
the bug but enhancing pydoc seems reasonable to me.  It 
appears to open the file to get the first line of the doc 
string.  So I would have the exception clause instead 
return a string like "Permission denied: you cannot import 
this file.  See your system administrator for more."

I would have attached such a mini patch here.  Once a 
committer reads this bug report and decides to make a 
change, hardly any review is needed.

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

Comment By: splitscreen (splitscreen)
Date: 2006-02-28 19:08

Message:
Logged In: YES 
user_id=1126061

Patch #1440660 fixes this.

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

Comment By: Grant Olson (logistix)
Date: 2006-02-28 16:55

Message:
Logged In: YES 
user_id=699438

I personally don't have commit rights, but yes, it's
generally easiest if you post the patch to Patch manager and
put a cross reference note on the bug.  Developers usually
give working patches precidence over bugs.

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

Comment By: splitscreen (splitscreen)
Date: 2006-02-28 10:54

Message:
Logged In: YES 
user_id=1126061

Yeah, I've modified it to tell the user which file caused
the problem.

Want the patch posting to the Patch Manager?

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

Comment By: Grant Olson (logistix)
Date: 2006-02-26 18:32

Message:
Logged In: YES 
user_id=699438

That patch sounds pretty-much right, but I think it should
print some feedback to stderr instead of silently swallowing
the exception.

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

Comment By: splitscreen (splitscreen)
Date: 2006-02-25 07:34

Message:
Logged In: YES 
user_id=1126061

Could this just be silently skipped? i.e returning None if
the user does not have the corrept permissions to access a
particular file?

Just wrap the 'file = open(filename)' in pydoc.py: line 182
in a try: except block returning None if there's an error
(such as permission denied).

I have written a patch I can supply if anyone wants it and
if this is the Right Thing To Do (TM).


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

Comment By: A. Coder (hauptbeuteltier)
Date: 2006-02-25 04:44

Message:
Logged In: YES 
user_id=1420716

My apologies. The tageditor.py file had the same permissions
for my test as pygtk.py. The particular file is irrelevant
in this case, it only matters that a user has insufficient
permissions for any file in the site-packages directory.

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

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

From noreply at sourceforge.net  Mon Mar  6 04:20:44 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 5 Mar 2006 19:20:44 -0800
Subject: [ python-Bugs-764493 ] test test_nis crashed -- nis.error: no such
	key in map
Message-ID: <200603060320.k263KiTT006458@sc8-sf-db2-new-b.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Demos and Tools
Group: Python 2.3
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Martin Mokrejs (mmokrejs)
Assigned to: Nobody/Anonymous (nobody)
Summary: test test_nis crashed -- nis.error: no such key in map

Initial Comment:
I always ignored this test error, but maybe you want to
fix this:

test test_nis crashed -- nis.error: no such key in map


$ ./python Lib/test/test_nis.py
nis.maps()
group.bygid.tmp
mail.aliases
      
     n.strack strack
Traceback (most recent call last):
  File &quot;Lib/test/test_nis.py&quot;, line 24, in ?
    if nis.match(k, nismap) != v:
nis.error: no such key in map
$

I believe this might be some misconfiguration of NIS on
thsi host(we use it on other machines, but it should
not be enabled on this particular machine). 

But, when I do &quot;ypcat mail.aliases&quot;, I do not see a
line with &quot;n.strack strack&quot;. Maybe more debug trace
would help to find what's going on.

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

>Comment By: SourceForge Robot (sf-robot)
Date: 03/05/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 (birkenfeld)
Date: 02/19/06 07:10

Message:
Logged In: YES 
user_id=1188172

Does this error persist in Python 2.4?

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

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

From noreply at sourceforge.net  Mon Mar  6 04:36:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 05 Mar 2006 19:36:24 -0800
Subject: [ python-Bugs-1439659 ] file to store pickled object should be opened
	in binary mode
Message-ID: <E1FG6WG-0001lO-SZ@sc8-sf-web1.sourceforge.net>

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

Please note that this 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: Raghuram Devarakonda (draghuram)
Assigned to: Nobody/Anonymous (nobody)
Summary: file to store pickled object should be opened in binary mode

Initial Comment:

Hi,

To unpickle objects on UNIX that were pickled on
windows, the file should be opened in binary mode for
read and write on windows. It will be nice to have this
mentioned in the doc. Something along these lines will
be good enough:

"Please note that if you are writing the pickled object
to a file on windows, make sure it is opened in binary
mode. Otherwise, the file may not be able to be used to
unpickle on other non-windows platforms".

Thanks,
Raghu. 

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

>Comment By: Terry J. Reedy (tjreedy)
Date: 2006-03-05 22:36

Message:
Logged In: YES 
user_id=593130

For ASCII protocol pickles, intended for human 
readability, one should use text mode to be able to read 
the file, for instance, in Notepad.

For either binary protocol, I would think binary mode 
should be best even to reread on Windows.  If anything is 
added, I would put
"On Windows, open files in a mode (text/binary) that 
matches the protocol."
at the bottom of http://docs.python.org/lib/node64.html

Looking forward to 3.0, when file mode might be more 
significant (text/binary corresponding to unicode/bytes), 
the "for windoews' qualifier might be omitted, but this 
might be premature.

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

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

From noreply at sourceforge.net  Mon Mar  6 04:37:28 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 05 Mar 2006 19:37:28 -0800
Subject: [ python-Feature Requests-1441072 ] No simple example for pickle
Message-ID: <E1FG6XI-0004bI-NN@sc8-sf-web3.sourceforge.net>

Feature Requests item #1441072, was opened at 2006-03-01 11:49
Message generated for change (Settings changed) made by tjreedy
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: Open
Resolution: None
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

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

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

From noreply at sourceforge.net  Mon Mar  6 05:10:03 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 05 Mar 2006 20:10:03 -0800
Subject: [ python-Bugs-1443866 ] email 3.0+ stops parsing headers prematurely
Message-ID: <E1FG72p-0007AP-AS@sc8-sf-web6.sourceforge.net>

Bugs item #1443866, was opened at 2006-03-05 20: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=1443866&group_id=5470

Please note that this message 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 Sapiro (msapiro)
Assigned to: Nobody/Anonymous (nobody)
Summary: email 3.0+ stops parsing headers prematurely

Initial Comment:
given the following input:

Received: by main.example.com; Sun Nov  4 02:45:50 2001
X-From_: postmaster at example.com  Sun Nov  4 02:45:50 2001
>From bob  Sun Nov  4 02:45:50 2001
Return-Path: <postmaster at example.com>
Delivered-To: bob at example.com

followed by more headers and message body, the email
3.0+ parser parses everything beginning with the

>From bob  Sun Nov  4 02:45:50 2001

line as the body of the message with only the first two
lines as the header. RFC 2822 is clear that the message
headers are separated from the body by an empty line,
so I think the parser should continue parsing
everything as headers until an empty line or the end of
input is encountered, and should consider lines such as

>From bob  Sun Nov  4 02:45:50 2001

or

Some arbitrary text

encountered in the headers to be MalformedHeaderDefect.
A complete example message is atteched.


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

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

From noreply at sourceforge.net  Mon Mar  6 05:12:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 05 Mar 2006 20:12:05 -0800
Subject: [ python-Bugs-1443866 ] email 3.0+ stops parsing headers prematurely
Message-ID: <E1FG74n-0004V8-IB@sc8-sf-web4-b.sourceforge.net>

Bugs item #1443866, was opened at 2006-03-05 20:10
Message generated for change (Settings changed) made by msapiro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1443866&group_id=5470

Please note that this message 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 Sapiro (msapiro)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email 3.0+ stops parsing headers prematurely

Initial Comment:
given the following input:

Received: by main.example.com; Sun Nov  4 02:45:50 2001
X-From_: postmaster at example.com  Sun Nov  4 02:45:50 2001
>From bob  Sun Nov  4 02:45:50 2001
Return-Path: <postmaster at example.com>
Delivered-To: bob at example.com

followed by more headers and message body, the email
3.0+ parser parses everything beginning with the

>From bob  Sun Nov  4 02:45:50 2001

line as the body of the message with only the first two
lines as the header. RFC 2822 is clear that the message
headers are separated from the body by an empty line,
so I think the parser should continue parsing
everything as headers until an empty line or the end of
input is encountered, and should consider lines such as

>From bob  Sun Nov  4 02:45:50 2001

or

Some arbitrary text

encountered in the headers to be MalformedHeaderDefect.
A complete example message is atteched.


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

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

From noreply at sourceforge.net  Mon Mar  6 05:40:01 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 05 Mar 2006 20:40:01 -0800
Subject: [ python-Bugs-1441264 ] set update method description is incorrect
Message-ID: <E1FG7Vp-0005sD-Gt@sc8-sf-web5.sourceforge.net>

Bugs item #1441264, was opened at 2006-03-01 15:19
Message generated for change (Settings changed) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1441264&group_id=5470

Please note that this 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: Invalid
Priority: 5
Submitted By: Richard King (rickbking)
Assigned to: Nobody/Anonymous (nobody)
Summary: set update method description is incorrect

Initial Comment:
Update is described as returning the set with the new 
members, but it only updates the set and returns None.

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

>Comment By: Terry J. Reedy (tjreedy)
Date: 2006-03-05 23:40

Message:
Logged In: YES 
user_id=593130

You are right.

It is standard in Python for mutating methods to return 
None.  

The doc strings for update are more or less OK.
>>> set.update.__doc__
'Update a set with the union of itself and another.'
>>> sets.Set.update.__doc__
'Add all values from an iterable (such as a list or file).'

But
http://docs.python.org/lib/types-set.html 
http://docs.python.org/lib/set-objects.html
both incorrectly describes the first four update methods 
as returning the set after the update

(In the furture, giving specific section references or url 
for questionable docs would help verify the report.)

Verifying the expected behavior for the module:
>>> from sets import Set as S
>>> c=S([1,2,3])
>>> d=S([2,3,4])
>>> c.update(d)
>>> c
Set([1, 2, 3, 4])
# etc

Suggested fixes for both files:  In "The following table 
lists operations available ..." add 'mutation' 
before 'operatons' and follow the sentence with "All 
return None."
Change "return set s with elements added from t"
to "add elements from t to s"
Change "return set s keeping only elements also found in t"
to "remove elements of s not found in t"
Change "return set s after removing elements found in t"
to "remove elements of s also found in t"
Change "return set s after removing elements found in t"
to "remove elements of s also in t and add elements of t 
not in s"

Verify with set/sets author (RH I believe).

Additional glitch: at the bottom of 
http://docs.python.org/lib/types-set.html
there is a link to 'sets'
http://docs.python.org/lib/module-comparison-to-builtin-
set.html
I currently get 'page not found' message.

While on the topic of doc glitches:
http://docs.python.org/lib/typesmapping.html
has title "2.3.8 Mapping Types -- classdict"
'classdict'? looks like a typo.


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

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

From noreply at sourceforge.net  Mon Mar  6 06:04:09 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 05 Mar 2006 21:04:09 -0800
Subject: [ python-Bugs-1416477 ] Inconsistency between StringIO and cStringIO
Message-ID: <E1FG7tB-0007cn-6O@sc8-sf-web4-b.sourceforge.net>

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

Please note that this 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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Kerrin (mkerrin)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Inconsistency between StringIO and cStringIO

Initial Comment:
The readline method for StringIO defalt argument for
the size arguement is None while for all other
file-like objects it is -1. So if we pass in -1 to the
StringIO readline method, all lines are returned, again
inconsistent with the other file-like objects, and if
we pass in None to any other file-like object we get a
TypeError, int required.

The attached python script is a very simple example of
what I mean.

Note that this is causing me a lot of grief in trying
to get tests to pass for a simple fix to an open source
project.

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

Comment By: Kent Hsu (cphsu)
Date: 2006-03-06 13:04

Message:
Logged In: YES 
user_id=1468643

BTW, another inconsistency between StringIO and cStringIO :-)

>>> import cStringIO as c
>>> sio = c.StringIO()
>>> sio.write("aaaaa")
>>> sio.truncate(0)
>>> print sio.getvalue()

>>> sio.write("bbbbb")
>>> print sio.getvalue()
aaaaabbbbb

which I get in StringIO module is "bbbbb".


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

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

From noreply at sourceforge.net  Mon Mar  6 06:16:04 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 05 Mar 2006 21:16:04 -0800
Subject: [ python-Bugs-1416477 ] Inconsistency between StringIO and cStringIO
Message-ID: <E1FG84i-00028R-GX@sc8-sf-web3.sourceforge.net>

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

Please note that this 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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Kerrin (mkerrin)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Inconsistency between StringIO and cStringIO

Initial Comment:
The readline method for StringIO defalt argument for
the size arguement is None while for all other
file-like objects it is -1. So if we pass in -1 to the
StringIO readline method, all lines are returned, again
inconsistent with the other file-like objects, and if
we pass in None to any other file-like object we get a
TypeError, int required.

The attached python script is a very simple example of
what I mean.

Note that this is causing me a lot of grief in trying
to get tests to pass for a simple fix to an open source
project.

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

Comment By: Kent Hsu (cphsu)
Date: 2006-03-06 13:16

Message:
Logged In: YES 
user_id=1468643

Sorry, it seems the bug has been fixed in 2.4.

>>>>>>>>>>>>>>>>>>>
>>> import cStringIO as c
>>> sio = c.StringIO()
>>> sio.write("aaaaa")
>>> sio.truncate(0)
>>> print sio.getvalue()

>>> sio.write("bbbbb")
>>> print sio.getvalue()
aaaaabbbbb

which I get in StringIO module is "bbbbb".

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

Comment By: Kent Hsu (cphsu)
Date: 2006-03-06 13:04

Message:
Logged In: YES 
user_id=1468643

BTW, another inconsistency between StringIO and cStringIO :-)

>>> import cStringIO as c
>>> sio = c.StringIO()
>>> sio.write("aaaaa")
>>> sio.truncate(0)
>>> print sio.getvalue()

>>> sio.write("bbbbb")
>>> print sio.getvalue()
aaaaabbbbb

which I get in StringIO module is "bbbbb".


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

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

From noreply at sourceforge.net  Mon Mar  6 10:21:02 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 06 Mar 2006 01:21:02 -0800
Subject: [ python-Bugs-764493 ] test test_nis crashed -- nis.error: no such
	key in map
Message-ID: <E1FGBtm-0008U8-Np@sc8-sf-web3.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Demos and Tools
Group: Python 2.3
Status: Closed
Resolution: None
Priority: 5
Submitted By: Martin Mokrejs (mmokrejs)
Assigned to: Nobody/Anonymous (nobody)
Summary: test test_nis crashed -- nis.error: no such key in map

Initial Comment:
I always ignored this test error, but maybe you want to
fix this:

test test_nis crashed -- nis.error: no such key in map


$ ./python Lib/test/test_nis.py
nis.maps()
group.bygid.tmp
mail.aliases
      
     n.strack strack
Traceback (most recent call last):
  File &quot;Lib/test/test_nis.py&quot;, line 24, in ?
    if nis.match(k, nismap) != v:
nis.error: no such key in map
$

I believe this might be some misconfiguration of NIS on
thsi host(we use it on other machines, but it should
not be enabled on this particular machine). 

But, when I do &quot;ypcat mail.aliases&quot;, I do not see a
line with &quot;n.strack strack&quot;. Maybe more debug trace
would help to find what's going on.

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

>Comment By: Martin Mokrejs (mmokrejs)
Date: 2006-03-06 10:21

Message:
Logged In: YES 
user_id=696559

Unfortunately I do not have an access to that machine
running Tru64Unix 5.1. I tried to reproduce on Linux i686
with python-2.4.2 with no luck (that means NIS is not set up
and the test correctly complains there is no NIS configured):

$ ./python Lib/test/test_nis.py
nis.maps()
Traceback (most recent call last):
  File "Lib/test/test_nis.py", line 10, in ?
    raise TestFailed, msg
test.test_support.TestFailed: No NIS master found for any map
$

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

Comment By: SourceForge Robot (sf-robot)
Date: 2006-03-06 04: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 (birkenfeld)
Date: 2006-02-19 16:10

Message:
Logged In: YES 
user_id=1188172

Does this error persist in Python 2.4?

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

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

From noreply at sourceforge.net  Mon Mar  6 14:04:49 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 06 Mar 2006 05:04:49 -0800
Subject: [ python-Bugs-1444104 ] os.open() Documentation
Message-ID: <E1FGFOL-0005L8-9z@sc8-sf-web3.sourceforge.net>

Bugs item #1444104, was opened at 2006-03-06 13: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=1444104&group_id=5470

Please note that this 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: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Guettler (guettli)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.open() Documentation

Initial Comment:
Hi,

I think the note in the docu could be improved:

"""To read a ``file object'' returned by the built-in
function open() or by popen() or fdopen(), or
sys.stdin, use its read() or readline() methods."""

(I think) a better note:

"""To read a ``file object'' returned by the built-in
function open(), popen(), fdopen() or sys.stdin, use
its read() or readline() methods. You can convert the
file descriptor returned by os.open() to a file object
with [LINK os.fdopen()]"""

The same note is used for os.write().

At os.open() there should be a link to os.fdopen(), too.

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

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

From noreply at sourceforge.net  Mon Mar  6 16:11:31 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 06 Mar 2006 07:11:31 -0800
Subject: [ python-Bugs-1439659 ] file to store pickled object should be opened
	in binary mode
Message-ID: <E1FGHMx-0004gX-4i@sc8-sf-web3.sourceforge.net>

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

Please note that this 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: Raghuram Devarakonda (draghuram)
Assigned to: Nobody/Anonymous (nobody)
Summary: file to store pickled object should be opened in binary mode

Initial Comment:

Hi,

To unpickle objects on UNIX that were pickled on
windows, the file should be opened in binary mode for
read and write on windows. It will be nice to have this
mentioned in the doc. Something along these lines will
be good enough:

"Please note that if you are writing the pickled object
to a file on windows, make sure it is opened in binary
mode. Otherwise, the file may not be able to be used to
unpickle on other non-windows platforms".

Thanks,
Raghu. 

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

>Comment By: Raghuram Devarakonda (draghuram)
Date: 2006-03-06 10:11

Message:
Logged In: YES 
user_id=984087


Hi,

The point is that even if ASCII protocol is used on
windows(as I was), the unpickling process would fail on
windows. So the pickle file should be opened in binary mode
on windows even for ASCII protocol. This may make reading
the file in notepad difficult but then, cross platform
support should take precedence, I suppose. Another option
would be for python to do line end translations for ASCII
pickle files. 

Raghu.


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

Comment By: Terry J. Reedy (tjreedy)
Date: 2006-03-05 22:36

Message:
Logged In: YES 
user_id=593130

For ASCII protocol pickles, intended for human 
readability, one should use text mode to be able to read 
the file, for instance, in Notepad.

For either binary protocol, I would think binary mode 
should be best even to reread on Windows.  If anything is 
added, I would put
"On Windows, open files in a mode (text/binary) that 
matches the protocol."
at the bottom of http://docs.python.org/lib/node64.html

Looking forward to 3.0, when file mode might be more 
significant (text/binary corresponding to unicode/bytes), 
the "for windoews' qualifier might be omitted, but this 
might be premature.

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

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

From noreply at sourceforge.net  Mon Mar  6 16:12:49 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 06 Mar 2006 07:12:49 -0800
Subject: [ python-Bugs-1439659 ] file to store pickled object should be opened
	in binary mode
Message-ID: <E1FGHOD-0004ko-UJ@sc8-sf-web3.sourceforge.net>

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

Please note that this 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: Raghuram Devarakonda (draghuram)
Assigned to: Nobody/Anonymous (nobody)
Summary: file to store pickled object should be opened in binary mode

Initial Comment:

Hi,

To unpickle objects on UNIX that were pickled on
windows, the file should be opened in binary mode for
read and write on windows. It will be nice to have this
mentioned in the doc. Something along these lines will
be good enough:

"Please note that if you are writing the pickled object
to a file on windows, make sure it is opened in binary
mode. Otherwise, the file may not be able to be used to
unpickle on other non-windows platforms".

Thanks,
Raghu. 

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

>Comment By: Raghuram Devarakonda (draghuram)
Date: 2006-03-06 10:12

Message:
Logged In: YES 
user_id=984087


There seems to be a mistane in my earlier comment. I meant
the unpickling on *UNIX* fails even if ASCII was used on
windows.

Raghu.

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2006-03-06 10:11

Message:
Logged In: YES 
user_id=984087


Hi,

The point is that even if ASCII protocol is used on
windows(as I was), the unpickling process would fail on
windows. So the pickle file should be opened in binary mode
on windows even for ASCII protocol. This may make reading
the file in notepad difficult but then, cross platform
support should take precedence, I suppose. Another option
would be for python to do line end translations for ASCII
pickle files. 

Raghu.


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

Comment By: Terry J. Reedy (tjreedy)
Date: 2006-03-05 22:36

Message:
Logged In: YES 
user_id=593130

For ASCII protocol pickles, intended for human 
readability, one should use text mode to be able to read 
the file, for instance, in Notepad.

For either binary protocol, I would think binary mode 
should be best even to reread on Windows.  If anything is 
added, I would put
"On Windows, open files in a mode (text/binary) that 
matches the protocol."
at the bottom of http://docs.python.org/lib/node64.html

Looking forward to 3.0, when file mode might be more 
significant (text/binary corresponding to unicode/bytes), 
the "for windoews' qualifier might be omitted, but this 
might be premature.

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

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

From noreply at sourceforge.net  Mon Mar  6 20:03:55 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 06 Mar 2006 11:03:55 -0800
Subject: [ python-Bugs-1439659 ] file to store pickled object should be opened
	in binary mode
Message-ID: <E1FGKzr-0008PM-HF@sc8-sf-web1.sourceforge.net>

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

Please note that this 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: Raghuram Devarakonda (draghuram)
Assigned to: Nobody/Anonymous (nobody)
Summary: file to store pickled object should be opened in binary mode

Initial Comment:

Hi,

To unpickle objects on UNIX that were pickled on
windows, the file should be opened in binary mode for
read and write on windows. It will be nice to have this
mentioned in the doc. Something along these lines will
be good enough:

"Please note that if you are writing the pickled object
to a file on windows, make sure it is opened in binary
mode. Otherwise, the file may not be able to be used to
unpickle on other non-windows platforms".

Thanks,
Raghu. 

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

>Comment By: Terry J. Reedy (tjreedy)
Date: 2006-03-06 14:03

Message:
Logged In: YES 
user_id=593130

Any text file written with /r/n in Windows can have 
problems when read on *nix or Mac or ???, so this problem 
is not specific to pickle or even to Python.  I am under 
the impression that the new universal newline support was 
intended to fix such problems (when used).  But as a Win-
only user (currently) I have no experience with it.

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2006-03-06 10:12

Message:
Logged In: YES 
user_id=984087


There seems to be a mistane in my earlier comment. I meant
the unpickling on *UNIX* fails even if ASCII was used on
windows.

Raghu.

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2006-03-06 10:11

Message:
Logged In: YES 
user_id=984087


Hi,

The point is that even if ASCII protocol is used on
windows(as I was), the unpickling process would fail on
windows. So the pickle file should be opened in binary mode
on windows even for ASCII protocol. This may make reading
the file in notepad difficult but then, cross platform
support should take precedence, I suppose. Another option
would be for python to do line end translations for ASCII
pickle files. 

Raghu.


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

Comment By: Terry J. Reedy (tjreedy)
Date: 2006-03-05 22:36

Message:
Logged In: YES 
user_id=593130

For ASCII protocol pickles, intended for human 
readability, one should use text mode to be able to read 
the file, for instance, in Notepad.

For either binary protocol, I would think binary mode 
should be best even to reread on Windows.  If anything is 
added, I would put
"On Windows, open files in a mode (text/binary) that 
matches the protocol."
at the bottom of http://docs.python.org/lib/node64.html

Looking forward to 3.0, when file mode might be more 
significant (text/binary corresponding to unicode/bytes), 
the "for windoews' qualifier might be omitted, but this 
might be premature.

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

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

From noreply at sourceforge.net  Mon Mar  6 20:26:36 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 06 Mar 2006 11:26:36 -0800
Subject: [ python-Feature Requests-1423082 ] lib-deprecated
Message-ID: <E1FGLLo-0001Ni-Sr@sc8-sf-web1.sourceforge.net>

Feature Requests item #1423082, was opened at 2006-02-02 19:20
Message generated for change (Comment added) made by jimjjewett
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1423082&group_id=5470

Please note that this message 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: None
Priority: 5
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: lib-deprecated

Initial Comment:
obsolete modules are moved to lib-old.

deprecated modules remain in the library.

This makes the search for a relevant library more 
difficult. People browsing the code may not realize 
that they are deprecated.  (Example, I found no notice 
of deprecation within the code for rfc822.)  Even when 
the notice is there, the modules add to the number of 
alternatives, which hurts One-Obvious-Way-To-Do-It.

If these modules were moved to a deprecated directory, 
these problems would be greatly reduced.  (Ensure 
backwards compatibility by leaving the deprecated 
directory on the search path.) 

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

>Comment By: Jim Jewett (jimjjewett)
Date: 2006-03-06 14:26

Message:
Logged In: YES 
user_id=764593

Reading the docs is not a bad thing, but they aren't always 
convenient when developing, and the code itself should be 
correct too.

Moving them out of the standard library (and possibly the 
idlelib module search) will make them less of an attractive 
nuisance; at the least, it will save people the effort of 
looking them up and then backing out.



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

Comment By: SourceForge Robot (sf-robot)
Date: 2006-03-03 22:23

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 (birkenfeld)
Date: 2006-02-17 07:03

Message:
Logged In: YES 
user_id=1188172

I think it's common practise to add a DeprecationWarning to
those modules which are deprecated since one or two
releases. That should be enough reminder.

You should be reading the docs anyway :)

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

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

From noreply at sourceforge.net  Mon Mar  6 20:48:54 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 06 Mar 2006 11:48:54 -0800
Subject: [ python-Bugs-1439659 ] file to store pickled object should be opened
	in binary mode
Message-ID: <E1FGLhO-0003fy-5b@sc8-sf-web2.sourceforge.net>

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

Please note that this 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: Raghuram Devarakonda (draghuram)
Assigned to: Nobody/Anonymous (nobody)
Summary: file to store pickled object should be opened in binary mode

Initial Comment:

Hi,

To unpickle objects on UNIX that were pickled on
windows, the file should be opened in binary mode for
read and write on windows. It will be nice to have this
mentioned in the doc. Something along these lines will
be good enough:

"Please note that if you are writing the pickled object
to a file on windows, make sure it is opened in binary
mode. Otherwise, the file may not be able to be used to
unpickle on other non-windows platforms".

Thanks,
Raghu. 

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

>Comment By: Tim Peters (tim_one)
Date: 2006-03-06 14:48

Message:
Logged In: YES 
user_id=31435

Pickle files should be opened in binary mode, regardless of
pickle protocol, regardless of platform, and regardless of
whether reading or writing.  That protocol 0 used to be
called "text mode" was an historic mistake, and was given
that name by a Unix-head who wouldn't know the difference
between text and binary mode if it suck its teeth in their
posterior and tore off an entire bloody buttock :-)

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

Comment By: Terry J. Reedy (tjreedy)
Date: 2006-03-06 14:03

Message:
Logged In: YES 
user_id=593130

Any text file written with /r/n in Windows can have 
problems when read on *nix or Mac or ???, so this problem 
is not specific to pickle or even to Python.  I am under 
the impression that the new universal newline support was 
intended to fix such problems (when used).  But as a Win-
only user (currently) I have no experience with it.

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2006-03-06 10:12

Message:
Logged In: YES 
user_id=984087


There seems to be a mistane in my earlier comment. I meant
the unpickling on *UNIX* fails even if ASCII was used on
windows.

Raghu.

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2006-03-06 10:11

Message:
Logged In: YES 
user_id=984087


Hi,

The point is that even if ASCII protocol is used on
windows(as I was), the unpickling process would fail on
windows. So the pickle file should be opened in binary mode
on windows even for ASCII protocol. This may make reading
the file in notepad difficult but then, cross platform
support should take precedence, I suppose. Another option
would be for python to do line end translations for ASCII
pickle files. 

Raghu.


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

Comment By: Terry J. Reedy (tjreedy)
Date: 2006-03-05 22:36

Message:
Logged In: YES 
user_id=593130

For ASCII protocol pickles, intended for human 
readability, one should use text mode to be able to read 
the file, for instance, in Notepad.

For either binary protocol, I would think binary mode 
should be best even to reread on Windows.  If anything is 
added, I would put
"On Windows, open files in a mode (text/binary) that 
matches the protocol."
at the bottom of http://docs.python.org/lib/node64.html

Looking forward to 3.0, when file mode might be more 
significant (text/binary corresponding to unicode/bytes), 
the "for windoews' qualifier might be omitted, but this 
might be premature.

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

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

From noreply at sourceforge.net  Mon Mar  6 21:41:06 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 06 Mar 2006 12:41:06 -0800
Subject: [ python-Bugs-1442874 ] handling comments with markupbase and
	HTMLParser
Message-ID: <E1FGMVu-0005zc-Uq@sc8-sf-web5.sourceforge.net>

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

Please note that this message 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: 3
Submitted By: Daniel (danielx_)
Assigned to: Nobody/Anonymous (nobody)
Summary: handling comments with markupbase and HTMLParser

Initial Comment:
If the following webpage is correct about the
definition of a comment, HTMLParser.HTMLParser reports
valid (albiet strange) comments as being erroenous:

http://www.htmlhelp.com/reference/wilbur/misc/comment.html

This site gives '<!>' as an example of a valid html
comment. See attachment for what happens at the
console. A similar thing happens with other
(pathalogical) form of comments.

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

Comment By: Jim Jewett (jimjjewett)
Date: 2006-03-06 15:41

Message:
Logged In: YES 
user_id=764593

I recommend this as a wontfix.  

As the page itself notes, browsers generally got this 
wrong, and existing webpages rely on this buggy behavior.  
Even today, Opera is going back and forth on how right they 
can afford to be without breaking too many pages.

The suggestion at the bottom of the page notes that if you 
keep your comments sane, you won't have problems on your 
own pages.  Realistically, anything not following that rule 
(no embedded -- or >) is effectively buggy, and HTMLParser 
can only guess at the real intention.


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

Comment By: Daniel (danielx_)
Date: 2006-03-03 22:17

Message:
Logged In: YES 
user_id=1383230

Sorry, I'm unfamiliar with the bug reporting system and my
attachment doesn't seem to have attached.

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

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

From noreply at sourceforge.net  Mon Mar  6 21:48:30 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 06 Mar 2006 12:48:30 -0800
Subject: [ python-Bugs-1444408 ] subprocess test cases fail with
	noexec-mounted /tmp
Message-ID: <E1FGMd4-000199-DP@sc8-sf-web6.sourceforge.net>

Bugs item #1444408, was opened at 2006-03-06 21:48
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Wummel (calvin)
Assigned to: Nobody/Anonymous (nobody)
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


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

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

From noreply at sourceforge.net  Tue Mar  7 00:47:01 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 06 Mar 2006 15:47:01 -0800
Subject: [ python-Bugs-1441486 ] yet another svn head compiler change
Message-ID: <E1FGPPp-0003bp-SK@sc8-sf-web6.sourceforge.net>

Bugs item #1441486, was opened at 2006-03-02 00:39
Message generated for change (Comment added) made by logistix
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: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Nobody/Anonymous (nobody)
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: Grant Olson (logistix)
Date: 2006-03-06 17: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  Tue Mar  7 04:24:16 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 6 Mar 2006 19:24:16 -0800
Subject: [ python-Bugs-1389157 ] test_tarfile fails with readonly source dir
	for Python 2.4.2
Message-ID: <200603070324.k273OG5U019119@sc8-sf-db2-new-b.sourceforge.net>

Bugs item #1389157, was opened at 12/23/05 13:29
Message generated for change (Settings changed) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1389157&group_id=5470

Please note that this 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: Langly (langly)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_tarfile fails with readonly source dir for Python 2.4.2

Initial Comment:
When compiling Python-2.4.2 and using separate source
and build directories, the test_tarfile test fails if
the source directory is read-only.

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

>Comment By: SourceForge Robot (sf-robot)
Date: 03/06/06 19:24

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 (birkenfeld)
Date: 01/05/06 05:54

Message:
Logged In: YES 
user_id=1188172

How do you compile Python using separate source and build
directories?

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

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

From noreply at sourceforge.net  Tue Mar  7 04:24:36 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 6 Mar 2006 19:24:36 -0800
Subject: [ python-Bugs-1393109 ] cannot build SVN trunk on old systems
Message-ID: <200603070324.k273Oavq019131@sc8-sf-db2-new-b.sourceforge.net>

Bugs item #1393109, was opened at 12/29/05 12:25
Message generated for change (Settings changed) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1393109&group_id=5470

Please note that this 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: None
Priority: 5
Submitted By: Fredrik Lundh (effbot)
Assigned to: Nobody/Anonymous (nobody)
Summary: cannot build SVN trunk on old systems

Initial Comment:
Parser/asdl_c.py uses "/usr/bin/env python" to
find a proper python, but the script don't work
on old Pythons (at least it fails on 2.1 and
older).

iirc, various solutions to this were discussed on
python-dev, but nobody seems to have done anything
about it.

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

>Comment By: SourceForge Robot (sf-robot)
Date: 03/06/06 19:24

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: 01/11/06 14:47

Message:
Logged In: YES 
user_id=21627

Is this still a problem? Parser/asdl_c.py should not
normally be invoked, unless you edit the grammar

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

Comment By: Neal Norwitz (nnorwitz)
Date: 01/01/06 20:31

Message:
Logged In: YES 
user_id=33168

One issue I see in asdl.py is that new-style classes are
used.  I don't know if they are really necessary.  You could
try adding something like this to the top of asdl.py and see
if that fixes things:

try:
  object
except NameError:
  class object: pass

Or maybe we just shouldn't make them new-style if that does
fix things.  I don't have an old version of python around.

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

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

From noreply at sourceforge.net  Tue Mar  7 04:24:47 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 6 Mar 2006 19:24:47 -0800
Subject: [ python-Bugs-729236 ] building readline module fails on Irix 6.5
Message-ID: <200603070324.k273OlpU019139@sc8-sf-db2-new-b.sourceforge.net>

Bugs item #729236, was opened at 04/28/03 16:03
Message generated for change (Settings changed) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729236&group_id=5470

Please note that this 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.3
>Status: Closed
Resolution: None
Priority: 5
Submitted By: alexandre gillet (gillet)
Assigned to: Nobody/Anonymous (nobody)
Summary: building readline module fails on Irix 6.5

Initial Comment:
I am trying to build  Python2.3b1 on a sgi Irix 6.5 using
MIPSpro Compilers: Version 7.30

I can't get the readline module to build. I get the
following error:
cc  -OPT:Olimit=0 -DNDEBUG -O -I. -I../Include 
-I/mgl/prog/share/include/ -c ../Modules/readline.c -o
Modules/readline.o
cc-1119 cc: ERROR File = ../Modules/readline.c, Line = 587
  The &quot;return&quot; expression type differs from the
function return type.

        return completion_matches(text, *on_completion);
               ^

cc-1552 cc: WARNING File = ../Modules/readline.c, Line
= 732
  The variable &quot;m&quot; is set but never used.

        PyObject *m;
                  ^

1 error detected in the compilation of
&quot;../Modules/readline.c&quot;.
gmake: *** [Modules/readline.o] Error 2


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

>Comment By: SourceForge Robot (sf-robot)
Date: 03/06/06 19:24

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 (birkenfeld)
Date: 02/20/06 01:15

Message:
Logged In: YES 
user_id=1188172

Is this still the case with Python 2.4?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 05/21/03 16:49

Message:
Logged In: YES 
user_id=33168

Is HAVE_RL_COMPLETION_MATCHES defined?  If so is
rl_completion_matches() defined to return char ** in
readline.h?  If HAVE_* is not defined, where is
completion_matches() defined and what does it return?

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

Comment By: alexandre gillet (gillet)
Date: 05/12/03 11:02

Message:
Logged In: YES 
user_id=150999

I was able to compile readline on Irix after changing the
function flex_complete. the function prototyte say it should
return a char** .So we did put the following change and it
works. Is it a right way to do it?

** readline.c  2003-05-09 13:45:38.000000000 -0700
--- readline.c~ 2003-03-01 07:19:41.000000000 -0800
***************
*** 577,589 ****
  /* A more flexible constructor that saves the &quot;begidx&quot; and
&quot;endidx&quot;
   * before calling the normal completer */

! static char ** flex_complete(char *text, int start, int end)
  {
        Py_XDECREF(begidx);
        Py_XDECREF(endidx);
        begidx = PyInt_FromLong((long) start);
        endidx = PyInt_FromLong((long) end);
!       return (char **)completion_matches(text,
*on_completion);
  }


--- 577,590 ----
  /* A more flexible constructor that saves the &quot;begidx&quot; and
&quot;endidx&quot;
   * before calling the normal completer */

! static char **
! flex_complete(char *text, int start, int end)
  {
        Py_XDECREF(begidx);
        Py_XDECREF(endidx);
        begidx = PyInt_FromLong((long) start);
        endidx = PyInt_FromLong((long) end);
!       return completion_matches(text, *on_completion);
  }











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

Comment By: alexandre gillet (gillet)
Date: 05/12/03 10:44

Message:
Logged In: YES 
user_id=150999

My readline version is 4.3

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

Comment By: Martin v. L??wis (loewis)
Date: 04/29/03 04:44

Message:
Logged In: YES 
user_id=21627

What is your readline version?

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

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

From noreply at sourceforge.net  Tue Mar  7 04:25:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 6 Mar 2006 19:25:05 -0800
Subject: [ python-Bugs-1212703 ] Python 2.5 CVS broken for HP-UX platform?
Message-ID: <200603070325.k273P5WA019417@sc8-sf-db2-new-b.sourceforge.net>

Bugs item #1212703, was opened at 06/01/05 06:05
Message generated for change (Settings changed) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212703&group_id=5470

Please note that this 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: Vincent Jamart (ranma)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.5 CVS broken for HP-UX platform?

Initial Comment:
While trying to compile Python 2.5 from the nighlty CVS
image, it raises the following errors on HP-UX. (OS
version= HP-UX 11.22 on ia64, compiler= aCC: HP
aC++/ANSI C B3910B A.06.00 [Aug 25 2004])

Compilation flags:
export CC=aCC
export CFLAGS="-Ae +DD64"
export LDFLAGS="+DD64"
make clean
./configure --prefix=/usr/local/python_cvs --with-cxx=aCC


(...)
creating Makefile
        aCC -c  -DNDEBUG -O  -I. -I./Include  
-DPy_BUILD_CORE -o
Modules/ccpython.o ./Modules/ccpython.cc
"/usr/include/sys/unistd.h", line 594: warning #2837-D:
omission of
explicit
          type is nonstandard ("int" assumed)
  inline truncate(const char *a, off_t b)       { return
__truncate64(a,b); }
         ^
 
"/usr/include/sys/unistd.h", line 595: warning #2837-D:
omission of
explicit
          type is nonstandard ("int" assumed)
  inline prealloc(int a, off_t b)               { return
__prealloc64(a,b); }
         ^
 
"/usr/include/sys/unistd.h", line 596: warning #2837-D:
omission of
explicit
          type is nonstandard ("int" assumed)
  inline lockf(int a, int b, off_t c)           { return
__lockf64(a,b,c); }
         ^
 
"/usr/include/sys/unistd.h", line 597: warning #2837-D:
omission of
explicit
          type is nonstandard ("int" assumed)
  inline ftruncate(int a, off_t b)              { return
__ftruncate64(a,b); }
         ^
 
"/usr/include/sys/stat.h", line 173: warning #2837-D:
omission of
explicit
          type is nonstandard ("int" assumed)
       inline lstat __((const char *, struct stat *));
              ^
 
"./Include/pyport.h", line 612: error #2035: #error
directive: "LONG_BIT
          definition appears wrong for platform (bad
gcc/glibc
config?)."
  #error "LONG_BIT definition appears wrong for
platform (bad gcc/glibc
config?)."
   ^
 
1 error detected in the compilation of
"./Modules/ccpython.cc".
*** Error exit code 2
 
Stop.
        aCC -c  -DNDEBUG -O  -I. -I./Include  
-DPy_BUILD_CORE -o
Modules/ccpython.o ./Modules/ccpython.cc
"/usr/include/sys/unistd.h", line 594: warning #2837-D:
omission of
explicit
          type is nonstandard ("int" assumed)
  inline truncate(const char *a, off_t b)       { return
__truncate64(a,b); }
         ^
 
"/usr/include/sys/unistd.h", line 595: warning #2837-D:
omission of
explicit
          type is nonstandard ("int" assumed)
  inline prealloc(int a, off_t b)               { return
__prealloc64(a,b); }
         ^
 
"/usr/include/sys/unistd.h", line 596: warning #2837-D:
omission of
explicit
          type is nonstandard ("int" assumed)
  inline lockf(int a, int b, off_t c)           { return
__lockf64(a,b,c); }
         ^
 
"/usr/include/sys/unistd.h", line 597: warning #2837-D:
omission of
explicit
          type is nonstandard ("int" assumed)
  inline ftruncate(int a, off_t b)              { return
__ftruncate64(a,b); }
         ^
 
"/usr/include/sys/stat.h", line 173: warning #2837-D:
omission of
explicit
          type is nonstandard ("int" assumed)
       inline lstat __((const char *, struct stat *));
              ^
 
"./Include/pyport.h", line 612: error #2035: #error
directive: "LONG_BIT
          definition appears wrong for platform (bad
gcc/glibc
config?)."
  #error "LONG_BIT definition appears wrong for
platform (bad gcc/glibc
config?)."
   ^
 
1 error detected in the compilation of
"./Modules/ccpython.cc".
*** Error exit code 2
 
Stop.

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

>Comment By: SourceForge Robot (sf-robot)
Date: 03/06/06 19:24

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: Anthony Baxter (anthonybaxter)
Date: 09/19/05 23:32

Message:
Logged In: YES 
user_id=29957

As far as I know, the patches contributed by Elemental
Security make current CVS HEAD work fine on ia64 HP/UX.
Please do test them, though - I think Guido put some notes
in the toplevel README about how to get the build to work.


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

Comment By: Neal Norwitz (nnorwitz)
Date: 09/19/05 23:21

Message:
Logged In: YES 
user_id=33168

I think there was a fix checked in recently to address some
(hopefully all) of these issues.  Does the current CVS build
on your HPUX box?

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

Comment By: Vincent Jamart (ranma)
Date: 06/28/05 23:50

Message:
Logged In: YES 
user_id=150220

This is how we managed to solve the problem here, but it's
not a clean solution:

#install script for HP-UX 11.xx
CPPFLAGS="+DD64 -I/usr/local/bzip2-1.0.3/include"
export CPPFLAGS
CC="/opt/aCC/bin/aCC -Ae +DD64"
export CC
CFLAGS="-Ae +DD64"
export CFLAGS
CXX="/opt/aCC/bin/aCC -Ae"
export CXX
CXXFLAGS="-Ae +DD64"
export CXXFLAGS
LDFLAGS="+DD64 -L/usr/local/bzip2-1.0.3/lib"
export LDFLAGS
cd dist/src
#
# Do not use the --without-gcc flag because the CC env.var.
will be
# reset to 'cc' (which do not want)
# Additionally we're not using --with-cxx because we want
the system to use
# the CC as it is defined above. The reason is that
apparantly CFLAGS is not
# taken into account thus all options should go into the
definition of CC
#
./configure --prefix=/usr/local/python --without-threads
#
# Finally after the configure we need to edit the resulting
Makefile
# by hand because 'ld' will be used to link the extension
modules. However
# 'ld' does not know the '+DD64' flag and we should link
with aCC instead.
# However there is no way to ask 'configure' to link with
aCC instead of ld.

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

Comment By: Vincent Jamart (ranma)
Date: 06/28/05 08:05

Message:
Logged In: YES 
user_id=150220

This is how we managed to solve the problem here, but it's
not a clean solution:

#install script for HP-UX 11.xx
CPPFLAGS="+DD64 -I/usr/local/bzip2-1.0.3/include"
export CPPFLAGS
CC="/opt/aCC/bin/aCC -Ae +DD64"
export CC
CFLAGS="-Ae +DD64"
export CFLAGS
CXX="/opt/aCC/bin/aCC -Ae"
export CXX
CXXFLAGS="-Ae +DD64"
export CXXFLAGS
LDFLAGS="+DD64 -L/usr/local/bzip2-1.0.3/lib"
export LDFLAGS
cd dist/src
#
# Do not use the --without-gcc flag because the CC env.var.
will be
# reset to 'cc' (which do not want)
# Additionally we're not using --with-cxx because we want
the system to use
# the CC as it is defined above. The reason is that
apparantly CFLAGS is not
# taken into account thus all options should go into the
definition of CC
#
./configure --prefix=/usr/local/python --without-threads
#
# Finally after the configure we need to edit the resulting
Makefile
# by hand because 'ld' will be used to link the extension
modules. However
# 'ld' does not know the '+DD64' flag and we should link
with aCC instead.
# However there is no way to ask 'configure' to link with
aCC instead of ld.

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

Comment By: Anthony Baxter (anthonybaxter)
Date: 06/19/05 02:01

Message:
Logged In: YES 
user_id=29957

It's not clear from your message - did you find a fix for
this? It seems like this should be closed as notabug...



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

Comment By: Vincent Jamart (ranma)
Date: 06/16/05 03:09

Message:
Logged In: YES 
user_id=150220

We nailed down the problem. 
Apparantly the option "+DD64" is not used by 'make'. 
Nevertheless we added this to CPPFLAGS and CFLAGS. 

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

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

From noreply at sourceforge.net  Tue Mar  7 04:25:18 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 6 Mar 2006 19:25:18 -0800
Subject: [ python-Bugs-1002465 ] MemoryError on AIX52
Message-ID: <200603070325.k273PIo0019429@sc8-sf-db2-new-b.sourceforge.net>

Bugs item #1002465, was opened at 08/03/04 01:04
Message generated for change (Settings changed) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002465&group_id=5470

Please note that this 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.3
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Datranet (richardjmason)
Assigned to: Nobody/Anonymous (nobody)
Summary: MemoryError on AIX52

Initial Comment:
I found the orginal problem when trying to send large 
email attachments on AIX 5.2. I tracked the issue down 
to the fact that a string can only grow to a very 
restricted size on AIX 5.2. bin2ascii fails at the pint the 
function tries to join the list togther to form 1 string.

I wrote the following test program to prove the issue:

a = ''
cnt = 0

while cnt < 1024:
 a = a + 'x'
 cnt += 1

c = ''
cnt = 0

while cnt < 1024:
 c = c + a
 cnt += 1

b = ''
cnt2 = 0

while 1:
   b = b + c
   cnt2 += 1
   print cnt2

On AIX 5.2 you get a MemoryError with a cnt2 value of 
42. I can run the test program on all other platforms and 
get a cnt2 value over 150 before stopping to program 
myself.

I have tried the binary python 2.2 from the IBM site and 
building python 2.3.4 myself using the gcc from the IBM 
site. Both fail with a cnt2 value of 42.

Can anyone please advise on how to get AIX 5.2 to 
allow single objects to have more memory allocated.

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

>Comment By: SourceForge Robot (sf-robot)
Date: 03/06/06 19:25

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: Neal Norwitz (nnorwitz)
Date: 10/02/05 22:23

Message:
Logged In: YES 
user_id=33168

richardjmason, are you still having this problem?

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

Comment By: Michael Hudson (mwh)
Date: 08/05/04 04:59

Message:
Logged In: YES 
user_id=6656

A way this has happened in the past is calling "malloc(0)",
which is entitled to return NULL and Python then thinks this
is a memory error.  This doesn't seeme especially likely
here, though.  Agree with Martin that you're probably going
to need to use a debugger.

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

Comment By: Martin v. L??wis (loewis)
Date: 08/04/04 11:09

Message:
Logged In: YES 
user_id=21627

You need to use a debugger to find the cause of the problem.
What is the string parameter of the MemoryError? This might
give a clue where precisely it is raised.

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

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

From noreply at sourceforge.net  Tue Mar  7 04:25:34 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 6 Mar 2006 19:25:34 -0800
Subject: [ python-Bugs-962918 ] 2.3.4 can not be installed over 2.3.3
Message-ID: <200603070325.k273PYdF019439@sc8-sf-db2-new-b.sourceforge.net>

Bugs item #962918, was opened at 05/29/04 14:54
Message generated for change (Settings changed) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=962918&group_id=5470

Please note that this 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.3
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Jarek Zgoda (zgoda)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.3.4 can not be installed over 2.3.3

Initial Comment:
When trying to install newly-compiled 2.3.4 over
existing 2.3.3 I ran into "libinstall error" on
zipfile.py. After removing whole /usr/lib/python2.3 and
installing from scratch the installation was succesful.
I think it's some omission from installer script, since
I didn't have any problem when I upgraded 2.3.0 to
2.3.2 ant thet to 2.3.3.

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

>Comment By: SourceForge Robot (sf-robot)
Date: 03/06/06 19:25

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 (birkenfeld)
Date: 02/20/06 02:18

Message:
Logged In: YES 
user_id=1188172

Are you still having problems with 2.4?

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

Comment By: Jarek Zgoda (zgoda)
Date: 05/31/04 23:59

Message:
Logged In: YES 
user_id=92222

System is Slackware Linux 9.1/2.6.6, Python 2.3.3 (version
that I tried to overwrite) was compiled by me on the same
machine.
Error message was as I wrote: "libinstall error". Command
chain was very usual: 
./configure --prefix=/usr --disable-ipv6
make
make test
make install
Error was raised during last step, the very last entry
before error occured on the list of installed libraries was
zipfile.py.

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

Comment By: Martin v. L??wis (loewis)
Date: 05/31/04 14:09

Message:
Logged In: YES 
user_id=21627

What operating system are you using? Can you report the
precise wording of the error that you get, and the command
that you have invoked to trigger this error?

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

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

From noreply at sourceforge.net  Tue Mar  7 04:25:43 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 6 Mar 2006 19:25:43 -0800
Subject: [ python-Bugs-1188231 ] Rebuilding from source on RH9 fails
	(_tkinter.so missing)
Message-ID: <200603070325.k273Ph2w019447@sc8-sf-db2-new-b.sourceforge.net>

Bugs item #1188231, was opened at 04/22/05 11:21
Message generated for change (Settings changed) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1188231&group_id=5470

Please note that this 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: Marty Heyman (mheyman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Rebuilding from source on RH9 fails (_tkinter.so missing)

Initial Comment:
On a Red Hat 9 system, I downloaded the python2.4-2.4.
1-1pydotorg.src.rpm and, following the web page ran "rpm --rebuild .
..". It went a long for a good long while with no apparent errors and 
then said:

---

RPM build errors:
   File not found by glob: /var/tmp/python2.4-2.4.
1-root/usr/lib/python2.4/lib-dynload/_tkinter.so*

---
I looked in the directory and there is, in fact, no _tkinter.so file(s) 
there. 

--
Marty Heyman

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

>Comment By: SourceForge Robot (sf-robot)
Date: 03/06/06 19:25

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 (birkenfeld)
Date: 02/20/06 02:25

Message:
Logged In: YES 
user_id=1188172

This looks like it is not Python's fault.

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

Comment By: green-ghost (green-ghost)
Date: 07/30/05 08:35

Message:
Logged In: YES 
user_id=1321225

I had a similar problem compiling python from source on a
(nominally) redhat8 system.  For whatever reason, X11
headers were not installed (probably because it's a server I
only use from an ssh console). YMMV

Try:
apt-get install XFree86-devel
or:
rpm -i XFree86-devel-<correct version for your dist>.rpm

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

Comment By: Martin v. L??wis (loewis)
Date: 05/02/05 14:16

Message:
Logged In: YES 
user_id=21627

Ah, so it seems you are lacking the X11 header files. They
should have been installed as a dependency on the Tk
headers. So this is either a Redhat bug (for not including a
dependency of the -dev packages) or a local misconfiguration
of some kind (e.g. forcefully installing Tk headers without
all prerequisites present).

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

Comment By: Marty Heyman (mheyman)
Date: 04/22/05 11:42

Message:
Logged In: YES 
user_id=421967

APOLOGIES: ADDITIONAL INFO FOLLOWS 
---Snip from rebuild output follows
In file included from
/usr/src/redhat/BUILD/Python-2.4.1/Modules/_tkinter.c:67:
/usr/include/tk.h:83:29: X11/Xlib.h: No such file or directory
In file included from
/usr/src/redhat/BUILD/Python-2.4.1/Modules/_tkinter.c:67:
/usr/include/tk.h:581: parse error before "Bool"
/usr/include/tk.h:583: parse error before "event"
/usr/include/tk.h:584: parse error before "root"
/usr/include/tk.h:585: parse error before "subwindow"
/usr/include/tk.h:586: parse error before "time"
/usr/include/tk.h:586: `time' redeclared as different kind
of symbol
/usr/include/time.h:184: previous declaration of `time'
/usr/include/tk.h:591: parse error before "same_screen"
--- snip ends
many more "parse error lines occurred after this. I doubt
they're interesting .
A bit later, another group of failures begins
--Snip starts
In file included from /usr/include/tk.h:1361,
                 from
/usr/src/redhat/BUILD/Python-2.4.1/Modules/_tkinter.c:67:
/usr/include/tkDecls.h:37: parse error before '*' token
/usr/include/tkDecls.h:39: parse error before "Tk_3DBorderGC"
/usr/include/tkDecls.h:45: parse error before "Drawable"
/usr/include/tkDecls.h:50: parse error before "Drawable"
/usr/include/tkDecls.h:58: parse error before "XEvent"
--Snip ends
   Again, there are many more similar messages following
those and then:
--Snip starts
/usr/include/tkDecls.h:843: `GC' declared as function
returning a function
... [parse errors]
/usr/include/tkDecls.h:906: `Font' declared as function
returning a function
--Snip ends
There are many such embedded in that group. Then the
messages stop followed by a line that says: "running
build_scripts" ... and things proceed as if all was OK for
hundreds more lines of output before the failure copied into
the original report.

I captured the complete log and can upload it if needed on
request. I'd need to trim it and it doesn't look all that
interesting otherwise but then, what do I know :-)


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

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

From noreply at sourceforge.net  Tue Mar  7 04:26:02 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 6 Mar 2006 19:26:02 -0800
Subject: [ python-Bugs-1071597 ] configure problem on HP-UX 11.11
Message-ID: <200603070326.k273Q2BC019520@sc8-sf-db2-new-b.sourceforge.net>

Bugs item #1071597, was opened at 11/23/04 02:30
Message generated for change (Settings changed) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071597&group_id=5470

Please note that this 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: Harri Pasanen (harripasanen)
Assigned to: Nobody/Anonymous (nobody)
Summary: configure problem on HP-UX 11.11

Initial Comment:
Python 2.4c1 has this problem (but if I recall, so did 2.3.3)_ 
 
Using gcc 3.3.3 to build on HP-UX 11.11, the  
configure out of the box is a bit off, resulting in a failed build, due 
to missing thread symbols: 
 
/usr/ccs/bin/ld: Unsatisfied symbols: 
   PyThread_acquire_lock (first referenced in 
libpython2.4.a(import.o)) (code) 
   PyThread_exit_thread (first referenced in 
libpython2.4.a(threadmodule.o)) (code) 
   PyThread_allocate_lock (first referenced in 
libpython2.4.a(import.o)) (code) 
   PyThread_free_lock (first referenced in 
libpython2.4.a(threadmodule.o)) (code) 
   PyThread_start_new_thread (first referenced in 
libpython2.4.a(threadmodule.o)) (code) 
   PyThread_release_lock (first referenced in 
libpython2.4.a(import.o)) (code) 
   PyThread_get_thread_ident (first referenced in 
libpython2.4.a(import.o)) (code) 
   PyThread__init_thread (first referenced in 
libpython2.4.a(thread.o)) (code) 
collect2: ld returned 1 exit status 
 
A workaround is to manually edit pyconfig.h, adding  
#define _POSIX_THREADS 
 
(The reason it is not picked up is that unistd.h on HP-UX has this 
comment: 
 
/************************************************************************ 
 * The following defines are specified in the standard, but are not 
yet 
 * implemented: 
 * 
 *        _POSIX_THREADS                     can't be defined until all 
 *                                           features are implemented 
) 
 
The implementation seems however to be sufficiently complete 
to permit compiling and running Python with _POSIX_THREADS. 
 
While I'm editing pyconfig.h, I also comment out 
_POSIX_C_SOURCE definition, as it will result in lots of 
compilation warnings, of the style: 
 
gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall 
-Wstrict-prototypes -I. -I../Python-2.4c1/Include  
-DPy_BUILD_CORE -o 
Objects/frameobject.o ../Python-2.4c1/Objects/frameobject.c 
In file included from ../Python-2.4c1/Include/Python.h:8, 
                 from ../Python-2.4c1/Objects/frameobject.c:4: 
pyconfig.h:835:1: warning: "_POSIX_C_SOURCE" redefined 
<command line>:6:1: warning: this is the location of the 
previous definition 
 
------------ 
 
So, to recapitulate:  After configure, add  
#define _POSIX_THREADS 
and comment out 
#define _POSIX_C_SOURCE 200112L 
 
That will give you a Python working rather well,  
with "make test" producing: 
 
251 tests OK. 
1 test failed: 
    test_pty 
38 tests skipped: 
    test_aepack test_al test_applesingle test_bsddb 
test_bsddb185 
    test_bsddb3 test_cd test_cl test_codecmaps_cn 
test_codecmaps_hk 
    test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw 
test_curses 
    test_dl test_gdbm test_gl test_imgfile test_largefile 
    test_linuxaudiodev test_locale test_macfs test_macostools 
test_nis 
    test_normalization test_ossaudiodev test_pep277 test_plistlib 
    test_scriptpackages test_socket_ssl test_socketserver 
    test_sunaudiodev test_tcl test_timeout test_urllib2net 
    test_urllibnet test_winreg test_winsound 
1 skip unexpected on hp-ux11: 
    test_tcl 
 
 
 

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

>Comment By: SourceForge Robot (sf-robot)
Date: 03/06/06 19:25

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 (birkenfeld)
Date: 02/20/06 02:27

Message:
Logged In: YES 
user_id=1188172

cbeatley: your problem should be fixed as the pwd module is
now builtin.

OP: do you still have problems with recent releases?

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

Comment By: Cameron Beatley (cbeatley)
Date: 06/15/05 13:18

Message:
Logged In: YES 
user_id=991535

I have the same problems. When I edit the pyconfig.h file as 
described and run Make again, I get the following

Traceback (most recent call last):
  File "./setup.py", line 1184, in ?
    main()
  File "./setup.py", line 1178, in main
    scripts = ['Tools/scripts/pydoc', 'Tools/scripts/idle',
  File "/CVS/apps/Python-2.4.1/Lib/distutils/core.py", line 
123, in setup
    dist.parse_config_files()
  File "/CVS/apps/Python-2.4.1/Lib/distutils/dist.py", line 339, 
in parse_config_files
    filenames = self.find_config_files()
  File "/CVS/apps/Python-2.4.1/Lib/distutils/dist.py", line 302, 
in find_config_files
    check_environ()
  File "/CVS/apps/Python-2.4.1/Lib/distutils/util.py", line 155, 
in check_environ
    import pwd
ImportError: No module named pwd
*** Error exit code 1


any idea what THIS is?

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

Comment By: Harri Pasanen (harripasanen)
Date: 01/06/05 03:01

Message:
Logged In: YES 
user_id=77088

Note that the _POSIX_C_SOURCE is also defined for gcc 3.4.3 on 
HP-UX 11.23 (Itanium).   I don't know if it defined for all the gcc 
platforms, as it would only show up if the definition in pyconfig.h is 
different from what the gcc driver uses. 

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

Comment By: Harri Pasanen (harripasanen)
Date: 01/05/05 06:46

Message:
Logged In: YES 
user_id=77088

_POSIX_C_SOURCE appears to come from the gcc driver, along with a 
few other macros. 
 
If I add "-v" to compilation, the output expands to: 
 
Reading specs 
from /usr/local/lib/gcc-lib/hppa2.0w-hp-hpux11.11/3.3.3/specs 
Configured 
with: /scratch/zack/pkgbuild/3.3.1/hpux-11/gcc-3.3.3/configure 
--enable-languages=c,c++ --enable-threads=posix --disable-nls 
--with-gnu-as --without-gnu-ld --with-as=/usr/local/bin/as 
--prefix=/usr/local 
Thread model: posix 
gcc version 3.3.3 
 /usr/local/lib/gcc-lib/hppa2.0w-hp-hpux11.11/3.3.3/cc1 -quiet -v -I. 
-I./Include -D__GNUC__=3 -D__GNUC_MINOR__=3 
-D__GNUC_PATCHLEVEL__=3 -D_REENTRANT -D_THREAD_SAFE 
-D_POSIX_C_SOURCE=199506L -DNDEBUG -DPy_BUILD_CORE 
Modules/python.c -quiet -dumpbase python.c -auxbase-strip 
Modules/python.o -g -O3 -Wall -Wstrict-prototypes -version 
-fno-strict-aliasing -o /var/tmp//ccLnAhZ0.s 
GNU C version 3.3.3 (hppa2.0w-hp-hpux11.11) 
        compiled by GNU C version 3.3.3. 
GGC heuristics: --param ggc-min-expand=100 --param 
ggc-min-heapsize=131072 
ignoring nonexistent directory 
"/usr/local/hppa2.0w-hp-hpux11.11/include" 
#include "..." search starts here: 
#include <...> search starts here: 
 . 
 Include 
 /usr/local/include 
 /usr/local/lib/gcc-lib/hppa2.0w-hp-hpux11.11/3.3.3/include 
 /usr/include 
End of search list. 
In file included from Include/Python.h:8, 
                 from Modules/python.c:3: 
pyconfig.h:835:1: warning: "_POSIX_C_SOURCE" redefined 
<command line>:6:1: warning: this is the location of the previous 
definition 
 /usr/local/bin/as --traditional-format -o 
Modules/python.o /var/tmp//ccLnAhZ0.s 
 

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

Comment By: Martin v. L??wis (loewis)
Date: 12/23/04 15:50

Message:
Logged In: YES 
user_id=21627

Can you find out why gcc says that "_POSIX_C_SOURCE" is
defined on the command line? On the command line you
provide, it isn't.

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

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

From noreply at sourceforge.net  Tue Mar  7 04:28:28 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 6 Mar 2006 19:28:28 -0800
Subject: [ python-Bugs-820953 ] dbm Error
Message-ID: <200603070328.k273SSBY020479@sc8-sf-db2-new-b.sourceforge.net>

Bugs item #820953, was opened at 10/09/03 16:13
Message generated for change (Settings changed) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=820953&group_id=5470

Please note that this 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.2.3
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Jim Gifford (giffordj)
Assigned to: Nobody/Anonymous (nobody)
Summary: dbm Error

Initial Comment:
Receive the following error during make install of python 
2.3.2. Any suggestions or is it safe to ignore.

building 'dbm' extension
gcc -pthread -DNDEBUG -g -march=pentium2 -mmmx -
O2 -pipe -Wall -Wstrict-prototypes -fPIC -fno-strict-
aliasing -DHAVE_NDBM_H -I. -I/usr/src/Python-
2.3.2/./Include -I/usr/local/include -I/usr/src/Python-
2.3.2/Include -I/usr/src/Python-2.3.2 -
c /usr/src/Python-2.3.2/Modules/dbmmodule.c -o 
build/temp.linux-i686-2.3/dbmmodule.o
gcc -pthread -shared build/temp.linux-i686-
2.3/dbmmodule.o -L/usr/local/lib -o build/lib.linux-i686-
2.3/dbm.so
*** WARNING: renaming &quot;dbm&quot; since importing it failed: 
build/lib.linux-i686-2.3/dbm.so: undefined symbol: 
dbm_firstkey
running build_scripts


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

>Comment By: SourceForge Robot (sf-robot)
Date: 03/06/06 19:28

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: 02/20/06 07:30

Message:
Logged In: YES 
user_id=849994

Do you still have problems with 2.4?

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

Comment By: Jim Gifford (giffordj)
Date: 10/12/03 00:42

Message:
Logged In: YES 
user_id=492775

Upon further research, when this error occurs installation 
does continue, but libpython2.3.a is never created.

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

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

From noreply at sourceforge.net  Tue Mar  7 04:28:40 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 6 Mar 2006 19:28:40 -0800
Subject: [ python-Bugs-675187 ] bsddb hangs with recno/source sync
Message-ID: <200603070328.k273SeF7020586@sc8-sf-db2-new-b.sourceforge.net>

Bugs item #675187, was opened at 01/26/03 16:01
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675187&group_id=5470

Please note that this message 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: None
Priority: 5
Submitted By: Magnus Lie Hetland (mlh)
Assigned to: Nobody/Anonymous (nobody)
Summary: bsddb hangs with recno/source sync

Initial Comment:
I just tried to use bsddb with the source argument to have
flat 
backing file. Creating a database with such a backing
file as 
source was not problematic, but after I had modified
it, the 
sync() and close() method would hang.

For 
example:

from bsddb import rnopen
r = 
rnopen('test.dat', source='test.txt')
r[1] = 'foobar'
r.sync() 
# Hangs here...

After running this, test.txt will be empty 
(even though it
wasn't before). Running the code above without 
the source
argument works just fine.

I'm running 
Python 2.3 cvs version (slightly earlier than the
first alpha) on 
SunOS 5.9.

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

>Comment By: SourceForge Robot (sf-robot)
Date: 03/06/06 19:28

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: 02/20/06 09:43

Message:
Logged In: YES 
user_id=849994

Cannot reproduce with Python 2.4.

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

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

From noreply at sourceforge.net  Tue Mar  7 04:28:51 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 6 Mar 2006 19:28:51 -0800
Subject: [ python-Bugs-872736 ] Python 2.3.3 urllib proxy support fails
Message-ID: <200603070328.k273Spow020662@sc8-sf-db2-new-b.sourceforge.net>

Bugs item #872736, was opened at 01/07/04 16:20
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=872736&group_id=5470

Please note that this message 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: None
Priority: 5
Submitted By: Eric Johnson (eggsy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.3.3 urllib proxy support fails

Initial Comment:
Using Python 2.3.3 on Win2K and Win98 the urllib module
does not seem to support proxies as described in the
documentation.

I have the http_proxy environment variable set and
urllib2.urlopen can successfully access the web via the
proxy.
Trying urllib.urlopen results in a
IOError: [Errno socket error] (7, 'getaddrinfo failed')
exception which suggests that it is not using the proxy.
This occurs both with an explicit proxy defined and
when using the environment variable.

See attached file for an example script.

I could not see any reference to proxies in the urllib
test script so I wonder whether this has been tested.

I have not (yet) tried to investigate why this does not
work.

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

>Comment By: SourceForge Robot (sf-robot)
Date: 03/06/06 19:28

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: 02/20/06 12:03

Message:
Logged In: YES 
user_id=849994

Proxy support has recently been improved in urllib. Can you
test whether it works now?

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

Comment By: Jim Jewett (jimjjewett)
Date: 01/08/04 07:33

Message:
Logged In: YES 
user_id=764593

Do you need to authenticate to your proxy?

The default getpass will fail instead of asking for a password if 
it thinks there is an eavesdropper - and idle counts as an 
eavesdropper.


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

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

From noreply at sourceforge.net  Tue Mar  7 04:28:47 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 6 Mar 2006 19:28:47 -0800
Subject: [ python-Bugs-815999 ] ImportError: No module named _socket
Message-ID: <200603070328.k273SlEr020642@sc8-sf-db2-new-b.sourceforge.net>

Bugs item #815999, was opened at 10/01/03 10:21
Message generated for change (Settings changed) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815999&group_id=5470

Please note that this 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.3
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Peter Stauffert (stauffert)
Assigned to: Nobody/Anonymous (nobody)
Summary: ImportError: No module named _socket

Initial Comment:
Hi

There is a problem during the installation of python 2.3.1:

I used configure with the following options:
./configure --enable-shared=yes --with-signal-
module=yes --with-cxx=/usr/freeware/bin/c++

make runs to the end, only warning messages are 
displayed.

Running &quot;make test&quot; on a SGI Origin200, IRIX 6.5-18 I 
got the following error message:
test test___all__ failed -- Traceback (most recent call 
last):
  File &quot;/install/fw/Python-2.3.1/Lib/test/test___all__.py&quot;, 
line 54, in test_all
    import _socket
ImportError: No module named _socket

This looks like the python bug 565710 reported for 
python 2.2.1 which was solved by modifications of 
setup.py in the top level directory.

But setup.py was modified in python 2.3.1 and I could 
not apply the old patch to the new version.

Could you help me with this problem?

Thanks a lot

Peter Stauffert


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

>Comment By: SourceForge Robot (sf-robot)
Date: 03/06/06 19:28

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: 02/20/06 11:33

Message:
Logged In: YES 
user_id=849994

OP: Do you still experience problems with 2.4?

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

Comment By: Martin v. L??wis (loewis)
Date: 10/13/03 14:27

Message:
Logged In: YES 
user_id=21627

jemfinch, I very much doubt that you have the same problem
as the submitter of this report, and your Usenet message
gives hardly enough detail to analyse the problem; for
example, the linker error you report has a truncated error
message. Please submit a separate report, and report
precisely what you did, the complete output that you got,
and what exactly isn't working the way you expect it to work.

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

Comment By: Jeremy Fincher (jemfinch)
Date: 10/13/03 07:33

Message:
Logged In: YES 
user_id=99508

If you don't mind, I'll just link you to my comp.lang.python
post about it:

http://groups.google.com/groups?q=group:comp.lang.python+solaris+7&amp;hl=en&amp;lr=&amp;ie=UTF-8&amp;oe=UTF-8&amp;selm=698f09f8.0310100915.359b2e09%40posting.google.com&amp;rnum=9

That has the exact compilation error.  I've tried passing
the --disable-IPV6 option to configure (as MvL mentioned)
and it seemed to compile, but I still don't have access to
the _socket library, probably due to the second error I
mentioned.  I tried the fix in the bug #565710 (adding
runtime_library_dirs to setup.py) but to no avail.

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

Comment By: Anthony Baxter (anthonybaxter)
Date: 10/12/03 22:51

Message:
Logged In: YES 
user_id=29957

Works for me on Solaris 2.6, 7 and 8. What compiler, what
version, what error did you get during the build of
socketmodule?


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

Comment By: Jeremy Fincher (jemfinch)
Date: 10/11/03 04:35

Message:
Logged In: YES 
user_id=99508

I have this same bug on Solaris 7 with 2.3.2.

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

Comment By: Anthony Baxter (anthonybaxter)
Date: 10/03/03 17:24

Message:
Logged In: YES 
user_id=29957

Does the patch available from www.python.org/bugs.html fix
this problem?

Which compiler did you use? From the configure line, above,
it looks like you might be using gcc?


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

Comment By: Martin v. L??wis (loewis)
Date: 10/03/03 06:28

Message:
Logged In: YES 
user_id=21627

Can you please attach the build log? In particular, it would
be importing to see whether building _socket was attempted,
and failed.

Maybe your compiler just doesn't work???

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

Comment By: casey dunn (caseyd)
Date: 10/01/03 12:53

Message:
Logged In: YES 
user_id=878394

I have seen this on Solaris as well, recent and old vintages.

Casey Dunn

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

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

From noreply at sourceforge.net  Tue Mar  7 13:32:03 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 07 Mar 2006 04:32:03 -0800
Subject: [ python-Bugs-713169 ] test_pty fails on HP-UX and AIX when run after
	test_openpty
Message-ID: <E1FGbMB-0007yW-NL@sc8-sf-web6.sourceforge.net>

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

Please note that this 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: Richard Townsend (rptownsend)
Assigned to: Neal Norwitz (nnorwitz)
Summary: test_pty fails on HP-UX and AIX when run after test_openpty

Initial Comment:
Here is the output from test_pty.py:

capulet:dist/src &gt; ./python Lib/test/test_pty.py
Calling master_open()
Got master_fd '3', slave_name '/dev/pts/0'
Calling slave_open('/dev/pts/0')
Got slave_fd '4'
Traceback (most recent call last):
  File &quot;Lib/test/test_pty.py&quot;, line 58, in ?
    test_basic_pty()
  File &quot;Lib/test/test_pty.py&quot;, line 29, in 
test_basic_pty
    if not os.isatty(slave_fd):
  File &quot;Lib/test/test_pty.py&quot;, line 50, in handle_sig
    raise TestFailed, &quot;isatty hung&quot;
test.test_support.TestFailed: isatty hung


This was running Python 2.3a2 (downloaded from 
CVS on Sunday 30th March) built on HP-UX11i.

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

Comment By: Mark Lorenzen (mlorenzen)
Date: 2006-03-07 12:32

Message:
Logged In: YES 
user_id=1469902

I have the same problem with Python 2.4.2 running on AIX 5.2.

The test test_pty hangs for 10 seconds after which it is
aborted by a time-out condition. I have traced the system
calls and it turns out that the following scenario occurs:

1) os.write(slave_fd, TEST_STRING_2[:5])
2) os.write(slave_fd, TEST_STRING_2[5:])
3) s2 = os.read(master_fd, 1024)
[...]
4) os.close(slave_fd)

At 3) we only read the first part of the string written in
1) and not the complete string written in both 1) and 2).
The close() call then hangs in 4) (as it is waiting for
slave_fd to be flushed?).

The solution is to continue reading until a newline
character is read ie. readling a complete line. The patch is
shown below.

*** Lib/test/test_pty.py.orig   2004-02-12 7:35:11.000000000
+0000
--- Lib/test/test_pty.py        2006-03-07 2:05:39.000000000
+0000
***************
*** 40,47 ****
      debug("Writing chunked output")
      os.write(slave_fd, TEST_STRING_2[:5])
      os.write(slave_fd, TEST_STRING_2[5:])
!     s2 = os.read(master_fd, 1024)
!     sys.stdout.write(s2.replace("\r\n", "\n"))
  
      os.close(slave_fd)
      os.close(master_fd)
--- 40,49 ----
      debug("Writing chunked output")
      os.write(slave_fd, TEST_STRING_2[:5])
      os.write(slave_fd, TEST_STRING_2[5:])
!     s2 = "";
!     while not s2 or s2[-1] != "\n":
!         s2 = s2 + os.read(master_fd, 1024)
!     sys.stdout.write(s2.replace("\r\n", "\n"));
  
      os.close(slave_fd)
      os.close(master_fd)


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-20 19:05

Message:
Logged In: YES 
user_id=33168

Can you test with the patch in bug report: 
https://sourceforge.net/tracker/index.php?func=detail&aid=1433877&group_id=5470&atid=105470
?  I wonder if that fixes the problem.  Though I'm not sure
the same code is executed or not.

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

Comment By: Michael Hoffman (hoffmanm)
Date: 2005-01-25 16:29

Message:
Logged In: YES 
user_id=987664

This happens with Python 2.4 on Tru64Unix V5.1 when
compiling using gcc-3.4.3, but not if you use the vendor cc.

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

Comment By: Richard Townsend (rptownsend)
Date: 2004-07-12 08:30

Message:
Logged In: YES 
user_id=200117

This still happens with Python-2.4.0a1 on HP-UX11i


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

Comment By: Mark D. Roth (mdr0)
Date: 2004-03-10 17:22

Message:
Logged In: YES 
user_id=994239

I'm running into this problem under both AIX 4.3.3 and 5.1.
 Is this going to cause a problem if I put python into
produciton, or is it "safe" to ignore it?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-01 16:31

Message:
Logged In: YES 
user_id=33168

Actually, there is a 'fix' which is really a work-around the
problem.  You can disable os.openpty() in pty.master_open. 
I added a raise OSError at line 50 (before os.openpty()). 
This allows the test to pass.  I think Martin and I agreed
that globally disabling wasn't the best solution.  That
would probably be in some patch.

Also, just in case it isn't clear--if you run test_pty
BEFORE test_openpty, both tests pass.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-01 16:02

Message:
Logged In: YES 
user_id=33168

I fixed the test hanging, but not the actual bug.  The bug
appears when running test_pty after test_openpty.  There's
some interaction, but I don't know what it is.  The problem
happens on AIX also.  I searched through some man pages, but
nothing leapt out at me.  I think I tried googling for the
answer to no avail. Any insight or ideas would be helpful. 
This may have started when adding /dev/ptmx (ptc for AIX)
support.

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

Comment By: Michael Hudson (mwh)
Date: 2003-04-01 10:26

Message:
Logged In: YES 
user_id=6656

Neal?  I thought you thought this was fixed?

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

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

From noreply at sourceforge.net  Tue Mar  7 13:48:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 07 Mar 2006 04:48:42 -0800
Subject: [ python-Bugs-1432525 ] os.listdir doesn't release GIL
Message-ID: <E1FGbcI-0000XF-T7@sc8-sf-web6.sourceforge.net>

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

Please note that this 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: Jonathan Ellis (ellisj)
Assigned to: Georg Brandl (gbrandl)
Summary: os.listdir doesn't release GIL

Initial Comment:
posix_listdir in posixmodule.c does not release the
global interpreter lock, blocking all other threads for
the duration of the call.

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

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-07 12:48

Message:
Logged In: YES 
user_id=849994

Committed as rev. 42884.

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-03-03 17:48

Message:
Logged In: YES 
user_id=21627

The patch looks fine. Please apply.

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

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-18 11:13

Message:
Logged In: YES 
user_id=1188172

Attaching a patch. Please check.

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

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

From noreply at sourceforge.net  Tue Mar  7 14:42:47 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 07 Mar 2006 05:42:47 -0800
Subject: [ python-Bugs-1442012 ] Traceback in pydoc
Message-ID: <E1FGcSd-0000aS-3N@sc8-sf-web1.sourceforge.net>

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

Please note that this 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: Duplicate
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
Summary: Traceback in pydoc

Initial Comment:
On some objects I have, calling 'help(obj)' raises an
exception.  Python 2.4.2, Windows XP.

This is the traceback, together with some info from
pdb.pm():

>>> help(r)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\Python24\lib\site.py", line 328, in __call__
    return pydoc.help(*args, **kwds)
  File "c:\python24\lib\pydoc.py", line 1647, in __call__
    self.help(request)
  File "c:\python24\lib\pydoc.py", line 1691, in help
    else: doc(request, 'Help on %s:')
  File "c:\python24\lib\pydoc.py", line 1475, in doc
    pager(title % desc + '\n\n' + text.document(object,
name))
  File "c:\python24\lib\pydoc.py", line 296, in document
    if inspect.isclass(object): return self.docclass(*args)
  File "c:\python24\lib\pydoc.py", line 1193, in docclass
    lambda t: t[1] == 'method')
  File "c:\python24\lib\pydoc.py", line 1143, in spill
    name, mod, object))
  File "c:\python24\lib\pydoc.py", line 301, in document
    return self.docother(*args)
  File "c:\python24\lib\pydoc.py", line 1290, in docother
    chop = maxlen - len(line)
TypeError: unsupported operand type(s) for -:
'_compointer_meta' and 'int'
>>> import pdb
>>> pdb.pm()
> c:\python24\lib\pydoc.py(1290)docother()
-> chop = maxlen - len(line)
(Pdb) args
self = <pydoc.TextDoc instance at 0x00CC0DA0>
object = <comtypes.named_property object at 0x00CA9390>
name = Item
mod = None
maxlen = <class 'comtypes.POINTER(IROIList)'>
doc = None
(Pdb) where
  <stdin>(1)?()
  c:\python24\lib\site.py(328)__call__()
-> return pydoc.help(*args, **kwds)
  c:\python24\lib\pydoc.py(1647)__call__()
-> self.help(request)
  c:\python24\lib\pydoc.py(1691)help()
-> else: doc(request, 'Help on %s:')
  c:\python24\lib\pydoc.py(1477)doc()
-> print value
  c:\python24\lib\pydoc.py(299)document()
-> pass
  c:\python24\lib\pydoc.py(1193)docclass()
-> lambda t: t[1] == 'method')
  c:\python24\lib\pydoc.py(1143)spill()
-> name, mod, object))
  c:\python24\lib\pydoc.py(301)document()
-> return self.docother(*args)
> c:\python24\lib\pydoc.py(1290)docother()
-> chop = maxlen - len(line)
(Pdb)


The problem seems to be that the TextDoc.docother
method is called with unexpected arguments.

The signature is 
docother(object, name, mod, maxlen, doc)

but it is called with the object to document as the
'maxlen' parameter.

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

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-07 13:42

Message:
Logged In: YES 
user_id=849994

This was already fixed in rev. 39636/7 and will be in 2.4.3.

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

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

From noreply at sourceforge.net  Tue Mar  7 14:44:00 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 07 Mar 2006 05:44:00 -0800
Subject: [ python-Bugs-1444408 ] subprocess test cases fail with
	noexec-mounted /tmp
Message-ID: <E1FGcTo-0000eD-7I@sc8-sf-web1.sourceforge.net>

Bugs item #1444408, was opened at 2006-03-06 20:48
Message generated for change (Settings changed) made by gbrandl
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: None
Group: None
Status: Open
Resolution: None
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


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

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

From noreply at sourceforge.net  Tue Mar  7 14:47:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 07 Mar 2006 05:47:46 -0800
Subject: [ python-Bugs-1440831 ] UnicodeWriter: "utf-8" hardcoded instead of
	self.encoding
Message-ID: <E1FGcXS-0000uS-PZ@sc8-sf-web1.sourceforge.net>

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

Please note that this 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: Rodrigo Daunoravicius (rodelrod)
>Assigned to: Georg Brandl (gbrandl)
Summary: UnicodeWriter: "utf-8" hardcoded instead of self.encoding

Initial Comment:
In the Python Library Reference, 12.20.5 Examples.
In the UnicodeReader/UnicodeWriter example.

class UnicodeWriter:
...
|    def writerow(self, row):
|    |    self.writer.writerow([s.encode("utf-8") for s
in row])

should be:

class UnicodeWriter:
...
|    def writerow(self, row):
|    |    self.writer.writerow([s.encode(self.encoding)
for s in row])

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

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-07 13:47

Message:
Logged In: YES 
user_id=849994

Thank you, fixed in rev. 42887.

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

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

From noreply at sourceforge.net  Tue Mar  7 15:39:40 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 07 Mar 2006 06:39:40 -0800
Subject: [ python-Bugs-1444893 ] Pointer freed twice in Py_InitializeEx()
Message-ID: <E1FGdLg-000468-Fw@sc8-sf-web4-b.sourceforge.net>

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

Please note that this 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: athorp (athorp)
Assigned to: Nobody/Anonymous (nobody)
Summary: Pointer freed twice in Py_InitializeEx()

Initial Comment:
saved_locale is freed twice in
pythonrun.c:Py_InitializeEx().

Example code attached.

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

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

From noreply at sourceforge.net  Tue Mar  7 17:32:04 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 07 Mar 2006 08:32:04 -0800
Subject: [ python-Bugs-1437699 ] robotparser crashes if robots.txt contains
	non-ASCII
Message-ID: <E1FGf6S-000303-Nr@sc8-sf-web4-b.sourceforge.net>

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

Please note that this 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: osvenskan (osvenskan)
Assigned to: M.-A. Lemburg (lemburg)
Summary: robotparser crashes if robots.txt contains non-ASCII

Initial Comment:
One-line summary: If the robotparser module encounters
a robots.txt file that contains non-ASCII characters
AND I pass a Unicode user agent string to can_fetch(),
that function crashes with a TypeError under Python
2.4. Under Python 2.3, the error is a UnicodeDecodeError. 

More detail:
When one calls can_fetch(MyUserAgent, url), the
robotparser module compares  the UserAgent to each user
agent described in the robots.txt file. If
isinstance(MyUserAgent, str) == True then the
comparison does not raise an error regardless of the
contents of robots.txt. However, if
isinstance(MyUserAgent, unicode) == True, then Python
implicitly tries to convert the contents of the
robots.txt file to Unicode before comparing it to
MyUserAgent. By default, Python assumes a US-ASCII
encoding when converting, so if the contents of
robots.txt aren't ASCII, the conversion fails. In other
words, this works:
MyRobotParser.can_fetch('foobot', url)
but this fails:
MyRobotParser.can_fetch(u'foobot', url)

I recreated this with Python 2.4.1 on FreeBSD 6 and
Python 2.3 under Darwin/OS X. I'll attach examples from
both. The URLs that I use in the attachments are from
my Web site and will remain live. They reference
robots.txt files which contain an umlaut-ed 'a' (0xe4
in iso-8859-1). They're served up using a special
.htaccess file that adds a Content-Type header which
correctly identifies the encoding used for each file.
Here's the contents of the .htaccess file:

AddCharset iso-8859-1 .iso8859-1
AddCharset utf-8 .utf8


A suggested solution:
AFAICT, the construction of robots.txt is still defined
by "a consensus on 30 June 1994 on the robots mailing
list" [http://www.robotstxt.org/wc/norobots.html] and a
1996 draft proposal
[http://www.robotstxt.org/wc/norobots-rfc.html] that
has never evolved into a formal standard. Neither of
these mention character sets or encodings which is no
surprise considering that they date back to the days
when the Internet was poor but happy and we considered
even ASCII a luxury and we were grateful to have it.
("ASCII? We used to dream of having ASCII. We only had
one bit, and it was a zero. We lived in a shoebox in
the middle of the road..." etc.) A backwards-compatible
yet forward-looking solution would be to have the
robotparser module respect the Content-Type header sent
with robots.txt. If no such header is present,
robotparser should try to decode it using iso-8859-1
per section 3.7.1 of the HTTP 1.1 spec
(http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7.1)
which says, 'When no explicit charset parameter is
provided by the sender, media subtypes of the "text"
type are defined to have a default charset value of
"ISO-8859-1" when received via HTTP. Data in character
sets other than "ISO-8859-1" or its subsets MUST be
labeled with an appropriate charset value.' Section
3.6.1 of the HTTP 1.0 spec says the same. Since
ISO-8859-1 is a superset of US-ASCII, robots.txt files
that are pure ASCII won't be affected by the change.






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

>Comment By: osvenskan (osvenskan)
Date: 2006-03-07 11:32

Message:
Logged In: YES 
user_id=1119995

Thanks for looking at this. I have some followup comments. 

The list at robotstxt.org is many years stale (note that
Google's bot is present only as Backrub which was still a
server at Stanford at the time:
http://www.robotstxt.org/wc/active/html/backrub.html) but
nevertheless AFAICT it is the most current bot list on the
Web. If you look carefully, the list *does* contain a
non-ASCII entry (#76 --easy to miss in that long list). That
Finnish bot is gone but it has left a legacy in the form of
many robots.txt files that were created by automated tools
based on the robotstxt.org list. Google helps us here:
http://www.google.com/search?q=allintext%3AH%C3%A4m%C3%A4h%C3%A4kki+disallow+filetype%3Atxt

And by Googling for some common non-ASCII words and letters
I can find more like this one (look at the end of the
alphabetical list):
http://paranormal.se/robots.txt

Robots.txt files that contain non-ASCII are few and far
between, it seems, but they're out there.

Which leads me to a nitpicky (but important!) point about
Unicode. As you point out, the spec doesn't mention Unicode;
it says nothing at all on the topic of encodings. My
argument is that just because the spec doesn't mention
encodings doesn't let us off the hook because the HTTP
1.0/1.1 specs are very clear that iso-8859-1, not US-ASCII,
is the default for text content delivered via HTTP. By my
interpretation, this means that the robots.txt examples
provided above are compliant with published specs, therefore
code that fails to interpret them does not comply. There's
no obvious need for robotparser to support full-blown
Unicode, just iso-8859-1. 

You might be interested in a replacement for this module
that I've implemented. It does everything that robotparser
does and also handles non-ASCII plus a few other things. It
is GPL; you're welcome to copy it in part or lock, stock and
barrel. So far I've only tested it "in the lab" but I've
done fairly extensive unit testing and I'll soon be testing
it on real-world data. The code and docs are here:
http://semanchuk.com/philip/boneyard/rerp/

Comments & feedback would be most welcome.



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

Comment By: Terry J. Reedy (tjreedy)
Date: 2006-03-05 22:01

Message:
Logged In: YES 
user_id=593130

To me, this is not a bug report but at best an RFE.  The 
reported behavior is what I would expect.  I read both 
module doc and the referenced web page and further links.  
The doc does not mention Unicode as allowed and the 300 
registered UserAgents at
http://www.robotstxt.org/wc/active/html/index.html
all have ascii names.

So I recomment closing this as a bug report but will give 
ML a chance to respond.  If switched instead to Feature 
Request, I would think it would need some 'in the wild' 
evidence of need.

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

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

From noreply at sourceforge.net  Tue Mar  7 19:34:38 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 07 Mar 2006 10:34:38 -0800
Subject: [ python-Bugs-729236 ] building readline module fails on Irix 6.5
Message-ID: <E1FGh14-0002Bc-CY@sc8-sf-web1.sourceforge.net>

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

Please note that this 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.3
Status: Closed
Resolution: None
Priority: 5
Submitted By: alexandre gillet (gillet)
Assigned to: Nobody/Anonymous (nobody)
Summary: building readline module fails on Irix 6.5

Initial Comment:
I am trying to build  Python2.3b1 on a sgi Irix 6.5 using
MIPSpro Compilers: Version 7.30

I can't get the readline module to build. I get the
following error:
cc  -OPT:Olimit=0 -DNDEBUG -O -I. -I../Include 
-I/mgl/prog/share/include/ -c ../Modules/readline.c -o
Modules/readline.o
cc-1119 cc: ERROR File = ../Modules/readline.c, Line = 587
  The &quot;return&quot; expression type differs from the
function return type.

        return completion_matches(text, *on_completion);
               ^

cc-1552 cc: WARNING File = ../Modules/readline.c, Line
= 732
  The variable &quot;m&quot; is set but never used.

        PyObject *m;
                  ^

1 error detected in the compilation of
&quot;../Modules/readline.c&quot;.
gmake: *** [Modules/readline.o] Error 2


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

>Comment By: alexandre gillet (gillet)
Date: 2006-03-07 18:34

Message:
Logged In: YES 
user_id=150999

Tested it with python2.4.2 and readline 5.1. It builds with
no problem.


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

Comment By: SourceForge Robot (sf-robot)
Date: 2006-03-07 03:24

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 (birkenfeld)
Date: 2006-02-20 09:15

Message:
Logged In: YES 
user_id=1188172

Is this still the case with Python 2.4?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-05-21 23:49

Message:
Logged In: YES 
user_id=33168

Is HAVE_RL_COMPLETION_MATCHES defined?  If so is
rl_completion_matches() defined to return char ** in
readline.h?  If HAVE_* is not defined, where is
completion_matches() defined and what does it return?

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

Comment By: alexandre gillet (gillet)
Date: 2003-05-12 18:02

Message:
Logged In: YES 
user_id=150999

I was able to compile readline on Irix after changing the
function flex_complete. the function prototyte say it should
return a char** .So we did put the following change and it
works. Is it a right way to do it?

** readline.c  2003-05-09 13:45:38.000000000 -0700
--- readline.c~ 2003-03-01 07:19:41.000000000 -0800
***************
*** 577,589 ****
  /* A more flexible constructor that saves the &quot;begidx&quot; and
&quot;endidx&quot;
   * before calling the normal completer */

! static char ** flex_complete(char *text, int start, int end)
  {
        Py_XDECREF(begidx);
        Py_XDECREF(endidx);
        begidx = PyInt_FromLong((long) start);
        endidx = PyInt_FromLong((long) end);
!       return (char **)completion_matches(text,
*on_completion);
  }


--- 577,590 ----
  /* A more flexible constructor that saves the &quot;begidx&quot; and
&quot;endidx&quot;
   * before calling the normal completer */

! static char **
! flex_complete(char *text, int start, int end)
  {
        Py_XDECREF(begidx);
        Py_XDECREF(endidx);
        begidx = PyInt_FromLong((long) start);
        endidx = PyInt_FromLong((long) end);
!       return completion_matches(text, *on_completion);
  }











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

Comment By: alexandre gillet (gillet)
Date: 2003-05-12 17:44

Message:
Logged In: YES 
user_id=150999

My readline version is 4.3

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

Comment By: Martin v. L??wis (loewis)
Date: 2003-04-29 11:44

Message:
Logged In: YES 
user_id=21627

What is your readline version?

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

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

From noreply at sourceforge.net  Tue Mar  7 20:48:45 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 07 Mar 2006 11:48:45 -0800
Subject: [ python-Bugs-1445068 ] getpass.getpass queries on STDOUT not STERR
	(*nix)
Message-ID: <E1FGiAn-0001gM-Bc@sc8-sf-web6.sourceforge.net>

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

Please note that this message 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: Jon Lasser (jonlasser)
Assigned to: Nobody/Anonymous (nobody)
Summary: getpass.getpass queries on STDOUT not STERR (*nix)

Initial Comment:
Expected behavior of a *nix system would be to get the
password query on STDERR, so that (for non-interactive
applications) one can send the output of the command to
somewhere else, and not be hanging on a password
request that was never seen by the user at the
terminal. (And also so that output isn't polluted by
the password request, when parsing it via a pipeline.)

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

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

From noreply at sourceforge.net  Tue Mar  7 21:30:10 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 07 Mar 2006 12:30:10 -0800
Subject: [ python-Bugs-1439659 ] file to store pickled object should be opened
	in binary mode
Message-ID: <E1FGios-0003lz-0X@sc8-sf-web3.sourceforge.net>

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

Please note that this 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: Raghuram Devarakonda (draghuram)
Assigned to: Nobody/Anonymous (nobody)
Summary: file to store pickled object should be opened in binary mode

Initial Comment:

Hi,

To unpickle objects on UNIX that were pickled on
windows, the file should be opened in binary mode for
read and write on windows. It will be nice to have this
mentioned in the doc. Something along these lines will
be good enough:

"Please note that if you are writing the pickled object
to a file on windows, make sure it is opened in binary
mode. Otherwise, the file may not be able to be used to
unpickle on other non-windows platforms".

Thanks,
Raghu. 

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

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-07 20:30

Message:
Logged In: YES 
user_id=849994

I recently added a note to the docs about this. I it's not
enough, feel free to reopen.

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

Comment By: Tim Peters (tim_one)
Date: 2006-03-06 19:48

Message:
Logged In: YES 
user_id=31435

Pickle files should be opened in binary mode, regardless of
pickle protocol, regardless of platform, and regardless of
whether reading or writing.  That protocol 0 used to be
called "text mode" was an historic mistake, and was given
that name by a Unix-head who wouldn't know the difference
between text and binary mode if it suck its teeth in their
posterior and tore off an entire bloody buttock :-)

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

Comment By: Terry J. Reedy (tjreedy)
Date: 2006-03-06 19:03

Message:
Logged In: YES 
user_id=593130

Any text file written with /r/n in Windows can have 
problems when read on *nix or Mac or ???, so this problem 
is not specific to pickle or even to Python.  I am under 
the impression that the new universal newline support was 
intended to fix such problems (when used).  But as a Win-
only user (currently) I have no experience with it.

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2006-03-06 15:12

Message:
Logged In: YES 
user_id=984087


There seems to be a mistane in my earlier comment. I meant
the unpickling on *UNIX* fails even if ASCII was used on
windows.

Raghu.

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2006-03-06 15:11

Message:
Logged In: YES 
user_id=984087


Hi,

The point is that even if ASCII protocol is used on
windows(as I was), the unpickling process would fail on
windows. So the pickle file should be opened in binary mode
on windows even for ASCII protocol. This may make reading
the file in notepad difficult but then, cross platform
support should take precedence, I suppose. Another option
would be for python to do line end translations for ASCII
pickle files. 

Raghu.


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

Comment By: Terry J. Reedy (tjreedy)
Date: 2006-03-06 03:36

Message:
Logged In: YES 
user_id=593130

For ASCII protocol pickles, intended for human 
readability, one should use text mode to be able to read 
the file, for instance, in Notepad.

For either binary protocol, I would think binary mode 
should be best even to reread on Windows.  If anything is 
added, I would put
"On Windows, open files in a mode (text/binary) that 
matches the protocol."
at the bottom of http://docs.python.org/lib/node64.html

Looking forward to 3.0, when file mode might be more 
significant (text/binary corresponding to unicode/bytes), 
the "for windoews' qualifier might be omitted, but this 
might be premature.

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

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

From noreply at sourceforge.net  Tue Mar  7 21:30:34 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 07 Mar 2006 12:30:34 -0800
Subject: [ python-Bugs-1439538 ] test -e is not portable (Solaris 2.7)
Message-ID: <E1FGipG-0003m7-S5@sc8-sf-web3.sourceforge.net>

Bugs item #1439538, was opened at 2006-02-27 10:51
Message generated for change (Settings changed) 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.

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

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

From noreply at sourceforge.net  Tue Mar  7 22:09:48 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 07 Mar 2006 13:09:48 -0800
Subject: [ python-Bugs-1432525 ] os.listdir doesn't release GIL
Message-ID: <E1FGjRE-0003VE-U3@sc8-sf-web1.sourceforge.net>

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

Please note that this 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: Jonathan Ellis (ellisj)
Assigned to: Georg Brandl (gbrandl)
Summary: os.listdir doesn't release GIL

Initial Comment:
posix_listdir in posixmodule.c does not release the
global interpreter lock, blocking all other threads for
the duration of the call.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2006-03-07 16:09

Message:
Logged In: YES 
user_id=6380

So the patch is broken because there's a continue in the
do-while-loop that jumps to the "while (result)" test
without setting result.

Fixing this by adding a label and a goto (in two places!)
creates awful spaghetti code.

Before somebody spends more time refactoring such hairy
code, I'd like to see a better motivation; the motivation
currently provided is a bit thin.  Are there use cases where
this call takes a long time?

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

Comment By: Georg Brandl (gbrandl)
Date: 2006-03-07 07:48

Message:
Logged In: YES 
user_id=849994

Committed as rev. 42884.

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

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

Message:
Logged In: YES 
user_id=21627

The patch looks fine. Please apply.

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

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-18 06:13

Message:
Logged In: YES 
user_id=1188172

Attaching a patch. Please check.

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

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

From noreply at sourceforge.net  Tue Mar  7 23:36:17 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 07 Mar 2006 14:36:17 -0800
Subject: [ python-Bugs-1432525 ] os.listdir doesn't release GIL
Message-ID: <E1FGkmv-0000NK-3D@sc8-sf-web4-b.sourceforge.net>

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

Please note that this 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: Jonathan Ellis (ellisj)
Assigned to: Georg Brandl (gbrandl)
Summary: os.listdir doesn't release GIL

Initial Comment:
posix_listdir in posixmodule.c does not release the
global interpreter lock, blocking all other threads for
the duration of the call.

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

>Comment By: Jonathan Ellis (ellisj)
Date: 2006-03-07 22:36

Message:
Logged In: YES 
user_id=657828

My original use case is on a server back end with fairly
busy disks.  It's not unusual for listdir to take 100ms. 
That's a relatively long time to shut down the rest of the
system.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2006-03-07 21:09

Message:
Logged In: YES 
user_id=6380

So the patch is broken because there's a continue in the
do-while-loop that jumps to the "while (result)" test
without setting result.

Fixing this by adding a label and a goto (in two places!)
creates awful spaghetti code.

Before somebody spends more time refactoring such hairy
code, I'd like to see a better motivation; the motivation
currently provided is a bit thin.  Are there use cases where
this call takes a long time?

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

Comment By: Georg Brandl (gbrandl)
Date: 2006-03-07 12:48

Message:
Logged In: YES 
user_id=849994

Committed as rev. 42884.

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-03-03 17:48

Message:
Logged In: YES 
user_id=21627

The patch looks fine. Please apply.

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

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-18 11:13

Message:
Logged In: YES 
user_id=1188172

Attaching a patch. Please check.

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

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

From noreply at sourceforge.net  Wed Mar  8 00:20:09 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 07 Mar 2006 15:20:09 -0800
Subject: [ python-Bugs-1445210 ] embedding Python causes memory leaks
Message-ID: <E1FGlTN-000341-F7@sc8-sf-web4-b.sourceforge.net>

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

Please note that this message 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: Andrew Trevorrow (andykt)
Assigned to: Nobody/Anonymous (nobody)
Summary: embedding Python causes memory leaks

Initial Comment:
[This bug has been submitted by others but for some reason it
has been marked Closed.  I consider it to be an extremely serious
bug -- if I can't solve it I'm going to have to abandon Python as
my app's scripting language, even though I've fallen in love!]

I've added Python script support to my cross-platfom wxWidgets app
so that users can run .py scripts from within the app to automate the
GUI and do other fancy things.  It all works very nicely, except for
one nasty problem: *every* time a script is run there is a memory leak,
usually small (about 10K) but sometimes massive (about 4MB in the 
case of one rather complicated script).

The problem occurs on both Mac OS 10.3.9 and Windows 2000.
I'm using Python 2.3 on the Mac and 2.4.2 on Windows.

Every time the user runs a script, my app makes these calls:
(I've removed a lot of irrelevant stuff.)

   Py_Initialize();
   PyRun_SimpleString("execfile('foo.py')");
   Py_Finalize();

It's definitely not a wxWidgets problem.  In fact it's quite easy to
see the memory leak using a simple command-line program:

#include <stdio.h>
#include <Python.h>
main(int argc, char *argv[])
{
   int i;
   for (i=0; i<1000; i++) {
      Py_Initialize();
      Py_Finalize();
      printf(".");
      if ((i+1) % 50 == 0) printf("\n");
   }
}

Note that it doesn't even execute a script.  If I run this program on
my Mac and watch its memory usage with Activity Monitor, I see a leak
of about 10K each time through the loop.  Similar result on Windows.

Curiously, on both machines, the Py_Finalize() call takes longer and
longer to complete whatever it's doing.  The above program takes a
few *minutes* to complete on my 400MHz Mac.

Andrew


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

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

From noreply at sourceforge.net  Wed Mar  8 00:48:54 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 07 Mar 2006 15:48:54 -0800
Subject: [ python-Bugs-1432525 ] os.listdir doesn't release GIL
Message-ID: <E1FGlvC-0007XI-2p@sc8-sf-web3.sourceforge.net>

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

Please note that this 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: Jonathan Ellis (ellisj)
Assigned to: Georg Brandl (gbrandl)
Summary: os.listdir doesn't release GIL

Initial Comment:
posix_listdir in posixmodule.c does not release the
global interpreter lock, blocking all other threads for
the duration of the call.

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

Comment By: Jim Jewett (jimjjewett)
Date: 2006-03-07 18:48

Message:
Logged In: YES 
user_id=764593

I think the spaghetti was already there.  

The gotos can be removed by just reversing the logic (if ! 
(...))

The XXX comment complains about four versions, but I count 
either three (windows without opendir, OS2, everything 
else) or five (the non-OS2 versions are split for unicode).

The code getting skipped is repeated because the logic for 
skipping "." and ".." is repeated four times.  (There would 
be another goto, if the OS2 case allowed threads.)



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

Comment By: Jonathan Ellis (ellisj)
Date: 2006-03-07 17:36

Message:
Logged In: YES 
user_id=657828

My original use case is on a server back end with fairly
busy disks.  It's not unusual for listdir to take 100ms. 
That's a relatively long time to shut down the rest of the
system.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2006-03-07 16:09

Message:
Logged In: YES 
user_id=6380

So the patch is broken because there's a continue in the
do-while-loop that jumps to the "while (result)" test
without setting result.

Fixing this by adding a label and a goto (in two places!)
creates awful spaghetti code.

Before somebody spends more time refactoring such hairy
code, I'd like to see a better motivation; the motivation
currently provided is a bit thin.  Are there use cases where
this call takes a long time?

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

Comment By: Georg Brandl (gbrandl)
Date: 2006-03-07 07:48

Message:
Logged In: YES 
user_id=849994

Committed as rev. 42884.

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

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

Message:
Logged In: YES 
user_id=21627

The patch looks fine. Please apply.

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

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-18 06:13

Message:
Logged In: YES 
user_id=1188172

Attaching a patch. Please check.

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

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

From noreply at sourceforge.net  Wed Mar  8 00:52:20 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 07 Mar 2006 15:52:20 -0800
Subject: [ python-Bugs-1432525 ] os.listdir doesn't release GIL
Message-ID: <E1FGlyW-00051d-Tv@sc8-sf-web4-b.sourceforge.net>

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

Please note that this 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: Jonathan Ellis (ellisj)
Assigned to: Georg Brandl (gbrandl)
Summary: os.listdir doesn't release GIL

Initial Comment:
posix_listdir in posixmodule.c does not release the
global interpreter lock, blocking all other threads for
the duration of the call.

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

Comment By: Jim Jewett (jimjjewett)
Date: 2006-03-07 18:52

Message:
Logged In: YES 
user_id=764593

I think the spaghetti was already there.  

The gotos can be removed by just reversing the logic (if ! 
(...))

The XXX comment complains about four versions, but I count 
either three (windows without opendir, OS2, everything 
else) or five (the non-OS2 versions are split for unicode).

The code getting skipped is repeated because the logic for 
skipping "." and ".." is repeated four times.  (There would 
be another goto, if the OS2 case allowed threads.)



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

Comment By: Jim Jewett (jimjjewett)
Date: 2006-03-07 18:48

Message:
Logged In: YES 
user_id=764593

I think the spaghetti was already there.  

The gotos can be removed by just reversing the logic (if ! 
(...))

The XXX comment complains about four versions, but I count 
either three (windows without opendir, OS2, everything 
else) or five (the non-OS2 versions are split for unicode).

The code getting skipped is repeated because the logic for 
skipping "." and ".." is repeated four times.  (There would 
be another goto, if the OS2 case allowed threads.)



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

Comment By: Jonathan Ellis (ellisj)
Date: 2006-03-07 17:36

Message:
Logged In: YES 
user_id=657828

My original use case is on a server back end with fairly
busy disks.  It's not unusual for listdir to take 100ms. 
That's a relatively long time to shut down the rest of the
system.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2006-03-07 16:09

Message:
Logged In: YES 
user_id=6380

So the patch is broken because there's a continue in the
do-while-loop that jumps to the "while (result)" test
without setting result.

Fixing this by adding a label and a goto (in two places!)
creates awful spaghetti code.

Before somebody spends more time refactoring such hairy
code, I'd like to see a better motivation; the motivation
currently provided is a bit thin.  Are there use cases where
this call takes a long time?

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

Comment By: Georg Brandl (gbrandl)
Date: 2006-03-07 07:48

Message:
Logged In: YES 
user_id=849994

Committed as rev. 42884.

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

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

Message:
Logged In: YES 
user_id=21627

The patch looks fine. Please apply.

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

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-18 06:13

Message:
Logged In: YES 
user_id=1188172

Attaching a patch. Please check.

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

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

From noreply at sourceforge.net  Wed Mar  8 05:07:58 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 07 Mar 2006 20:07:58 -0800
Subject: [ python-Bugs-1432525 ] os.listdir doesn't release GIL
Message-ID: <E1FGpxu-0003fE-Rz@sc8-sf-web1.sourceforge.net>

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

Please note that this 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: Jonathan Ellis (ellisj)
Assigned to: Georg Brandl (gbrandl)
Summary: os.listdir doesn't release GIL

Initial Comment:
posix_listdir in posixmodule.c does not release the
global interpreter lock, blocking all other threads for
the duration of the call.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2006-03-07 23:07

Message:
Logged In: YES 
user_id=6380

Well, the difference is that before the patch was applied it
worked, and now it's broken.  So somebody please roll it
back; *then* we can think of a proper fix and review it
properly.

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

Comment By: Jim Jewett (jimjjewett)
Date: 2006-03-07 18:52

Message:
Logged In: YES 
user_id=764593

I think the spaghetti was already there.  

The gotos can be removed by just reversing the logic (if ! 
(...))

The XXX comment complains about four versions, but I count 
either three (windows without opendir, OS2, everything 
else) or five (the non-OS2 versions are split for unicode).

The code getting skipped is repeated because the logic for 
skipping "." and ".." is repeated four times.  (There would 
be another goto, if the OS2 case allowed threads.)



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

Comment By: Jim Jewett (jimjjewett)
Date: 2006-03-07 18:48

Message:
Logged In: YES 
user_id=764593

I think the spaghetti was already there.  

The gotos can be removed by just reversing the logic (if ! 
(...))

The XXX comment complains about four versions, but I count 
either three (windows without opendir, OS2, everything 
else) or five (the non-OS2 versions are split for unicode).

The code getting skipped is repeated because the logic for 
skipping "." and ".." is repeated four times.  (There would 
be another goto, if the OS2 case allowed threads.)



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

Comment By: Jonathan Ellis (ellisj)
Date: 2006-03-07 17:36

Message:
Logged In: YES 
user_id=657828

My original use case is on a server back end with fairly
busy disks.  It's not unusual for listdir to take 100ms. 
That's a relatively long time to shut down the rest of the
system.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2006-03-07 16:09

Message:
Logged In: YES 
user_id=6380

So the patch is broken because there's a continue in the
do-while-loop that jumps to the "while (result)" test
without setting result.

Fixing this by adding a label and a goto (in two places!)
creates awful spaghetti code.

Before somebody spends more time refactoring such hairy
code, I'd like to see a better motivation; the motivation
currently provided is a bit thin.  Are there use cases where
this call takes a long time?

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

Comment By: Georg Brandl (gbrandl)
Date: 2006-03-07 07:48

Message:
Logged In: YES 
user_id=849994

Committed as rev. 42884.

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

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

Message:
Logged In: YES 
user_id=21627

The patch looks fine. Please apply.

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

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-18 06:13

Message:
Logged In: YES 
user_id=1188172

Attaching a patch. Please check.

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

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

From noreply at sourceforge.net  Wed Mar  8 12:30:13 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 08 Mar 2006 03:30:13 -0800
Subject: [ python-Bugs-1434298 ] CHM file contains proprietary link format
Message-ID: <E1FGwrt-0000LY-Gn@sc8-sf-web6.sourceforge.net>

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

Please note that this 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: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Alexander Schremmer (alexanderweb)
Assigned to: Thomas Heller (theller)
Summary: CHM file contains proprietary link format

Initial Comment:
The .chm file distributed with Python contains URL 
using the proprietary link scheme mk:@MSITStore. While 
this is not a problem in Windows environments, it 
prevents e.g. xchm from loading the pictures.
My suggestion is to advise the html help compiler to 
make these links absolute without specifying a 
protocol. As I do not have setup the html help compiler 
here, I cannot check if this is a working work around.

Having a .chm file that is compatible to multiple 
platforms is a large advantage because you can advise 
newbies to get this file. They are easy navigatable and 
tend to be complete.

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

>Comment By: Alexander Schremmer (alexanderweb)
Date: 2006-03-08 12:30

Message:
Logged In: YES 
user_id=254738

I figured out that this issue seems to be related to xchm 
and that there are no ms-specific URLs in the source. I 
recommend non-windows users to choose http://www.kchmviewer.
net/ as it is known to work correctly with python's chm 
file.

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

Comment By: Thomas Heller (theller)
Date: 2006-02-18 22:19

Message:
Logged In: YES 
user_id=11105

The project files are generated by calling the script
Doc/tools/prechm.py.  See als PEP 101.

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

Comment By: Alexander Schremmer (alexanderweb)
Date: 2006-02-18 21:50

Message:
Logged In: YES 
user_id=254738

I could check if it is possible if you can tell me where the 
HTML help compiler project etc. files are in the source 
tree.

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

Comment By: Thomas Heller (theller)
Date: 2006-02-18 21:36

Message:
Logged In: YES 
user_id=11105

Can you tell me how this is done?

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

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-18 21:27

Message:
Logged In: YES 
user_id=1188172

Moving to Bugs.

Martin, do you create the CHM file?

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

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

From noreply at sourceforge.net  Wed Mar  8 12:31:36 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 08 Mar 2006 03:31:36 -0800
Subject: [ python-Bugs-1441884 ] A (treaded) Python crash only on dual core
	machines
Message-ID: <E1FGwtE-0005G1-3K@sc8-sf-web4-b.sourceforge.net>

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

Please note that this 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.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Robert Kiendl (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: A (treaded) Python crash only on dual core machines

Initial Comment:
There is a strange freeze/crash only on dual core machines:

I have a python app (Python 2.3.5 /Pythonwin build 203
/ Windows) running with no stability problems on normal
machines (Or a crash is so rare, that absolutely nobody
obverses it, though the overall majority of users uses
single core machines). Threads, network &
pythonwin/win32ui all in use.

Yet, from 3 users, _all_ using a Dual Processor System
(XEON, amd x2 3800+) computer, I have reports, that the
application freezes hard and/or crashes with a kind of
random stack dump (operating system). I cannot
experiment with those machines.

I found no hints other than:

http://groups.google.de/group/comp.lang.python/browse_frm/thread/64ca033e1a7f6c61/719b147e870bd5e6

http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=480325

.. both discussions remaining in uncertainty.

Are there (known) problems with Python/Pythonwin
specifically for dual core's  (py2.3.5 / pywin203) ?

What could I do to find the problem?

Robert


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

PS: there is very little C extension-code (SWIG)
involved, yet I looked over that so often, I guess its
save:


//

#include "stdafx.h"
#include "commctrl.h"
#include "ext.h"

BOOL APIENTRY DllMain( HANDLE hModule,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved
                     )
{
    return TRUE;
}

class CAllowThreads {
public:
    PyThreadState *_save; \
    CAllowThreads() {
            _save = PyEval_SaveThread();
    }
    ~CAllowThreads() {
        PyEval_RestoreThread(_save);
    }
};

PyObject* PyListView_GetSubItemRect(
    HWND hwndLV,
    int iItem,
    int iSubItem,
    int code
//    LPRECT lpRect
)
{
    RECT r;
    {
      CAllowThreads _t;
      ListView_GetSubItemRect(
        hwndLV,
        iItem,
        iSubItem,
        code,
        &r );
    }
    return Py_BuildValue("iiii",
r.left,r.top,r.right,r.bottom);

}

int GetStringAddr(const char* s) {
    return (int)s;
}

int PlaySoundResource(int resid, HMODULE hmod)
{
    CAllowThreads _t;
    return PlaySound(MAKEINTRESOURCE(resid), hmod,
SND_RESOURCE);
}

int PlaySoundFile(const char* fname, int flag)
{
    CAllowThreads _t;
    return PlaySound(fname, NULL, flag);
}

PyObject* py_ToolTipRelayMsg(  PyObject* self,
PyObject* args )
{
    MSG msg;
    HWND hwTT;
   
if(!PyArg_ParseTuple(args,"i(iiiii(ii)):ToolTipRelayMsg",
                         &hwTT,

&msg.hwnd,&msg.message,&msg.wParam,&msg.lParam,&msg.time,
                         &msg.pt, ((int*)&msg.pt)+1) )
        return NULL;

    
    {
      CAllowThreads _t;
      SendMessage(hwTT,TTM_RELAYEVENT,0,(LPARAM)&msg);
    }

    Py_INCREF( Py_None );
    return Py_None;
}

---

"GetStringAddress" is used only once like this (leades
to correct NUL termination I think):

self.sb.SendMessage(commctrl.SB_SETTEXT,iPane,extension.GetStringAddr(text))

--- swig:
static PyObject *_wrap_GetStringAddr(PyObject *self,
PyObject *args) {
    PyObject *resultobj;
    char *arg0 ;
    int result ;

    if(!PyArg_ParseTuple(args,(char
*)"s:GetStringAddr",&arg0)) return NULL;
    result = (int )GetStringAddr((char const *)arg0);
    resultobj = PyInt_FromLong((long)result);
    return resultobj;
} 

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

>Comment By: Robert Kiendl (kxroberto)
Date: 2006-03-08 12:31

Message:
Logged In: YES 
user_id=972995

Find no indications, that it is a GIL problem. Whenever
there was a GIL problem in past, I quickly got problems on
any machine, not specifically only on dual cores.
(The thread-state handling of above short extension code is
done in the same style as in PythonWin for critical
functions, which might come back as new messages in the
message handler. This should be ok. Otherwise there is only
normal Python/Pythonwin code).

The python part of the soft is too big, and I didn't manage
to isolate the problem further as I have only a handful of
user reports like this:
"""
Yes here is one popup window.

---------------------------
app.exe - Application Error
---------------------------
The instruction at "0x73dd11c7" referenced memory at
"0x00000004". The memory could not be "read". 
Click on OK to terminate the program
---------------------------
OK   
---------------------------
"""

"""
AppName: app.exe	 AppVer: 2.7.0.0	 ModName: python23.dll
ModVer: 0.0.0.0	 Offset: 00084ade

Followed by an application error window.

---------------------------
app.exe - Application Error
---------------------------
The instruction at "0x73dd11c7" referenced memory at
"0x00000004". The memory could not be "read". 
Click on OK to terminate the program
---------------------------
OK   
---------------------------
"""

"""
Here is another error just now after latest upgrade

---------------------------
Microsoft Visual C++ Runtime Library
---------------------------
Runtime Error!

Program: C:\bin\app.exe

 This application has requested the Runtime to terminate it
in an unusual way.
Please contact the application's support team for more
information. 
---------------------------
OK   
---------------------------
"""
=======================================
(The memory errors above are within mfc42.dll)

I use a maybe questionable practice (which I use in order to
smoothen the GUI ):  I start normal Python threads, which
use themselfs win32-functions. I guess this is ok, as
windows GUI functions are considered to be thread-safe.

A simplified example:

thread.start_new(win32ui.MessageBox, 'test')

Guess, this is ok?



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

Comment By: Martin v. L??wis (loewis)
Date: 2006-03-03 18:40

Message:
Logged In: YES 
user_id=21627

You don't provide complete source code for anybody to try to reproduce this 
problem. My guess is that you are calling into the Python runtime without 
holding the global interpreter lock. This can easily create all sorts of problems.

Never release the GIL unless you are absolutely certain that no Python code will 
be executed; neither directly nor indirectly. Don't invoke Python API in a thread 
(e.g. while processing a Windows message) without acquiring the GIL first.

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

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

From noreply at sourceforge.net  Wed Mar  8 16:41:47 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 08 Mar 2006 07:41:47 -0800
Subject: [ python-Bugs-1441884 ] A (treaded) Python crash only on dual core
	machines
Message-ID: <E1FH0nL-00060m-Il@sc8-sf-web2.sourceforge.net>

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

Please note that this 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.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Robert Kiendl (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: A (treaded) Python crash only on dual core machines

Initial Comment:
There is a strange freeze/crash only on dual core machines:

I have a python app (Python 2.3.5 /Pythonwin build 203
/ Windows) running with no stability problems on normal
machines (Or a crash is so rare, that absolutely nobody
obverses it, though the overall majority of users uses
single core machines). Threads, network &
pythonwin/win32ui all in use.

Yet, from 3 users, _all_ using a Dual Processor System
(XEON, amd x2 3800+) computer, I have reports, that the
application freezes hard and/or crashes with a kind of
random stack dump (operating system). I cannot
experiment with those machines.

I found no hints other than:

http://groups.google.de/group/comp.lang.python/browse_frm/thread/64ca033e1a7f6c61/719b147e870bd5e6

http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=480325

.. both discussions remaining in uncertainty.

Are there (known) problems with Python/Pythonwin
specifically for dual core's  (py2.3.5 / pywin203) ?

What could I do to find the problem?

Robert


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

PS: there is very little C extension-code (SWIG)
involved, yet I looked over that so often, I guess its
save:


//

#include "stdafx.h"
#include "commctrl.h"
#include "ext.h"

BOOL APIENTRY DllMain( HANDLE hModule,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved
                     )
{
    return TRUE;
}

class CAllowThreads {
public:
    PyThreadState *_save; \
    CAllowThreads() {
            _save = PyEval_SaveThread();
    }
    ~CAllowThreads() {
        PyEval_RestoreThread(_save);
    }
};

PyObject* PyListView_GetSubItemRect(
    HWND hwndLV,
    int iItem,
    int iSubItem,
    int code
//    LPRECT lpRect
)
{
    RECT r;
    {
      CAllowThreads _t;
      ListView_GetSubItemRect(
        hwndLV,
        iItem,
        iSubItem,
        code,
        &r );
    }
    return Py_BuildValue("iiii",
r.left,r.top,r.right,r.bottom);

}

int GetStringAddr(const char* s) {
    return (int)s;
}

int PlaySoundResource(int resid, HMODULE hmod)
{
    CAllowThreads _t;
    return PlaySound(MAKEINTRESOURCE(resid), hmod,
SND_RESOURCE);
}

int PlaySoundFile(const char* fname, int flag)
{
    CAllowThreads _t;
    return PlaySound(fname, NULL, flag);
}

PyObject* py_ToolTipRelayMsg(  PyObject* self,
PyObject* args )
{
    MSG msg;
    HWND hwTT;
   
if(!PyArg_ParseTuple(args,"i(iiiii(ii)):ToolTipRelayMsg",
                         &hwTT,

&msg.hwnd,&msg.message,&msg.wParam,&msg.lParam,&msg.time,
                         &msg.pt, ((int*)&msg.pt)+1) )
        return NULL;

    
    {
      CAllowThreads _t;
      SendMessage(hwTT,TTM_RELAYEVENT,0,(LPARAM)&msg);
    }

    Py_INCREF( Py_None );
    return Py_None;
}

---

"GetStringAddress" is used only once like this (leades
to correct NUL termination I think):

self.sb.SendMessage(commctrl.SB_SETTEXT,iPane,extension.GetStringAddr(text))

--- swig:
static PyObject *_wrap_GetStringAddr(PyObject *self,
PyObject *args) {
    PyObject *resultobj;
    char *arg0 ;
    int result ;

    if(!PyArg_ParseTuple(args,(char
*)"s:GetStringAddr",&arg0)) return NULL;
    result = (int )GetStringAddr((char const *)arg0);
    resultobj = PyInt_FromLong((long)result);
    return resultobj;
} 

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

>Comment By: Robert Kiendl (kxroberto)
Date: 2006-03-08 16:41

Message:
Logged In: YES 
user_id=972995

Indications point more to a "dual core" problem in Pythonwin
=> Bug 1442426 in sf pywin32 project.


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

Comment By: Robert Kiendl (kxroberto)
Date: 2006-03-08 12:31

Message:
Logged In: YES 
user_id=972995

Find no indications, that it is a GIL problem. Whenever
there was a GIL problem in past, I quickly got problems on
any machine, not specifically only on dual cores.
(The thread-state handling of above short extension code is
done in the same style as in PythonWin for critical
functions, which might come back as new messages in the
message handler. This should be ok. Otherwise there is only
normal Python/Pythonwin code).

The python part of the soft is too big, and I didn't manage
to isolate the problem further as I have only a handful of
user reports like this:
"""
Yes here is one popup window.

---------------------------
app.exe - Application Error
---------------------------
The instruction at "0x73dd11c7" referenced memory at
"0x00000004". The memory could not be "read". 
Click on OK to terminate the program
---------------------------
OK   
---------------------------
"""

"""
AppName: app.exe	 AppVer: 2.7.0.0	 ModName: python23.dll
ModVer: 0.0.0.0	 Offset: 00084ade

Followed by an application error window.

---------------------------
app.exe - Application Error
---------------------------
The instruction at "0x73dd11c7" referenced memory at
"0x00000004". The memory could not be "read". 
Click on OK to terminate the program
---------------------------
OK   
---------------------------
"""

"""
Here is another error just now after latest upgrade

---------------------------
Microsoft Visual C++ Runtime Library
---------------------------
Runtime Error!

Program: C:\bin\app.exe

 This application has requested the Runtime to terminate it
in an unusual way.
Please contact the application's support team for more
information. 
---------------------------
OK   
---------------------------
"""
=======================================
(The memory errors above are within mfc42.dll)

I use a maybe questionable practice (which I use in order to
smoothen the GUI ):  I start normal Python threads, which
use themselfs win32-functions. I guess this is ok, as
windows GUI functions are considered to be thread-safe.

A simplified example:

thread.start_new(win32ui.MessageBox, 'test')

Guess, this is ok?



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

Comment By: Martin v. L??wis (loewis)
Date: 2006-03-03 18:40

Message:
Logged In: YES 
user_id=21627

You don't provide complete source code for anybody to try to reproduce this 
problem. My guess is that you are calling into the Python runtime without 
holding the global interpreter lock. This can easily create all sorts of problems.

Never release the GIL unless you are absolutely certain that no Python code will 
be executed; neither directly nor indirectly. Don't invoke Python API in a thread 
(e.g. while processing a Windows message) without acquiring the GIL first.

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

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

From noreply at sourceforge.net  Wed Mar  8 18:06:41 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 08 Mar 2006 09:06:41 -0800
Subject: [ python-Bugs-1445781 ] install fails on hard link
Message-ID: <E1FH27V-0001Ka-0S@sc8-sf-web1.sourceforge.net>

Bugs item #1445781, was opened at 2006-03-08 11: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=1445781&group_id=5470

Please note that this 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: goldenautumnday (goldenautumnday)
Assigned to: Nobody/Anonymous (nobody)
Summary: install fails on hard link

Initial Comment:
Installing on an attached linux drive from a Mac OS X (Tiger) system fails 
because hard links are not supported.  This is attempted when trying to 
link python2.4 to python (ln python2.4 python).  If it fails, a copy should 
be performed instead.

changing mode of /Users/martinol/auto_v4.0/devel/powerpc-apple-
darwin8.5.0/bin/idle to 755
changing mode of /Users/martinol/auto_v4.0/devel/powerpc-apple-
darwin8.5.0/bin/pydoc to 755
changing mode of /Users/martinol/auto_v4.0/devel/powerpc-apple-
darwin8.5.0/bin/smtpd.py to 755
if test -f /Users/martinol/auto_v4.0/devel/powerpc-apple-darwin8.5.0/
bin/python -o -h /Users/martinol/auto_v4.0/devel/powerpc-apple-
darwin8.5.0/bin/python; \
then rm -f /Users/martinol/auto_v4.0/devel/powerpc-apple-
darwin8.5.0/bin/python; \
else true; \
fi
(cd /Users/martinol/auto_v4.0/devel/powerpc-apple-darwin8.5.0/bin; ln 
python2.4 python)
ln: python: Operation not supported

/Users/martinol/auto_v4.0 is symbolic link to /Volumes/thing/martinol 
which has been attached to using openapple-K (via SMB).

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

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

From noreply at sourceforge.net  Wed Mar  8 18:38:20 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 08 Mar 2006 09:38:20 -0800
Subject: [ python-Bugs-1445807 ] install fails on hard link
Message-ID: <E1FH2c8-0004ul-0y@sc8-sf-web2.sourceforge.net>

Bugs item #1445807, was opened at 2006-03-08 11: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=1445807&group_id=5470

Please note that this 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: goldenautumnday (goldenautumnday)
Assigned to: Nobody/Anonymous (nobody)
Summary: install fails on hard link

Initial Comment:
Installing on an attached linux drive from a Mac OS X (Tiger) system fails 
because hard links are not supported.  This is attempted when trying to 
link python2.4 to python (ln python2.4 python).  If it fails, a copy should 
be performed instead.

changing mode of /Users/martinol/auto_v4.0/devel/powerpc-apple-
darwin8.5.0/bin/idle to 755
changing mode of /Users/martinol/auto_v4.0/devel/powerpc-apple-
darwin8.5.0/bin/pydoc to 755
changing mode of /Users/martinol/auto_v4.0/devel/powerpc-apple-
darwin8.5.0/bin/smtpd.py to 755
if test -f /Users/martinol/auto_v4.0/devel/powerpc-apple-darwin8.5.0/
bin/python -o -h /Users/martinol/auto_v4.0/devel/powerpc-apple-
darwin8.5.0/bin/python; \
then rm -f /Users/martinol/auto_v4.0/devel/powerpc-apple-
darwin8.5.0/bin/python; \
else true; \
fi
(cd /Users/martinol/auto_v4.0/devel/powerpc-apple-darwin8.5.0/bin; ln 
python2.4 python)
ln: python: Operation not supported

/Users/martinol/auto_v4.0 is symbolic link to /Volumes/thing/martinol 
which has been attached to using openapple-K (via SMB).

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

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

From noreply at sourceforge.net  Wed Mar  8 18:39:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 08 Mar 2006 09:39:25 -0800
Subject: [ python-Bugs-1445807 ] install fails on hard link
Message-ID: <E1FH2dB-0002zx-83@sc8-sf-web5.sourceforge.net>

Bugs item #1445807, was opened at 2006-03-08 11:38
Message generated for change (Settings changed) made by goldenautumnday
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1445807&group_id=5470

Please note that this 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: Deleted
Resolution: None
Priority: 5
Submitted By: goldenautumnday (goldenautumnday)
Assigned to: Nobody/Anonymous (nobody)
Summary: install fails on hard link

Initial Comment:
Installing on an attached linux drive from a Mac OS X (Tiger) system fails 
because hard links are not supported.  This is attempted when trying to 
link python2.4 to python (ln python2.4 python).  If it fails, a copy should 
be performed instead.

changing mode of /Users/martinol/auto_v4.0/devel/powerpc-apple-
darwin8.5.0/bin/idle to 755
changing mode of /Users/martinol/auto_v4.0/devel/powerpc-apple-
darwin8.5.0/bin/pydoc to 755
changing mode of /Users/martinol/auto_v4.0/devel/powerpc-apple-
darwin8.5.0/bin/smtpd.py to 755
if test -f /Users/martinol/auto_v4.0/devel/powerpc-apple-darwin8.5.0/
bin/python -o -h /Users/martinol/auto_v4.0/devel/powerpc-apple-
darwin8.5.0/bin/python; \
then rm -f /Users/martinol/auto_v4.0/devel/powerpc-apple-
darwin8.5.0/bin/python; \
else true; \
fi
(cd /Users/martinol/auto_v4.0/devel/powerpc-apple-darwin8.5.0/bin; ln 
python2.4 python)
ln: python: Operation not supported

/Users/martinol/auto_v4.0 is symbolic link to /Volumes/thing/martinol 
which has been attached to using openapple-K (via SMB).

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

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

From noreply at sourceforge.net  Wed Mar  8 21:22:17 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 08 Mar 2006 12:22:17 -0800
Subject: [ python-Bugs-1445781 ] install fails on hard link
Message-ID: <E1FH5An-0008AK-RI@sc8-sf-web6.sourceforge.net>

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

Please note that this 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: goldenautumnday (goldenautumnday)
Assigned to: Nobody/Anonymous (nobody)
Summary: install fails on hard link

Initial Comment:
Installing on an attached linux drive from a Mac OS X (Tiger) system fails 
because hard links are not supported.  This is attempted when trying to 
link python2.4 to python (ln python2.4 python).  If it fails, a copy should 
be performed instead.

changing mode of /Users/martinol/auto_v4.0/devel/powerpc-apple-
darwin8.5.0/bin/idle to 755
changing mode of /Users/martinol/auto_v4.0/devel/powerpc-apple-
darwin8.5.0/bin/pydoc to 755
changing mode of /Users/martinol/auto_v4.0/devel/powerpc-apple-
darwin8.5.0/bin/smtpd.py to 755
if test -f /Users/martinol/auto_v4.0/devel/powerpc-apple-darwin8.5.0/
bin/python -o -h /Users/martinol/auto_v4.0/devel/powerpc-apple-
darwin8.5.0/bin/python; \
then rm -f /Users/martinol/auto_v4.0/devel/powerpc-apple-
darwin8.5.0/bin/python; \
else true; \
fi
(cd /Users/martinol/auto_v4.0/devel/powerpc-apple-darwin8.5.0/bin; ln 
python2.4 python)
ln: python: Operation not supported

/Users/martinol/auto_v4.0 is symbolic link to /Volumes/thing/martinol 
which has been attached to using openapple-K (via SMB).

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

>Comment By: goldenautumnday (goldenautumnday)
Date: 2006-03-08 14:22

Message:
Logged In: YES 
user_id=1471082

Changing line 599 in Makefile.pre.in to:

(cd $(DESTDIR)$(BINDIR); $(LN) python$(VERSION)$(EXE) $(PYTHON) || cp python
$(VERSION)$(EXE) $(PYTHON))

allowed make to complete.

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

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

From noreply at sourceforge.net  Wed Mar  8 21:28:45 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 08 Mar 2006 12:28:45 -0800
Subject: [ python-Bugs-1445901 ] os.path.realpath works on windows
Message-ID: <E1FH5H3-00005B-2j@sc8-sf-web6.sourceforge.net>

Bugs item #1445901, was opened at 2006-03-08 20: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=1445901&group_id=5470

Please note that this 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: Jonathan Ellis (ellisj)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.realpath works on windows

Initial Comment:
documentation says "Availability: Unix," but it works
on Windows too.

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

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

From noreply at sourceforge.net  Wed Mar  8 21:59:37 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 08 Mar 2006 12:59:37 -0800
Subject: [ python-Bugs-1445901 ] os.path.realpath works on windows
Message-ID: <E1FH5kv-0000hk-Du@sc8-sf-web2.sourceforge.net>

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

Please note that this 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: Jonathan Ellis (ellisj)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.realpath works on windows

Initial Comment:
documentation says "Availability: Unix," but it works
on Windows too.

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

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-08 20:59

Message:
Logged In: YES 
user_id=849994

Thanks, updated the docs in rev. 42923, 42924.

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

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

From noreply at sourceforge.net  Thu Mar  9 01:55:01 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 08 Mar 2006 16:55:01 -0800
Subject: [ python-Bugs-1446043 ] unicode('foo',
	'.utf99') does not raise LookupError 
Message-ID: <E1FH9Qj-0007q4-Su@sc8-sf-web3.sourceforge.net>

Bugs item #1446043, was opened at 2006-03-08 19: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=1446043&group_id=5470

Please note that this 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: osvenskan (osvenskan)
Assigned to: M.-A. Lemburg (lemburg)
Summary: unicode('foo', '.utf99') does not raise LookupError 

Initial Comment:
A very minor inconsistency -- when I call unicode()
with an encoding that Python doesn't know about, it
usually returns a lookup error (e.g LookupError:
unknown encoding: utf99). But when the encoding begins
with a dot (ASCII 0x2e), Python instead gives a
ValueError: Empty module name. It is certainly correct
in raising an error, but it should raise a lookup
error, not a value error.

I've recreated this under Python 2.4.1/FreeBSD 6.0 and
2.3/OS X. See attachment for recreation steps.



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

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

From noreply at sourceforge.net  Thu Mar  9 02:13:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 08 Mar 2006 17:13:25 -0800
Subject: [ python-Bugs-1441884 ] A (treaded) Python crash only on dual core
	machines
Message-ID: <E1FH9iX-0006Sa-KR@sc8-sf-web1.sourceforge.net>

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

Please note that this 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.3
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Robert Kiendl (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: A (treaded) Python crash only on dual core machines

Initial Comment:
There is a strange freeze/crash only on dual core machines:

I have a python app (Python 2.3.5 /Pythonwin build 203
/ Windows) running with no stability problems on normal
machines (Or a crash is so rare, that absolutely nobody
obverses it, though the overall majority of users uses
single core machines). Threads, network &
pythonwin/win32ui all in use.

Yet, from 3 users, _all_ using a Dual Processor System
(XEON, amd x2 3800+) computer, I have reports, that the
application freezes hard and/or crashes with a kind of
random stack dump (operating system). I cannot
experiment with those machines.

I found no hints other than:

http://groups.google.de/group/comp.lang.python/browse_frm/thread/64ca033e1a7f6c61/719b147e870bd5e6

http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=480325

.. both discussions remaining in uncertainty.

Are there (known) problems with Python/Pythonwin
specifically for dual core's  (py2.3.5 / pywin203) ?

What could I do to find the problem?

Robert


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

PS: there is very little C extension-code (SWIG)
involved, yet I looked over that so often, I guess its
save:


//

#include "stdafx.h"
#include "commctrl.h"
#include "ext.h"

BOOL APIENTRY DllMain( HANDLE hModule,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved
                     )
{
    return TRUE;
}

class CAllowThreads {
public:
    PyThreadState *_save; \
    CAllowThreads() {
            _save = PyEval_SaveThread();
    }
    ~CAllowThreads() {
        PyEval_RestoreThread(_save);
    }
};

PyObject* PyListView_GetSubItemRect(
    HWND hwndLV,
    int iItem,
    int iSubItem,
    int code
//    LPRECT lpRect
)
{
    RECT r;
    {
      CAllowThreads _t;
      ListView_GetSubItemRect(
        hwndLV,
        iItem,
        iSubItem,
        code,
        &r );
    }
    return Py_BuildValue("iiii",
r.left,r.top,r.right,r.bottom);

}

int GetStringAddr(const char* s) {
    return (int)s;
}

int PlaySoundResource(int resid, HMODULE hmod)
{
    CAllowThreads _t;
    return PlaySound(MAKEINTRESOURCE(resid), hmod,
SND_RESOURCE);
}

int PlaySoundFile(const char* fname, int flag)
{
    CAllowThreads _t;
    return PlaySound(fname, NULL, flag);
}

PyObject* py_ToolTipRelayMsg(  PyObject* self,
PyObject* args )
{
    MSG msg;
    HWND hwTT;
   
if(!PyArg_ParseTuple(args,"i(iiiii(ii)):ToolTipRelayMsg",
                         &hwTT,

&msg.hwnd,&msg.message,&msg.wParam,&msg.lParam,&msg.time,
                         &msg.pt, ((int*)&msg.pt)+1) )
        return NULL;

    
    {
      CAllowThreads _t;
      SendMessage(hwTT,TTM_RELAYEVENT,0,(LPARAM)&msg);
    }

    Py_INCREF( Py_None );
    return Py_None;
}

---

"GetStringAddress" is used only once like this (leades
to correct NUL termination I think):

self.sb.SendMessage(commctrl.SB_SETTEXT,iPane,extension.GetStringAddr(text))

--- swig:
static PyObject *_wrap_GetStringAddr(PyObject *self,
PyObject *args) {
    PyObject *resultobj;
    char *arg0 ;
    int result ;

    if(!PyArg_ParseTuple(args,(char
*)"s:GetStringAddr",&arg0)) return NULL;
    result = (int )GetStringAddr((char const *)arg0);
    resultobj = PyInt_FromLong((long)result);
    return resultobj;
} 

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

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

Message:
Logged In: YES 
user_id=21627

Well, this bug here is clearly something different. An
attempt to access 0x00000004 very obviously is a null
pointer access, at a structure offset at offset 4. At offset
4, if this is a Python object (which it might not be), is
the ob_type field of an object. So it might be that somebody
tries to find out the Python type of a null pointer (which
ought to crash).

This is different from 1442426, which apparently is not a
null-pointer access.

Without any kind of backtrace, it is very hard to guess what
the cause of this null-pointer access might be - it could be
everywhere (including Python, PythonWin, and,
last-but-not-least, your code).

So I'm closing this as "unreproducable" (for which SF only
has "works for me").

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

Comment By: Robert Kiendl (kxroberto)
Date: 2006-03-08 16:41

Message:
Logged In: YES 
user_id=972995

Indications point more to a "dual core" problem in Pythonwin
=> Bug 1442426 in sf pywin32 project.


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

Comment By: Robert Kiendl (kxroberto)
Date: 2006-03-08 12:31

Message:
Logged In: YES 
user_id=972995

Find no indications, that it is a GIL problem. Whenever
there was a GIL problem in past, I quickly got problems on
any machine, not specifically only on dual cores.
(The thread-state handling of above short extension code is
done in the same style as in PythonWin for critical
functions, which might come back as new messages in the
message handler. This should be ok. Otherwise there is only
normal Python/Pythonwin code).

The python part of the soft is too big, and I didn't manage
to isolate the problem further as I have only a handful of
user reports like this:
"""
Yes here is one popup window.

---------------------------
app.exe - Application Error
---------------------------
The instruction at "0x73dd11c7" referenced memory at
"0x00000004". The memory could not be "read". 
Click on OK to terminate the program
---------------------------
OK   
---------------------------
"""

"""
AppName: app.exe	 AppVer: 2.7.0.0	 ModName: python23.dll
ModVer: 0.0.0.0	 Offset: 00084ade

Followed by an application error window.

---------------------------
app.exe - Application Error
---------------------------
The instruction at "0x73dd11c7" referenced memory at
"0x00000004". The memory could not be "read". 
Click on OK to terminate the program
---------------------------
OK   
---------------------------
"""

"""
Here is another error just now after latest upgrade

---------------------------
Microsoft Visual C++ Runtime Library
---------------------------
Runtime Error!

Program: C:\bin\app.exe

 This application has requested the Runtime to terminate it
in an unusual way.
Please contact the application's support team for more
information. 
---------------------------
OK   
---------------------------
"""
=======================================
(The memory errors above are within mfc42.dll)

I use a maybe questionable practice (which I use in order to
smoothen the GUI ):  I start normal Python threads, which
use themselfs win32-functions. I guess this is ok, as
windows GUI functions are considered to be thread-safe.

A simplified example:

thread.start_new(win32ui.MessageBox, 'test')

Guess, this is ok?



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

Comment By: Martin v. L??wis (loewis)
Date: 2006-03-03 18:40

Message:
Logged In: YES 
user_id=21627

You don't provide complete source code for anybody to try to reproduce this 
problem. My guess is that you are calling into the Python runtime without 
holding the global interpreter lock. This can easily create all sorts of problems.

Never release the GIL unless you are absolutely certain that no Python code will 
be executed; neither directly nor indirectly. Don't invoke Python API in a thread 
(e.g. while processing a Windows message) without acquiring the GIL first.

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

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

From noreply at sourceforge.net  Thu Mar  9 05:26:20 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 08 Mar 2006 20:26:20 -0800
Subject: [ python-Bugs-1446119 ] subprocess interpreted double quotation mark
	wrong on window
Message-ID: <E1FHCjE-0003wd-K2@sc8-sf-web3.sourceforge.net>

Bugs item #1446119, was opened at 2006-03-09 15: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=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: Nobody/Anonymous (nobody)
Summary: subprocess interpreted double quotation mark wrong on window

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.


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

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

From noreply at sourceforge.net  Thu Mar  9 05:30:07 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 08 Mar 2006 20:30:07 -0800
Subject: [ python-Bugs-1446119 ] subprocess interpreted double quotation wrong
	on windows
Message-ID: <E1FHCmt-0004BW-2p@sc8-sf-web3.sourceforge.net>

Bugs item #1446119, was opened at 2006-03-09 15:26
Message generated for change (Settings changed) made by simonhang
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: Nobody/Anonymous (nobody)
>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.


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

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

From noreply at sourceforge.net  Thu Mar  9 07:03:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 08 Mar 2006 22:03:05 -0800
Subject: [ python-Bugs-1353504 ] Python drops core when stdin is bogus
Message-ID: <E1FHEEr-0007Py-N7@sc8-sf-web1.sourceforge.net>

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

Please note that this message 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: Works For Me
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Python drops core when stdin is bogus

Initial Comment:
Someone here at work had the bright idea to execute a
Python
script from a Solaris 10 ~/.dtprofile file. 
Apparently, at the time
that script is run stdin is bogus.  Python core dumps
with this
gdb backtrace:

#0  0x0807d290 in PyDict_SetItem (op=0x815b79c,
key=0x8163f20, value=0x0)
    at ../Objects/dictobject.c:549
#1  0x0807e0f7 in PyDict_SetItemString (v=0x815b79c,
key=0x8118df2 "stdin",
    item=0x0) at ../Objects/dictobject.c:1988
#2  0x080e0d03 in _PySys_Init () at
../Python/sysmodule.c:977
#3  0x080ddfdb in Py_InitializeEx (install_sigs=1) at
../Python/pythonrun.c:190
#4  0x080dfa89 in Py_Initialize () at
../Python/pythonrun.c:283
#5  0x0805cd55 in Py_Main (argc=3, argv=0x8047c08) at
../Modules/main.c:418
#6  0x0805ca13 in main (argc=3, argv=0x8047c08) at
../Modules/python.c:23

(This is from 2.4.2, but it also happens in 2.3.4.)

Looking at the code in _PySys_Init it calls

    sysin = PyFile_FromFile(stdin, "<stdin>", "r", NULL);

which returns NULL.  In PyFile_FromFile it creates a new
PyFileObject, then initializes it by calling a static
function,
fill_file_fields.  This apparently fails, causing a NULL
pointer return.  Back in _PySys_Init it checks
PyErr_Occurred,
but fill_file_fields never raised an except.  The NULL
pointer
is passed to PyDict_SetItemString and havoc ensues.

I haven't checked CVS, but 2.4 (and probably 2.3) should be
fixed.  I suggest raising an IOError in
fill_file_fields instead
of just setting f to NULL and returning it.


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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-08 22:03

Message:
Logged In: YES 
user_id=33168

I just changed this to print an error message and exit in 2.5.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-11-14 16:16

Message:
Logged In: YES 
user_id=33168

Ok, I understand that part.  But if you can't accept input
from the user, what can you do?

If all you are suggesting is to change Py_FatalError() to
raising a SystemError and still exiting, I'm fine with that
if it can work.  I agree this would probably be nicer too. 
Or am I still missing your point?  Do you want to work on a
patch?  I'm fine with any improvement, I'm just not sure how
much can be done.  If you want to improve the error message,
that would be good too.

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

Comment By: Skip Montanaro (montanaro)
Date: 2005-11-14 15:57

Message:
Logged In: YES 
user_id=44345

No, we're still discussing stdin.  My only point is that what
you do might be predicated on whether or not you think you
can communicate with the user on stderr.

My thought was that if stderr is valid you can raise an exception
that prints a traceback.  If not, Py_FatalError is your only
recourse.  Your code checks for the directori-ness of stdin as
the first thing, then bails if it is.  If it checked to see if stderr was
valid first, it could decide to raise SystemError instead of
calling Py_FatalError.


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-11-14 14:08

Message:
Logged In: YES 
user_id=33168

Did you mistype and still mean stdin or are we talking about
stderr?

IIRC, calling Py_FatalError() was what I intended if stdin
is bogus.  I don't know what else to do.  If you can think
of scenarios where we could improve the behaviour, I think
that's fine to do.  I suppose you could set stdin to None,
but I'm not sure what that would do or if it would improve
anything.

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

Comment By: Skip Montanaro (montanaro)
Date: 2005-11-14 14:01

Message:
Logged In: YES 
user_id=44345

Well, I built from CVS^H^H^HSubversion HEAD at work and tried
again.  Still got a core dump, but that was a side-effect of
calling
Py_FatalError.  Is that the intended behavior?  I guess with a
bogus stderr that makes sense, but if stderr happened to be
valid at this point, I'd rather have it raise something more
meaningful for the user, like SystemError.


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

Comment By: Skip Montanaro (montanaro)
Date: 2005-11-12 05:18

Message:
Logged In: YES 
user_id=44345

Thanks Neal.  I'll check it out at work next week.


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-11-10 23:24

Message:
Logged In: YES 
user_id=33168

This should be fixed in 2.4.3 and CVS (2.3.5 is probably
affected too).  I remember dealing with directories
specifically.  Checkout the current sysmodule.c.  Here's the
checkin:  

r39652 | nnorwitz | 2005-10-02 18:03:46 -0700 (Sun, 02 Oct
2005) | 5 lines

SF bug #887946.

Let me know if this bug is different and the patch doesn't
solve the problem.

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

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

From noreply at sourceforge.net  Thu Mar  9 09:01:06 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 09 Mar 2006 00:01:06 -0800
Subject: [ python-Bugs-1446119 ] subprocess interpreted double quotation wrong
	on windows
Message-ID: <E1FHG54-0006Bx-OE@sc8-sf-web1.sourceforge.net>

Bugs item #1446119, was opened at 2006-03-09 04:26
Message generated for change (Settings changed) made by gbrandl
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.


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

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

From noreply at sourceforge.net  Thu Mar  9 09:12:51 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 09 Mar 2006 00:12:51 -0800
Subject: [ python-Bugs-1446043 ] unicode('foo',
	'.utf99') does not raise LookupError 
Message-ID: <E1FHGGR-000177-0l@sc8-sf-web6.sourceforge.net>

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

Please note that this 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: osvenskan (osvenskan)
Assigned to: M.-A. Lemburg (lemburg)
Summary: unicode('foo', '.utf99') does not raise LookupError 

Initial Comment:
A very minor inconsistency -- when I call unicode()
with an encoding that Python doesn't know about, it
usually returns a lookup error (e.g LookupError:
unknown encoding: utf99). But when the encoding begins
with a dot (ASCII 0x2e), Python instead gives a
ValueError: Empty module name. It is certainly correct
in raising an error, but it should raise a lookup
error, not a value error.

I've recreated this under Python 2.4.1/FreeBSD 6.0 and
2.3/OS X. See attachment for recreation steps.



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

>Comment By: Walter D?rwald (doerwalter)
Date: 2006-03-09 09:12

Message:
Logged In: YES 
user_id=89016

The problem is that after normalizing the encoding name a
module with this name is imported. Maybe
encodings/__init__.py:search_function should do:

if ".".join(filter(None, modname.split("."))) != modname:
   return None


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

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

From noreply at sourceforge.net  Thu Mar  9 09:16:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 09 Mar 2006 00:16:25 -0800
Subject: [ python-Bugs-1446043 ] unicode('foo',
	'.utf99') does not raise LookupError 
Message-ID: <E1FHGJt-00076f-W1@sc8-sf-web1.sourceforge.net>

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

Please note that this 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: osvenskan (osvenskan)
Assigned to: M.-A. Lemburg (lemburg)
Summary: unicode('foo', '.utf99') does not raise LookupError 

Initial Comment:
A very minor inconsistency -- when I call unicode()
with an encoding that Python doesn't know about, it
usually returns a lookup error (e.g LookupError:
unknown encoding: utf99). But when the encoding begins
with a dot (ASCII 0x2e), Python instead gives a
ValueError: Empty module name. It is certainly correct
in raising an error, but it should raise a lookup
error, not a value error.

I've recreated this under Python 2.4.1/FreeBSD 6.0 and
2.3/OS X. See attachment for recreation steps.



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

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-09 08:16

Message:
Logged In: YES 
user_id=849994

Is it possible for an encoding name to contain dots at all?

If not, this would do too:
if '.' in modname: continue

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

Comment By: Walter D?rwald (doerwalter)
Date: 2006-03-09 08:12

Message:
Logged In: YES 
user_id=89016

The problem is that after normalizing the encoding name a
module with this name is imported. Maybe
encodings/__init__.py:search_function should do:

if ".".join(filter(None, modname.split("."))) != modname:
   return None


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

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

From noreply at sourceforge.net  Thu Mar  9 09:21:06 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 09 Mar 2006 00:21:06 -0800
Subject: [ python-Bugs-1443328 ] Pickle protocol 2 fails on private slots.
Message-ID: <E1FHGOQ-0007PH-6U@sc8-sf-web1.sourceforge.net>

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

Please note that this message 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: Daniele Varrazzo (dvarrazzo)
>Assigned to: Tim Peters (tim_one)
Summary: Pickle protocol 2 fails on private slots.

Initial Comment:
The pickling protocol 2 can manage new style objects
defining __slots__ and without __dict__. Anyway it
fails when one of the slots is "private".

>>> class C1(object):
	__slots__ = ["__priv"]
	def __init__(self):
		self.__priv = 42
	def get_priv(self):
		return self.__priv

>>> C1().get_priv()
42
>>> import pickle
>>> pickle.loads(pickle.dumps(C1(), 2)).get_priv()

Traceback (most recent call last):
  File "<pyshell#258>", line 1, in -toplevel-
    pickle.loads(pickle.dumps(C1(), 2)).get_priv()
  File "<pyshell#255>", line 6, in get_priv
    return self.__priv
AttributeError: _C1__priv

of course redefining __getstate__ and __setstate__
bypasses the problem.

the cPickle module shows the same issue.

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

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-09 08:21

Message:
Logged In: YES 
user_id=849994

Confirmed with pickle and cPickle here.

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

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

From noreply at sourceforge.net  Thu Mar  9 14:28:06 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 09 Mar 2006 05:28:06 -0800
Subject: [ python-Bugs-1442874 ] handling comments with markupbase and
	HTMLParser
Message-ID: <E1FHLBW-0000nL-Mb@sc8-sf-web4-b.sourceforge.net>

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

Please note that this message 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: 3
Submitted By: Daniel (danielx_)
Assigned to: Nobody/Anonymous (nobody)
Summary: handling comments with markupbase and HTMLParser

Initial Comment:
If the following webpage is correct about the
definition of a comment, HTMLParser.HTMLParser reports
valid (albiet strange) comments as being erroenous:

http://www.htmlhelp.com/reference/wilbur/misc/comment.html

This site gives '<!>' as an example of a valid html
comment. See attachment for what happens at the
console. A similar thing happens with other
(pathalogical) form of comments.

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

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-09 13:28

Message:
Logged In: YES 
user_id=849994

Updated markupbase to cope with "<!>" in rev. 42938.

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

Comment By: Jim Jewett (jimjjewett)
Date: 2006-03-06 20:41

Message:
Logged In: YES 
user_id=764593

I recommend this as a wontfix.  

As the page itself notes, browsers generally got this 
wrong, and existing webpages rely on this buggy behavior.  
Even today, Opera is going back and forth on how right they 
can afford to be without breaking too many pages.

The suggestion at the bottom of the page notes that if you 
keep your comments sane, you won't have problems on your 
own pages.  Realistically, anything not following that rule 
(no embedded -- or >) is effectively buggy, and HTMLParser 
can only guess at the real intention.


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

Comment By: Daniel (danielx_)
Date: 2006-03-04 03:17

Message:
Logged In: YES 
user_id=1383230

Sorry, I'm unfamiliar with the bug reporting system and my
attachment doesn't seem to have attached.

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

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

From noreply at sourceforge.net  Thu Mar  9 16:04:14 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 09 Mar 2006 07:04:14 -0800
Subject: [ python-Bugs-1446043 ] unicode('foo',
	'.utf99') does not raise LookupError 
Message-ID: <E1FHMgY-000748-Fd@sc8-sf-web1.sourceforge.net>

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

Please note that this 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: osvenskan (osvenskan)
Assigned to: M.-A. Lemburg (lemburg)
Summary: unicode('foo', '.utf99') does not raise LookupError 

Initial Comment:
A very minor inconsistency -- when I call unicode()
with an encoding that Python doesn't know about, it
usually returns a lookup error (e.g LookupError:
unknown encoding: utf99). But when the encoding begins
with a dot (ASCII 0x2e), Python instead gives a
ValueError: Empty module name. It is certainly correct
in raising an error, but it should raise a lookup
error, not a value error.

I've recreated this under Python 2.4.1/FreeBSD 6.0 and
2.3/OS X. See attachment for recreation steps.



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

>Comment By: osvenskan (osvenskan)
Date: 2006-03-09 10:04

Message:
Logged In: YES 
user_id=1119995

There are encoding names that contain dots, such as
ANSI_X3.4-1968, ANSI_X3.4-1986 and ISO_646.IRV:1991 (as
reported by iconv). There are none in iconv's list that
begin with a dot. 

Please note that the behavior of this function has been
discussed before in Python bugs 513666 and 960874. Apologies
for not referencing them in my original report. 

Having stepped through the code, I understand how the
ValueError is getting generated. My frustration with this as
a programmer is that I want to write specific except clauses
for each possible exception that a method can raise, but
that's impractical if any exception is fair game on any
method. So I'm forced to use a catch-all except clause about
which the Python documentation says (wisely, IMHO), "Use
this with extreme caution, since it is easy to mask a real
programming error in this way!" While it is helpful to
document errors that a method is *likely* to raise, my code
needs to handle all possibilities, not just likely ones.

Perhaps the answer is just, "This is how Python works" and
if I feel it is a weakness in the language I need to take it
up on a different level. 

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

Comment By: Georg Brandl (gbrandl)
Date: 2006-03-09 03:16

Message:
Logged In: YES 
user_id=849994

Is it possible for an encoding name to contain dots at all?

If not, this would do too:
if '.' in modname: continue

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

Comment By: Walter D?rwald (doerwalter)
Date: 2006-03-09 03:12

Message:
Logged In: YES 
user_id=89016

The problem is that after normalizing the encoding name a
module with this name is imported. Maybe
encodings/__init__.py:search_function should do:

if ".".join(filter(None, modname.split("."))) != modname:
   return None


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

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

From noreply at sourceforge.net  Thu Mar  9 17:10:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 09 Mar 2006 08:10:42 -0800
Subject: [ python-Feature Requests-1404859 ] friendly quit object
Message-ID: <E1FHNis-0002xs-0S@sc8-sf-web4-b.sourceforge.net>

Feature Requests item #1404859, was opened at 2006-01-13 10:25
Message generated for change (Comment added) made by jimjjewett
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1404859&group_id=5470

Please note that this message 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: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: friendly quit object

Initial Comment:
Today, there is no cross-platform way to quit.

Today, typing quit returns a message that suggests the 
interpreter is willfully disobeying you.

Instead, change the quit object to one whose __call__ 
will exit, and whose __str__ says something like

"""
quit() exits the interpreter, by calling this quit 
object.
"""


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

>Comment By: Jim Jewett (jimjjewett)
Date: 2006-03-09 11:10

Message:
Logged In: YES 
user_id=764593

This RFE would be answered by applying patch 1446372


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

Comment By: Jim Jewett (jimjjewett)
Date: 2006-01-13 10:26

Message:
Logged In: YES 
user_id=764593

Rewording welcome; the point is that it should explain *why* 
it can't just exit immediately, unless it is explicitly 
called.


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

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

From noreply at sourceforge.net  Thu Mar  9 17:11:08 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 09 Mar 2006 08:11:08 -0800
Subject: [ python-Feature Requests-1404859 ] friendly quit object
Message-ID: <E1FHNjI-0005wf-KV@sc8-sf-web3.sourceforge.net>

Feature Requests item #1404859, was opened at 2006-01-13 10:25
Message generated for change (Comment added) made by jimjjewett
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1404859&group_id=5470

Please note that this message 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: Jim Jewett (jimjjewett)
>Assigned to: Georg Brandl (gbrandl)
Summary: friendly quit object

Initial Comment:
Today, there is no cross-platform way to quit.

Today, typing quit returns a message that suggests the 
interpreter is willfully disobeying you.

Instead, change the quit object to one whose __call__ 
will exit, and whose __str__ says something like

"""
quit() exits the interpreter, by calling this quit 
object.
"""


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

>Comment By: Jim Jewett (jimjjewett)
Date: 2006-03-09 11:11

Message:
Logged In: YES 
user_id=764593




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

Comment By: Jim Jewett (jimjjewett)
Date: 2006-03-09 11:10

Message:
Logged In: YES 
user_id=764593

This RFE would be answered by applying patch 1446372


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

Comment By: Jim Jewett (jimjjewett)
Date: 2006-01-13 10:26

Message:
Logged In: YES 
user_id=764593

Rewording welcome; the point is that it should explain *why* 
it can't just exit immediately, unless it is explicitly 
called.


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

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

From noreply at sourceforge.net  Thu Mar  9 18:37:34 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 09 Mar 2006 09:37:34 -0800
Subject: [ python-Bugs-1446619 ] extended slice behavior inconsistent with docs
Message-ID: <E1FHP4w-0008Ud-As@sc8-sf-web1.sourceforge.net>

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

Please note that this 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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Steven Bethard (bediviere)
Assigned to: Nobody/Anonymous (nobody)
Summary: extended slice behavior inconsistent with docs

Initial Comment:
I don't know whether the behavior or the docs is wrong,
but the extended slice behavior does not match the
documentation.  I found three places that talk about
extended slicing:

http://docs.python.org/ref/slicings.html
The semantics for a simple slicing are as follows... It
is not an error if i or j lie outside the range of
valid indexes (such items don't exist so they aren't
selected).
The semantics for an extended slicing are as follows...

http://docs.python.org/ref/types.html
Some sequences also support ``extended slicing'' with a
third ``step'' parameter: a[i:j:k] selects all items of
a with index x where x = i + n*k, n >= 0 and i <= x < j.

http://docs.python.org/lib/typesseq.html
s[i:j:k]   slice of s from i to j with step k   (3),(5)
...
(3) If i or j is negative, the index is relative to the
end of the string: len(s) + i or len(s) + j is
substituted. But note that -0 is still 0.
(5) The slice of s from i to j with step k is defined
as the sequence of items with index x = i + n*k such
that $0 \leq n < \frac{j-i}{k}$. In other words, the
indices are i, i+k, i+2*k, i+3*k and so on, stopping
when j is reached (but never including j). If i or j is
greater than len(s), use len(s). If i or j are omitted
then they become ``end'' values (which end depends on
the sign of k). Note, k cannot be zero.



Given those docs, consider this behavior:

>>> range(10)[10:0:-2]
[9, 7, 5, 3, 1]

By the Sequence Type Language Reference, [10:0:-2]
selects all items with index x where x = 10 + n*(-2), n
>= 0 and 10 <= x < 0.  Since no such values of x exist,
I conclude the result should have been an empty list.

By the Sequence Type Library Reference, [10:0:-2]
selects all items with index x = 10 + n*(-2) such that
0 <= n < (0 - 10)/(-2) = 5.  Thus I conclude that I
should get indices [10, 8, 6, 4, 2].  But this is also
wrong -- that would either have given me an IndexError,
if I stick to what's written for extended slicings, or
the list [8, 6, 4, 2] if I assume that the phrase "It
is not an error if i or j lie outside the range of
valid indexes" from the simple slicings section in the
Slicings Language Reference also applies to extended
slicings.


All the references I can find document this behavior
incorrectly.  I suggest rewording all the sections to
say something like:

"""
To get the slice of s from i to j with step k, first
determine the bounds.  If k is positive, and i or j is
greater than len(s), use len(s).  If k is negative, and
i or j is greater than len(s)-1, use len(s)-1. Note, k
cannot be zero.  If i or j are omitted then they become
``end'' values (which end depends on the sign of k). 

The slice of s from i to j with step k is then defined
as the sequence of items with index x = i + n*k such
that 0 <= n < (j - i)/k.  In other words, the indices
are i, i+k, i+2*k, i+3*k and so on, stopping when j is
reached (but never including j).
"""

The most important sentence above is "If k is negative,
and i or j is greater than len(s)-1, use len(s)-1." 
Without this sentence, the documentation doesn't match
the behavior.  The remainder of the rewording is to
make it clear that the bounds are adjusted *before* the
indices are calculated.

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

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

From noreply at sourceforge.net  Thu Mar  9 20:22:43 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 09 Mar 2006 11:22:43 -0800
Subject: [ python-Bugs-1446690 ] bug with xmlrpclib
Message-ID: <E1FHQih-0006li-EY@sc8-sf-web1.sourceforge.net>

Bugs item #1446690, was opened at 2006-03-09 19: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=1446690&group_id=5470

Please note that this 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.3
Status: Open
Resolution: None
Priority: 5
Submitted By: varun bhansaly (varun_bhansaly)
Assigned to: Nobody/Anonymous (nobody)
Summary: bug with xmlrpclib

Initial Comment:
I am currently working on a project in which I am
required to send some data from OpenOffice.org v2.0.(OOo)
I have placed buttons on the spreadsheet, and a python
script is to be invoked when the button is clicked.
I am required to send the data in the spreadsheet to an
app server, hence I am using XML-RPC to get this job done.
The version of XML-RPC(xmlrpclib.py) I'm using is
v1.36.2.1,
The app server requires the connection to be
authenticated, whereas the current xmlrpclib.py doesnot
come with support for sending requests with basic
authentication.
In order to extend the capabilities of the xmlrpclib.py
with http authentication, I have written code that
provides necessary basic authentication.(class
BasicAuthTransport in the attached file
Project_saveFromOOoCalcAction.py) The actual connection
and authentication details have been replaced for
security reasons.
When the button on the OOo spreadsheet is clicked, the
script throws the following error.

com.sun.star.uno.RuntimeExceptionexceptions.TypeError:
request() got an unexpected keyword argument 'verbose',
traceback follows 

File "usr/lib/python2.4/xmlrpclib.py", in line 1096, in
__call__
return self.__send(self.__name,args)

File "usr/lib/python2.4/xmlrpclib.py", in line 1383, in
__request
verbose=self.__verbose

When I comment out the line 1383 of the above file,
everything runs smoothly, this is a very trivial
solution though,as this would require me to comment out
the line 1383 of the above file n all the client
machines in which the script has to executed.

Hence I'm looking for a more viable solution. The files
are attached along.

Any help or advice in this regard shall be welcome.

regards,

-VB

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

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

From noreply at sourceforge.net  Fri Mar 10 00:25:44 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 09 Mar 2006 15:25:44 -0800
Subject: [ python-Feature Requests-1404859 ] friendly quit object
Message-ID: <E1FHUVs-0005So-AH@sc8-sf-web4-b.sourceforge.net>

Feature Requests item #1404859, was opened at 2006-01-13 15:25
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1404859&group_id=5470

Please note that this message 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: Jim Jewett (jimjjewett)
Assigned to: Georg Brandl (gbrandl)
Summary: friendly quit object

Initial Comment:
Today, there is no cross-platform way to quit.

Today, typing quit returns a message that suggests the 
interpreter is willfully disobeying you.

Instead, change the quit object to one whose __call__ 
will exit, and whose __str__ says something like

"""
quit() exits the interpreter, by calling this quit 
object.
"""


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

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-09 23:25

Message:
Logged In: YES 
user_id=849994

Patch 1446372 is now applied in rev. 42948.

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

Comment By: Jim Jewett (jimjjewett)
Date: 2006-03-09 16:11

Message:
Logged In: YES 
user_id=764593




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

Comment By: Jim Jewett (jimjjewett)
Date: 2006-03-09 16:10

Message:
Logged In: YES 
user_id=764593

This RFE would be answered by applying patch 1446372


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

Comment By: Jim Jewett (jimjjewett)
Date: 2006-01-13 15:26

Message:
Logged In: YES 
user_id=764593

Rewording welcome; the point is that it should explain *why* 
it can't just exit immediately, unless it is explicitly 
called.


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

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

From noreply at sourceforge.net  Fri Mar 10 00:45:51 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 09 Mar 2006 15:45:51 -0800
Subject: [ python-Bugs-1442493 ] IDLE shell window gets very slow when
	displaying long lines
Message-ID: <E1FHUpL-0007Ck-HD@sc8-sf-web5.sourceforge.net>

Bugs item #1442493, was opened at 2006-03-03 09:45
Message generated for change (Comment added) made by tjreedy
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: 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  Fri Mar 10 01:22:21 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 09 Mar 2006 16:22:21 -0800
Subject: [ python-Bugs-1441408 ] svn head compiler fails to spot extended
	slicing
Message-ID: <E1FHVOf-00028T-IA@sc8-sf-web2.sourceforge.net>

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

Please note that this 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: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Nobody/Anonymous (nobody)
Summary: svn head compiler fails to spot extended slicing

Initial Comment:
This is Python SVN HEAD:

>>> dis.dis(compile("x[::]", '', 'single'))
  1           0 LOAD_NAME                0 (x)
              3 SLICE+0             
              4 PRINT_EXPR          
              5 LOAD_CONST               0 (None)
              8 RETURN_VALUE        

This is Python 2.4:

>>> dis.dis(compile("x[::]", '', 'single'))
  1           0 LOAD_NAME                0 (x)
              3 LOAD_CONST               0 (None)
              6 LOAD_CONST               0 (None)
              9 LOAD_CONST               0 (None)
             12 BUILD_SLICE              3
             15 BINARY_SUBSCR       
             16 PRINT_EXPR          
             17 LOAD_CONST               0 (None)
             20 RETURN_VALUE        


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

Comment By: Grant Olson (logistix)
Date: 2006-03-09 18:22

Message:
Logged In: YES 
user_id=699438

Patch 1446847 Posted.

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

Comment By: Grant Olson (logistix)
Date: 2006-03-05 17:33

Message:
Logged In: YES 
user_id=699438

This only happens when you have implicit slice values. 
x[1:2:3] works fine.  I'm finishing up a patch and will post
to sf shortly.


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

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

From noreply at sourceforge.net  Fri Mar 10 03:33:47 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 09 Mar 2006 18:33:47 -0800
Subject: [ python-Bugs-1441486 ] yet another svn head compiler change
Message-ID: <E1FHXRr-0008Pi-3w@sc8-sf-web6.sourceforge.net>

Bugs item #1441486, was opened at 2006-03-02 00:39
Message generated for change (Comment added) made by logistix
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: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Nobody/Anonymous (nobody)
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: Grant Olson (logistix)
Date: 2006-03-09 20:33

Message:
Logged In: YES 
user_id=699438

Patch 1446922 posted.

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

Comment By: Grant Olson (logistix)
Date: 2006-03-06 17: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  Fri Mar 10 03:42:26 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 09 Mar 2006 18:42:26 -0800
Subject: [ python-Bugs-1446619 ] extended slice behavior inconsistent with docs
Message-ID: <E1FHXaE-0001S8-EN@sc8-sf-web5.sourceforge.net>

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

Please note that this 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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Steven Bethard (bediviere)
Assigned to: Nobody/Anonymous (nobody)
Summary: extended slice behavior inconsistent with docs

Initial Comment:
I don't know whether the behavior or the docs is wrong,
but the extended slice behavior does not match the
documentation.  I found three places that talk about
extended slicing:

http://docs.python.org/ref/slicings.html
The semantics for a simple slicing are as follows... It
is not an error if i or j lie outside the range of
valid indexes (such items don't exist so they aren't
selected).
The semantics for an extended slicing are as follows...

http://docs.python.org/ref/types.html
Some sequences also support ``extended slicing'' with a
third ``step'' parameter: a[i:j:k] selects all items of
a with index x where x = i + n*k, n >= 0 and i <= x < j.

http://docs.python.org/lib/typesseq.html
s[i:j:k]   slice of s from i to j with step k   (3),(5)
...
(3) If i or j is negative, the index is relative to the
end of the string: len(s) + i or len(s) + j is
substituted. But note that -0 is still 0.
(5) The slice of s from i to j with step k is defined
as the sequence of items with index x = i + n*k such
that $0 \leq n < \frac{j-i}{k}$. In other words, the
indices are i, i+k, i+2*k, i+3*k and so on, stopping
when j is reached (but never including j). If i or j is
greater than len(s), use len(s). If i or j are omitted
then they become ``end'' values (which end depends on
the sign of k). Note, k cannot be zero.



Given those docs, consider this behavior:

>>> range(10)[10:0:-2]
[9, 7, 5, 3, 1]

By the Sequence Type Language Reference, [10:0:-2]
selects all items with index x where x = 10 + n*(-2), n
>= 0 and 10 <= x < 0.  Since no such values of x exist,
I conclude the result should have been an empty list.

By the Sequence Type Library Reference, [10:0:-2]
selects all items with index x = 10 + n*(-2) such that
0 <= n < (0 - 10)/(-2) = 5.  Thus I conclude that I
should get indices [10, 8, 6, 4, 2].  But this is also
wrong -- that would either have given me an IndexError,
if I stick to what's written for extended slicings, or
the list [8, 6, 4, 2] if I assume that the phrase "It
is not an error if i or j lie outside the range of
valid indexes" from the simple slicings section in the
Slicings Language Reference also applies to extended
slicings.


All the references I can find document this behavior
incorrectly.  I suggest rewording all the sections to
say something like:

"""
To get the slice of s from i to j with step k, first
determine the bounds.  If k is positive, and i or j is
greater than len(s), use len(s).  If k is negative, and
i or j is greater than len(s)-1, use len(s)-1. Note, k
cannot be zero.  If i or j are omitted then they become
``end'' values (which end depends on the sign of k). 

The slice of s from i to j with step k is then defined
as the sequence of items with index x = i + n*k such
that 0 <= n < (j - i)/k.  In other words, the indices
are i, i+k, i+2*k, i+3*k and so on, stopping when j is
reached (but never including j).
"""

The most important sentence above is "If k is negative,
and i or j is greater than len(s)-1, use len(s)-1." 
Without this sentence, the documentation doesn't match
the behavior.  The remainder of the rewording is to
make it clear that the bounds are adjusted *before* the
indices are calculated.

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

Comment By: Grant Olson (logistix)
Date: 2006-03-09 20:42

Message:
Logged In: YES 
user_id=699438

One problem in your analysis that range(10) returns the array

[0,1,2,3,4,5,6,7,8,9]

not:

[1,2,3,4,5,6,7,8,9,10]

The 10th element of the array holds the value 9.  so when x
= 10 + (0*-2), you get 10.  Then:

[0,1,2,3,4,5,6,7,8,9][10]

will return 9

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

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

From noreply at sourceforge.net  Fri Mar 10 04:42:01 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 09 Mar 2006 19:42:01 -0800
Subject: [ python-Bugs-1446619 ] extended slice behavior inconsistent with docs
Message-ID: <E1FHYVt-00057K-Uo@sc8-sf-web5.sourceforge.net>

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

Please note that this 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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Steven Bethard (bediviere)
Assigned to: Nobody/Anonymous (nobody)
Summary: extended slice behavior inconsistent with docs

Initial Comment:
I don't know whether the behavior or the docs is wrong,
but the extended slice behavior does not match the
documentation.  I found three places that talk about
extended slicing:

http://docs.python.org/ref/slicings.html
The semantics for a simple slicing are as follows... It
is not an error if i or j lie outside the range of
valid indexes (such items don't exist so they aren't
selected).
The semantics for an extended slicing are as follows...

http://docs.python.org/ref/types.html
Some sequences also support ``extended slicing'' with a
third ``step'' parameter: a[i:j:k] selects all items of
a with index x where x = i + n*k, n >= 0 and i <= x < j.

http://docs.python.org/lib/typesseq.html
s[i:j:k]   slice of s from i to j with step k   (3),(5)
...
(3) If i or j is negative, the index is relative to the
end of the string: len(s) + i or len(s) + j is
substituted. But note that -0 is still 0.
(5) The slice of s from i to j with step k is defined
as the sequence of items with index x = i + n*k such
that $0 \leq n < \frac{j-i}{k}$. In other words, the
indices are i, i+k, i+2*k, i+3*k and so on, stopping
when j is reached (but never including j). If i or j is
greater than len(s), use len(s). If i or j are omitted
then they become ``end'' values (which end depends on
the sign of k). Note, k cannot be zero.



Given those docs, consider this behavior:

>>> range(10)[10:0:-2]
[9, 7, 5, 3, 1]

By the Sequence Type Language Reference, [10:0:-2]
selects all items with index x where x = 10 + n*(-2), n
>= 0 and 10 <= x < 0.  Since no such values of x exist,
I conclude the result should have been an empty list.

By the Sequence Type Library Reference, [10:0:-2]
selects all items with index x = 10 + n*(-2) such that
0 <= n < (0 - 10)/(-2) = 5.  Thus I conclude that I
should get indices [10, 8, 6, 4, 2].  But this is also
wrong -- that would either have given me an IndexError,
if I stick to what's written for extended slicings, or
the list [8, 6, 4, 2] if I assume that the phrase "It
is not an error if i or j lie outside the range of
valid indexes" from the simple slicings section in the
Slicings Language Reference also applies to extended
slicings.


All the references I can find document this behavior
incorrectly.  I suggest rewording all the sections to
say something like:

"""
To get the slice of s from i to j with step k, first
determine the bounds.  If k is positive, and i or j is
greater than len(s), use len(s).  If k is negative, and
i or j is greater than len(s)-1, use len(s)-1. Note, k
cannot be zero.  If i or j are omitted then they become
``end'' values (which end depends on the sign of k). 

The slice of s from i to j with step k is then defined
as the sequence of items with index x = i + n*k such
that 0 <= n < (j - i)/k.  In other words, the indices
are i, i+k, i+2*k, i+3*k and so on, stopping when j is
reached (but never including j).
"""

The most important sentence above is "If k is negative,
and i or j is greater than len(s)-1, use len(s)-1." 
Without this sentence, the documentation doesn't match
the behavior.  The remainder of the rewording is to
make it clear that the bounds are adjusted *before* the
indices are calculated.

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

>Comment By: Steven Bethard (bediviere)
Date: 2006-03-09 20:42

Message:
Logged In: YES 
user_id=945502

logistix wrote:
> [0,1,2,3,4,5,6,7,8,9][10]
> will return 9

Huh?  Python indexing starts from 0.  Hence:

>>> range(10)[10]
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
IndexError: list index out of range

>>> [0,1,2,3,4,5,6,7,8,9][10]
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
IndexError: list index out of range

If I didn't understand your complaint, please explain it again.

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

Comment By: Grant Olson (logistix)
Date: 2006-03-09 19:42

Message:
Logged In: YES 
user_id=699438

One problem in your analysis that range(10) returns the array

[0,1,2,3,4,5,6,7,8,9]

not:

[1,2,3,4,5,6,7,8,9,10]

The 10th element of the array holds the value 9.  so when x
= 10 + (0*-2), you get 10.  Then:

[0,1,2,3,4,5,6,7,8,9][10]

will return 9

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

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

From noreply at sourceforge.net  Fri Mar 10 06:43:04 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 09 Mar 2006 21:43:04 -0800
Subject: [ python-Bugs-1445210 ] embedding Python causes memory leaks
Message-ID: <E1FHaP2-0004Fd-TU@sc8-sf-web5.sourceforge.net>

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

Please note that this message 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: Andrew Trevorrow (andykt)
Assigned to: Nobody/Anonymous (nobody)
Summary: embedding Python causes memory leaks

Initial Comment:
[This bug has been submitted by others but for some reason it
has been marked Closed.  I consider it to be an extremely serious
bug -- if I can't solve it I'm going to have to abandon Python as
my app's scripting language, even though I've fallen in love!]

I've added Python script support to my cross-platfom wxWidgets app
so that users can run .py scripts from within the app to automate the
GUI and do other fancy things.  It all works very nicely, except for
one nasty problem: *every* time a script is run there is a memory leak,
usually small (about 10K) but sometimes massive (about 4MB in the 
case of one rather complicated script).

The problem occurs on both Mac OS 10.3.9 and Windows 2000.
I'm using Python 2.3 on the Mac and 2.4.2 on Windows.

Every time the user runs a script, my app makes these calls:
(I've removed a lot of irrelevant stuff.)

   Py_Initialize();
   PyRun_SimpleString("execfile('foo.py')");
   Py_Finalize();

It's definitely not a wxWidgets problem.  In fact it's quite easy to
see the memory leak using a simple command-line program:

#include <stdio.h>
#include <Python.h>
main(int argc, char *argv[])
{
   int i;
   for (i=0; i<1000; i++) {
      Py_Initialize();
      Py_Finalize();
      printf(".");
      if ((i+1) % 50 == 0) printf("\n");
   }
}

Note that it doesn't even execute a script.  If I run this program on
my Mac and watch its memory usage with Activity Monitor, I see a leak
of about 10K each time through the loop.  Similar result on Windows.

Curiously, on both machines, the Py_Finalize() call takes longer and
longer to complete whatever it's doing.  The above program takes a
few *minutes* to complete on my 400MHz Mac.

Andrew


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

>Comment By: Andrew Trevorrow (andykt)
Date: 2006-03-10 16:43

Message:
Logged In: YES 
user_id=1281947

See http://evanjones.ca/python-memory.html for some
useful info.  Apparently the Python memory allocator never
releases memory back to the OS!  So if a complicated script
happens to consume 100MB of interpreter memory then
that amount is no longer available to the app in which
Python is embedded.  Even worse, if a script has a
(Python) memory leak then there's nothing the app can
do about it.  It would be great if wrapping each script
inside Py_Initialize/Py_Finalize could avoid all that.

There should be some way to tell Python "release all
the memory you've ever allocated and start again
with a clean slate".



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

Comment By: Andrew Trevorrow (andykt)
Date: 2006-03-08 20:50

Message:
Logged In: YES 
user_id=1281947

Bloody hell -- sorry for the bad line breaks.
One day I'll figure out how to use sf properly!


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

Comment By: Andrew Trevorrow (andykt)
Date: 2006-03-08 20:46

Message:
Logged In: YES 
user_id=1281947

> Why do you call Py_Initialize/Py_Finalize more than once?

How else do I tell Python to free up memory after each PyRun_SimpleString
call?

I want users to be able to run scripts many times from within my app.
If I just keep calling PyRun_SimpleString then my app will leak more and
more memory until it becomes unusable.

>From http://docs.python.org/api/embedding.html:

  Sometimes, it is desirable to ``uninitialize'' Python. For instance, the
  application may want to start over (make another call to Py_Initialize())
  or the application is simply done with its use of Python and wants to free
  all memory allocated by Python. This can be accomplished by calling
  Py_Finalize().

That's exactly what I want to do.  I want the interpreter to run a script
and then release all the resources used by that script.  Unfortunately,
Py_Finalize does *not* restore memory usage to what it was before the
Py_Initialize call.  I wouldn't mind if there was a one-off allocation
cost (the 1st time Py_Initialize is called), but my app is leaking more
memory *every* time a script is run!


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-08 19:32

Message:
Logged In: YES 
user_id=33168

Why do you call Py_Initialize/Py_Finalize more than once? 
Why not do something like this (I'm kinda mixing C and
Python for convenience):

 /* startup */
 Py_Initialize();

 /* do whatever */
 while (moreFiles()) {
   PyRun_SimpleString("execfile('%s')" % nextFile());
   /* do whatever */
 }

 /* shutdown */
 Py_Finalize();


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

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

From noreply at sourceforge.net  Fri Mar 10 08:44:30 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 09 Mar 2006 23:44:30 -0800
Subject: [ python-Bugs-1447031 ] whatsnew 2.5: pep 353, python -m
Message-ID: <E1FHcIY-0002ac-76@sc8-sf-web6.sourceforge.net>

Bugs item #1447031, was opened at 2006-03-09 23:44
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1447031&group_id=5470

Please note that this 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: Gene Tani (gtani)
Assigned to: Nobody/Anonymous (nobody)
Summary: whatsnew 2.5: pep 353, python -m

Initial Comment:
http://docs.python.org/dev/whatsnew/whatsnew25.html

I don't see mention of PEP 353 (indexing with ssize_t)
or the python -m switch, as per:

http://agiletesting.blogspot.com/2006/02/pycon-notes-part-2-guidos-keynote.html


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

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

From noreply at sourceforge.net  Fri Mar 10 09:15:08 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 10 Mar 2006 00:15:08 -0800
Subject: [ python-Bugs-1447031 ] whatsnew 2.5: pep 353, python -m
Message-ID: <E1FHcmC-0006Oz-Ks@sc8-sf-web2.sourceforge.net>

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

Please note that this 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: Gene Tani (gtani)
>Assigned to: A.M. Kuchling (akuchling)
Summary: whatsnew 2.5: pep 353, python -m

Initial Comment:
http://docs.python.org/dev/whatsnew/whatsnew25.html

I don't see mention of PEP 353 (indexing with ssize_t)
or the python -m switch, as per:

http://agiletesting.blogspot.com/2006/02/pycon-notes-part-2-guidos-keynote.html


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

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

From noreply at sourceforge.net  Fri Mar 10 13:00:39 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 10 Mar 2006 04:00:39 -0800
Subject: [ python-Bugs-1054943 ] Python may contain NFC/NFKC bug per Unicode
	PRI #29
Message-ID: <E1FHgIR-00029z-3Z@sc8-sf-web4-b.sourceforge.net>

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

Please note that this 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.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Rick McGowan (rick_mcgowan)
Assigned to: Martin v. L??wis (loewis)
Summary: Python may contain NFC/NFKC bug per Unicode PRI #29

Initial Comment:
The Unicode Technical Committee posted Public Review
Issue #29, describing a bug in the documentation of NFC
and NFKC in the text of UAX #15 Unicode Normalization
Forms. I have examined unicodedata.c in the Python
implementation (2.3.4) and it appears the
implementation of normalization in Python 2.3.4 may
have the bug therein described. Please see the
description of the bug and the textual fix that is
being made to UAX #15, at the URL:
http://www.unicode.org/review/pr-29.html
The bug is in the definition of rule D2, affecting the
characters "blocked" during re-composition.

You may contact me by e-mail, or fill out the
Unicode.org error reporting form if you have any
questions or concerns.

Since Python uses Unicode internally, it may also be
wise to have someone from the Python development
community on the Unicode Consortium's notification list
to receive immediate notifications of public review
issues, bugs, and other announcements affecting
implementation of the standard.


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

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

Message:
Logged In: YES 
user_id=21627

When this is fixed, the @Part3 data in the normalization
tests need to be considered as well.

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

Comment By: Rick McGowan (rick_mcgowan)
Date: 2005-03-15 17:45

Message:
Logged In: YES 
user_id=1146994

Yes. The "current" version of UAX #15 is an annex to Unicode
4.1, which will be coming out very soon. No previous
versions of Unicode have been changed. Previous versions of
UAX #15 apply to previous versions of the standard. The UTC
plans to issue a "corrigendum" for this problem, and the
corrigendum is something that *can* be applied to
implementations of earlier versions of Unicode. In that
case, one would cite the implementation of "Unicode Version
X with Corrigendum Y" as shown on the "Enumerated Versions"
page of the Unicode web site. To follow corrigenda, you may
want to keep tabs on the "Updates and Errata" page on the
Unicode web site. This is likely to be Corrigendum #5. You
could fix the bug when you update Python to Unicode 4.1, or
fix it when the corrigendum comes out. Of course, I would
recommend fixing bugs sooner rather than later, but your
release plans may be such that one path is easier. If it's
going to be a long time before you update to 4.1, you may
want to fix the bug and cite the corrigendum when it comes
out. If you plan to update to 4.1 soon after it comes out,
perhaps fixing the bug with that update is fine.


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

Comment By: Martin v. L??wis (loewis)
Date: 2005-03-15 09:59

Message:
Logged In: YES 
user_id=21627

Is it true that the most recent interpretation of this PR
suggests that the correction should only apply to Unicode
4.1? If so, I think Python should abstain from adopting the
change right now, and should defer that to the point when
the Unicode 4.1 database is incorporated.

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

Comment By: Rick McGowan (rick_mcgowan)
Date: 2004-10-27 22:11

Message:
Logged In: YES 
user_id=1146994

Thanks all for quick reply. My initial thoughts regarding a
fix were as below. The relevant piece of code seems to be in
function "nfc_nfkc()" in the file unicodedata.c

>           if (comb1 && comb == comb1) { 
>               /* Character is blocked. */ 
>               i1++; 
>               continue; 
>           } 

That should possibly be changed to: 

>           if (comb1 && (comb <= comb1)) { 
>               /* Character is blocked. */ 
>               i1++; 
>               continue; 
>           } 

because the new spec says "either B is a starter or it has
the same or higher combining class as C".


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-10-27 20:11

Message:
Logged In: YES 
user_id=38388

Thanks for submitting a bug report. The problem does indeed
occur in the Python normalization code:

>>> unicodedata.normalize('NFC', u'\u0B47\u0300\u0B3E')
u'\u0b4b\u0300'

I think the following line in unicodedata.c needs to be changed:

          if (comb1 && comb == comb1) {
              /* Character is blocked. */
              i1++;
              continue;
          }

to

          if (comb && (comb1 == 0 || comb == comb1)) {
              /* Character is blocked. */
              i1++;
              continue;
          }

Martin, what do you think ?

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

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

From noreply at sourceforge.net  Fri Mar 10 14:54:22 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 10 Mar 2006 05:54:22 -0800
Subject: [ python-Bugs-1447222 ] tkinter Dialog fails when more than four
	buttons are used
Message-ID: <E1FHi4U-0000fn-D2@sc8-sf-web1.sourceforge.net>

Bugs item #1447222, was opened at 2006-03-10 10:54
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1447222&group_id=5470

Please note that this 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: Hernan P. Dacharry (hernanpd)
Assigned to: Martin v. L??wis (loewis)
Summary: tkinter Dialog fails when more than four buttons are used

Initial Comment:
Example code:

#! /usr/bin/env python
import Dialog
from Tkinter import *
root = Tk()
Button(root, text="Hello!").pack()
root.update()
dialog = Dialog.Dialog(None, {'title': 'Test Dialog',
          'text': "Text...",
          'bitmap': '',
          'default': 0,
          'strings':
('Button0','Button1','Button2','Button3','Button4')})
print 'dialog: ', dialog.num


This example works well, except when clicking in
Button4 that fails:
Traceback (most recent call last):
  File "test.py", line 12, in ?
    dialog = Dialog.Dialog(None, {'title': 'Test Dialog',
  File "/usr/lib/python2.3/lib-tk/Dialog.py", line 21,
in __init__
    cnf['bitmap'], cnf['default'],
TypeError: getint() argument 1 must be string, not tuple

I tried to trace the error (learning in the way a
little bit of python and tcl/tk ;)), mostly due to the
bizarre nature of this problem (note that in tcl/tk
there are no problems when creating dialogs with 4 or
more buttons).

In /usr/lib/python2.3/lib-tk/Dialog/py the exception is
raised because it expects a string as the result to the
call to 'tk_dialog', and for some 'obscure' reason (and
I mean it, I even inspected the Tcl/Tk sources looking
for a reason for this) if the call to 'tk_dialog' has
more than 4 buttons (more than 4 string arguments at
the end) it return a tuple with only one element, the
string result.

The impression I got after browsing the sources of
python/tkinter and Tcl/Tk is that this may be caused
because in tcl there is almost no difference between a
list and string, in this way in the tcl language a
string or a list containing only one string are not
really different.

I have this problem when using python2.3 or python2.4
with Tcl/Tk8.4 (in my particular case under
Debian/Testing distribution);

A quick workaround (although I 'm not sure if it would
cause some problems with other things) would be to
change 'workarounds = 1' to 'workarounds = 0' in
Tkinter.py.
Another option would be to change all calls to tk
functions within tkinter that allways expect as a
result a string...

Hernan
(my apologies for making the report so long) 

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

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

From noreply at sourceforge.net  Fri Mar 10 15:12:04 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 10 Mar 2006 06:12:04 -0800
Subject: [ python-Bugs-1447234 ] tkinter Dialog fails when more than four
	buttons are used
Message-ID: <E1FHiLc-0003Wy-7p@sc8-sf-web2.sourceforge.net>

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

Please note that this 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: Hernan P. Dacharry (hernanpd)
Assigned to: Martin v. L??wis (loewis)
Summary: tkinter Dialog fails when more than four buttons are used

Initial Comment:
Example code:

#! /usr/bin/env python
import Dialog
from Tkinter import *
root = Tk()
Button(root, text="Hello!").pack()
root.update()
dialog = Dialog.Dialog(None, {'title': 'Test Dialog',
          'text': "Text...",
          'bitmap': '',
          'default': 0,
          'strings':
('Button0','Button1','Button2','Button3','Button4')})
print 'dialog: ', dialog.num


This example works well, except when clicking in
Button4 that fails:
Traceback (most recent call last):
  File "test.py", line 12, in ?
    dialog = Dialog.Dialog(None, {'title': 'Test Dialog',
  File "/usr/lib/python2.3/lib-tk/Dialog.py", line 21,
in __init__
    cnf['bitmap'], cnf['default'],
TypeError: getint() argument 1 must be string, not tuple

I tried to trace the error (learning in the way a
little bit of python and tcl/tk ;)), mostly due to the
bizarre nature of this problem (note that in tcl/tk
there are no problems when creating dialogs with 4 or
more buttons).

In /usr/lib/python2.3/lib-tk/Dialog/py the exception is
raised because it expects a string as the result to the
call to 'tk_dialog', and for some 'obscure' reason (and
I mean it, I even inspected the Tcl/Tk sources looking
for a reason for this) if the call to 'tk_dialog' has
more than 4 buttons (more than 4 string arguments at
the end) it return a tuple with only one element, the
string result.

The impression I got after browsing the sources of
python/tkinter and Tcl/Tk is that this may be caused
because in tcl there is almost no difference between a
list and string, in this way in the tcl language a
string or a list containing only one string are not
really different.

I have this problem when using python2.3 or python2.4
with Tcl/Tk8.4 (in my particular case under
Debian/Testing distribution);

A quick workaround (although I 'm not sure if it would
cause some problems with other things) would be to
change 'workarounds = 1' to 'workarounds = 0' in
Tkinter.py.
Another option would be to change all calls to tk
functions within tkinter that allways expect as a
result a string...

Hernan
(my apologies for making the report so long) 

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

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

From noreply at sourceforge.net  Fri Mar 10 21:18:30 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 10 Mar 2006 12:18:30 -0800
Subject: [ python-Bugs-1442493 ] IDLE shell window gets very slow when
	displaying long lines
Message-ID: <E1FHo4E-0000OQ-8I@sc8-sf-web5.sourceforge.net>

Bugs item #1442493, was opened at 2006-03-03 06:45
Message generated for change (Comment added) made by josiahcarlson
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: Josiah Carlson (josiahcarlson)
Date: 2006-03-10 12: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 15: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  Fri Mar 10 23:02:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 10 Mar 2006 14:02:25 -0800
Subject: [ python-Bugs-1447587 ] Mac Framework build fails on intel
Message-ID: <E1FHpgn-00072f-00@sc8-sf-web5.sourceforge.net>

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

Please note that this 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: Michael Mondragon (mammon_)
Assigned to: Nobody/Anonymous (nobody)
Summary: Mac Framework build fails on intel

Initial Comment:
hardware: intel duo imac 20"
os x: 10.4.6

steps:
------
./configure
--enable-framework=/Library/Frameworks/Python.framework
--enable-shared
make
...
 c++  -u _PyMac_Error
Python.framework/Versions/2.4/Python -o python.exe \
                Modules/python.o \
                 -ldl      
/usr/bin/ld: warning
Python.framework/Versions/2.4/Python cputype (18,
architecture ppc) does not match cputype (7) for
specified -arch flag: i386 (file not loaded)
/usr/bin/ld: Undefined symbols:
_PyMac_Error
_Py_Main
collect2: ld returned 1 exit status
make: *** [python.exe] Error 1


analysis:
---------

The arch flag for the Python shared library in
the framework is incorrect.

file shows Python.framework/Versions/2.4/Python
to be a PPC binary.


scroll up in terminal to find link statement for
Python:

libtool -o Python.framework/Versions/2.4/Python
-dynamic  libpython2.4.a \
         -lSystem -lSystemStubs -arch_only ppc
-install_name
/Library/Frameworks/Python.framework/Python.framework/Versions/2.4/Python
-compatibility_version 2.4 -current_version 2.4

The '-arch_only ppc' flag is the problem.


workaround:
-----------

After running configure, open makefile and so
a s/arch_only ppc/arch_only i386/g


what needs to be fixed:
-----------------------

Around line 10218 in configure:
  Darwin/[01234567].*)    LIBTOOL_CRUFT="-framework
System -lcc_dynamic -arch_only ppc"   
LIBTOOL_CRUFT=$LIBTOOL_CRUFT' -install_name
$(PYTHONFRAMEWORKINSTALLDIR)/Versions/$(VERSION)/$(PYTHONFRAMEWORK)'
    LIBTOOL_CRUFT=$LIBTOOL_CRUFT'
-compatibility_version $(VERSION) -current_version
$(VERSION)';;
  Darwin/*)
    gcc_version=`gcc -v 2>&1 |  grep version | cut -d\
 -f3`
    if test ${gcc_version} '<' 4.0
        then
            LIBTOOL_CRUFT="-lcc_dynamic"
        else
            LIBTOOL_CRUFT=""
    fi


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

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

From noreply at sourceforge.net  Fri Mar 10 23:30:18 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 10 Mar 2006 14:30:18 -0800
Subject: [ python-Bugs-1447234 ] tkinter Dialog fails when more than four
	buttons are used
Message-ID: <E1FHq7m-00035N-Kj@sc8-sf-web3.sourceforge.net>

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

Please note that this 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: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Hernan P. Dacharry (hernanpd)
Assigned to: Martin v. L??wis (loewis)
Summary: tkinter Dialog fails when more than four buttons are used

Initial Comment:
Example code:

#! /usr/bin/env python
import Dialog
from Tkinter import *
root = Tk()
Button(root, text="Hello!").pack()
root.update()
dialog = Dialog.Dialog(None, {'title': 'Test Dialog',
          'text': "Text...",
          'bitmap': '',
          'default': 0,
          'strings':
('Button0','Button1','Button2','Button3','Button4')})
print 'dialog: ', dialog.num


This example works well, except when clicking in
Button4 that fails:
Traceback (most recent call last):
  File "test.py", line 12, in ?
    dialog = Dialog.Dialog(None, {'title': 'Test Dialog',
  File "/usr/lib/python2.3/lib-tk/Dialog.py", line 21,
in __init__
    cnf['bitmap'], cnf['default'],
TypeError: getint() argument 1 must be string, not tuple

I tried to trace the error (learning in the way a
little bit of python and tcl/tk ;)), mostly due to the
bizarre nature of this problem (note that in tcl/tk
there are no problems when creating dialogs with 4 or
more buttons).

In /usr/lib/python2.3/lib-tk/Dialog/py the exception is
raised because it expects a string as the result to the
call to 'tk_dialog', and for some 'obscure' reason (and
I mean it, I even inspected the Tcl/Tk sources looking
for a reason for this) if the call to 'tk_dialog' has
more than 4 buttons (more than 4 string arguments at
the end) it return a tuple with only one element, the
string result.

The impression I got after browsing the sources of
python/tkinter and Tcl/Tk is that this may be caused
because in tcl there is almost no difference between a
list and string, in this way in the tcl language a
string or a list containing only one string are not
really different.

I have this problem when using python2.3 or python2.4
with Tcl/Tk8.4 (in my particular case under
Debian/Testing distribution);

A quick workaround (although I 'm not sure if it would
cause some problems with other things) would be to
change 'workarounds = 1' to 'workarounds = 0' in
Tkinter.py.
Another option would be to change all calls to tk
functions within tkinter that allways expect as a
result a string...

Hernan
(my apologies for making the report so long) 

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

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-10 22:30

Message:
Logged In: YES 
user_id=849994

Duplicate of #1447222.

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

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

From noreply at sourceforge.net  Fri Mar 10 23:40:07 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 10 Mar 2006 14:40:07 -0800
Subject: [ python-Bugs-1446619 ] extended slice behavior inconsistent with docs
Message-ID: <E1FHqHH-0000jf-G7@sc8-sf-web1.sourceforge.net>

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

Please note that this 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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Steven Bethard (bediviere)
Assigned to: Nobody/Anonymous (nobody)
Summary: extended slice behavior inconsistent with docs

Initial Comment:
I don't know whether the behavior or the docs is wrong,
but the extended slice behavior does not match the
documentation.  I found three places that talk about
extended slicing:

http://docs.python.org/ref/slicings.html
The semantics for a simple slicing are as follows... It
is not an error if i or j lie outside the range of
valid indexes (such items don't exist so they aren't
selected).
The semantics for an extended slicing are as follows...

http://docs.python.org/ref/types.html
Some sequences also support ``extended slicing'' with a
third ``step'' parameter: a[i:j:k] selects all items of
a with index x where x = i + n*k, n >= 0 and i <= x < j.

http://docs.python.org/lib/typesseq.html
s[i:j:k]   slice of s from i to j with step k   (3),(5)
...
(3) If i or j is negative, the index is relative to the
end of the string: len(s) + i or len(s) + j is
substituted. But note that -0 is still 0.
(5) The slice of s from i to j with step k is defined
as the sequence of items with index x = i + n*k such
that $0 \leq n < \frac{j-i}{k}$. In other words, the
indices are i, i+k, i+2*k, i+3*k and so on, stopping
when j is reached (but never including j). If i or j is
greater than len(s), use len(s). If i or j are omitted
then they become ``end'' values (which end depends on
the sign of k). Note, k cannot be zero.



Given those docs, consider this behavior:

>>> range(10)[10:0:-2]
[9, 7, 5, 3, 1]

By the Sequence Type Language Reference, [10:0:-2]
selects all items with index x where x = 10 + n*(-2), n
>= 0 and 10 <= x < 0.  Since no such values of x exist,
I conclude the result should have been an empty list.

By the Sequence Type Library Reference, [10:0:-2]
selects all items with index x = 10 + n*(-2) such that
0 <= n < (0 - 10)/(-2) = 5.  Thus I conclude that I
should get indices [10, 8, 6, 4, 2].  But this is also
wrong -- that would either have given me an IndexError,
if I stick to what's written for extended slicings, or
the list [8, 6, 4, 2] if I assume that the phrase "It
is not an error if i or j lie outside the range of
valid indexes" from the simple slicings section in the
Slicings Language Reference also applies to extended
slicings.


All the references I can find document this behavior
incorrectly.  I suggest rewording all the sections to
say something like:

"""
To get the slice of s from i to j with step k, first
determine the bounds.  If k is positive, and i or j is
greater than len(s), use len(s).  If k is negative, and
i or j is greater than len(s)-1, use len(s)-1. Note, k
cannot be zero.  If i or j are omitted then they become
``end'' values (which end depends on the sign of k). 

The slice of s from i to j with step k is then defined
as the sequence of items with index x = i + n*k such
that 0 <= n < (j - i)/k.  In other words, the indices
are i, i+k, i+2*k, i+3*k and so on, stopping when j is
reached (but never including j).
"""

The most important sentence above is "If k is negative,
and i or j is greater than len(s)-1, use len(s)-1." 
Without this sentence, the documentation doesn't match
the behavior.  The remainder of the rewording is to
make it clear that the bounds are adjusted *before* the
indices are calculated.

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

Comment By: Grant Olson (logistix)
Date: 2006-03-10 16:40

Message:
Logged In: YES 
user_id=699438

You're right.  I misunderstood what you were saying.  I was
trying to point out that you wouldn't have an element '10'
but I now see that you said "indicies[10...]", not
values[10...].

Sorry.

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

Comment By: Steven Bethard (bediviere)
Date: 2006-03-09 21:42

Message:
Logged In: YES 
user_id=945502

logistix wrote:
> [0,1,2,3,4,5,6,7,8,9][10]
> will return 9

Huh?  Python indexing starts from 0.  Hence:

>>> range(10)[10]
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
IndexError: list index out of range

>>> [0,1,2,3,4,5,6,7,8,9][10]
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
IndexError: list index out of range

If I didn't understand your complaint, please explain it again.

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

Comment By: Grant Olson (logistix)
Date: 2006-03-09 20:42

Message:
Logged In: YES 
user_id=699438

One problem in your analysis that range(10) returns the array

[0,1,2,3,4,5,6,7,8,9]

not:

[1,2,3,4,5,6,7,8,9,10]

The 10th element of the array holds the value 9.  so when x
= 10 + (0*-2), you get 10.  Then:

[0,1,2,3,4,5,6,7,8,9][10]

will return 9

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

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

From noreply at sourceforge.net  Sat Mar 11 00:13:09 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 10 Mar 2006 15:13:09 -0800
Subject: [ python-Bugs-1447607 ] make frameworkinstall fails on Intel Macs
Message-ID: <E1FHqnF-0004Tp-Lg@sc8-sf-web2.sourceforge.net>

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

Please note that this 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: Michael Mondragon (mammon_)
Assigned to: Nobody/Anonymous (nobody)
Summary: make frameworkinstall fails on Intel Macs

Initial Comment:
make frameworkinstall fails on Intel Macs 
due to an endian error.

Hardware: Intel Duo iMac 20"
OS Version: OS X 10.4.6

Error:
------

  File
"/Users/Shared/Downloads/Python-2.4.2/Lib/plat-mac/applesingle.py",
line 58, in __init__
    raise Error, "Unknown AppleSingle magic number
0x%8.8x" % (magic,)
applesingle.Error: Unknown AppleSingle magic number
0x00160500
make[1]: *** [installmacsubtree] Error 1
make: *** [frameworkinstallmaclib] Error 2

Looking in the file at line 31:

AS_MAGIC=0x00051600

...it seems fairly obvious that byte order is
reverse. Looks like the file is in big-endian
format, not ntaive format.


Fix:
----

vi Lib/plat-mac/applesingle.py

Line 28: Replace 
   AS_HEADER_FORMAT="LL16sh"
with
   AS_HEADER_FORMAT=">LL16sh"

Line 35: Replace
  AS_ENTRY_FORMAT="lll"
with
  AS_ENTRY_FORMAT=">lll"

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

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

From noreply at sourceforge.net  Sat Mar 11 00:55:17 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 10 Mar 2006 15:55:17 -0800
Subject: [ python-Bugs-1447633 ] "reindent.py" exposes bug in tokenize
Message-ID: <E1FHrS1-0008R2-7i@sc8-sf-web3.sourceforge.net>

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

Please note that this message 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: Edward C. Jones (edcjones)
Assigned to: Nobody/Anonymous (nobody)
Summary: "reindent.py" exposes bug in tokenize

Initial Comment:
I use up-to-date Debian unstable (i368 port) on a PC with a AMD Athlon64
+3500 chip. I compile my own copy of Python which I keep in /usr/local.

Here is a small Python program called "fixnames.py":

#! /usr/bin/env python

"""Rename files that contain unpleasant characters.

Modify this code as needed.
"""
import os, sys, optparse

usage = 'USAGE: ./fixnames.py [-h] <filelist>'
parser = optparse.OptionParser(usage=usage)
options, args = parser.parse_args()
if len(args) != 1:
    parser.print_help()
    sys.exit('an argument is required'))

# The input is a list of files to be renamed.
for name in open(args[0]), 'r'):
    # Modify these as needed.
    newname = name.replace(' ', '_')
    newname = newname.replace('@', '_at_')
    newname = newname.replace('%20', '_')
    newname = newname.replace("'", '')
    os.rename(name, newname)

If I run

python /usr/local/src/Python-2.4.2/Tools/scripts/reindent.py fixnames.py

I get
Traceback (most recent call last):
  File "/usr/local/src/Python-2.4.2/Tools/scripts/reindent.py", line 293, in ?
    main()
  File "/usr/local/src/Python-2.4.2/Tools/scripts/reindent.py", line 83, in main
    check(arg)
  File "/usr/local/src/Python-2.4.2/Tools/scripts/reindent.py", line 108, in check
    if r.run():
  File "/usr/local/src/Python-2.4.2/Tools/scripts/reindent.py", line 166, in run
    tokenize.tokenize(self.getline, self.tokeneater)
  File "/usr/local/lib/python2.4/tokenize.py", line 153, in tokenize
    tokenize_loop(readline, tokeneater)
  File "/usr/local/lib/python2.4/tokenize.py", line 159, in tokenize_loop
    for token_info in generate_tokens(readline):
  File "/usr/local/lib/python2.4/tokenize.py", line 236, in generate_tokens
    raise TokenError, ("EOF in multi-line statement", (lnum, 0))
tokenize.TokenError: ('EOF in multi-line statement', (24, 0))



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

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

From noreply at sourceforge.net  Sat Mar 11 01:11:38 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 10 Mar 2006 16:11:38 -0800
Subject: [ python-Bugs-1447633 ] "reindent.py" exposes bug in tokenize
Message-ID: <E1FHrhq-0006fw-8C@sc8-sf-web4-b.sourceforge.net>

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

Please note that this message 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: Edward C. Jones (edcjones)
Assigned to: Nobody/Anonymous (nobody)
Summary: "reindent.py" exposes bug in tokenize

Initial Comment:
I use up-to-date Debian unstable (i368 port) on a PC with a AMD Athlon64
+3500 chip. I compile my own copy of Python which I keep in /usr/local.

Here is a small Python program called "fixnames.py":

#! /usr/bin/env python

"""Rename files that contain unpleasant characters.

Modify this code as needed.
"""
import os, sys, optparse

usage = 'USAGE: ./fixnames.py [-h] <filelist>'
parser = optparse.OptionParser(usage=usage)
options, args = parser.parse_args()
if len(args) != 1:
    parser.print_help()
    sys.exit('an argument is required'))

# The input is a list of files to be renamed.
for name in open(args[0]), 'r'):
    # Modify these as needed.
    newname = name.replace(' ', '_')
    newname = newname.replace('@', '_at_')
    newname = newname.replace('%20', '_')
    newname = newname.replace("'", '')
    os.rename(name, newname)

If I run

python /usr/local/src/Python-2.4.2/Tools/scripts/reindent.py fixnames.py

I get
Traceback (most recent call last):
  File "/usr/local/src/Python-2.4.2/Tools/scripts/reindent.py", line 293, in ?
    main()
  File "/usr/local/src/Python-2.4.2/Tools/scripts/reindent.py", line 83, in main
    check(arg)
  File "/usr/local/src/Python-2.4.2/Tools/scripts/reindent.py", line 108, in check
    if r.run():
  File "/usr/local/src/Python-2.4.2/Tools/scripts/reindent.py", line 166, in run
    tokenize.tokenize(self.getline, self.tokeneater)
  File "/usr/local/lib/python2.4/tokenize.py", line 153, in tokenize
    tokenize_loop(readline, tokeneater)
  File "/usr/local/lib/python2.4/tokenize.py", line 159, in tokenize_loop
    for token_info in generate_tokens(readline):
  File "/usr/local/lib/python2.4/tokenize.py", line 236, in generate_tokens
    raise TokenError, ("EOF in multi-line statement", (lnum, 0))
tokenize.TokenError: ('EOF in multi-line statement', (24, 0))



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

>Comment By: Tim Peters (tim_one)
Date: 2006-03-10 19:11

Message:
Logged In: YES 
user_id=31435

What do you think the bug is?  That is, what did you expect
to happen?  tokenize.py isn't a syntax checker, so this
looks like a case of garbage-in, garbage-out to me.  There
are two lines in the sample program that contain a right
parenthesis that shouldn't be there, and if those syntax
errors are repaired then tokenize.py is happy with the
program.  As is, because of the unbalanced parentheses the
net paren level isn't 0 when tokenize reaches the end of the
file, so _something_ is wrong with the file, and "EOF in
multi-line statement" is just its heurestic guess at the
most likely cause.

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

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

From noreply at sourceforge.net  Sat Mar 11 02:56:31 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 10 Mar 2006 17:56:31 -0800
Subject: [ python-Bugs-1447633 ] "reindent.py" exposes bug in tokenize
Message-ID: <E1FHtLL-0004kx-Vd@sc8-sf-web4-b.sourceforge.net>

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

Please note that this message 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: Edward C. Jones (edcjones)
Assigned to: Nobody/Anonymous (nobody)
Summary: "reindent.py" exposes bug in tokenize

Initial Comment:
I use up-to-date Debian unstable (i368 port) on a PC with a AMD Athlon64
+3500 chip. I compile my own copy of Python which I keep in /usr/local.

Here is a small Python program called "fixnames.py":

#! /usr/bin/env python

"""Rename files that contain unpleasant characters.

Modify this code as needed.
"""
import os, sys, optparse

usage = 'USAGE: ./fixnames.py [-h] <filelist>'
parser = optparse.OptionParser(usage=usage)
options, args = parser.parse_args()
if len(args) != 1:
    parser.print_help()
    sys.exit('an argument is required'))

# The input is a list of files to be renamed.
for name in open(args[0]), 'r'):
    # Modify these as needed.
    newname = name.replace(' ', '_')
    newname = newname.replace('@', '_at_')
    newname = newname.replace('%20', '_')
    newname = newname.replace("'", '')
    os.rename(name, newname)

If I run

python /usr/local/src/Python-2.4.2/Tools/scripts/reindent.py fixnames.py

I get
Traceback (most recent call last):
  File "/usr/local/src/Python-2.4.2/Tools/scripts/reindent.py", line 293, in ?
    main()
  File "/usr/local/src/Python-2.4.2/Tools/scripts/reindent.py", line 83, in main
    check(arg)
  File "/usr/local/src/Python-2.4.2/Tools/scripts/reindent.py", line 108, in check
    if r.run():
  File "/usr/local/src/Python-2.4.2/Tools/scripts/reindent.py", line 166, in run
    tokenize.tokenize(self.getline, self.tokeneater)
  File "/usr/local/lib/python2.4/tokenize.py", line 153, in tokenize
    tokenize_loop(readline, tokeneater)
  File "/usr/local/lib/python2.4/tokenize.py", line 159, in tokenize_loop
    for token_info in generate_tokens(readline):
  File "/usr/local/lib/python2.4/tokenize.py", line 236, in generate_tokens
    raise TokenError, ("EOF in multi-line statement", (lnum, 0))
tokenize.TokenError: ('EOF in multi-line statement', (24, 0))



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

>Comment By: David Goodger (goodger)
Date: 2006-03-10 20:56

Message:
Logged In: YES 
user_id=7733

reindent.py and tokenize.py require input with correct
syntax.  The bug is in the input code.

Closing this bug report.

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

Comment By: Tim Peters (tim_one)
Date: 2006-03-10 19:11

Message:
Logged In: YES 
user_id=31435

What do you think the bug is?  That is, what did you expect
to happen?  tokenize.py isn't a syntax checker, so this
looks like a case of garbage-in, garbage-out to me.  There
are two lines in the sample program that contain a right
parenthesis that shouldn't be there, and if those syntax
errors are repaired then tokenize.py is happy with the
program.  As is, because of the unbalanced parentheses the
net paren level isn't 0 when tokenize reaches the end of the
file, so _something_ is wrong with the file, and "EOF in
multi-line statement" is just its heurestic guess at the
most likely cause.

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

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

From noreply at sourceforge.net  Sat Mar 11 10:10:17 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 11 Mar 2006 01:10:17 -0800
Subject: [ python-Bugs-1445781 ] install fails on hard link
Message-ID: <E1FI077-0000ew-CD@sc8-sf-web3.sourceforge.net>

Bugs item #1445781, was opened at 2006-03-08 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=1445781&group_id=5470

Please note that this 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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: goldenautumnday (goldenautumnday)
>Assigned to: Martin v. L??wis (loewis)
Summary: install fails on hard link

Initial Comment:
Installing on an attached linux drive from a Mac OS X (Tiger) system fails 
because hard links are not supported.  This is attempted when trying to 
link python2.4 to python (ln python2.4 python).  If it fails, a copy should 
be performed instead.

changing mode of /Users/martinol/auto_v4.0/devel/powerpc-apple-
darwin8.5.0/bin/idle to 755
changing mode of /Users/martinol/auto_v4.0/devel/powerpc-apple-
darwin8.5.0/bin/pydoc to 755
changing mode of /Users/martinol/auto_v4.0/devel/powerpc-apple-
darwin8.5.0/bin/smtpd.py to 755
if test -f /Users/martinol/auto_v4.0/devel/powerpc-apple-darwin8.5.0/
bin/python -o -h /Users/martinol/auto_v4.0/devel/powerpc-apple-
darwin8.5.0/bin/python; \
then rm -f /Users/martinol/auto_v4.0/devel/powerpc-apple-
darwin8.5.0/bin/python; \
else true; \
fi
(cd /Users/martinol/auto_v4.0/devel/powerpc-apple-darwin8.5.0/bin; ln 
python2.4 python)
ln: python: Operation not supported

/Users/martinol/auto_v4.0 is symbolic link to /Volumes/thing/martinol 
which has been attached to using openapple-K (via SMB).

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

Comment By: goldenautumnday (goldenautumnday)
Date: 2006-03-08 20:22

Message:
Logged In: YES 
user_id=1471082

Changing line 599 in Makefile.pre.in to:

(cd $(DESTDIR)$(BINDIR); $(LN) python$(VERSION)$(EXE) $(PYTHON) || cp python
$(VERSION)$(EXE) $(PYTHON))

allowed make to complete.

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

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

From noreply at sourceforge.net  Sat Mar 11 14:46:45 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 11 Mar 2006 05:46:45 -0800
Subject: [ python-Bugs-1447885 ] traceback.format_exception_only() and
	SyntaxError
Message-ID: <E1FI4Qf-0007uQ-UN@sc8-sf-web6.sourceforge.net>

Bugs item #1447885, was opened at 2006-03-11 14: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=1447885&group_id=5470

Please note that this message 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: Remy Blank (remyblank)
Assigned to: Nobody/Anonymous (nobody)
Summary: traceback.format_exception_only() and SyntaxError

Initial Comment:
There is a special case in
traceback.format_exception_only() for SyntaxError so
that the location of the syntax error is printed.
Unfortunately, the test is written so that it only
works with SyntaxError, but not for children of
SyntaxError, e.g. IndentationError.

OTOH, the interpreter prints the correct output if the
exception is allowed to terminate the program.

I have attached a test case that shows the difference
in output. With the current traceback.py module, the
output is different:

joe at pat py $ ./testSyntaxError.py
Traceback (most recent call last):
  File "./testSyntaxError.py", line 7, in ?
    import SyntaxErr
IndentationError: expected an indented block
(SyntaxErr.py, line 2)

joe at pat py $ ./testSyntaxError.py raise
Traceback (most recent call last):
  File "./testSyntaxError.py", line 7, in ?
    import SyntaxErr
  File "/home/joe/tmp/py/SyntaxErr.py", line 2
    class OtherClass:
        ^
IndentationError: expected an indented block

There's a second file that is needed for the test case,
I'll attach it as well.

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

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

From noreply at sourceforge.net  Sat Mar 11 14:47:53 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 11 Mar 2006 05:47:53 -0800
Subject: [ python-Bugs-1447885 ] traceback.format_exception_only() and
	SyntaxError
Message-ID: <E1FI4Rl-0007yJ-7p@sc8-sf-web6.sourceforge.net>

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

Please note that this message 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: Remy Blank (remyblank)
Assigned to: Nobody/Anonymous (nobody)
Summary: traceback.format_exception_only() and SyntaxError

Initial Comment:
There is a special case in
traceback.format_exception_only() for SyntaxError so
that the location of the syntax error is printed.
Unfortunately, the test is written so that it only
works with SyntaxError, but not for children of
SyntaxError, e.g. IndentationError.

OTOH, the interpreter prints the correct output if the
exception is allowed to terminate the program.

I have attached a test case that shows the difference
in output. With the current traceback.py module, the
output is different:

joe at pat py $ ./testSyntaxError.py
Traceback (most recent call last):
  File "./testSyntaxError.py", line 7, in ?
    import SyntaxErr
IndentationError: expected an indented block
(SyntaxErr.py, line 2)

joe at pat py $ ./testSyntaxError.py raise
Traceback (most recent call last):
  File "./testSyntaxError.py", line 7, in ?
    import SyntaxErr
  File "/home/joe/tmp/py/SyntaxErr.py", line 2
    class OtherClass:
        ^
IndentationError: expected an indented block

There's a second file that is needed for the test case,
I'll attach it as well.

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

>Comment By: Remy Blank (remyblank)
Date: 2006-03-11 14:47

Message:
Logged In: YES 
user_id=568100

This file generates the IndentationError.

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

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

From noreply at sourceforge.net  Sat Mar 11 14:51:04 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 11 Mar 2006 05:51:04 -0800
Subject: [ python-Bugs-1447885 ] traceback.format_exception_only() and
	SyntaxError
Message-ID: <E1FI4Uq-0008CW-F8@sc8-sf-web6.sourceforge.net>

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

Please note that this message 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: Remy Blank (remyblank)
Assigned to: Nobody/Anonymous (nobody)
Summary: traceback.format_exception_only() and SyntaxError

Initial Comment:
There is a special case in
traceback.format_exception_only() for SyntaxError so
that the location of the syntax error is printed.
Unfortunately, the test is written so that it only
works with SyntaxError, but not for children of
SyntaxError, e.g. IndentationError.

OTOH, the interpreter prints the correct output if the
exception is allowed to terminate the program.

I have attached a test case that shows the difference
in output. With the current traceback.py module, the
output is different:

joe at pat py $ ./testSyntaxError.py
Traceback (most recent call last):
  File "./testSyntaxError.py", line 7, in ?
    import SyntaxErr
IndentationError: expected an indented block
(SyntaxErr.py, line 2)

joe at pat py $ ./testSyntaxError.py raise
Traceback (most recent call last):
  File "./testSyntaxError.py", line 7, in ?
    import SyntaxErr
  File "/home/joe/tmp/py/SyntaxErr.py", line 2
    class OtherClass:
        ^
IndentationError: expected an indented block

There's a second file that is needed for the test case,
I'll attach it as well.

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

>Comment By: Remy Blank (remyblank)
Date: 2006-03-11 14:51

Message:
Logged In: YES 
user_id=568100

This patch makes both the output of the interpreter and the
output generated by format_exception_only() identical.

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

Comment By: Remy Blank (remyblank)
Date: 2006-03-11 14:47

Message:
Logged In: YES 
user_id=568100

This file generates the IndentationError.

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

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

From noreply at sourceforge.net  Sat Mar 11 19:51:38 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 11 Mar 2006 10:51:38 -0800
Subject: [ python-Bugs-1447945 ] Unable to stringify datetime with tzinfo
Message-ID: <E1FI9Bi-0001lY-Vq@sc8-sf-web2.sourceforge.net>

Bugs item #1447945, was opened at 2006-03-11 20:51
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1447945&group_id=5470

Please note that this message 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: Ilpo Nyyss?nen (biny)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unable to stringify datetime with tzinfo

Initial Comment:
zdump -v Europe/Helsinki | head -5 gives

Europe/Helsinki  Fri Dec 13 20:45:52 1901 UTC = Fri Dec
13 22:25:44 1901 EET isdst=0 gmtoff=5992
Europe/Helsinki  Sat Dec 14 20:45:52 1901 UTC = Sat Dec
14 22:25:44 1901 EET isdst=0 gmtoff=5992
Europe/Helsinki  Sat Apr 30 22:20:07 1921 UTC = Sat Apr
30 23:59:59 1921 EET isdst=0 gmtoff=5992
Europe/Helsinki  Sat Apr 30 22:20:08 1921 UTC = Sun May
 1 00:20:08 1921 EET isdst=0 gmtoff=7200
Europe/Helsinki  Thu Apr  2 21:59:59 1942 UTC = Thu Apr
 2 23:59:59 1942 EET isdst=0 gmtoff=7200
Europe/Helsinki  Thu Apr  2 22:00:00 1942 UTC = Fri Apr
 3 01:00:00 1942 EEST isdst=1 gmtoff=10800

Python 2.4.1 (#1, May 16 2005, 15:19:29) 
[GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
->> from datetime import datetime
->> from dateutil import tz
->> str(datetime(1920, 1, 1, 0, 0,
tzinfo=tz.gettz('Europe/Helsinki')))
Traceback (most recent call last):
  File "<input>", line 2, in ?
ValueError: tzinfo.utcoffset() must return a whole
number of minutes
->>
tz.gettz('Europe/Helsinki').utcoffset((datetime(1900,
1, 1, 0, 0)))
datetime.timedelta(0, 5992)
->> 


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

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

From noreply at sourceforge.net  Sat Mar 11 19:58:15 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 11 Mar 2006 10:58:15 -0800
Subject: [ python-Bugs-1447945 ] Unable to stringify datetime with tzinfo
Message-ID: <E1FI9I7-0000YT-Na@sc8-sf-web1.sourceforge.net>

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

Please note that this message 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: Ilpo Nyyss?nen (biny)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unable to stringify datetime with tzinfo

Initial Comment:
zdump -v Europe/Helsinki | head -5 gives

Europe/Helsinki  Fri Dec 13 20:45:52 1901 UTC = Fri Dec
13 22:25:44 1901 EET isdst=0 gmtoff=5992
Europe/Helsinki  Sat Dec 14 20:45:52 1901 UTC = Sat Dec
14 22:25:44 1901 EET isdst=0 gmtoff=5992
Europe/Helsinki  Sat Apr 30 22:20:07 1921 UTC = Sat Apr
30 23:59:59 1921 EET isdst=0 gmtoff=5992
Europe/Helsinki  Sat Apr 30 22:20:08 1921 UTC = Sun May
 1 00:20:08 1921 EET isdst=0 gmtoff=7200
Europe/Helsinki  Thu Apr  2 21:59:59 1942 UTC = Thu Apr
 2 23:59:59 1942 EET isdst=0 gmtoff=7200
Europe/Helsinki  Thu Apr  2 22:00:00 1942 UTC = Fri Apr
 3 01:00:00 1942 EEST isdst=1 gmtoff=10800

Python 2.4.1 (#1, May 16 2005, 15:19:29) 
[GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
->> from datetime import datetime
->> from dateutil import tz
->> str(datetime(1920, 1, 1, 0, 0,
tzinfo=tz.gettz('Europe/Helsinki')))
Traceback (most recent call last):
  File "<input>", line 2, in ?
ValueError: tzinfo.utcoffset() must return a whole
number of minutes
->>
tz.gettz('Europe/Helsinki').utcoffset((datetime(1900,
1, 1, 0, 0)))
datetime.timedelta(0, 5992)
->> 


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

>Comment By: Tim Peters (tim_one)
Date: 2006-03-11 13:58

Message:
Logged In: YES 
user_id=31435

What's this?

>>> from dateutil import tz

There is no `dateutil` module in the Python distribution (in
which case problems with `dateutil` should be directed to
its developers, not to the Python tracker).

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

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

From noreply at sourceforge.net  Sat Mar 11 20:06:04 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 11 Mar 2006 11:06:04 -0800
Subject: [ python-Bugs-1447945 ] Unable to stringify datetime with tzinfo
Message-ID: <E1FI9Pg-0001Cr-HD@sc8-sf-web5.sourceforge.net>

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

Please note that this message 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: Ilpo Nyyss?nen (biny)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unable to stringify datetime with tzinfo

Initial Comment:
zdump -v Europe/Helsinki | head -5 gives

Europe/Helsinki  Fri Dec 13 20:45:52 1901 UTC = Fri Dec
13 22:25:44 1901 EET isdst=0 gmtoff=5992
Europe/Helsinki  Sat Dec 14 20:45:52 1901 UTC = Sat Dec
14 22:25:44 1901 EET isdst=0 gmtoff=5992
Europe/Helsinki  Sat Apr 30 22:20:07 1921 UTC = Sat Apr
30 23:59:59 1921 EET isdst=0 gmtoff=5992
Europe/Helsinki  Sat Apr 30 22:20:08 1921 UTC = Sun May
 1 00:20:08 1921 EET isdst=0 gmtoff=7200
Europe/Helsinki  Thu Apr  2 21:59:59 1942 UTC = Thu Apr
 2 23:59:59 1942 EET isdst=0 gmtoff=7200
Europe/Helsinki  Thu Apr  2 22:00:00 1942 UTC = Fri Apr
 3 01:00:00 1942 EEST isdst=1 gmtoff=10800

Python 2.4.1 (#1, May 16 2005, 15:19:29) 
[GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
->> from datetime import datetime
->> from dateutil import tz
->> str(datetime(1920, 1, 1, 0, 0,
tzinfo=tz.gettz('Europe/Helsinki')))
Traceback (most recent call last):
  File "<input>", line 2, in ?
ValueError: tzinfo.utcoffset() must return a whole
number of minutes
->>
tz.gettz('Europe/Helsinki').utcoffset((datetime(1900,
1, 1, 0, 0)))
datetime.timedelta(0, 5992)
->> 


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

>Comment By: Ilpo Nyyss?nen (biny)
Date: 2006-03-11 21:06

Message:
Logged In: YES 
user_id=861953

The error is from datetime and it is from python
distribution. The tz uses operating systems information
about the timezones and as the zdump shows, it gets there
utcoffset that is not full minute.

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

Comment By: Tim Peters (tim_one)
Date: 2006-03-11 20:58

Message:
Logged In: YES 
user_id=31435

What's this?

>>> from dateutil import tz

There is no `dateutil` module in the Python distribution (in
which case problems with `dateutil` should be directed to
its developers, not to the Python tracker).

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

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

From noreply at sourceforge.net  Sat Mar 11 20:12:50 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 11 Mar 2006 11:12:50 -0800
Subject: [ python-Bugs-1447945 ] Unable to stringify datetime with tzinfo
Message-ID: <E1FI9WE-00036g-Cq@sc8-sf-web2.sourceforge.net>

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

Please note that this message 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: Ilpo Nyyss?nen (biny)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unable to stringify datetime with tzinfo

Initial Comment:
zdump -v Europe/Helsinki | head -5 gives

Europe/Helsinki  Fri Dec 13 20:45:52 1901 UTC = Fri Dec
13 22:25:44 1901 EET isdst=0 gmtoff=5992
Europe/Helsinki  Sat Dec 14 20:45:52 1901 UTC = Sat Dec
14 22:25:44 1901 EET isdst=0 gmtoff=5992
Europe/Helsinki  Sat Apr 30 22:20:07 1921 UTC = Sat Apr
30 23:59:59 1921 EET isdst=0 gmtoff=5992
Europe/Helsinki  Sat Apr 30 22:20:08 1921 UTC = Sun May
 1 00:20:08 1921 EET isdst=0 gmtoff=7200
Europe/Helsinki  Thu Apr  2 21:59:59 1942 UTC = Thu Apr
 2 23:59:59 1942 EET isdst=0 gmtoff=7200
Europe/Helsinki  Thu Apr  2 22:00:00 1942 UTC = Fri Apr
 3 01:00:00 1942 EEST isdst=1 gmtoff=10800

Python 2.4.1 (#1, May 16 2005, 15:19:29) 
[GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
->> from datetime import datetime
->> from dateutil import tz
->> str(datetime(1920, 1, 1, 0, 0,
tzinfo=tz.gettz('Europe/Helsinki')))
Traceback (most recent call last):
  File "<input>", line 2, in ?
ValueError: tzinfo.utcoffset() must return a whole
number of minutes
->>
tz.gettz('Europe/Helsinki').utcoffset((datetime(1900,
1, 1, 0, 0)))
datetime.timedelta(0, 5992)
->> 


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

>Comment By: Ilpo Nyyss?nen (biny)
Date: 2006-03-11 21:12

Message:
Logged In: YES 
user_id=861953

What do you think is best solution?

1) Python datetime is changed to tolerate more.

2) Linux tzdata package is changed to contain only full
minute offsets. Who is going to convince them that this is
good idea?

3) The python-dateutil tz library is changed to touch the
information provided by the operating system.


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

Comment By: Ilpo Nyyss?nen (biny)
Date: 2006-03-11 21:06

Message:
Logged In: YES 
user_id=861953

The error is from datetime and it is from python
distribution. The tz uses operating systems information
about the timezones and as the zdump shows, it gets there
utcoffset that is not full minute.

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

Comment By: Tim Peters (tim_one)
Date: 2006-03-11 20:58

Message:
Logged In: YES 
user_id=31435

What's this?

>>> from dateutil import tz

There is no `dateutil` module in the Python distribution (in
which case problems with `dateutil` should be directed to
its developers, not to the Python tracker).

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

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

From noreply at sourceforge.net  Sat Mar 11 21:38:40 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 11 Mar 2006 12:38:40 -0800
Subject: [ python-Bugs-1447945 ] Unable to stringify datetime with tzinfo
Message-ID: <E1FIArI-000744-Q6@sc8-sf-web4-b.sourceforge.net>

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

Please note that this message 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: Ilpo Nyyss?nen (biny)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unable to stringify datetime with tzinfo

Initial Comment:
zdump -v Europe/Helsinki | head -5 gives

Europe/Helsinki  Fri Dec 13 20:45:52 1901 UTC = Fri Dec
13 22:25:44 1901 EET isdst=0 gmtoff=5992
Europe/Helsinki  Sat Dec 14 20:45:52 1901 UTC = Sat Dec
14 22:25:44 1901 EET isdst=0 gmtoff=5992
Europe/Helsinki  Sat Apr 30 22:20:07 1921 UTC = Sat Apr
30 23:59:59 1921 EET isdst=0 gmtoff=5992
Europe/Helsinki  Sat Apr 30 22:20:08 1921 UTC = Sun May
 1 00:20:08 1921 EET isdst=0 gmtoff=7200
Europe/Helsinki  Thu Apr  2 21:59:59 1942 UTC = Thu Apr
 2 23:59:59 1942 EET isdst=0 gmtoff=7200
Europe/Helsinki  Thu Apr  2 22:00:00 1942 UTC = Fri Apr
 3 01:00:00 1942 EEST isdst=1 gmtoff=10800

Python 2.4.1 (#1, May 16 2005, 15:19:29) 
[GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
->> from datetime import datetime
->> from dateutil import tz
->> str(datetime(1920, 1, 1, 0, 0,
tzinfo=tz.gettz('Europe/Helsinki')))
Traceback (most recent call last):
  File "<input>", line 2, in ?
ValueError: tzinfo.utcoffset() must return a whole
number of minutes
->>
tz.gettz('Europe/Helsinki').utcoffset((datetime(1900,
1, 1, 0, 0)))
datetime.timedelta(0, 5992)
->> 


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

>Comment By: Tim Peters (tim_one)
Date: 2006-03-11 15:38

Message:
Logged In: YES 
user_id=31435

I don't know that this needs "a solution", but doubt
anything relevant is going to change in Python regardless --
that utcoffset() must return a whole number of minutes has
been documented from the start, and in several years hasn't
caused anyone else a problem.

Do you really believe that Helsinki was once 99 minutes and
52 seconds off from UTC?  I don't ;-)  Seems more likely
that your installation's time zone info is corrupt; that
this specific piece of historical time zone info is wrong
but nobody noticed before ("historical" because it's
certainly not the case that Helsinki is ever 5992 seconds
off from UTC in current reality); or that `dateutil` has a
relevant error.

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

Comment By: Ilpo Nyyss?nen (biny)
Date: 2006-03-11 14:12

Message:
Logged In: YES 
user_id=861953

What do you think is best solution?

1) Python datetime is changed to tolerate more.

2) Linux tzdata package is changed to contain only full
minute offsets. Who is going to convince them that this is
good idea?

3) The python-dateutil tz library is changed to touch the
information provided by the operating system.


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

Comment By: Ilpo Nyyss?nen (biny)
Date: 2006-03-11 14:06

Message:
Logged In: YES 
user_id=861953

The error is from datetime and it is from python
distribution. The tz uses operating systems information
about the timezones and as the zdump shows, it gets there
utcoffset that is not full minute.

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

Comment By: Tim Peters (tim_one)
Date: 2006-03-11 13:58

Message:
Logged In: YES 
user_id=31435

What's this?

>>> from dateutil import tz

There is no `dateutil` module in the Python distribution (in
which case problems with `dateutil` should be directed to
its developers, not to the Python tracker).

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

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

From noreply at sourceforge.net  Sat Mar 11 23:49:57 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 11 Mar 2006 14:49:57 -0800
Subject: [ python-Bugs-1448042 ] Defining a class with __dict__ brakes
	attributes assignment
Message-ID: <E1FICuL-0001o5-2L@sc8-sf-web3.sourceforge.net>

Bugs item #1448042, was opened at 2006-03-11 23: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=1448042&group_id=5470

Please note that this message 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: Michal Kwiatkowski (rubyjoker)
Assigned to: Nobody/Anonymous (nobody)
Summary: Defining a class with __dict__ brakes attributes assignment

Initial Comment:
When defining a class with __dict__ attribute, its 
instances can't rebind their __dict__ attributes.

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

class C(object): __dict__ = {}

obj = C()
obj.a = object()

import gc
gc.get_referrers(obj.a) # => [{'a': <object object at 
0x811d5b0>}]

obj.__dict__ = {} # doesn't really bind new __dict__

vars(obj) # => {}
object.__getattribute__(obj, '__dict__') # => {}
object.__getattribute__(C, '__dict__') # => {..., but 
without "a"}
obj.a  # => <object object at 0x811d5b0> (no exception
!)

gc.get_referrers(obj.a) # => [{'a': <object object at 
0x811d5b0>, '__dict__': {}}]

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

Although neither class nor object has an attribute "a", 
it's still accessible. It's also not possible to rebind 
__dict__ in that object, as it gets inside real object 
attributes dictionary.

This behaviour has been tested on Python 2.2, 2.3 and 
2.4, but may as well affect earlier versions.

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

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

From noreply at sourceforge.net  Sun Mar 12 00:19:10 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 11 Mar 2006 15:19:10 -0800
Subject: [ python-Bugs-1448058 ] problems with too many sockets in FreeBSD
Message-ID: <E1FIDMc-0008VK-Fc@sc8-sf-web1.sourceforge.net>

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

Please note that this 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: aix-d (aix-d)
Assigned to: Nobody/Anonymous (nobody)
Summary: problems with too many sockets in FreeBSD

Initial Comment:
When there are about 200 sockets, or so, i'm getting
errors: "unable to select on socket"
We are running multithread application, for each thread
there is one socket.

TRACEBACK contains:
  r = self.connection.recv(1024)
error: unable to select on socket.

This error appeared after fixing this problem:
http://sourceforge.net/tracker/index.php?func=detail&aid=1429585&group_id=5470&atid=105470

Python version: 2.5a0 (trunk, Mar  8 2006, 18:28:30)
OS version: FreeBSD 6.1-PRERELEASE

Soon we will make program that will reproduce this
error if needed.

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

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

From noreply at sourceforge.net  Sun Mar 12 00:20:02 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 11 Mar 2006 15:20:02 -0800
Subject: [ python-Bugs-1448060 ] gettext.py breaks on plural-forms header
Message-ID: <E1FIDNS-0001lL-QN@sc8-sf-web2.sourceforge.net>

Bugs item #1448060, was opened at 2006-03-12 00:20
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448060&group_id=5470

Please note that this message 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: Danilo Segan (dsegan)
Assigned to: Nobody/Anonymous (nobody)
Summary: gettext.py breaks on plural-forms header

Initial Comment:
See http://bugzilla.gnome.org/show_bug.cgi?id=334256

The problem is a PO file like the following:

test.po:
msgid ""
msgstr ""
"Content-Type: text/plain; charset=UTF-8\n"
"Plural-Forms:  nplurals=2; plural=(n != 1);\n"
"#-#-#-#-#  plo.po (PACKAGE VERSION)  #-#-#-#-#\n"

(these kinds of entries are sometimes inserted by
msgmerge, so they're somewhat common)

Any Python program trying to access this breaks:

$ python test.py
Traceback (most recent call last):
  File "test.py", line 7, in ?
    gt = gettext.GNUTranslations(file)
  File "/usr/lib/python2.4/gettext.py", line 177, in
__init__
    self._parse(fp)
  File "/usr/lib/python2.4/gettext.py", line 300, in _parse
    v = v.split(';')
AttributeError: 'list' object has no attribute 'split'


test.py is simple:
#!/usr/bin/env python
import gettext
file = open("test.mo", "rb")
if file:
    gt = gettext.GNUTranslations(file)


The problem is the corner-case: plural-forms precedes
this kind of comment, so "v" is split (v=v.split(";")).
In the next instance, lastk is "plural-forms", yet the
entry doesn't contain ":", so it tries to set plural
forms to v.split(";") again, which fails since v is
already a list.

The attached simple patch fixes this.


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

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

From noreply at sourceforge.net  Sun Mar 12 00:22:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 11 Mar 2006 15:22:25 -0800
Subject: [ python-Bugs-1448060 ] gettext.py breaks on plural-forms header
	(PATCH)
Message-ID: <E1FIDPl-0000UH-HH@sc8-sf-web4-b.sourceforge.net>

Bugs item #1448060, was opened at 2006-03-12 00:20
Message generated for change (Settings changed) made by dsegan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448060&group_id=5470

Please note that this message 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: Danilo Segan (dsegan)
Assigned to: Nobody/Anonymous (nobody)
>Summary: gettext.py breaks on plural-forms header (PATCH)

Initial Comment:
See http://bugzilla.gnome.org/show_bug.cgi?id=334256

The problem is a PO file like the following:

test.po:
msgid ""
msgstr ""
"Content-Type: text/plain; charset=UTF-8\n"
"Plural-Forms:  nplurals=2; plural=(n != 1);\n"
"#-#-#-#-#  plo.po (PACKAGE VERSION)  #-#-#-#-#\n"

(these kinds of entries are sometimes inserted by
msgmerge, so they're somewhat common)

Any Python program trying to access this breaks:

$ python test.py
Traceback (most recent call last):
  File "test.py", line 7, in ?
    gt = gettext.GNUTranslations(file)
  File "/usr/lib/python2.4/gettext.py", line 177, in
__init__
    self._parse(fp)
  File "/usr/lib/python2.4/gettext.py", line 300, in _parse
    v = v.split(';')
AttributeError: 'list' object has no attribute 'split'


test.py is simple:
#!/usr/bin/env python
import gettext
file = open("test.mo", "rb")
if file:
    gt = gettext.GNUTranslations(file)


The problem is the corner-case: plural-forms precedes
this kind of comment, so "v" is split (v=v.split(";")).
In the next instance, lastk is "plural-forms", yet the
entry doesn't contain ":", so it tries to set plural
forms to v.split(";") again, which fails since v is
already a list.

The attached simple patch fixes this.


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

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

From noreply at sourceforge.net  Sun Mar 12 06:49:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 11 Mar 2006 21:49:24 -0800
Subject: [ python-Bugs-1447945 ] Unable to stringify datetime with tzinfo
Message-ID: <E1FIJSG-0000lL-9u@sc8-sf-web2.sourceforge.net>

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

Please note that this message 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: Ilpo Nyyss??nen (biny)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unable to stringify datetime with tzinfo

Initial Comment:
zdump -v Europe/Helsinki | head -5 gives

Europe/Helsinki  Fri Dec 13 20:45:52 1901 UTC = Fri Dec
13 22:25:44 1901 EET isdst=0 gmtoff=5992
Europe/Helsinki  Sat Dec 14 20:45:52 1901 UTC = Sat Dec
14 22:25:44 1901 EET isdst=0 gmtoff=5992
Europe/Helsinki  Sat Apr 30 22:20:07 1921 UTC = Sat Apr
30 23:59:59 1921 EET isdst=0 gmtoff=5992
Europe/Helsinki  Sat Apr 30 22:20:08 1921 UTC = Sun May
 1 00:20:08 1921 EET isdst=0 gmtoff=7200
Europe/Helsinki  Thu Apr  2 21:59:59 1942 UTC = Thu Apr
 2 23:59:59 1942 EET isdst=0 gmtoff=7200
Europe/Helsinki  Thu Apr  2 22:00:00 1942 UTC = Fri Apr
 3 01:00:00 1942 EEST isdst=1 gmtoff=10800

Python 2.4.1 (#1, May 16 2005, 15:19:29) 
[GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
->> from datetime import datetime
->> from dateutil import tz
->> str(datetime(1920, 1, 1, 0, 0,
tzinfo=tz.gettz('Europe/Helsinki')))
Traceback (most recent call last):
  File "<input>", line 2, in ?
ValueError: tzinfo.utcoffset() must return a whole
number of minutes
->>
tz.gettz('Europe/Helsinki').utcoffset((datetime(1900,
1, 1, 0, 0)))
datetime.timedelta(0, 5992)
->> 


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

>Comment By: Ilpo Nyyss??nen (biny)
Date: 2006-03-12 07:49

Message:
Logged In: YES 
user_id=861953

I need a solution for this. Either I need to work around it
myself or I need to create a patched version of python or
dateutil.

We can't compare datetimes with tzinfos with datetimes
without tzinfos. This means that I either have tzinfo for
every datetime or for none. I prefer having them. Mostly I
am handling recent or future times, but I do want to have
some a bit older times too. It is not a problem if those
older times are not that exact, but I really don't want
those to cause errors. I ran into this while trying to
import data to my software and the whole import failed
because of this.

I really don't know what the offset was. Maybe the tzdata
people have some reason for it, maybe it is a bug with them.
 But I don't see myself going to tell them that they need to
change the data because python does not work with it. How
could I be sure that they would change all such occurrences
and wouldn't do it again?

My preferred solution would be that python datetime would
somehow tolerate it and not cause errors. It could even
round it to make it full minute. As these errors clearly
happen only with old times people rarely use, I don't see it
as a problem to make it a bit inaccurate.

If python won't change, then maybe I need to go and try to
say to dateutil people that they need to round the offsets
to avoid errors.


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

Comment By: Tim Peters (tim_one)
Date: 2006-03-11 22:38

Message:
Logged In: YES 
user_id=31435

I don't know that this needs "a solution", but doubt
anything relevant is going to change in Python regardless --
that utcoffset() must return a whole number of minutes has
been documented from the start, and in several years hasn't
caused anyone else a problem.

Do you really believe that Helsinki was once 99 minutes and
52 seconds off from UTC?  I don't ;-)  Seems more likely
that your installation's time zone info is corrupt; that
this specific piece of historical time zone info is wrong
but nobody noticed before ("historical" because it's
certainly not the case that Helsinki is ever 5992 seconds
off from UTC in current reality); or that `dateutil` has a
relevant error.

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

Comment By: Ilpo Nyyss??nen (biny)
Date: 2006-03-11 21:12

Message:
Logged In: YES 
user_id=861953

What do you think is best solution?

1) Python datetime is changed to tolerate more.

2) Linux tzdata package is changed to contain only full
minute offsets. Who is going to convince them that this is
good idea?

3) The python-dateutil tz library is changed to touch the
information provided by the operating system.


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

Comment By: Ilpo Nyyss??nen (biny)
Date: 2006-03-11 21:06

Message:
Logged In: YES 
user_id=861953

The error is from datetime and it is from python
distribution. The tz uses operating systems information
about the timezones and as the zdump shows, it gets there
utcoffset that is not full minute.

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

Comment By: Tim Peters (tim_one)
Date: 2006-03-11 20:58

Message:
Logged In: YES 
user_id=31435

What's this?

>>> from dateutil import tz

There is no `dateutil` module in the Python distribution (in
which case problems with `dateutil` should be directed to
its developers, not to the Python tracker).

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

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

From noreply at sourceforge.net  Sun Mar 12 08:56:49 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 11 Mar 2006 23:56:49 -0800
Subject: [ python-Bugs-1183896 ] PCbuild/readme.txt description not quite right
Message-ID: <E1FILRZ-0006wg-TA@sc8-sf-web1.sourceforge.net>

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

Please note that this 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: Invalid
Priority: 5
Submitted By: Gregory Smith (gregsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: PCbuild/readme.txt description not quite right

Initial Comment:
PCbuild/readme.txt contains some very useful
instructions on obtaining external packages
needed to build extensions (zlib, tk, etc),
but there is a small error in the instruction as
to where these distributions should be placed.

"... download the base
packages first and unpack them into siblings of
PCbuilds's parent
directory; for example, if your PCbuild is 
.......\dist\src\PCbuild\,
unpack into new subdirectories of dist\."

This should say
"if your PCbuild is 
.......\dist\Python-2.4.1\src\PCbuild\"

... because that's what works.



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

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-12 07:56

Message:
Logged In: YES 
user_id=849994

Actually, it currently seems to be correct.

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

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

From noreply at sourceforge.net  Sun Mar 12 11:04:18 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 12 Mar 2006 02:04:18 -0800
Subject: [ python-Bugs-1446690 ] bug with xmlrpclib
Message-ID: <E1FINQw-0006eD-KK@sc8-sf-web5.sourceforge.net>

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

Please note that this 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.3
Status: Open
Resolution: None
>Priority: 9
Submitted By: varun bhansaly (varun_bhansaly)
Assigned to: Nobody/Anonymous (nobody)
Summary: bug with xmlrpclib

Initial Comment:
I am currently working on a project in which I am
required to send some data from OpenOffice.org v2.0.(OOo)
I have placed buttons on the spreadsheet, and a python
script is to be invoked when the button is clicked.
I am required to send the data in the spreadsheet to an
app server, hence I am using XML-RPC to get this job done.
The version of XML-RPC(xmlrpclib.py) I'm using is
v1.36.2.1,
The app server requires the connection to be
authenticated, whereas the current xmlrpclib.py doesnot
come with support for sending requests with basic
authentication.
In order to extend the capabilities of the xmlrpclib.py
with http authentication, I have written code that
provides necessary basic authentication.(class
BasicAuthTransport in the attached file
Project_saveFromOOoCalcAction.py) The actual connection
and authentication details have been replaced for
security reasons.
When the button on the OOo spreadsheet is clicked, the
script throws the following error.

com.sun.star.uno.RuntimeExceptionexceptions.TypeError:
request() got an unexpected keyword argument 'verbose',
traceback follows 

File "usr/lib/python2.4/xmlrpclib.py", in line 1096, in
__call__
return self.__send(self.__name,args)

File "usr/lib/python2.4/xmlrpclib.py", in line 1383, in
__request
verbose=self.__verbose

When I comment out the line 1383 of the above file,
everything runs smoothly, this is a very trivial
solution though,as this would require me to comment out
the line 1383 of the above file n all the client
machines in which the script has to executed.

Hence I'm looking for a more viable solution. The files
are attached along.

Any help or advice in this regard shall be welcome.

regards,

-VB

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

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

From noreply at sourceforge.net  Sun Mar 12 15:46:31 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 12 Mar 2006 06:46:31 -0800
Subject: [ python-Bugs-1448325 ] re search infinite loop
Message-ID: <E1FIRq3-0005sg-21@sc8-sf-web1.sourceforge.net>

Bugs item #1448325, was opened at 2006-03-12 09: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=1448325&group_id=5470

Please note that this 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: Don Allen (donallen)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: re search infinite loop

Initial Comment:
Given the attached test.csv file, the following program
loops forever (can't even ^c):

import re

orig = open('test.csv')

file_contents = orig.read()
orig.close()

find_line = re.compile(r'^(".*")?(,(".*")?)*\n')
search_result = find_line.search(file_contents)
print search_result.span()

The corresponding tcl program works correctly:

set orig [open test.csv r]

set file_contents [read $orig]
close $orig

regexp -indices {^(".*")?(,(".*")?)*\n} $file_contents
\ indices
puts "Indices were $indices"

Both tests were run on a TP G41 running Gentoo Linux.



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

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

From noreply at sourceforge.net  Sun Mar 12 16:22:11 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 12 Mar 2006 07:22:11 -0800
Subject: [ python-Bugs-1448325 ] re search infinite loop
Message-ID: <E1FISOZ-0008GA-B0@sc8-sf-web1.sourceforge.net>

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

Please note that this 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: Don Allen (donallen)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: re search infinite loop

Initial Comment:
Given the attached test.csv file, the following program
loops forever (can't even ^c):

import re

orig = open('test.csv')

file_contents = orig.read()
orig.close()

find_line = re.compile(r'^(".*")?(,(".*")?)*\n')
search_result = find_line.search(file_contents)
print search_result.span()

The corresponding tcl program works correctly:

set orig [open test.csv r]

set file_contents [read $orig]
close $orig

regexp -indices {^(".*")?(,(".*")?)*\n} $file_contents
\ indices
puts "Indices were $indices"

Both tests were run on a TP G41 running Gentoo Linux.



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

>Comment By: Don Allen (donallen)
Date: 2006-03-12 10:22

Message:
Logged In: YES 
user_id=1474165

If you eliminate the \n at the end of the regular
expression, the python program works correctly (for this
example; I am trying to use regular expressions to parse the
.csv files generated by Microsoft Outlook, which contain
eols inside fields, so I'm trying to find the eols *not*
inside fields with this regexp, so I need the \n; I'll have
to go to Plan B, I suppose).


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

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

From noreply at sourceforge.net  Sun Mar 12 22:57:33 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 12 Mar 2006 13:57:33 -0800
Subject: [ python-Bugs-1448490 ] Convertion error for latin1 characters with
	iso-2022-jp-2
Message-ID: <E1FIYZB-0007OZ-5m@sc8-sf-web4-b.sourceforge.net>

Bugs item #1448490, was opened at 2006-03-12 16: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=1448490&group_id=5470

Please note that this message 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: Francois Duranleau (duranlef)
Assigned to: Nobody/Anonymous (nobody)
Summary: Convertion error for latin1 characters with iso-2022-jp-2

Initial Comment:
It seems like there are some errors while reading a
text file encoded with ISO-2022-JP-2 using the codecs
module. In all my test cases, all latin1 characters
with an accent (e.g. e acute) do not appear in the
output string. However, if I convert the file manually
using iconv, I get everything right. Here is a simple
script that will illustrate the problem:

###########################################

import codecs

import pygtk
import gtk

f = codecs.open( "test.iso-2022-jp-2" , "r" , \
                 "iso-2022-jp-2" )
s1 = f.readline().strip()
f.close()

f = open( "test.utf-8" , "r" )
s2 = f.readline().strip()

pack = gtk.VBox()
pack.pack_start( gtk.Label( s1 ) )
pack.pack_start( gtk.Label( s2 ) )

window = gtk.Window( gtk.WINDOW_TOPLEVEL )
window.add( pack )
window.show_all()

def event_destroy( widget , event , data ) :
    gtk.main_quit()
    return 0

window.connect( "delete_event" , \
                lambda w,e,d: False , None )
window.connect( "destroy" , event_destroy , None )

gtk.main()

###########################################

I put the file "test.iso-2022-jp-2" in attachment. To
create the UTF-8 version of the file, I used the
following shell command:

iconv -f ISO-2022-JP-2 -t UTF-8 \
    test.iso-2022-jp-2 > test.utf-8

When running this script, I would actually expect a
window with two times the same label. However, the
first one is missing the e acute.

--
Francois

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

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

From noreply at sourceforge.net  Mon Mar 13 05:52:26 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 12 Mar 2006 20:52:26 -0800
Subject: [ python-Bugs-1448639 ] asyncore dispatcher.__getattr__() masks
	self._map
Message-ID: <E1FIf2g-0001Qu-5G@sc8-sf-web2.sourceforge.net>

Bugs item #1448639, was opened at 2006-03-12 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=1448639&group_id=5470

Please note that this message 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: Doug White (dwhite)
Assigned to: Nobody/Anonymous (nobody)
Summary: asyncore dispatcher.__getattr__() masks self._map

Initial Comment:
The abstraction of socket_map in the asyncore module 
in Python 2.4 forgets to allow accesses to the 
internal attribute self._map in __getattr__(). This 
causes any asyncore application to fail in 
create_socket(), which pretty much renders asyncore 
inoperative in Python 2.4.  
 
This problem was introduced in rev 34469 as a commit 
of Bug #758241. 
 
Example backtrace, generated from an application that 
uses Medusa servers that don't use the private map 
function: 
 
Traceback (most recent call last): 
  File "/usr/local/qos/qosserver/qos_server.py", line 
1576, in ? 
    m = monitor.monitor_server ('127.0.0.1', 
BasePort) 
  File "/usr/local/qos/qosserver/monitor.py", line 
161, in __init__ 
    self.create_socket (socket.AF_INET, 
socket.SOCK_STREAM) 
  File "/usr/local/lib/python2.4/asyncore.py", line 
261, in create_socket 
    self.add_channel() 
  File "/usr/local/lib/python2.4/asyncore.py", line 
244, in add_channel 
    map = self._map 
  File "/usr/local/lib/python2.4/asyncore.py", line 
366, in __getattr__ 
    return getattr(self.socket, attr) 
AttributeError: '_socketobject' object has no 
attribute '_map' 
 
__getattr__() should test if the attribute exists in 
its own object before passing it on to the underlying 
socket object. 

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

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

From noreply at sourceforge.net  Mon Mar 13 05:54:45 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 12 Mar 2006 20:54:45 -0800
Subject: [ python-Bugs-1448640 ] datetime.__init__ cannot be overridden
Message-ID: <E1FIf4v-0008A5-4t@sc8-sf-web5.sourceforge.net>

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

Please note that this message 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: Martin Blais (blais)
Assigned to: Nobody/Anonymous (nobody)
Summary: datetime.__init__ cannot be overridden

Initial Comment:
Hi

The following code does not work properly:

#!/usr/bin/env python
"""
Test overriding constructor of datetime classes.
"""

import sys, datetime

class MyDate(datetime.date):

    def __init__( self, year, month, day ):
        print >> sys.stderr, 'lose data'

d = MyDate(2006, 11, 29)
print d

class MyDate(datetime.date):

    def __new__( self, year, month, day ):
        print 'lose data'

    def __init__( self, year, month, day ):
        print 'lose data again'

d = MyDate(2006, 11, 29)
print d



The output is:

lose data
2006-11-29
lose data
None



The problem is that the initialization of the object is
done in its time_new() method which is registered for
__new__ rather than using an __init__ method.  This
prevent one from overriding the date/datetime/time
constructors.

cheers,


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

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

From noreply at sourceforge.net  Mon Mar 13 11:27:21 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 13 Mar 2006 02:27:21 -0800
Subject: [ python-Bugs-1448490 ] Convertion error for latin1 characters with
	iso-2022-jp-2
Message-ID: <E1FIkGn-00051T-Mn@sc8-sf-web6.sourceforge.net>

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

Please note that this message 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: Francois Duranleau (duranlef)
>Assigned to: Hye-Shik Chang (perky)
Summary: Convertion error for latin1 characters with iso-2022-jp-2

Initial Comment:
It seems like there are some errors while reading a
text file encoded with ISO-2022-JP-2 using the codecs
module. In all my test cases, all latin1 characters
with an accent (e.g. e acute) do not appear in the
output string. However, if I convert the file manually
using iconv, I get everything right. Here is a simple
script that will illustrate the problem:

###########################################

import codecs

import pygtk
import gtk

f = codecs.open( "test.iso-2022-jp-2" , "r" , \
                 "iso-2022-jp-2" )
s1 = f.readline().strip()
f.close()

f = open( "test.utf-8" , "r" )
s2 = f.readline().strip()

pack = gtk.VBox()
pack.pack_start( gtk.Label( s1 ) )
pack.pack_start( gtk.Label( s2 ) )

window = gtk.Window( gtk.WINDOW_TOPLEVEL )
window.add( pack )
window.show_all()

def event_destroy( widget , event , data ) :
    gtk.main_quit()
    return 0

window.connect( "delete_event" , \
                lambda w,e,d: False , None )
window.connect( "destroy" , event_destroy , None )

gtk.main()

###########################################

I put the file "test.iso-2022-jp-2" in attachment. To
create the UTF-8 version of the file, I used the
following shell command:

iconv -f ISO-2022-JP-2 -t UTF-8 \
    test.iso-2022-jp-2 > test.utf-8

When running this script, I would actually expect a
window with two times the same label. However, the
first one is missing the e acute.

--
Francois

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

>Comment By: Hye-Shik Chang (perky)
Date: 2006-03-13 19:27

Message:
Logged In: YES 
user_id=55188

Fixed in SVN (trunk:r42989, release24-maint:42991).
Thank you for the report!


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

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

From noreply at sourceforge.net  Mon Mar 13 13:09:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 13 Mar 2006 04:09:25 -0800
Subject: [ python-Bugs-1448804 ] Subscript operations generating incorrect code
Message-ID: <E1FIlrZ-0001qq-LT@sc8-sf-web5.sourceforge.net>

Bugs item #1448804, was opened at 2006-03-13 22: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=1448804&group_id=5470

Please note that this 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: Nick Coghlan (ncoghlan)
Assigned to: Nick Coghlan (ncoghlan)
Summary: Subscript operations generating incorrect code

Initial Comment:
As noted by Travis Oliphant on python-dev, subscript
operations on the HEAD are not always generating the
actual subscript operation.



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

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

From noreply at sourceforge.net  Mon Mar 13 13:32:41 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 13 Mar 2006 04:32:41 -0800
Subject: [ python-Bugs-1448804 ] Subscript operations generating incorrect code
Message-ID: <E1FImE5-0003J1-VE@sc8-sf-web5.sourceforge.net>

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

Please note that this 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: Nick Coghlan (ncoghlan)
Assigned to: Nick Coghlan (ncoghlan)
Summary: Subscript operations generating incorrect code

Initial Comment:
As noted by Travis Oliphant on python-dev, subscript
operations on the HEAD are not always generating the
actual subscript operation.



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

>Comment By: Nick Coghlan (ncoghlan)
Date: 2006-03-13 22:32

Message:
Logged In: YES 
user_id=1038590

Fixed (and test added) in SVN rev 42998

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

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

From noreply at sourceforge.net  Mon Mar 13 16:55:10 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 13 Mar 2006 07:55:10 -0800
Subject: [ python-Bugs-1448934 ] urllib2+https+proxy not working
Message-ID: <E1FIpO2-0007wz-UE@sc8-sf-web5.sourceforge.net>

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

Please note that this message 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: Rui Martins (ruibmartins)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2+https+proxy not working

Initial Comment:
Using urllib2 to access an https site using a proxy 
doesn't work. It always returns "<HTML> </HTML>"

I've been looking around for bug reports on this and 
code samples, but all that I've got were emails/forum 
posts dating back to 2003 warning that the HTTPS over 
Proxy in urllib2 isn't implemented in Python!

Is this true?

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

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

From noreply at sourceforge.net  Mon Mar 13 16:40:07 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 13 Mar 2006 07:40:07 -0800
Subject: [ python-Bugs-1448640 ] datetime.__init__ cannot be overridden
Message-ID: <E1FIp9T-0000nn-6G@sc8-sf-web2.sourceforge.net>

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

Please note that this message 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: Martin Blais (blais)
Assigned to: Nobody/Anonymous (nobody)
Summary: datetime.__init__ cannot be overridden

Initial Comment:
Hi

The following code does not work properly:

#!/usr/bin/env python
"""
Test overriding constructor of datetime classes.
"""

import sys, datetime

class MyDate(datetime.date):

    def __init__( self, year, month, day ):
        print >> sys.stderr, 'lose data'

d = MyDate(2006, 11, 29)
print d

class MyDate(datetime.date):

    def __new__( self, year, month, day ):
        print 'lose data'

    def __init__( self, year, month, day ):
        print 'lose data again'

d = MyDate(2006, 11, 29)
print d



The output is:

lose data
2006-11-29
lose data
None



The problem is that the initialization of the object is
done in its time_new() method which is registered for
__new__ rather than using an __init__ method.  This
prevent one from overriding the date/datetime/time
constructors.

cheers,


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

Comment By: splitscreen (splitscreen)
Date: 2006-03-13 15:40

Message:
Logged In: YES 
user_id=1126061

Isn't this an abuse of __new__ ?

Taken from the documentation:

"__new__ must return an object. There's nothing that
requires that it return a new object that is an instance of
its class argument, although that is the convention. If you
return an existing object, the constructor call will still
call its __init__ method. If you return an object of a
different class, its __init__ method will be called. If you
forget to return something, Python will unhelpfully return
None, and your caller will probably be very confused."

So, you're actually calling __init__ with None?

Or have i misunderstood?

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

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

From noreply at sourceforge.net  Mon Mar 13 17:42:13 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 13 Mar 2006 08:42:13 -0800
Subject: [ python-Bugs-1448640 ] datetime.__init__ cannot be overridden
Message-ID: <E1FIq7Z-0003n1-EM@sc8-sf-web6.sourceforge.net>

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

Please note that this message 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: Martin Blais (blais)
>Assigned to: Michael Hudson (mwh)
Summary: datetime.__init__ cannot be overridden

Initial Comment:
Hi

The following code does not work properly:

#!/usr/bin/env python
"""
Test overriding constructor of datetime classes.
"""

import sys, datetime

class MyDate(datetime.date):

    def __init__( self, year, month, day ):
        print >> sys.stderr, 'lose data'

d = MyDate(2006, 11, 29)
print d

class MyDate(datetime.date):

    def __new__( self, year, month, day ):
        print 'lose data'

    def __init__( self, year, month, day ):
        print 'lose data again'

d = MyDate(2006, 11, 29)
print d



The output is:

lose data
2006-11-29
lose data
None



The problem is that the initialization of the object is
done in its time_new() method which is registered for
__new__ rather than using an __init__ method.  This
prevent one from overriding the date/datetime/time
constructors.

cheers,


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

>Comment By: Michael Hudson (mwh)
Date: 2006-03-13 16:42

Message:
Logged In: YES 
user_id=6656

datetime.date objects are immutable, so this is the same as not being able to 
override __init__ in a subclass of int.  Override __new__ instead.

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

Comment By: splitscreen (splitscreen)
Date: 2006-03-13 15:40

Message:
Logged In: YES 
user_id=1126061

Isn't this an abuse of __new__ ?

Taken from the documentation:

"__new__ must return an object. There's nothing that
requires that it return a new object that is an instance of
its class argument, although that is the convention. If you
return an existing object, the constructor call will still
call its __init__ method. If you return an object of a
different class, its __init__ method will be called. If you
forget to return something, Python will unhelpfully return
None, and your caller will probably be very confused."

So, you're actually calling __init__ with None?

Or have i misunderstood?

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

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

From noreply at sourceforge.net  Mon Mar 13 20:19:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 13 Mar 2006 11:19:42 -0800
Subject: [ python-Bugs-1436428 ] urllib has trouble with Windows filenames
Message-ID: <E1FIsZy-0006UW-GF@sc8-sf-web2.sourceforge.net>

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

Please note that this message 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: Donovan Eastman (dpeastman)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib has trouble with Windows filenames

Initial Comment:
When you pass urllib the name of a local file including
a Windows drive letter (e.g. 'C:\dir\My File.txt')
URLopener.open() incorrectly interprets the drive
letter as the scheme of a URL.  Of course, given that
there is no scheme 'C', this fails.

I have solved this in my own code by putting the
following test before calling urllib.urlopen():

if url[1] == ':' and url[0].isalpha():
    url = 'file:' + url

Although this works fine in my particular case, it
seems like urllib should just simply "do the right
thing" without having to worry about it.  Therefore I
propose that urllib should automatically assume that
any URL that begins with a single alpha followed by a
colon is a local file.

The only potential downside would be that it would
preclude the use of single letter scheme names.  I did
a little research on this.  RFC 3986 suggests, but does
not explicitly state that scheme names must be more
than one character.
(http://www.gbiv.com/protocols/uri/rfc/rfc3986.html#scheme)
.  That said, there are no currently recognized single
letter scheme names
(http://www.iana.org/assignments/uri-schemes.html) and
it seems very unlikely that there every would be.

I would gladly write the code for this myself -- but I
suspect that it would take someone longer to review and
integrate my changes than it would to just write the code.

Thanks,
Donovan


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

Comment By: Koen van de Sande (shadowmorpher)
Date: 2006-03-13 20:19

Message:
Logged In: YES 
user_id=270334

Why should the URL lib module support opening of local 
files? It already does so through the file: protocol prefix, 
and do not see why it should support automatic detection of 
Windows filenames. AFAIK it does not do automatic detection 
of Unix filenames (one could recognize it from /home/
something), so why would Windows work differently?

I'm not an expert or anything, so I might be wrong.

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

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

From noreply at sourceforge.net  Mon Mar 13 22:45:29 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 13 Mar 2006 13:45:29 -0800
Subject: [ python-Bugs-1448640 ] datetime.__init__ cannot be overridden
Message-ID: <E1FIur3-0005Xr-Ot@sc8-sf-web4-b.sourceforge.net>

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

Please note that this message 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: Martin Blais (blais)
Assigned to: Michael Hudson (mwh)
Summary: datetime.__init__ cannot be overridden

Initial Comment:
Hi

The following code does not work properly:

#!/usr/bin/env python
"""
Test overriding constructor of datetime classes.
"""

import sys, datetime

class MyDate(datetime.date):

    def __init__( self, year, month, day ):
        print >> sys.stderr, 'lose data'

d = MyDate(2006, 11, 29)
print d

class MyDate(datetime.date):

    def __new__( self, year, month, day ):
        print 'lose data'

    def __init__( self, year, month, day ):
        print 'lose data again'

d = MyDate(2006, 11, 29)
print d



The output is:

lose data
2006-11-29
lose data
None



The problem is that the initialization of the object is
done in its time_new() method which is registered for
__new__ rather than using an __init__ method.  This
prevent one from overriding the date/datetime/time
constructors.

cheers,


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

>Comment By: Martin Blais (blais)
Date: 2006-03-13 21:45

Message:
Logged In: YES 
user_id=10996

Hmmmm... that's not quite true.  If I derive from datetime
in order to add new data members (e.g. in my case I add
"seq" which is used as a sequence number on top of datetime
for storing the names of photographs, the sequence number is
in case I have a panorama or multiple photographs in burst
mode--all within one second), I might want a different
constructor.

I tried overriding __new__ and had some troubles, cannot
remember what exactly, will reproduce and send code soon.


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

Comment By: Michael Hudson (mwh)
Date: 2006-03-13 16:42

Message:
Logged In: YES 
user_id=6656

datetime.date objects are immutable, so this is the same as not being able to 
override __init__ in a subclass of int.  Override __new__ instead.

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

Comment By: splitscreen (splitscreen)
Date: 2006-03-13 15:40

Message:
Logged In: YES 
user_id=1126061

Isn't this an abuse of __new__ ?

Taken from the documentation:

"__new__ must return an object. There's nothing that
requires that it return a new object that is an instance of
its class argument, although that is the convention. If you
return an existing object, the constructor call will still
call its __init__ method. If you return an object of a
different class, its __init__ method will be called. If you
forget to return something, Python will unhelpfully return
None, and your caller will probably be very confused."

So, you're actually calling __init__ with None?

Or have i misunderstood?

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

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

From noreply at sourceforge.net  Tue Mar 14 02:56:13 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 13 Mar 2006 17:56:13 -0800
Subject: [ python-Bugs-1436428 ] urllib has trouble with Windows filenames
Message-ID: <E1FIylh-0007oC-QD@sc8-sf-web3.sourceforge.net>

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

Please note that this message 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: Donovan Eastman (dpeastman)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib has trouble with Windows filenames

Initial Comment:
When you pass urllib the name of a local file including
a Windows drive letter (e.g. 'C:\dir\My File.txt')
URLopener.open() incorrectly interprets the drive
letter as the scheme of a URL.  Of course, given that
there is no scheme 'C', this fails.

I have solved this in my own code by putting the
following test before calling urllib.urlopen():

if url[1] == ':' and url[0].isalpha():
    url = 'file:' + url

Although this works fine in my particular case, it
seems like urllib should just simply "do the right
thing" without having to worry about it.  Therefore I
propose that urllib should automatically assume that
any URL that begins with a single alpha followed by a
colon is a local file.

The only potential downside would be that it would
preclude the use of single letter scheme names.  I did
a little research on this.  RFC 3986 suggests, but does
not explicitly state that scheme names must be more
than one character.
(http://www.gbiv.com/protocols/uri/rfc/rfc3986.html#scheme)
.  That said, there are no currently recognized single
letter scheme names
(http://www.iana.org/assignments/uri-schemes.html) and
it seems very unlikely that there every would be.

I would gladly write the code for this myself -- but I
suspect that it would take someone longer to review and
integrate my changes than it would to just write the code.

Thanks,
Donovan


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

>Comment By: Donovan Eastman (dpeastman)
Date: 2006-03-13 17:56

Message:
Logged In: YES 
user_id=757799

Reasons why urllib should open local files:
1) This allows you to write code that handles local files
and Internet files equally well -- without having to do any
special magic of your own.
2) The docs all say that it should.

I believe this would work just fine under Unix. In
URLopener.open() it looks for the protocol prefix and if it
can't find one, it assumes that it is a local file.

The problem on Windows is that you have these pesky drive
letters.  The form 'C:\location' ends up looking a lot like
the form 'http://location'.  Therefore it looks for a
protocol called 'c' -- which obviously isn't going to work.

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

Comment By: Koen van de Sande (shadowmorpher)
Date: 2006-03-13 11:19

Message:
Logged In: YES 
user_id=270334

Why should the URL lib module support opening of local 
files? It already does so through the file: protocol prefix, 
and do not see why it should support automatic detection of 
Windows filenames. AFAIK it does not do automatic detection 
of Unix filenames (one could recognize it from /home/
something), so why would Windows work differently?

I'm not an expert or anything, so I might be wrong.

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

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

From noreply at sourceforge.net  Tue Mar 14 03:07:02 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 13 Mar 2006 18:07:02 -0800
Subject: [ python-Bugs-1449311 ] optparse: extending actions missing
	ALWAYS_TYPES_ACTIONS
Message-ID: <E1FIywA-0005IJ-Vz@sc8-sf-web4-b.sourceforge.net>

Bugs item #1449311, was opened at 2006-03-13 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=1449311&group_id=5470

Please note that this 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: Christopher (chrism1)
Assigned to: Nobody/Anonymous (nobody)
Summary: optparse: extending actions missing ALWAYS_TYPES_ACTIONS

Initial Comment:
http://docs.python.org/lib/optparse-adding-new-actions.
html

This page of docs should include the ALWAYS_TYPED_
ACTIONS list from optparse.py. In the example, unless 
you add the following line:

    ALWAYS_TYPED_ACTIONS = Option.ALWAYS_TYPED_ACTIONS 
+ ("dict",)

, then the "Value" variable gets no value unless you 
explicitly pass "type='string'" to parser.add_option().



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

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

From noreply at sourceforge.net  Tue Mar 14 03:32:12 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 13 Mar 2006 18:32:12 -0800
Subject: [ python-Bugs-1436428 ] urllib has trouble with Windows filenames
Message-ID: <E1FIzKW-0006sb-JY@sc8-sf-web1.sourceforge.net>

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

Please note that this message 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: Donovan Eastman (dpeastman)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib has trouble with Windows filenames

Initial Comment:
When you pass urllib the name of a local file including
a Windows drive letter (e.g. 'C:\dir\My File.txt')
URLopener.open() incorrectly interprets the drive
letter as the scheme of a URL.  Of course, given that
there is no scheme 'C', this fails.

I have solved this in my own code by putting the
following test before calling urllib.urlopen():

if url[1] == ':' and url[0].isalpha():
    url = 'file:' + url

Although this works fine in my particular case, it
seems like urllib should just simply "do the right
thing" without having to worry about it.  Therefore I
propose that urllib should automatically assume that
any URL that begins with a single alpha followed by a
colon is a local file.

The only potential downside would be that it would
preclude the use of single letter scheme names.  I did
a little research on this.  RFC 3986 suggests, but does
not explicitly state that scheme names must be more
than one character.
(http://www.gbiv.com/protocols/uri/rfc/rfc3986.html#scheme)
.  That said, there are no currently recognized single
letter scheme names
(http://www.iana.org/assignments/uri-schemes.html) and
it seems very unlikely that there every would be.

I would gladly write the code for this myself -- but I
suspect that it would take someone longer to review and
integrate my changes than it would to just write the code.

Thanks,
Donovan


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

>Comment By: Donovan Eastman (dpeastman)
Date: 2006-03-13 18:32

Message:
Logged In: YES 
user_id=757799

OK - Here's my suggested fix:
This can be fixed with a single if statement (and a comment
to explain it to confused unix programmers).

In splittype(), right after the line that reads: 
scheme = match.group(1)
add the following:
#ignore single char schemes to avoid confusion with win32
drive letters
if len(scheme) > 1:

...and indent the next line.

Alternatively, the if statement could read:
if len(scheme) > 1 or sys.platform != 'win32':
...which would allow single letter scheme names on
non-Windows systems.  I would argue that it is better to be
consistent and have it work the same way on all OS's.

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

Comment By: Donovan Eastman (dpeastman)
Date: 2006-03-13 17:56

Message:
Logged In: YES 
user_id=757799

Reasons why urllib should open local files:
1) This allows you to write code that handles local files
and Internet files equally well -- without having to do any
special magic of your own.
2) The docs all say that it should.

I believe this would work just fine under Unix. In
URLopener.open() it looks for the protocol prefix and if it
can't find one, it assumes that it is a local file.

The problem on Windows is that you have these pesky drive
letters.  The form 'C:\location' ends up looking a lot like
the form 'http://location'.  Therefore it looks for a
protocol called 'c' -- which obviously isn't going to work.

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

Comment By: Koen van de Sande (shadowmorpher)
Date: 2006-03-13 11:19

Message:
Logged In: YES 
user_id=270334

Why should the URL lib module support opening of local 
files? It already does so through the file: protocol prefix, 
and do not see why it should support automatic detection of 
Windows filenames. AFAIK it does not do automatic detection 
of Unix filenames (one could recognize it from /home/
something), so why would Windows work differently?

I'm not an expert or anything, so I might be wrong.

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

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

From noreply at sourceforge.net  Tue Mar 14 08:37:15 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 13 Mar 2006 23:37:15 -0800
Subject: [ python-Bugs-1448058 ] problems with too many sockets in FreeBSD
Message-ID: <E1FJ45j-0000dF-TC@sc8-sf-web1.sourceforge.net>

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

Please note that this 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: aix-d (aix-d)
Assigned to: Nobody/Anonymous (nobody)
Summary: problems with too many sockets in FreeBSD

Initial Comment:
When there are about 200 sockets, or so, i'm getting
errors: "unable to select on socket"
We are running multithread application, for each thread
there is one socket.

TRACEBACK contains:
  r = self.connection.recv(1024)
error: unable to select on socket.

This error appeared after fixing this problem:
http://sourceforge.net/tracker/index.php?func=detail&aid=1429585&group_id=5470&atid=105470

Python version: 2.5a0 (trunk, Mar  8 2006, 18:28:30)
OS version: FreeBSD 6.1-PRERELEASE

Soon we will make program that will reproduce this
error if needed.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-13 23:37

Message:
Logged In: YES 
user_id=33168

What is the value of FD_SETSIZE?  Perhaps you should
increase this value before including any headers on FreeBSD?
 If you are using a lot of sockets, you may prefer to use
poll() instead of select() as poll() doesn't have the
FD_SETSIZE limitation.

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

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

From noreply at sourceforge.net  Tue Mar 14 08:50:35 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 13 Mar 2006 23:50:35 -0800
Subject: [ python-Bugs-1449397 ] urllib2+https+proxy not working
Message-ID: <E1FJ4Id-0001ht-5z@sc8-sf-web4-b.sourceforge.net>

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

Please note that this message 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: Rui Martins (ruibmartins)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2+https+proxy not working

Initial Comment:
Using urllib2 to access an https site using a proxy 
doesn't work. It always returns "<HTML> </HTML>"

I've been looking around for bug reports on this and 
code samples, but all that I've got were emails/forum 
posts dating back to 2003 warning that the HTTPS over 
Proxy in urllib2 isn't implemented in Python!

Is this true?

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

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

From noreply at sourceforge.net  Tue Mar 14 08:58:31 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 13 Mar 2006 23:58:31 -0800
Subject: [ python-Bugs-1449397 ] urllib2+https+proxy not working
Message-ID: <E1FJ4QJ-00045t-P9@sc8-sf-web2.sourceforge.net>

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

Please note that this message 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: Deleted
Resolution: None
Priority: 5
Submitted By: Rui Martins (ruibmartins)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2+https+proxy not working

Initial Comment:
Using urllib2 to access an https site using a proxy 
doesn't work. It always returns "<HTML> </HTML>"

I've been looking around for bug reports on this and 
code samples, but all that I've got were emails/forum 
posts dating back to 2003 warning that the HTTPS over 
Proxy in urllib2 isn't implemented in Python!

Is this true?

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

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

From noreply at sourceforge.net  Tue Mar 14 12:04:10 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 14 Mar 2006 03:04:10 -0800
Subject: [ python-Feature Requests-1449496 ] Python should use 3GB Address
	Space on Windows
Message-ID: <E1FJ7Jy-0005ZD-1c@sc8-sf-web4-b.sourceforge.net>

Feature Requests item #1449496, was opened at 2006-03-14 12:04
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=1449496&group_id=5470

Please note that this 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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin Gfeller (gfe)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python should use 3GB Address Space on Windows

Initial Comment:
Python runs fine using a 3GB address space on 32bit 
Windows.

To take advantage of this feature, Python should be 
linked using the /LARGEADDRESSAWARE flag of the 
linker. 

For details, please refer to:

http://msdn.microsoft.com/library/en-
us/memory/base/4gt_ram_tuning.asp

As most Windows users just use pre-built executables, 
this would be a worthwhile change. 

Best regards,
Martin Gfeller



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

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

From noreply at sourceforge.net  Tue Mar 14 15:54:12 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 14 Mar 2006 06:54:12 -0800
Subject: [ python-Bugs-1443504 ] locale.getpreferredencoding() dies when
	setlocale fails
Message-ID: <E1FJAua-00037F-DY@sc8-sf-web5.sourceforge.net>

Bugs item #1443504, was opened at 2006-03-05 08:50
Message generated for change (Settings changed) made by catherinedevlin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1443504&group_id=5470

Please note that this message 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: 3
Submitted By: Catherine Devlin (catherinedevlin)
Assigned to: Nobody/Anonymous (nobody)
Summary: locale.getpreferredencoding() dies when setlocale fails

Initial Comment:
I'm on Ubuntu 5.10, with Python 2.4.2-0ubuntu2, and
when I open a terminal window and run python, I get

>>> import locale
>>> locale.getpreferredencoding()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.4/locale.py", line 417, in
getpreferredencoding
    setlocale(LC_CTYPE, "")
  File "/usr/lib/python2.4/locale.py", line 381, in
setlocale
    return _setlocale(category, locale)
locale.Error: unsupported locale setting

However, if I su - root - or even su right back to my
own account (catherine) ! - then everything works.

This is of concern (to me, anyway) because this error
crashes bzr. 

I chose "Esperanto" as my language when setting up
Ubuntu.  (No, I wasn't trying to be funny - I really do
speak Esperanto!)  That may be why I found the problem,
but I don't think this is simply a problem with flawed
Esperanto support in Ubuntu - because the routine works
after su is used, and because
locale.nl_langinfo(CODESET) works fine (please read on).

Anyway, within locale.getpreferredencoding(), line 417
- setlocale(LC_CTYPE, "") - seems to be the problem...

>>> locale.setlocale(locale.LC_CTYPE)
'C'
>>> locale.setlocale(locale.LC_CTYPE, "")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.4/locale.py", line 381, in
setlocale
    return _setlocale(category, locale)
locale.Error: unsupported locale setting
>>> locale.setlocale(locale.LC_CTYPE, None)
'C'

This makes me wonder if setlocale(LC_TYPE, "") is
really so very necessary.  It seems to be there to prep
for the nl_langinfo call, but it doesn't actually seem
strictly necessary for that call to work.

>>> locale.nl_langinfo(locale.CODESET)
'ANSI_X3.4-1968'

... I get that result whether before or after calling
setlocale, and I get it under any account (including
root, where setlocale does not raise an exception).

Thus, as far as I can tell, it isn't really necessary
to set setlocale(LC_CTYPE, "") or die trying, and
accepting the nl_langinfo result without a 
successful setlocale(LC_CTYPE, "") would be preferable
to raising an unhandled exception.  I suggest that
setlocale(LC_TYPE, "") be enclosed in a try block.

                try:
                    setlocale(LC_CTYPE, "")
                except:
                    None

Since I don't really understand what it's doing in the
first place, I don't know if this is really a good patch.

Thanks!

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

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

From noreply at sourceforge.net  Wed Mar 15 01:23:53 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 14 Mar 2006 16:23:53 -0800
Subject: [ python-Bugs-1450019 ] Build of readline fails
Message-ID: <E1FJJnt-00080T-NT@sc8-sf-web2.sourceforge.net>

Bugs item #1450019, was opened at 2006-03-14 18: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=1450019&group_id=5470

Please note that this 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.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Sydney Weidman (weidmans)
Assigned to: Nobody/Anonymous (nobody)
Summary: Build of readline fails

Initial Comment:
I was attempting to compile Python-2.3.5 under Fedora
Core 4:

Python 2.3.5 (#14, Mar 14 2006, 17:57:17)
[GCC 4.0.2 20051125 (Red Hat 4.0.2-8)] on linux2

and needed it to have readline support

No matter how I compiled it, the readline module was
never built, and of course readline functionality did
not work.

I tried ./configure --with-readline=/usr and a couple
of other configure options that I thought would help,
but nothing worked. Finally, I tried:

make Modules/readline

which gave the error:

gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -I. -I./Include
-L/home/sweidman/Applications/Python-2.3.5 
Modules/readline.c   -o Modules/readline
Modules/readline.c:96: error: static declaration of
???history_length??? follows non-static declaration
/usr/include/readline/history.h:242: error: previous
declaration of ???history_length??? was here
make: *** [Modules/readline] Error 1

So without knowing what I was really doing, I commented
out the definition of history_length at
Modules/readline.c:96

After making that change, Python-2.3.5 compiled and ran
fine with readline support working; i.e. "import
readline" gave no errors and the arrow keys bring back
the last command.

So is this a bug or a quirk on my platform or something
else I'm doing wrong?

Thanks for the great software!!


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

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

From noreply at sourceforge.net  Wed Mar 15 06:05:06 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 14 Mar 2006 21:05:06 -0800
Subject: [ python-Bugs-931877 ] Segfault in object_reduce_ex
Message-ID: <E1FJOC2-0006oe-9f@sc8-sf-web4-b.sourceforge.net>

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

Please note that this message 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: Tim Peters (tim_one)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Segfault in object_reduce_ex

Initial Comment:
Shane Hathaway bumped into this, unbounded recursion 
in typeobject.c's object_reduce_ex().  This occurs in 
Python 2.3.3 and current CVS.

Assigned to Guido, to ponder whether object_reduce_ex 
is doing what it should; if it is (which seems likely to 
me), I suppose we need to inject a recursion counter to 
prevent the segfault.

The failing case is short, but I'll attach it (temp99.py) to 
avoid SF line mangling.  While the test uses pickle, same 
symptom if it's changed to use cPickle instead.

Jim Fulton's analysis:

"""
This is a very clever infinite loop.  The proxy doesn't
actually proxy, but it does manage to confuse reduce 
about what's going on.

reduce tries to figure out if it has been overridden by
asking whether the class's reduce is the same as
object.__reduce__. It doesn't expect to be lied to
about the class.  Things wouldn't have been so bad if
the proxy had proxied __reduce__ as well as __class__.
"""

The priority hasn't been bumped, because "the real 
code" from which this was whittled down wasn't doing 
what it needed to do anyway, and the recursion went 
away when the real code was repaired.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2006-03-15 00:05

Message:
Logged In: YES 
user_id=6380

Unassigning. I need to concentrate on Python 3000.

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

Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-10 16:58

Message:
Logged In: YES 
user_id=1188172

Still crashing with 2.5...

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

Comment By: Nathan Srebro (nati)
Date: 2004-11-29 20:26

Message:
Logged In: YES 
user_id=63133

This infinite recursion also occurs in another place, that
got me stumped for a couple of days when old code that
worked with Python 2.2 stopped working.  If __class__ is not
fidgeted with (as in original bug report), but a descriptor
returns a custom reduce for the class, but not for its
objects, reduce enters an infinite loop on the object:

"""
class descriptor_for_reduce(object):
    def __get__(self,obj,tp=None):
        if obj is not None: return
super(ASpecialClass,obj).__reduce__
        return self.reducer
    def reducer(self,proto=None):
        return "VerySpecial"

class ASpecialClass(object):
    __reduce__ = descriptor_for_reduce()

copy.copy(ASpecialClass())
"""

ASpecialClass().__reduce__ is object.__reduce__, which is
implemented by typeobject.c:object_reduce_ex.  This function
(that doesn't know if its called as the __reduce__ or the
__reduce_ex__ method) tries to detect if the object's
__reduce__ is overridden.  It does so by checking if the
object's class's __reduce__ is overridden, and in fact it
is.  It then assumes that the object's __reduce__ is
overridden, and calls it.  But the object's __reduce__ is
the same function, causing the infinite loop.

If __reduce_ex__ is used instead of __reduce__, the problem
goes away, ASpecialClass().__reduce_ex__() return the usual
tuple, and ASpecialClass.__reduce_ex__() return
"VerySpecial".  But when __reduce__ is overridden,
ASpecialClass().__reduce__() enters an infinite loop.

I believe this is a legitimate example that should behave
just as when __reduce_ex__ is overridden.  The example
doesn't lie about __class__, and it is certainly legitimate
for define a property that behaves differently for the class
and for its objects.

Where did this come up and why would I ever care about a
class's __reduce__?  The __reduce__ attribute of a class is
never used by (the standard) pickle or copy, since
save_global() is called instead. However, I have a custom
pickler, implemented as a subclass of pickle.Pickler, which
falls back on the class's __reduce__ when save_global()
fails.  This way, I can pickle certain classes that are
created at run-time (and can be easily recreated, e.g. from
their bases and dictionaries).


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

Comment By: Tim Peters (tim_one)
Date: 2004-04-08 13:51

Message:
Logged In: YES 
user_id=31435

Hmm!  The temp99.py download link doesn't work for me.  
Here's the content in case it doesn't work for others either:

"""
import cPickle as pickle
from pickle import dumps

class SimpleItem:
    def __reduce__(self):
        return (self.__class__, None, {})

class Proxy(object):
    __class__ =  property(lambda self: self.__target.__class__)

    def __init__(self, target):
        self.__target = target

    def __getstate__(self):
        raise RuntimeError("No don't pickle me!  Aaarrgghh!")

p = Proxy(SimpleItem())
dumps(p)
"""

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

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

From noreply at sourceforge.net  Wed Mar 15 09:08:10 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 15 Mar 2006 00:08:10 -0800
Subject: [ python-Bugs-1450019 ] Build of readline fails
Message-ID: <E1FJR3C-0001HN-38@sc8-sf-web1.sourceforge.net>

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

Please note that this 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.3
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Sydney Weidman (weidmans)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: Build of readline fails

Initial Comment:
I was attempting to compile Python-2.3.5 under Fedora
Core 4:

Python 2.3.5 (#14, Mar 14 2006, 17:57:17)
[GCC 4.0.2 20051125 (Red Hat 4.0.2-8)] on linux2

and needed it to have readline support

No matter how I compiled it, the readline module was
never built, and of course readline functionality did
not work.

I tried ./configure --with-readline=/usr and a couple
of other configure options that I thought would help,
but nothing worked. Finally, I tried:

make Modules/readline

which gave the error:

gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -I. -I./Include
-L/home/sweidman/Applications/Python-2.3.5 
Modules/readline.c   -o Modules/readline
Modules/readline.c:96: error: static declaration of
???history_length??? follows non-static declaration
/usr/include/readline/history.h:242: error: previous
declaration of ???history_length??? was here
make: *** [Modules/readline] Error 1

So without knowing what I was really doing, I commented
out the definition of history_length at
Modules/readline.c:96

After making that change, Python-2.3.5 compiled and ran
fine with readline support working; i.e. "import
readline" gave no errors and the arrow keys bring back
the last command.

So is this a bug or a quirk on my platform or something
else I'm doing wrong?

Thanks for the great software!!


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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-15 00:08

Message:
Logged In: YES 
user_id=33168

Python 2.3 isn't supported any longer.  In the current
version, it looks like history_length was renamed to prepend
an underscore (ie, the name became: _history_length).  This
was presumably to fix the same problem.  The name also
changed in write_history_file(), set_history_length(), and
get_history_length().

It's not so much anything you are doing wrong, just a
compatability problem, since FC4 is quite a bit newer than
Python 2.3.  If you upgrade to Python 2.4, you shouldn't
have the problem, or you can run with your local modification.

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

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

From noreply at sourceforge.net  Wed Mar 15 10:05:10 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 15 Mar 2006 01:05:10 -0800
Subject: [ python-Bugs-1450212 ] int() and isdigit() accept non-digit numbers
	when using unic
Message-ID: <E1FJRwM-0004qA-0b@sc8-sf-web1.sourceforge.net>

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

Please note that this message 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: Pierre-Fr?d?ric Caillaud (peufeu)
Assigned to: Nobody/Anonymous (nobody)
Summary: int() and isdigit() accept non-digit numbers when using unic

Initial Comment:
I had a very surprising bug this morning, in a python script which 
extract numeric information from human entered text.

The problem is the following : many UNICODE characters, in 
UNICODE strings, are considered to be digits. For instance, the 
character "??" (does it appear on your screen ? it's u'\xb2').

The output of the following command is pretty interesting :

print ''.join([x for x in map( unichr, xrange( 65536 )) if x.isdigit()])

Then, int() will happily parse the string :

int( u"????????????????" )
56789012

(I really hope this bug system supports unicode).

However, I can't do a=???????????????? for instance.

Philosophically, Python is right, these characters are probably all 
digits, and it's pretty cool to be able to parse numbers written in 
ARABIC-INDIC DIGITs or something, as unicodedata.name says).

However, from a practical point of view, I guess most parsing done 
with python isn't on OCR'd cuneiform stone tablets, but rather 
modern computer documents...

Whenever a surface (in m??) was near a phone number in my human 
entered text, the "??" would be absorbed as a part of the phone 
number, because u"??".isdigit() is True. Then bullshit phone numbers 
would appear on the website.

Any number followed by a little footnote number will get the 
footnote number embedded...

I had to replace all the .isdigit() with a re.compile( ur"^\d+$" ).
match(). Interestingly, for re, even in unicode, \d is 0-9 and nothing 
else.

At least, it would be normal for int() to raise an exception when fed 
this type of data. Please.




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

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

From noreply at sourceforge.net  Wed Mar 15 10:10:50 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 15 Mar 2006 01:10:50 -0800
Subject: [ python-Bugs-1450212 ] int() and isdigit() accept non-digit unicode
	numbers
Message-ID: <E1FJS1q-0005Ck-Fx@sc8-sf-web5.sourceforge.net>

Bugs item #1450212, was opened at 2006-03-15 09:05
Message generated for change (Settings changed) made by peufeu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1450212&group_id=5470

Please note that this message 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: Pierre-Fr?d?ric Caillaud (peufeu)
Assigned to: Nobody/Anonymous (nobody)
>Summary: int() and isdigit() accept non-digit unicode numbers

Initial Comment:
I had a very surprising bug this morning, in a python script which 
extract numeric information from human entered text.

The problem is the following : many UNICODE characters, in 
UNICODE strings, are considered to be digits. For instance, the 
character "??" (does it appear on your screen ? it's u'\xb2').

The output of the following command is pretty interesting :

print ''.join([x for x in map( unichr, xrange( 65536 )) if x.isdigit()])

Then, int() will happily parse the string :

int( u"????????????????" )
56789012

(I really hope this bug system supports unicode).

However, I can't do a=???????????????? for instance.

Philosophically, Python is right, these characters are probably all 
digits, and it's pretty cool to be able to parse numbers written in 
ARABIC-INDIC DIGITs or something, as unicodedata.name says).

However, from a practical point of view, I guess most parsing done 
with python isn't on OCR'd cuneiform stone tablets, but rather 
modern computer documents...

Whenever a surface (in m??) was near a phone number in my human 
entered text, the "??" would be absorbed as a part of the phone 
number, because u"??".isdigit() is True. Then bullshit phone numbers 
would appear on the website.

Any number followed by a little footnote number will get the 
footnote number embedded...

I had to replace all the .isdigit() with a re.compile( ur"^\d+$" ).
match(). Interestingly, for re, even in unicode, \d is 0-9 and nothing 
else.

At least, it would be normal for int() to raise an exception when fed 
this type of data. Please.




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

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

From noreply at sourceforge.net  Wed Mar 15 11:42:54 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 15 Mar 2006 02:42:54 -0800
Subject: [ python-Bugs-1450212 ] int() and isdigit() accept non-digit unicode
	numbers
Message-ID: <E1FJTSw-0004tk-AH@sc8-sf-web2.sourceforge.net>

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

Please note that this message 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: Invalid
Priority: 5
Submitted By: Peufeu (peufeu)
Assigned to: Nobody/Anonymous (nobody)
Summary: int() and isdigit() accept non-digit unicode numbers

Initial Comment:
I had a very surprising bug this morning, in a python script which 
extract numeric information from human entered text.

The problem is the following : many UNICODE characters, in 
UNICODE strings, are considered to be digits. For instance, the 
character "??" (does it appear on your screen ? it's u'\xb2').

The output of the following command is pretty interesting :

print ''.join([x for x in map( unichr, xrange( 65536 )) if x.isdigit()])

Then, int() will happily parse the string :

int( u"????????????????" )
56789012

(I really hope this bug system supports unicode).

However, I can't do a=???????????????? for instance.

Philosophically, Python is right, these characters are probably all 
digits, and it's pretty cool to be able to parse numbers written in 
ARABIC-INDIC DIGITs or something, as unicodedata.name says).

However, from a practical point of view, I guess most parsing done 
with python isn't on OCR'd cuneiform stone tablets, but rather 
modern computer documents...

Whenever a surface (in m??) was near a phone number in my human 
entered text, the "??" would be absorbed as a part of the phone 
number, because u"??".isdigit() is True. Then bullshit phone numbers 
would appear on the website.

Any number followed by a little footnote number will get the 
footnote number embedded...

I had to replace all the .isdigit() with a re.compile( ur"^\d+$" ).
match(). Interestingly, for re, even in unicode, \d is 0-9 and nothing 
else.

At least, it would be normal for int() to raise an exception when fed 
this type of data. Please.




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

>Comment By: M.-A. Lemburg (lemburg)
Date: 2006-03-15 11:42

Message:
Logged In: YES 
user_id=38388

Python is following the Unicode standard in this respect.

If you want to make sure that only a subset of numbers is
parsed, I'd suggest that you write a little helper function
that implements the RE check and then lets int() do its work.

Rejecting as "invalid".


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

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

From noreply at sourceforge.net  Wed Mar 15 13:18:18 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 15 Mar 2006 04:18:18 -0800
Subject: [ python-Bugs-1450212 ] int() and isdigit() accept non-digit unicode
	numbers
Message-ID: <E1FJUxG-0000Hf-53@sc8-sf-web4-b.sourceforge.net>

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

Please note that this message 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: Invalid
Priority: 5
Submitted By: Peufeu (peufeu)
Assigned to: Nobody/Anonymous (nobody)
Summary: int() and isdigit() accept non-digit unicode numbers

Initial Comment:
I had a very surprising bug this morning, in a python script which 
extract numeric information from human entered text.

The problem is the following : many UNICODE characters, in 
UNICODE strings, are considered to be digits. For instance, the 
character "??" (does it appear on your screen ? it's u'\xb2').

The output of the following command is pretty interesting :

print ''.join([x for x in map( unichr, xrange( 65536 )) if x.isdigit()])

Then, int() will happily parse the string :

int( u"????????????????" )
56789012

(I really hope this bug system supports unicode).

However, I can't do a=???????????????? for instance.

Philosophically, Python is right, these characters are probably all 
digits, and it's pretty cool to be able to parse numbers written in 
ARABIC-INDIC DIGITs or something, as unicodedata.name says).

However, from a practical point of view, I guess most parsing done 
with python isn't on OCR'd cuneiform stone tablets, but rather 
modern computer documents...

Whenever a surface (in m??) was near a phone number in my human 
entered text, the "??" would be absorbed as a part of the phone 
number, because u"??".isdigit() is True. Then bullshit phone numbers 
would appear on the website.

Any number followed by a little footnote number will get the 
footnote number embedded...

I had to replace all the .isdigit() with a re.compile( ur"^\d+$" ).
match(). Interestingly, for re, even in unicode, \d is 0-9 and nothing 
else.

At least, it would be normal for int() to raise an exception when fed 
this type of data. Please.




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

>Comment By: Hye-Shik Chang (perky)
Date: 2006-03-15 21:18

Message:
Logged In: YES 
user_id=55188

In the mean time, it can be simply regarded as unicode
conforming.
But a minor issue came up to my mind:

I think the name, `isdigit', is quite similar to ISO C's
equivalent.  But they don't behave same; ISO C and POSIX
SUSv3 specifies isdigit() is true only for 0 1 2 3 4 5 6 7 8
9.  So, isdigit() of C doesn't return true for any of
unicode characters > ord('9').  I just fear that the
inconsistency might cause some confusion.



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

Comment By: M.-A. Lemburg (lemburg)
Date: 2006-03-15 19:42

Message:
Logged In: YES 
user_id=38388

Python is following the Unicode standard in this respect.

If you want to make sure that only a subset of numbers is
parsed, I'd suggest that you write a little helper function
that implements the RE check and then lets int() do its work.

Rejecting as "invalid".


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

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

From noreply at sourceforge.net  Wed Mar 15 13:32:54 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 15 Mar 2006 04:32:54 -0800
Subject: [ python-Bugs-1450212 ] int() and isdigit() accept non-digit unicode
	numbers
Message-ID: <E1FJVBO-0004di-Fp@sc8-sf-web3.sourceforge.net>

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

Please note that this message 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: Invalid
Priority: 5
Submitted By: Peufeu (peufeu)
Assigned to: Nobody/Anonymous (nobody)
Summary: int() and isdigit() accept non-digit unicode numbers

Initial Comment:
I had a very surprising bug this morning, in a python script which 
extract numeric information from human entered text.

The problem is the following : many UNICODE characters, in 
UNICODE strings, are considered to be digits. For instance, the 
character "??" (does it appear on your screen ? it's u'\xb2').

The output of the following command is pretty interesting :

print ''.join([x for x in map( unichr, xrange( 65536 )) if x.isdigit()])

Then, int() will happily parse the string :

int( u"????????????????" )
56789012

(I really hope this bug system supports unicode).

However, I can't do a=???????????????? for instance.

Philosophically, Python is right, these characters are probably all 
digits, and it's pretty cool to be able to parse numbers written in 
ARABIC-INDIC DIGITs or something, as unicodedata.name says).

However, from a practical point of view, I guess most parsing done 
with python isn't on OCR'd cuneiform stone tablets, but rather 
modern computer documents...

Whenever a surface (in m??) was near a phone number in my human 
entered text, the "??" would be absorbed as a part of the phone 
number, because u"??".isdigit() is True. Then bullshit phone numbers 
would appear on the website.

Any number followed by a little footnote number will get the 
footnote number embedded...

I had to replace all the .isdigit() with a re.compile( ur"^\d+$" ).
match(). Interestingly, for re, even in unicode, \d is 0-9 and nothing 
else.

At least, it would be normal for int() to raise an exception when fed 
this type of data. Please.




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

>Comment By: M.-A. Lemburg (lemburg)
Date: 2006-03-15 13:32

Message:
Logged In: YES 
user_id=38388

I can see your point, but if we were to follow that scheme,
we'd have to introduce a whole new set of APIs for Unicode
character testing.

Note that the comparison to C standards is flawed in this
respect: 

Unicode APIs would have to be compared to the wide character
APIs, e.g. iswdigit() which do behave (more or less) like
isdigit() does in Python for Unicode characters.

Furthermore, the isXYZ() and iswXYZ() APIs in C are locale
aware (and so are the Python functions for strings), whereas
the Python Unicode implementation deliberately is not.

So in summary, you can't really compare the C functions to
the Python functions.


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

Comment By: Hye-Shik Chang (perky)
Date: 2006-03-15 13:18

Message:
Logged In: YES 
user_id=55188

In the mean time, it can be simply regarded as unicode
conforming.
But a minor issue came up to my mind:

I think the name, `isdigit', is quite similar to ISO C's
equivalent.  But they don't behave same; ISO C and POSIX
SUSv3 specifies isdigit() is true only for 0 1 2 3 4 5 6 7 8
9.  So, isdigit() of C doesn't return true for any of
unicode characters > ord('9').  I just fear that the
inconsistency might cause some confusion.



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

Comment By: M.-A. Lemburg (lemburg)
Date: 2006-03-15 11:42

Message:
Logged In: YES 
user_id=38388

Python is following the Unicode standard in this respect.

If you want to make sure that only a subset of numbers is
parsed, I'd suggest that you write a little helper function
that implements the RE check and then lets int() do its work.

Rejecting as "invalid".


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

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

From noreply at sourceforge.net  Wed Mar 15 14:05:15 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 15 Mar 2006 05:05:15 -0800
Subject: [ python-Bugs-1450212 ] int() and isdigit() accept non-digit unicode
	numbers
Message-ID: <E1FJVgh-0003JN-Qn@sc8-sf-web1.sourceforge.net>

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

Please note that this message 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: Invalid
Priority: 5
Submitted By: Peufeu (peufeu)
Assigned to: Nobody/Anonymous (nobody)
Summary: int() and isdigit() accept non-digit unicode numbers

Initial Comment:
I had a very surprising bug this morning, in a python script which 
extract numeric information from human entered text.

The problem is the following : many UNICODE characters, in 
UNICODE strings, are considered to be digits. For instance, the 
character "??" (does it appear on your screen ? it's u'\xb2').

The output of the following command is pretty interesting :

print ''.join([x for x in map( unichr, xrange( 65536 )) if x.isdigit()])

Then, int() will happily parse the string :

int( u"????????????????" )
56789012

(I really hope this bug system supports unicode).

However, I can't do a=???????????????? for instance.

Philosophically, Python is right, these characters are probably all 
digits, and it's pretty cool to be able to parse numbers written in 
ARABIC-INDIC DIGITs or something, as unicodedata.name says).

However, from a practical point of view, I guess most parsing done 
with python isn't on OCR'd cuneiform stone tablets, but rather 
modern computer documents...

Whenever a surface (in m??) was near a phone number in my human 
entered text, the "??" would be absorbed as a part of the phone 
number, because u"??".isdigit() is True. Then bullshit phone numbers 
would appear on the website.

Any number followed by a little footnote number will get the 
footnote number embedded...

I had to replace all the .isdigit() with a re.compile( ur"^\d+$" ).
match(). Interestingly, for re, even in unicode, \d is 0-9 and nothing 
else.

At least, it would be normal for int() to raise an exception when fed 
this type of data. Please.




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

>Comment By: Peufeu (peufeu)
Date: 2006-03-15 13:05

Message:
Logged In: YES 
user_id=587274

It certainly is confusing, and it bit me ;)

That .isdigit() is unicode-conformant is understandable (but a hint should 
be added to the docs IMHO). I with there was a .isasciidigit() function on 
the unicode string, because using a helper is ugly.

However int() accepting all these characters and happily parsing them 
worries me a bit more. Is it really supposed to do this ?

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2006-03-15 12:32

Message:
Logged In: YES 
user_id=38388

I can see your point, but if we were to follow that scheme,
we'd have to introduce a whole new set of APIs for Unicode
character testing.

Note that the comparison to C standards is flawed in this
respect: 

Unicode APIs would have to be compared to the wide character
APIs, e.g. iswdigit() which do behave (more or less) like
isdigit() does in Python for Unicode characters.

Furthermore, the isXYZ() and iswXYZ() APIs in C are locale
aware (and so are the Python functions for strings), whereas
the Python Unicode implementation deliberately is not.

So in summary, you can't really compare the C functions to
the Python functions.


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

Comment By: Hye-Shik Chang (perky)
Date: 2006-03-15 12:18

Message:
Logged In: YES 
user_id=55188

In the mean time, it can be simply regarded as unicode
conforming.
But a minor issue came up to my mind:

I think the name, `isdigit', is quite similar to ISO C's
equivalent.  But they don't behave same; ISO C and POSIX
SUSv3 specifies isdigit() is true only for 0 1 2 3 4 5 6 7 8
9.  So, isdigit() of C doesn't return true for any of
unicode characters > ord('9').  I just fear that the
inconsistency might cause some confusion.



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

Comment By: M.-A. Lemburg (lemburg)
Date: 2006-03-15 10:42

Message:
Logged In: YES 
user_id=38388

Python is following the Unicode standard in this respect.

If you want to make sure that only a subset of numbers is
parsed, I'd suggest that you write a little helper function
that implements the RE check and then lets int() do its work.

Rejecting as "invalid".


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

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

From noreply at sourceforge.net  Wed Mar 15 16:17:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 15 Mar 2006 07:17:23 -0800
Subject: [ python-Bugs-1450456 ] windows python truncates files when reading
	them
Message-ID: <E1FJXkZ-0003Iu-ML@sc8-sf-web4-b.sourceforge.net>

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

Please note that this 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: tom berger (object)
Assigned to: Nobody/Anonymous (nobody)
Summary: windows python truncates files when reading them

Initial Comment:
when using python for windows, opening a file and
calling read() on the file object returns only some of
the file (about 1K). i am expecting read to return the
entire contents of the file (and this is what i get
when i run the same code on cygwin and linux).

to reproduce:

prepare a sufficiently large file myfile.xxx (say > 100K)

source = open('myfile.xxx', 'r')
dest = open('copy_myfile.xxx', 'w')
dest.write(source.read())
source.close()
dest.close()

myfile.xxx and copy_myfile.xxx should be identical, and
they are if you run this on most python distributions.
when running the version installed from the .msi
installer on python.org the copy is truncated (as part
of reading, i'm pretty sure).

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

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

From noreply at sourceforge.net  Wed Mar 15 16:22:39 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 15 Mar 2006 07:22:39 -0800
Subject: [ python-Bugs-1450456 ] windows python truncates files when reading
	them
Message-ID: <E1FJXpf-0003kq-AS@sc8-sf-web4-b.sourceforge.net>

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

Please note that this 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: Pending
>Resolution: Invalid
Priority: 5
Submitted By: tom berger (object)
Assigned to: Nobody/Anonymous (nobody)
Summary: windows python truncates files when reading them

Initial Comment:
when using python for windows, opening a file and
calling read() on the file object returns only some of
the file (about 1K). i am expecting read to return the
entire contents of the file (and this is what i get
when i run the same code on cygwin and linux).

to reproduce:

prepare a sufficiently large file myfile.xxx (say > 100K)

source = open('myfile.xxx', 'r')
dest = open('copy_myfile.xxx', 'w')
dest.write(source.read())
source.close()
dest.close()

myfile.xxx and copy_myfile.xxx should be identical, and
they are if you run this on most python distributions.
when running the version installed from the .msi
installer on python.org the copy is truncated (as part
of reading, i'm pretty sure).

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

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-15 15:22

Message:
Logged In: YES 
user_id=849994

I'm guessing here, but the only conclusion is that you are
reading a binary file. Since Windows makes a difference
between text and binary files, you must read the file with
mode 'rb', or Windows will stop at the first chr(26) ==
Ctrl+Z == EOF.

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

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

From noreply at sourceforge.net  Wed Mar 15 16:36:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 15 Mar 2006 07:36:46 -0800
Subject: [ python-Bugs-1450456 ] windows python truncates files when reading
	them
Message-ID: <E1FJY3K-0004eF-Bw@sc8-sf-web4-b.sourceforge.net>

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

Please note that this 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: Deleted
Resolution: Invalid
Priority: 5
Submitted By: tom berger (object)
Assigned to: Nobody/Anonymous (nobody)
Summary: windows python truncates files when reading them

Initial Comment:
when using python for windows, opening a file and
calling read() on the file object returns only some of
the file (about 1K). i am expecting read to return the
entire contents of the file (and this is what i get
when i run the same code on cygwin and linux).

to reproduce:

prepare a sufficiently large file myfile.xxx (say > 100K)

source = open('myfile.xxx', 'r')
dest = open('copy_myfile.xxx', 'w')
dest.write(source.read())
source.close()
dest.close()

myfile.xxx and copy_myfile.xxx should be identical, and
they are if you run this on most python distributions.
when running the version installed from the .msi
installer on python.org the copy is truncated (as part
of reading, i'm pretty sure).

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

>Comment By: tom berger (object)
Date: 2006-03-15 10:36

Message:
Logged In: YES 
user_id=110577

yes, of course.

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

Comment By: Georg Brandl (gbrandl)
Date: 2006-03-15 10:22

Message:
Logged In: YES 
user_id=849994

I'm guessing here, but the only conclusion is that you are
reading a binary file. Since Windows makes a difference
between text and binary files, you must read the file with
mode 'rb', or Windows will stop at the first chr(26) ==
Ctrl+Z == EOF.

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

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

From noreply at sourceforge.net  Thu Mar 16 00:36:35 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 15 Mar 2006 15:36:35 -0800
Subject: [ python-Bugs-1450807 ] Python build fails for gcc 4.x from Gnu
Message-ID: <E1FJfXf-0001gU-E9@sc8-sf-web4-b.sourceforge.net>

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

Please note that this 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: John W. Grove (johnwgrove)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python build fails for gcc 4.x from Gnu

Initial Comment:
The configure script for Python 4.2.2 add the compiler
flags -Wno-long-double and -no-cpp-precomp when using
the Gnu gcc compiler on Darwin. This causes the build
to fail when using versions of GCC build directly from
Gnu source (for example gcc-4.0.2 and gcc-4.1). These
options are only available when using the "native" gcc
compilers supplied with the Darwin OS. In particular I
am using OS X 8.5.0. There is a simple correction to
this problem that involves using autoconf tests for the
appropriateness of these options before adding them to
the BASECFLAGS environment variable. In particular the
following works:

Replace the line

BASECFLAGS="$BASECFLAGS -Wno-long-double
-no-cpp-precomp -mno-fused-madd"

at or near line 3165 under the Darwin case in configure.in

with the following test

AC_LANG_SAVE
	    AC_LANG_C
            ac_save_cc="$CC"
	    for arg in -Wno-long-double -no-cpp-precomp
-mno-fused-madd ; do
	      CC="$ac_save_cc $arg"
	      AC_COMPILE_IFELSE([
		      AC_LANG_SOURCE([[
#include <stdlib.h>
#include <stdio.h>
int main(int argc,char**argv)
{
    return 0;
}
              ]])],[BASECFLAGS="$BASECFLAGS $arg"],[])
	    done
            CC="$ac_save_cc"
	    AC_LANG_RESTORE

in other words test to see if the option works with the
chosen compiler before adding it blindly to BASECFLAGS.

I am attaching this version of configure.in for your
convenience. I tested my build of Python-2.4.2 on both
Linux and Darwin using the apple version of gcc 3.3 as
well as Gnu versions gcc 4.0.2 and 4.1 that I built
from source. The build and install worked properly and
the python executable was runable in all cases. I did
not perform more extensive regression tests, but I
believe this change has no effect for compilations
using previously support configurations, and only
applies for new currently unsupported compilers.





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

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

From noreply at sourceforge.net  Thu Mar 16 16:00:43 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 16 Mar 2006 07:00:43 -0800
Subject: [ python-Bugs-1451341 ] msgfmt.py: fuzzy messages not correctly found
Message-ID: <E1FJtxz-0000vF-Si@sc8-sf-web5.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Demos and Tools
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Hanno Schlichting (hannosch)
Assigned to: Nobody/Anonymous (nobody)
Summary: msgfmt.py: fuzzy messages not correctly found

Initial Comment:
In the msgfmt.py script which is installed in
%PYTHON_HOME%\Tools\i18n (on Windows) on line 129 to
131 it says:

# Record a fuzzy mark
if l[:2] == '#,' and l.find('fuzzy'):
    fuzzy = 1

this should be:

# Record a fuzzy mark
if l[:2] == '#,' and l.find('fuzzy') > -1:
    fuzzy = 1

or all lines beginning with '#,' will be treated as
fuzzy. Only change is the "> -1".

This applies to all versions of Python. It has been
brought to my attention by Andrey Lebedev who found
this in a product which uses a slightly modified msgfmt.py.

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

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

From noreply at sourceforge.net  Thu Mar 16 17:20:26 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 16 Mar 2006 08:20:26 -0800
Subject: [ python-Bugs-1444408 ] subprocess test cases fail with
	noexec-mounted /tmp
Message-ID: <E1FJvD8-0000a9-Bu@sc8-sf-web2.sourceforge.net>

Bugs item #1444408, was opened at 2006-03-06 21:48
Message generated for change (Comment added) made by calvin
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: None
Group: None
Status: Open
Resolution: None
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: 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  Thu Mar 16 18:21:35 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 16 Mar 2006 09:21:35 -0800
Subject: [ python-Bugs-1451466 ] reading very large files
Message-ID: <E1FJwAJ-0004Y6-8J@sc8-sf-web2.sourceforge.net>

Bugs item #1451466, was opened at 2006-03-16 18: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=1451466&group_id=5470

Please note that this message 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: christen (richardchristen)
Assigned to: Nobody/Anonymous (nobody)
Summary: reading very large files

Initial Comment:
I work on the human genome
I extracted words from chromosomes using a suffix tree
(C compiled for 64 done on a SUN with 300 Go RAM, since
my suffix tree requires 150 Go RAM for chromosome 1,
the largest one)

this gave some >5 Go files, for example with 163763326
lines for chr 4, the one presently analyzed.

Using python 2.4.2 on a windows 32-computer (1.5 Go
RAM), reading this file line by line either

for li in file:
    do something

or

while li!='':
    li=file.readline()

I got problems seemingly around the 4 Go boundary
(after reading the problematic first line), for some
lines (not all), the li returned the correct content
but with the first word of the next line also within li
(see below)

As a result a simple
file1=open('1')
file2=open('2','w')
li=file1.readline()
while li!='':
    file2.write(li) 
    li=file1.readline()

produced a second file of only
163754385 lines
problem lines were "seemingly random", i.e. not in a
row, with the last line being OK.


The same code on the same file but on my OSX
64-dualcore machine went fine, despite the use of
default Python 2.2.3 and "file Python" showing it is a
Mach-0 executable ppc, i.e. a 32 bit app.

Everything was run from the command line.


the first file looks like that
...
TCAGCCACAGCAGAAAGTGA:\t33240 551212 751185
TCAGCCACAGCAGAAAGTGC:\t131324047
TCAGCCACAGCACTGTGTTA:\t61641912
....

the second file contains lines like these :
TCAGCCACAGCAGAAAGTGC:\t131324047TCAGCCACAGCAGAAGAAGA:  

which is 'first line'+'1rst word of next line'

PS1 : no problem to read the big file with UEdit on the
windows machine. Therefore the OS itself is not the
problem (also I transfered the bigfile from the Windows
to the Mac, if the file had had problems, it would have
been corrupted on the Mac)
PS2 : I tried python 2.3.5 on windows with the same
problem.
PS3: If needed, I can run the same test on a similar
file but for chromosome 8 which is slightly below the 4
Go limit (3.99).
PS4: I think I remember having done a similar parsing
on a Linux Athlon 64 monoCPU a month ago, with no trouble.

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

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

From noreply at sourceforge.net  Thu Mar 16 19:08:28 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 16 Mar 2006 10:08:28 -0800
Subject: [ python-Bugs-1451503 ] os.startfile() still doesn't work with
	Unicode filenames
Message-ID: <E1FJwtg-0008L2-2V@sc8-sf-web3.sourceforge.net>

Bugs item #1451503, was opened at 2006-03-16 18: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=1451503&group_id=5470

Please note that this 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: roee88 (roee88)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.startfile() still doesn't work with Unicode filenames

Initial Comment:
>From 2.4.2 changelog:
>>>Bug #1007046: os.startfile() did not accept 
unicode strings encoded in the file system encoding. 

If the filename is unicode type and the encoding 
isn't the default system encoding, all "unknown" (to 
system encoding) characters are replaced by "?".
This is causing the os.startfile() to fail with 
WindowsError: [Errno2] 
Because the filename doesn't really have the "?".

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

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

From noreply at sourceforge.net  Thu Mar 16 20:26:31 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 16 Mar 2006 11:26:31 -0800
Subject: [ python-Feature Requests-1451588 ] bisect should support a custom
	comparison function
Message-ID: <E1FJy7D-0004uQ-Tf@sc8-sf-web3.sourceforge.net>

Feature Requests item #1451588, was opened at 2006-03-16 14:26
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=1451588&group_id=5470

Please note that this message 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: Jonathan S. Joseph (jsjoseph)
Assigned to: Nobody/Anonymous (nobody)
Summary: bisect should support a custom comparison function

Initial Comment:
The 'bisect' module provides functions for finding the
proper insertion point of an item in a sorted list. 

The sort() function for lists supports passing in a
custom comparison function, however none of the
functions in bisect() support this. The method used by
bisect to find the proper insertion point is not
documented, but I guess the module relies on a natural
ordering for the items, or on the items of the list
implementing __cmp__. 

I suggest adding a 5th argument, with keyword 'cmp', to
the functions in the 'bisect' module that would allow
supplying a custom comparison function, as for 'sort'.

bisect_left(  	list, item[, lo[, hi]][,cmp])
bisect_right( 	list, item[, lo[, hi]][,cmp])
bisect(...)
insort_left( 	list, item[, lo[, hi]][,cmp])
insort_right( 	list, item[, lo[, hi]][,cmp])
insort(...)

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

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

From noreply at sourceforge.net  Thu Mar 16 21:43:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 16 Mar 2006 12:43:42 -0800
Subject: [ python-Bugs-1451641 ] segfault in optimize_code()
Message-ID: <E1FJzJu-00067K-3P@sc8-sf-web5.sourceforge.net>

Bugs item #1451641, was opened at 2006-03-16 20:43
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=1451641&group_id=5470

Please note that this 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: Kristj?n Valur (krisvale)
Assigned to: Nobody/Anonymous (nobody)
Summary: segfault in optimize_code()

Initial Comment:
The function optimize_code() is called, for example 
when unpickling code objects.  However, with corrupt 
data it can cause segfaults.

This is because of code such as:
tgt = GETJUMPTGT(codestr, (i+1))
if (codestr[tgt])
    continue;

tgt can in this case easily be some nonsense and 
cause access violation when used as an index into 
codestr.  This behaviour has been observed.

My particular patch is this:
#define CHECK_I(i) do {if ((i)<0 || (i)>=codelen) 
goto exitError;}while(0)
#define CHECKARG(i) do {CHECK_I(i+1); CHECK_I(i+2);}
while(0)
#define CHECKJUMPTGT(i) do{CHECKARG(i); CHECK_I(i);}
while(0)

then, adding tests such as
CHECKJUMPTGT(j);
  before code that looks like
tgt = GETJUMPTGT(j);
  and
CHECK_I(tgt);
  before
codestr[tgt] = foo;

Also, this function needs to be able to raise an 
exception.  jcompile() must be able to deal with this 
case.

Finally, this is also an issue in 2.3 (actually, I 
discovered it there, but a quick look seems to 
indicate it being a problem in 2.4 too.



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

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

From noreply at sourceforge.net  Thu Mar 16 23:22:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 16 Mar 2006 14:22:42 -0800
Subject: [ python-Bugs-1451717 ] OS/X on i386 framework build
Message-ID: <E1FK0ri-0004SF-4i@sc8-sf-web4-b.sourceforge.net>

Bugs item #1451717, was opened at 2006-03-17 09: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=1451717&group_id=5470

Please note that this 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: Ian Holsman (webperf)
Assigned to: Nobody/Anonymous (nobody)
Summary: OS/X on i386 framework build

Initial Comment:
in Makefile.pre (374) it hard codes the architecture to
'ppc' which isn't correct for the new x86 boxes.

this needs to be i386 for the framework install to
actually build on the new macs.

regards
Ian

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

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

From noreply at sourceforge.net  Thu Mar 16 23:34:06 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 16 Mar 2006 14:34:06 -0800
Subject: [ python-Bugs-1451717 ] OS/X on i386 framework build
Message-ID: <E1FK12k-00057l-Ad@sc8-sf-web1.sourceforge.net>

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

Please note that this 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: Ian Holsman (webperf)
Assigned to: Nobody/Anonymous (nobody)
Summary: OS/X on i386 framework build

Initial Comment:
in Makefile.pre (374) it hard codes the architecture to
'ppc' which isn't correct for the new x86 boxes.

this needs to be i386 for the framework install to
actually build on the new macs.

regards
Ian

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

>Comment By: Ian Holsman (webperf)
Date: 2006-03-17 09:34

Message:
Logged In: YES 
user_id=5209

also..
in plat-mac/applesingle.py the fields
AS_HEADER_FORMAT
and 
AS_ENTRY_FORMAT
need a '>' infront of the definitions
AS_HEADER_FORMAT=">LL16sh"
AS_ENTRY_FORMAT=">lll"
(this is what the system-packaged python has.

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

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

From noreply at sourceforge.net  Fri Mar 17 00:14:39 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 16 Mar 2006 15:14:39 -0800
Subject: [ python-Bugs-1451641 ] segfault in optimize_code()
Message-ID: <E1FK1fz-0007HB-CM@sc8-sf-web5.sourceforge.net>

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

Please note that this 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: Kristj?n Valur (krisvale)
Assigned to: Nobody/Anonymous (nobody)
Summary: segfault in optimize_code()

Initial Comment:
The function optimize_code() is called, for example 
when unpickling code objects.  However, with corrupt 
data it can cause segfaults.

This is because of code such as:
tgt = GETJUMPTGT(codestr, (i+1))
if (codestr[tgt])
    continue;

tgt can in this case easily be some nonsense and 
cause access violation when used as an index into 
codestr.  This behaviour has been observed.

My particular patch is this:
#define CHECK_I(i) do {if ((i)<0 || (i)>=codelen) 
goto exitError;}while(0)
#define CHECKARG(i) do {CHECK_I(i+1); CHECK_I(i+2);}
while(0)
#define CHECKJUMPTGT(i) do{CHECKARG(i); CHECK_I(i);}
while(0)

then, adding tests such as
CHECKJUMPTGT(j);
  before code that looks like
tgt = GETJUMPTGT(j);
  and
CHECK_I(tgt);
  before
codestr[tgt] = foo;

Also, this function needs to be able to raise an 
exception.  jcompile() must be able to deal with this 
case.

Finally, this is also an issue in 2.3 (actually, I 
discovered it there, but a quick look seems to 
indicate it being a problem in 2.4 too.



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

>Comment By: Michael Hudson (mwh)
Date: 2006-03-16 23:14

Message:
Logged In: YES 
user_id=6656

I don't *think* optimize_code is called for unmarshalled code objects any more 
(i.e. in 2.4 and 2.5/SVN HEAD).  But I could be wrong.

If not, and so optimize_code is only called with code freshly generated from the 
compiler, this isn't really an issue, is it?

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

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

From noreply at sourceforge.net  Fri Mar 17 00:27:44 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 16 Mar 2006 15:27:44 -0800
Subject: [ python-Bugs-1451641 ] segfault in optimize_code()
Message-ID: <E1FK1se-0002ZP-Ti@sc8-sf-web2.sourceforge.net>

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

Please note that this 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: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Kristj?n Valur (krisvale)
Assigned to: Nobody/Anonymous (nobody)
Summary: segfault in optimize_code()

Initial Comment:
The function optimize_code() is called, for example 
when unpickling code objects.  However, with corrupt 
data it can cause segfaults.

This is because of code such as:
tgt = GETJUMPTGT(codestr, (i+1))
if (codestr[tgt])
    continue;

tgt can in this case easily be some nonsense and 
cause access violation when used as an index into 
codestr.  This behaviour has been observed.

My particular patch is this:
#define CHECK_I(i) do {if ((i)<0 || (i)>=codelen) 
goto exitError;}while(0)
#define CHECKARG(i) do {CHECK_I(i+1); CHECK_I(i+2);}
while(0)
#define CHECKJUMPTGT(i) do{CHECKARG(i); CHECK_I(i);}
while(0)

then, adding tests such as
CHECKJUMPTGT(j);
  before code that looks like
tgt = GETJUMPTGT(j);
  and
CHECK_I(tgt);
  before
codestr[tgt] = foo;

Also, this function needs to be able to raise an 
exception.  jcompile() must be able to deal with this 
case.

Finally, this is also an issue in 2.3 (actually, I 
discovered it there, but a quick look seems to 
indicate it being a problem in 2.4 too.



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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2006-03-16 18:27

Message:
Logged In: YES 
user_id=80475

For 2.4, Michael is correct and the optimizer only applied 
to internally generated code.

Also, FWIW, in Py2.5, I'm planning to move the optimizer 
to appear before the assembler instead of after -- this 
will both speed it up and simplify it.

Also, discussions on python-dev have noted that there are 
a number of ways to make bad things happen if you execute 
corrupt byte-code.  IIRC, there is a proposal for a Java 
style byte-code verifier to be put in place someday.

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

Comment By: Michael Hudson (mwh)
Date: 2006-03-16 18:14

Message:
Logged In: YES 
user_id=6656

I don't *think* optimize_code is called for unmarshalled code objects any more 
(i.e. in 2.4 and 2.5/SVN HEAD).  But I could be wrong.

If not, and so optimize_code is only called with code freshly generated from the 
compiler, this isn't really an issue, is it?

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

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

From noreply at sourceforge.net  Fri Mar 17 07:37:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 16 Mar 2006 22:37:24 -0800
Subject: [ python-Bugs-1447607 ] make frameworkinstall fails on Intel Macs
Message-ID: <E1FK8aS-00046K-Pj@sc8-sf-web2.sourceforge.net>

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

Please note that this 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: Duplicate
Priority: 5
Submitted By: Michael Mondragon (mammon_)
Assigned to: Nobody/Anonymous (nobody)
Summary: make frameworkinstall fails on Intel Macs

Initial Comment:
make frameworkinstall fails on Intel Macs 
due to an endian error.

Hardware: Intel Duo iMac 20"
OS Version: OS X 10.4.6

Error:
------

  File
"/Users/Shared/Downloads/Python-2.4.2/Lib/plat-mac/applesingle.py",
line 58, in __init__
    raise Error, "Unknown AppleSingle magic number
0x%8.8x" % (magic,)
applesingle.Error: Unknown AppleSingle magic number
0x00160500
make[1]: *** [installmacsubtree] Error 1
make: *** [frameworkinstallmaclib] Error 2

Looking in the file at line 31:

AS_MAGIC=0x00051600

...it seems fairly obvious that byte order is
reverse. Looks like the file is in big-endian
format, not ntaive format.


Fix:
----

vi Lib/plat-mac/applesingle.py

Line 28: Replace 
   AS_HEADER_FORMAT="LL16sh"
with
   AS_HEADER_FORMAT=">LL16sh"

Line 35: Replace
  AS_ENTRY_FORMAT="lll"
with
  AS_ENTRY_FORMAT=">lll"

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

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-17 06:37

Message:
Logged In: YES 
user_id=849994

Duplicate of #1451717.

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

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

From noreply at sourceforge.net  Fri Mar 17 11:37:56 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 17 Mar 2006 02:37:56 -0800
Subject: [ python-Bugs-1452174 ] xmlrpclib.py problem solved
Message-ID: <E1FKCLE-0008Gd-Gl@sc8-sf-web4-b.sourceforge.net>

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

Please note that this 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: varun bhansaly (varun_bhansaly)
Assigned to: Nobody/Anonymous (nobody)
Summary: xmlrpclib.py problem solved

Initial Comment:
hi,
I have found a solution, to my problem of xmlrpclib.py.
regards,

-VB
  

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

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

From noreply at sourceforge.net  Fri Mar 17 11:58:41 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 17 Mar 2006 02:58:41 -0800
Subject: [ python-Bugs-1452174 ] xmlrpclib.py problem solved
Message-ID: <E1FKCfJ-0001AZ-CJ@sc8-sf-web4-b.sourceforge.net>

Bugs item #1452174, was opened at 2006-03-17 10:37
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1452174&group_id=5470

Please note that this 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: Deleted
>Resolution: Invalid
Priority: 5
Submitted By: varun bhansaly (varun_bhansaly)
Assigned to: Nobody/Anonymous (nobody)
Summary: xmlrpclib.py problem solved

Initial Comment:
hi,
I have found a solution, to my problem of xmlrpclib.py.
regards,

-VB
  

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

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

From noreply at sourceforge.net  Fri Mar 17 11:59:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 17 Mar 2006 02:59:46 -0800
Subject: [ python-Bugs-1446690 ] bug with xmlrpclib
Message-ID: <E1FKCgM-0001EP-V7@sc8-sf-web4-b.sourceforge.net>

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

Please note that this 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.3
>Status: Closed
>Resolution: Works For Me
Priority: 9
Submitted By: varun bhansaly (varun_bhansaly)
Assigned to: Nobody/Anonymous (nobody)
Summary: bug with xmlrpclib

Initial Comment:
I am currently working on a project in which I am
required to send some data from OpenOffice.org v2.0.(OOo)
I have placed buttons on the spreadsheet, and a python
script is to be invoked when the button is clicked.
I am required to send the data in the spreadsheet to an
app server, hence I am using XML-RPC to get this job done.
The version of XML-RPC(xmlrpclib.py) I'm using is
v1.36.2.1,
The app server requires the connection to be
authenticated, whereas the current xmlrpclib.py doesnot
come with support for sending requests with basic
authentication.
In order to extend the capabilities of the xmlrpclib.py
with http authentication, I have written code that
provides necessary basic authentication.(class
BasicAuthTransport in the attached file
Project_saveFromOOoCalcAction.py) The actual connection
and authentication details have been replaced for
security reasons.
When the button on the OOo spreadsheet is clicked, the
script throws the following error.

com.sun.star.uno.RuntimeExceptionexceptions.TypeError:
request() got an unexpected keyword argument 'verbose',
traceback follows 

File "usr/lib/python2.4/xmlrpclib.py", in line 1096, in
__call__
return self.__send(self.__name,args)

File "usr/lib/python2.4/xmlrpclib.py", in line 1383, in
__request
verbose=self.__verbose

When I comment out the line 1383 of the above file,
everything runs smoothly, this is a very trivial
solution though,as this would require me to comment out
the line 1383 of the above file n all the client
machines in which the script has to executed.

Hence I'm looking for a more viable solution. The files
are attached along.

Any help or advice in this regard shall be welcome.

regards,

-VB

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

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-17 10:59

Message:
Logged In: YES 
user_id=849994

OP indicated that the problem is solved.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1446690&group_id=5470

From noreply at sourceforge.net  Fri Mar 17 12:37:39 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 17 Mar 2006 03:37:39 -0800
Subject: [ python-Bugs-1448639 ] asyncore dispatcher.__getattr__() masks
	self._map
Message-ID: <E1FKDH1-000740-BQ@sc8-sf-web3.sourceforge.net>

Bugs item #1448639, was opened at 2006-03-13 05:52
Message generated for change (Comment added) made by zseil
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448639&group_id=5470

Please note that this message 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: Doug White (dwhite)
Assigned to: Nobody/Anonymous (nobody)
Summary: asyncore dispatcher.__getattr__() masks self._map

Initial Comment:
The abstraction of socket_map in the asyncore module 
in Python 2.4 forgets to allow accesses to the 
internal attribute self._map in __getattr__(). This 
causes any asyncore application to fail in 
create_socket(), which pretty much renders asyncore 
inoperative in Python 2.4.  
 
This problem was introduced in rev 34469 as a commit 
of Bug #758241. 
 
Example backtrace, generated from an application that 
uses Medusa servers that don't use the private map 
function: 
 
Traceback (most recent call last): 
  File "/usr/local/qos/qosserver/qos_server.py", line 
1576, in ? 
    m = monitor.monitor_server ('127.0.0.1', 
BasePort) 
  File "/usr/local/qos/qosserver/monitor.py", line 
161, in __init__ 
    self.create_socket (socket.AF_INET, 
socket.SOCK_STREAM) 
  File "/usr/local/lib/python2.4/asyncore.py", line 
261, in create_socket 
    self.add_channel() 
  File "/usr/local/lib/python2.4/asyncore.py", line 
244, in add_channel 
    map = self._map 
  File "/usr/local/lib/python2.4/asyncore.py", line 
366, in __getattr__ 
    return getattr(self.socket, attr) 
AttributeError: '_socketobject' object has no 
attribute '_map' 
 
__getattr__() should test if the attribute exists in 
its own object before passing it on to the underlying 
socket object. 

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-03-17 12:37

Message:
Logged In: YES 
user_id=1326842

This is a bug in your code, since you don't call the
base class's __init__() method, and as a consequence
the '_map' attribute really doesn't exist.

__getattr__() doesn't have to check for existance of
an attribute since it is called only when the normal
lookup mechanism fails. See the docs:
http://docs.python.org/ref/attribute-access.html



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448639&group_id=5470

From noreply at sourceforge.net  Fri Mar 17 12:51:28 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 17 Mar 2006 03:51:28 -0800
Subject: [ python-Bugs-1448639 ] asyncore dispatcher.__getattr__() masks
	self._map
Message-ID: <E1FKDUO-0004UI-8t@sc8-sf-web1.sourceforge.net>

Bugs item #1448639, was opened at 2006-03-13 04:52
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448639&group_id=5470

Please note that this message 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: Doug White (dwhite)
Assigned to: Nobody/Anonymous (nobody)
Summary: asyncore dispatcher.__getattr__() masks self._map

Initial Comment:
The abstraction of socket_map in the asyncore module 
in Python 2.4 forgets to allow accesses to the 
internal attribute self._map in __getattr__(). This 
causes any asyncore application to fail in 
create_socket(), which pretty much renders asyncore 
inoperative in Python 2.4.  
 
This problem was introduced in rev 34469 as a commit 
of Bug #758241. 
 
Example backtrace, generated from an application that 
uses Medusa servers that don't use the private map 
function: 
 
Traceback (most recent call last): 
  File "/usr/local/qos/qosserver/qos_server.py", line 
1576, in ? 
    m = monitor.monitor_server ('127.0.0.1', 
BasePort) 
  File "/usr/local/qos/qosserver/monitor.py", line 
161, in __init__ 
    self.create_socket (socket.AF_INET, 
socket.SOCK_STREAM) 
  File "/usr/local/lib/python2.4/asyncore.py", line 
261, in create_socket 
    self.add_channel() 
  File "/usr/local/lib/python2.4/asyncore.py", line 
244, in add_channel 
    map = self._map 
  File "/usr/local/lib/python2.4/asyncore.py", line 
366, in __getattr__ 
    return getattr(self.socket, attr) 
AttributeError: '_socketobject' object has no 
attribute '_map' 
 
__getattr__() should test if the attribute exists in 
its own object before passing it on to the underlying 
socket object. 

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-17 11:51

Message:
Logged In: YES 
user_id=849994

It seems that zseil is right. Closing as Invalid.

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-03-17 11:37

Message:
Logged In: YES 
user_id=1326842

This is a bug in your code, since you don't call the
base class's __init__() method, and as a consequence
the '_map' attribute really doesn't exist.

__getattr__() doesn't have to check for existance of
an attribute since it is called only when the normal
lookup mechanism fails. See the docs:
http://docs.python.org/ref/attribute-access.html



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448639&group_id=5470

From noreply at sourceforge.net  Fri Mar 17 12:57:36 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 17 Mar 2006 03:57:36 -0800
Subject: [ python-Bugs-1452246 ] htmllib doesn't properly substitute entities
Message-ID: <E1FKDaK-0007JB-U8@sc8-sf-web2.sourceforge.net>

Bugs item #1452246, was opened at 2006-03-17 11: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=1452246&group_id=5470

Please note that this message 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: Helmut Grohne (gnarfk)
Assigned to: Nobody/Anonymous (nobody)
Summary: htmllib doesn't properly substitute entities

Initial Comment:
I'd like to illustrate and suggest a fix by showing a
simple python file (which was named htmllib2.py so you
can uncomment the line in the doctest case to see that
my fix works). It's more like a hack than the fix though:
#!/usr/bin/env python2.4

"""
Use this instead of htmllib for having entitydefs
substituted in attributes,too.

Example:
>>> import htmllib
# >>> import htmllib2 as htmllib
>>> import formatter
>>> import StringIO
>>> s = StringIO.StringIO()
>>> p =
htmllib.HTMLParser(formatter.AbstractFormatter(formatter.DumbWriter(s)))
>>> p.feed('<img alt="&lt;&gt;&amp;">')
>>> s.getvalue()
'<>&'
"""

__all__ = ("HTMLParser",)

import htmllib
from htmlentitydefs import name2codepoint as entitytable

entitytable = dict([(k, chr(v)) for k, v in
entitytable.items() if v < 256])

def entitysub(s):
    ret = ""
    state = ""
    for c in s:
        if state.startswith('&'):
            if c == ';':
                ret += entitytable.get(state[1:], '%s;'
% state)
                state = ""
            else:
                state += c
        elif c == '&':
            state = c
        else:
            ret += c
    return ret

class HTMLParser(htmllib.HTMLParser):
    def handle_starttag(self, tag, method, attrs):
        """Repair attribute values."""
        attrs = [(k, entitysub(v)) for (k, v) in attrs]
        method(attrs)

if __name__ == '__main__':
    import doctest
    doctest.testmod()


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1452246&group_id=5470

From noreply at sourceforge.net  Fri Mar 17 14:45:51 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 17 Mar 2006 05:45:51 -0800
Subject: [ python-Bugs-1441408 ] svn head compiler fails to spot extended
	slicing
Message-ID: <E1FKFH5-0006mE-Nb@sc8-sf-web3.sourceforge.net>

Bugs item #1441408, was opened at 2006-03-02 11:20
Message generated for change (Comment added) made by ncoghlan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1441408&group_id=5470

Please note that this 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: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Nobody/Anonymous (nobody)
Summary: svn head compiler fails to spot extended slicing

Initial Comment:
This is Python SVN HEAD:

>>> dis.dis(compile("x[::]", '', 'single'))
  1           0 LOAD_NAME                0 (x)
              3 SLICE+0             
              4 PRINT_EXPR          
              5 LOAD_CONST               0 (None)
              8 RETURN_VALUE        

This is Python 2.4:

>>> dis.dis(compile("x[::]", '', 'single'))
  1           0 LOAD_NAME                0 (x)
              3 LOAD_CONST               0 (None)
              6 LOAD_CONST               0 (None)
              9 LOAD_CONST               0 (None)
             12 BUILD_SLICE              3
             15 BINARY_SUBSCR       
             16 PRINT_EXPR          
             17 LOAD_CONST               0 (None)
             20 RETURN_VALUE        


----------------------------------------------------------------------

>Comment By: Nick Coghlan (ncoghlan)
Date: 2006-03-17 23:45

Message:
Logged In: YES 
user_id=1038590

Alternate patch that doesn't modify the AST posted as 1452332

----------------------------------------------------------------------

Comment By: Grant Olson (logistix)
Date: 2006-03-10 10:22

Message:
Logged In: YES 
user_id=699438

Patch 1446847 Posted.

----------------------------------------------------------------------

Comment By: Grant Olson (logistix)
Date: 2006-03-06 09:33

Message:
Logged In: YES 
user_id=699438

This only happens when you have implicit slice values. 
x[1:2:3] works fine.  I'm finishing up a patch and will post
to sf shortly.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1441408&group_id=5470

From noreply at sourceforge.net  Fri Mar 17 14:51:26 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 17 Mar 2006 05:51:26 -0800
Subject: [ python-Bugs-1184112 ] Missing trailing newline with comment raises
	SyntaxError
Message-ID: <E1FKFMU-0004ct-PR@sc8-sf-web6.sourceforge.net>

Bugs item #1184112, was opened at 2005-04-16 11:55
Message generated for change (Comment added) made by ncoghlan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1184112&group_id=5470

Please note that this 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: Open
Resolution: None
Priority: 5
Submitted By: Eric Huss (ehuss)
Assigned to: Nobody/Anonymous (nobody)
Summary: Missing trailing newline with comment raises SyntaxError

Initial Comment:
The following illustrates a problem with the parser 
handling the lack of trailing newlines:

>>> parser.suite('def foo():\n\tpass\n\n# comment')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<string>", line 4
    # comment
           ^
SyntaxError: invalid syntax
>>> parser.suite('def foo():\n\tpass\n\n# comment\n')
<parser.st object at 0x847f0a0>

This is similar to bug 501622, however, this only seems 
to happen when you have an indented block, followed by 
a comment line that has no trailing newline.

I traced through tokenizer.c and whittled down the issue 
into tok_get().  In the statement where it is processing 
the comment character and looking at the tabforms, in 
the first case this will end up with 'c' equal to EOF 
whereas in the second case "c" will eqaul '\n'.  When it 
equals EOF, it is unable to do the cleanup necessary to 
emit the DEDENT token (it immediately bails out with 
ENDMARKER which causes parsetok() to barf because 
the indentation level is still 1 inside tok_state).

Attached is a patch of a little hack I made that seems 
to fix the problem.  Although it seems to be a safe thing 
to do, it is definitely a hack.


----------------------------------------------------------------------

>Comment By: Nick Coghlan (ncoghlan)
Date: 2006-03-17 23:51

Message:
Logged In: YES 
user_id=1038590

Confirmed on SVN HEAD using:

exec """
def foo():
    pass

#comment"""

(Blows up with a syntax error)

----------------------------------------------------------------------

Comment By: Eric Huss (ehuss)
Date: 2005-04-16 11:57

Message:
Logged In: YES 
user_id=393416

Well, wonderful sourceforge is barfing with the 
error "ArtifactFile: Could not open file for writing" when trying 
to upload my patch, so I'll just post it in the comment here.  
Very sorry. :(

--- tokenizer.c	3 Feb 2004 22:53:59 -0000	1.2
+++ tokenizer.c	16 Apr 2005 01:45:05 -0000
@@ -1139,6 +1139,9 @@
 		}
 		while (c != EOF && c != '\n')
 			c = tok_nextc(tok);
+		if (c == EOF) {
+			c = '\n';
+		}
 	}
 	
 	/* Check for EOF and errors now */


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1184112&group_id=5470

From noreply at sourceforge.net  Fri Mar 17 17:48:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 17 Mar 2006 08:48:25 -0800
Subject: [ python-Bugs-1184112 ] Missing trailing newline with comment raises
	SyntaxError
Message-ID: <E1FKI7l-0006XP-Cr@sc8-sf-web1.sourceforge.net>

Bugs item #1184112, was opened at 2005-04-15 21:55
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1184112&group_id=5470

Please note that this 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: Open
Resolution: None
Priority: 5
Submitted By: Eric Huss (ehuss)
Assigned to: Nobody/Anonymous (nobody)
Summary: Missing trailing newline with comment raises SyntaxError

Initial Comment:
The following illustrates a problem with the parser 
handling the lack of trailing newlines:

>>> parser.suite('def foo():\n\tpass\n\n# comment')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<string>", line 4
    # comment
           ^
SyntaxError: invalid syntax
>>> parser.suite('def foo():\n\tpass\n\n# comment\n')
<parser.st object at 0x847f0a0>

This is similar to bug 501622, however, this only seems 
to happen when you have an indented block, followed by 
a comment line that has no trailing newline.

I traced through tokenizer.c and whittled down the issue 
into tok_get().  In the statement where it is processing 
the comment character and looking at the tabforms, in 
the first case this will end up with 'c' equal to EOF 
whereas in the second case "c" will eqaul '\n'.  When it 
equals EOF, it is unable to do the cleanup necessary to 
emit the DEDENT token (it immediately bails out with 
ENDMARKER which causes parsetok() to barf because 
the indentation level is still 1 inside tok_state).

Attached is a patch of a little hack I made that seems 
to fix the problem.  Although it seems to be a safe thing 
to do, it is definitely a hack.


----------------------------------------------------------------------

>Comment By: Terry J. Reedy (tjreedy)
Date: 2006-03-17 11:48

Message:
Logged In: YES 
user_id=593130

As noted by F.Lundh on pydev list,
http://docs.python.org/lib/built-in-funcs.html
says "When compiling multi-line statements, two caveats 
apply: [...] and the input must be terminated by at least 
one newline character" so it appears that doc == behavior.
Should this be closed? or both changed?

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2006-03-17 08:51

Message:
Logged In: YES 
user_id=1038590

Confirmed on SVN HEAD using:

exec """
def foo():
    pass

#comment"""

(Blows up with a syntax error)

----------------------------------------------------------------------

Comment By: Eric Huss (ehuss)
Date: 2005-04-15 21:57

Message:
Logged In: YES 
user_id=393416

Well, wonderful sourceforge is barfing with the 
error "ArtifactFile: Could not open file for writing" when trying 
to upload my patch, so I'll just post it in the comment here.  
Very sorry. :(

--- tokenizer.c	3 Feb 2004 22:53:59 -0000	1.2
+++ tokenizer.c	16 Apr 2005 01:45:05 -0000
@@ -1139,6 +1139,9 @@
 		}
 		while (c != EOF && c != '\n')
 			c = tok_nextc(tok);
+		if (c == EOF) {
+			c = '\n';
+		}
 	}
 	
 	/* Check for EOF and errors now */


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1184112&group_id=5470

From noreply at sourceforge.net  Fri Mar 17 19:04:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 17 Mar 2006 10:04:23 -0800
Subject: [ python-Bugs-1441408 ] svn head compiler fails to spot extended
	slicing
Message-ID: <E1FKJJH-00031P-TD@sc8-sf-web1.sourceforge.net>

Bugs item #1441408, was opened at 2006-03-02 11:20
Message generated for change (Comment added) made by ncoghlan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1441408&group_id=5470

Please note that this 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: svn head compiler fails to spot extended slicing

Initial Comment:
This is Python SVN HEAD:

>>> dis.dis(compile("x[::]", '', 'single'))
  1           0 LOAD_NAME                0 (x)
              3 SLICE+0             
              4 PRINT_EXPR          
              5 LOAD_CONST               0 (None)
              8 RETURN_VALUE        

This is Python 2.4:

>>> dis.dis(compile("x[::]", '', 'single'))
  1           0 LOAD_NAME                0 (x)
              3 LOAD_CONST               0 (None)
              6 LOAD_CONST               0 (None)
              9 LOAD_CONST               0 (None)
             12 BUILD_SLICE              3
             15 BINARY_SUBSCR       
             16 PRINT_EXPR          
             17 LOAD_CONST               0 (None)
             20 RETURN_VALUE        


----------------------------------------------------------------------

>Comment By: Nick Coghlan (ncoghlan)
Date: 2006-03-18 04:04

Message:
Logged In: YES 
user_id=1038590

Applied 1452332 to SVN (generates an explicit None reference
for the step when the second colon is present but no
expressions is supplied for the step)

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2006-03-17 23:45

Message:
Logged In: YES 
user_id=1038590

Alternate patch that doesn't modify the AST posted as 1452332

----------------------------------------------------------------------

Comment By: Grant Olson (logistix)
Date: 2006-03-10 10:22

Message:
Logged In: YES 
user_id=699438

Patch 1446847 Posted.

----------------------------------------------------------------------

Comment By: Grant Olson (logistix)
Date: 2006-03-06 09:33

Message:
Logged In: YES 
user_id=699438

This only happens when you have implicit slice values. 
x[1:2:3] works fine.  I'm finishing up a patch and will post
to sf shortly.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1441408&group_id=5470

From noreply at sourceforge.net  Fri Mar 17 19:20:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 17 Mar 2006 10:20:05 -0800
Subject: [ python-Bugs-1448639 ] asyncore dispatcher.__getattr__() masks
	self._map
Message-ID: <E1FKJYT-00040m-Oc@sc8-sf-web1.sourceforge.net>

Bugs item #1448639, was opened at 2006-03-12 20:52
Message generated for change (Comment added) made by dwhite
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448639&group_id=5470

Please note that this message 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: Doug White (dwhite)
Assigned to: Nobody/Anonymous (nobody)
Summary: asyncore dispatcher.__getattr__() masks self._map

Initial Comment:
The abstraction of socket_map in the asyncore module 
in Python 2.4 forgets to allow accesses to the 
internal attribute self._map in __getattr__(). This 
causes any asyncore application to fail in 
create_socket(), which pretty much renders asyncore 
inoperative in Python 2.4.  
 
This problem was introduced in rev 34469 as a commit 
of Bug #758241. 
 
Example backtrace, generated from an application that 
uses Medusa servers that don't use the private map 
function: 
 
Traceback (most recent call last): 
  File "/usr/local/qos/qosserver/qos_server.py", line 
1576, in ? 
    m = monitor.monitor_server ('127.0.0.1', 
BasePort) 
  File "/usr/local/qos/qosserver/monitor.py", line 
161, in __init__ 
    self.create_socket (socket.AF_INET, 
socket.SOCK_STREAM) 
  File "/usr/local/lib/python2.4/asyncore.py", line 
261, in create_socket 
    self.add_channel() 
  File "/usr/local/lib/python2.4/asyncore.py", line 
244, in add_channel 
    map = self._map 
  File "/usr/local/lib/python2.4/asyncore.py", line 
366, in __getattr__ 
    return getattr(self.socket, attr) 
AttributeError: '_socketobject' object has no 
attribute '_map' 
 
__getattr__() should test if the attribute exists in 
its own object before passing it on to the underlying 
socket object. 

----------------------------------------------------------------------

>Comment By: Doug White (dwhite)
Date: 2006-03-17 10:20

Message:
Logged In: YES 
user_id=105929

Ugh... this was my fault. I had code checkouts out of sync. So sorry :(

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-03-17 03:51

Message:
Logged In: YES 
user_id=849994

It seems that zseil is right. Closing as Invalid.

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-03-17 03:37

Message:
Logged In: YES 
user_id=1326842

This is a bug in your code, since you don't call the
base class's __init__() method, and as a consequence
the '_map' attribute really doesn't exist.

__getattr__() doesn't have to check for existance of
an attribute since it is called only when the normal
lookup mechanism fails. See the docs:
http://docs.python.org/ref/attribute-access.html



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448639&group_id=5470

From noreply at sourceforge.net  Fri Mar 17 20:17:55 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 17 Mar 2006 11:17:55 -0800
Subject: [ python-Feature Requests-567972 ] Missing 4 socket object properties
Message-ID: <E1FKKSR-0007QV-Vm@sc8-sf-web5.sourceforge.net>

Feature Requests item #567972, was opened at 2002-06-12 11:56
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=567972&group_id=5470

Please note that this message 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: Accepted
Priority: 5
Submitted By: Graham Horler (grahamh)
>Assigned to: Georg Brandl (gbrandl)
Summary: Missing 4 socket object properties

Initial Comment:
The C socketmodule has a struct PySocketSockObject, 
with family, type and proto members.

These would be terribly helpful to have access to in 
Python, when implementing some generic socket helper 
functions.

The &quot;blocking&quot; flag could also be made available, but 
would require some extra coding.

(I'm using Python 2.1.3 under Linux 2.4.16, so I cannot 
extend the socket class itself ((as in py2.2)), and don't 
want to slow down sockets with a complete wrapper, as I 
use them heavily.)

Thanks, Graham.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-17 19:17

Message:
Logged In: YES 
user_id=849994

Committed as rev. 43126.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-08-24 20:05

Message:
Logged In: YES 
user_id=1188172

Attaching new patch. Following changes:

- getfamily(), gettype(), getproto() functions of
_socketobject which map to
- family, type, proto members of socket._sock
- timeout member of socket._sock
- documentation update
- test suite update

Please review.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-08-24 15:24

Message:
Logged In: YES 
user_id=21627

grahamh, I take it that your answer to the question "would
you like to implement a patch?", is "no".

I agree with parts of the review: these things should be
added to the _socketobject. Also, socket objects have one
more attribute, sock_timeout, which might be worth exposing.

I also wonder what style of API should be used. All other
state access goes through get-methods(), which all start
with get except for fileno(). Adding properties would
introduce another API style, so -1.

As for blocking: this sounds like a different feature
request, as this is not a member of struct
PySocketSockObject. So I would close this request as soon as
the three attributes are implemented; if you then still want
the getblocking() method, you should write another feature
request.

In addition, this patch lacks documentation and test suite
changes.

Unassigning myself, as I won't take any further action for
the moment.

----------------------------------------------------------------------

Comment By: Graham Horler (grahamh)
Date: 2005-07-20 14:47

Message:
Logged In: YES 
user_id=543663

The patch applies, compiles, runs OK for me (thanks).

However it does not add access to the blocking flag.
Under Linux I can go:
    fcntl.fcntl(fd, fcntl.F_GETFL) & os.O_NDELAY != 0
But this is not portable, and is probably repeating code.

Also the 3 added members are not available from an instance
of the _socketobject wrapper, you have to go
mysock._sock.family.
(The _socketobject wrapper in socket.py is a little bizarre
IMVHO.)
Perhaps they could be added using instances of property().


----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-17 13:49

Message:
Logged In: YES 
user_id=1188172

Attaching a patch which implements the three members of
_socket.socket.

Please review.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2002-06-15 13:21

Message:
Logged In: YES 
user_id=21627

Sounds good. Would you like to produce a patch implementing
this feature?

----------------------------------------------------------------------

Comment By: Graham Horler (grahamh)
Date: 2002-06-12 12:00

Message:
Logged In: YES 
user_id=543663

Oh yes, the repr of a socket object includes the missing info, 
so to get hold of the family, I go:
  int(repr(sock).split(' ')[3].split('=')[1][:-1])

Similar for type and protocol, not nice!


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=567972&group_id=5470

From noreply at sourceforge.net  Fri Mar 17 20:29:03 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 17 Mar 2006 11:29:03 -0800
Subject: [ python-Bugs-1151968 ] (XMLRPC) multitude of sockets ending up in
	TIME_WAIT
Message-ID: <E1FKKdD-00088v-5h@sc8-sf-web5.sourceforge.net>

Bugs item #1151968, was opened at 2005-02-25 18:00
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1151968&group_id=5470

Please note that this 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: Platform-specific
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Jonas Wid?n (jonsv322)
Assigned to: Nobody/Anonymous (nobody)
Summary: (XMLRPC) multitude of sockets ending up in TIME_WAIT

Initial Comment:
A problem with a multitude of sockets ending up in
TIME_WAIT when stressing a system with XML-RPC calls.
This can cause a Windows network to missbehave.

A solution on Windows platform is to set the sockopt
NOLINGER with parameters (1, 0) for the socket before
the socket is closed. This vill cause that Windows will
release the socket direct without going into TIME_WAIT.

The solution in code:
In httplib.py at somewhere:
NOLINGER = struct.pack('HH', 1, 0) # Release the
resource back to the system if socket closed

In httplib.py at 632:
self.sock.setsockopt(socket.SOL_SOCKET,
socket.SO_LINGER, NOLINGER)
self.sock.close()   # close it manually... there may be
other refs

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-17 19:29

Message:
Logged In: YES 
user_id=849994

Seems like Not a Bug.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-02-25 20:53

Message:
Logged In: YES 
user_id=21627

Why do you want to avoid the TIME_WAIT state, and why do you
think it is a Python bug that it doesn't? See

http://www.developerweb.net/sock-faq/detail.php?id=13

where Richard Stevens himself explains that SO_LINGER should
*not* be used.

It might be that SO_REUSEADDR is sufficient, see

http://www.developerweb.net/sock-faq/detail.php?id=44

If you want xmlrpclib to use different socket options, you
should subclass httplib.HTTP to redefine either connect() or
close(), and you should subclass xmlrpclib.Transport to use
your subclassed transport.

----------------------------------------------------------------------

Comment By: Jonas Wid?n (jonsv322)
Date: 2005-02-25 20:13

Message:
Logged In: YES 
user_id=352221

Read section, SO_LINGER at following address:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/wspsetsockopt_2.asp


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1151968&group_id=5470

From noreply at sourceforge.net  Fri Mar 17 20:33:28 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 17 Mar 2006 11:33:28 -0800
Subject: [ python-Feature Requests-739029 ] Constructor for counting things
Message-ID: <E1FKKhU-0008R8-9v@sc8-sf-web5.sourceforge.net>

Feature Requests item #739029, was opened at 2003-05-17 02:22
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=739029&group_id=5470

Please note that this 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: Rejected
Priority: 5
Submitted By: David Albert Torpey (dtorp)
Assigned to: Nobody/Anonymous (nobody)
Summary: Constructor for counting things

Initial Comment:
Counting things is very common.  May I suggest an 
alternate dictionary constructor that works like this:

class BetterDictionary(dict):
    def bag(classobject, sequence):
        &quot;Fast way to count things&quot;
        b = classobject()
        for k in sequence:
            b[k] = b.get(k,0) + 1
        return b
    bag = classmethod(bag)

print BetterDictionary.bag(&quot;jack and jill went up a 
hill ...&quot;)

A C implementation could do this very fast.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-17 19:33

Message:
Logged In: YES 
user_id=849994

I think this a reasonable use case for defaultdict:

d = defaultdict(int)
for k in seq:
    d[k] += 1

----------------------------------------------------------------------

Comment By: Michael Chermside (mcherm)
Date: 2005-12-28 17:19

Message:
Logged In: YES 
user_id=99874

I think I prefer birkenfeld's approach: create a well-tuned
implementation for the collections module rather than adding
yet one MORE use case to the already overburdened (yet very
powerful) dict.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-17 14:07

Message:
Logged In: YES 
user_id=1188172

Perhaps "bag" is a good addition to the "collections" module.

----------------------------------------------------------------------

Comment By: David Albert Torpey (dtorp)
Date: 2003-08-26 18:07

Message:
Logged In: YES 
user_id=681258

Smalltalk has a collection class called Bag that fills the same 
role.  It is a frequently used class.

The current way of doing things is too slow.  Disassembly 
shows that the whole process involves loading a constant for 
1, loading a constant for zero, loading the local variable 'b', 
performing an attribute lookup for 'get', loading the local 
variable 'k', calling 'get', running the summation, re-loading 
both 'b' and 'k' and doing a subscript store.  Along the way, 
there are two dictionary lookups for the same key.   All of 
that is just the inner loop and is wrapped in for-loop with all 
of its overhead.  Instead, the whole thing could be done in 
one step at C speed:  b.bag(itemlist).

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-08-12 06:12

Message:
Logged In: YES 
user_id=357491

I don't know if it is *that* common.  Besides, as your code shows, 
it isn't that complex.  It strikes me as a little too specific to be 
made a built-in dict constructor.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=739029&group_id=5470

From noreply at sourceforge.net  Fri Mar 17 20:49:06 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 17 Mar 2006 11:49:06 -0800
Subject: [ python-Bugs-872175 ] README build instructions for fpectl
Message-ID: <E1FKKwc-0004cQ-0l@sc8-sf-web3.sourceforge.net>

Bugs item #872175, was opened at 2004-01-07 06:15
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=872175&group_id=5470

Please note that this 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: Feature Request
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Steve Chaplin (stevech)
Assigned to: Nobody/Anonymous (nobody)
Summary: README build instructions for fpectl

Initial Comment:
configure.in supports the option '--with-fpectl'

However, the "Configuration options and variables"
section in the Python-2.3.3/README file mentions many
options, but does not mention --with-fpectl

I think the README should contain a few lines saying
what the default setting is and why you may want to
switch it on or off.


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-17 19:49

Message:
Logged In: YES 
user_id=849994

Added the question about fpectl to PEP 356, this will be
resolved before 2.5.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2006-02-20 12:59

Message:
Logged In: YES 
user_id=6656

Waaa, the correct thing to is to remove the --with-fpectl from configure!  I've 
been meaning to post to python-dev for a while now proposing the ripping out 
of this code.  It's just not useful any more.  At any rate, I am actively opposed to 
advertising its existence more widely.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-20 10:24

Message:
Logged In: YES 
user_id=1188172

Added a note in rev. 42512.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=872175&group_id=5470

From noreply at sourceforge.net  Fri Mar 17 20:51:22 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 17 Mar 2006 11:51:22 -0800
Subject: [ python-Bugs-1115379 ] Built-in compile function with PEP 0263
	encoding bug
Message-ID: <E1FKKyo-0004lz-Ep@sc8-sf-web3.sourceforge.net>

Bugs item #1115379, was opened at 2005-02-03 13:11
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115379&group_id=5470

Please note that this 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: 7
Submitted By: Christoph Zwerschke (cito)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: Built-in compile function with PEP 0263 encoding bug

Initial Comment:
a = 'print "Hello, World"'
u = '# -*- coding: utf-8 -*-\n' + a

print compile(a, '<string>', 'exec') # ok
print compile(u, '<string>', 'exec') # ok
print compile(unicode(a), '<string>', 'exec') # ok
print compile(unicode(u), '<string>', 'exec') # error

# The last line gives a SystemError.
# Think this is a bug.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 21:37

Message:
Logged In: YES 
user_id=849994

This even aborts the interpreter in 2.5 HEAD with a failing
assertion.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-09-28 05:48

Message:
Logged In: YES 
user_id=21627

If you load the files manually, why is it that you want to
decode them to Unicode before compile()ing them? Couldn't
you just pass the bytes you read from the file to compile()?

----------------------------------------------------------------------

Comment By: V?gv?lgyi Attila (wigy)
Date: 2005-09-28 04:29

Message:
Logged In: YES 
user_id=156682

If this special case is a feature, not a bug, than it breaks
some symmetry for sure.

If I run a script having utf-8 encoding from a file with

  python script.py

then it has to have an encoding declaration. Now if I would
like to load the same file manually, decode it to a unicode
object, I also have to remove the encoding declaration at
the beginning of the file before I can give it to the
compile() function.

What special advantage comes from the fact that the compiler
does not simply ignore encoding declaration nodes from
unicode objects? Does this error message catch some possible
errors or does it make the compiler code simpler?

----------------------------------------------------------------------

Comment By: V?gv?lgyi Attila (wigy)
Date: 2005-09-28 04:20

Message:
Logged In: YES 
user_id=156682

If this special case is a feature, not a bug, than it breaks
some symmetry for sure.

If I run a script having utf-8 encoding from a file with

  python script.py

then it has to have an encoding declaration. Now if I would
like to load the same file manually, decode it to a unicode
object, I also have to remove the encoding declaration at
the beginning of the file before I can give it to the
compile() function.

What special advantage comes from the fact that the compiler
does not simply ignore encoding declaration nodes from
unicode objects? Does this error message catch some possible
errors or does it make the compiler code simpler?

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-02-10 00:37

Message:
Logged In: YES 
user_id=21627

There is a bug somewhere, certainly. However, I believe it
is in PEP 263, which should point out that unicode strings
in compile are only legal if they do *not* contain an
encoding declaration, as such strings are implicitly encoded
as UTF-8.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115379&group_id=5470

From noreply at sourceforge.net  Fri Mar 17 21:07:12 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 17 Mar 2006 12:07:12 -0800
Subject: [ python-Bugs-1452697 ] broken string on mbcs
Message-ID: <E1FKLE8-0002Pj-7m@sc8-sf-web1.sourceforge.net>

Bugs item #1452697, was opened at 2006-03-18 05: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=1452697&group_id=5470

Please note that this 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: ocean-city (ocean-city)
Assigned to: M.-A. Lemburg (lemburg)
Summary: broken string on mbcs

Initial Comment:
Hello. I noticed unicode conversion from mbcs was
sometimes broken. This happened when I used
codecs.open("foo", "r", "mbcs") as iterator.

# It's OK if I use "shift_jis" or "cp932".

I'll attach the script and text file to reproduce the
problem. I'm using Win2000SP4(Japanese).

Thank you.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1452697&group_id=5470

From noreply at sourceforge.net  Fri Mar 17 21:27:07 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 17 Mar 2006 12:27:07 -0800
Subject: [ python-Bugs-1443504 ] locale.getpreferredencoding() dies when
	setlocale fails
Message-ID: <E1FKLXP-0005wj-4g@sc8-sf-web2.sourceforge.net>

Bugs item #1443504, was opened at 2006-03-05 14:50
Message generated for change (Comment added) made by jminka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1443504&group_id=5470

Please note that this message 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: 3
Submitted By: Catherine Devlin (catherinedevlin)
Assigned to: Nobody/Anonymous (nobody)
Summary: locale.getpreferredencoding() dies when setlocale fails

Initial Comment:
I'm on Ubuntu 5.10, with Python 2.4.2-0ubuntu2, and
when I open a terminal window and run python, I get

>>> import locale
>>> locale.getpreferredencoding()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.4/locale.py", line 417, in
getpreferredencoding
    setlocale(LC_CTYPE, "")
  File "/usr/lib/python2.4/locale.py", line 381, in
setlocale
    return _setlocale(category, locale)
locale.Error: unsupported locale setting

However, if I su - root - or even su right back to my
own account (catherine) ! - then everything works.

This is of concern (to me, anyway) because this error
crashes bzr. 

I chose "Esperanto" as my language when setting up
Ubuntu.  (No, I wasn't trying to be funny - I really do
speak Esperanto!)  That may be why I found the problem,
but I don't think this is simply a problem with flawed
Esperanto support in Ubuntu - because the routine works
after su is used, and because
locale.nl_langinfo(CODESET) works fine (please read on).

Anyway, within locale.getpreferredencoding(), line 417
- setlocale(LC_CTYPE, "") - seems to be the problem...

>>> locale.setlocale(locale.LC_CTYPE)
'C'
>>> locale.setlocale(locale.LC_CTYPE, "")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.4/locale.py", line 381, in
setlocale
    return _setlocale(category, locale)
locale.Error: unsupported locale setting
>>> locale.setlocale(locale.LC_CTYPE, None)
'C'

This makes me wonder if setlocale(LC_TYPE, "") is
really so very necessary.  It seems to be there to prep
for the nl_langinfo call, but it doesn't actually seem
strictly necessary for that call to work.

>>> locale.nl_langinfo(locale.CODESET)
'ANSI_X3.4-1968'

... I get that result whether before or after calling
setlocale, and I get it under any account (including
root, where setlocale does not raise an exception).

Thus, as far as I can tell, it isn't really necessary
to set setlocale(LC_CTYPE, "") or die trying, and
accepting the nl_langinfo result without a 
successful setlocale(LC_CTYPE, "") would be preferable
to raising an unhandled exception.  I suggest that
setlocale(LC_TYPE, "") be enclosed in a try block.

                try:
                    setlocale(LC_CTYPE, "")
                except:
                    None

Since I don't really understand what it's doing in the
first place, I don't know if this is really a good patch.

Thanks!

----------------------------------------------------------------------

Comment By: jminka (jminka)
Date: 2006-03-17 21:27

Message:
Logged In: YES 
user_id=1116964

I've got the same problem with bzr on Gentoo. If LANG or
LC_ALL consists '/', then bzr has the problem (e.g. en_US is
ok, en_US/ISO8859-1 is wrong). 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1443504&group_id=5470

From noreply at sourceforge.net  Sat Mar 18 01:35:17 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 17 Mar 2006 16:35:17 -0800
Subject: [ python-Bugs-1451466 ] reading very large files
Message-ID: <E1FKPPZ-0002WR-5w@sc8-sf-web1.sourceforge.net>

Bugs item #1451466, was opened at 2006-03-16 09:21
Message generated for change (Comment added) made by josiahcarlson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451466&group_id=5470

Please note that this message 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: christen (richardchristen)
Assigned to: Nobody/Anonymous (nobody)
Summary: reading very large files

Initial Comment:
I work on the human genome
I extracted words from chromosomes using a suffix tree
(C compiled for 64 done on a SUN with 300 Go RAM, since
my suffix tree requires 150 Go RAM for chromosome 1,
the largest one)

this gave some >5 Go files, for example with 163763326
lines for chr 4, the one presently analyzed.

Using python 2.4.2 on a windows 32-computer (1.5 Go
RAM), reading this file line by line either

for li in file:
    do something

or

while li!='':
    li=file.readline()

I got problems seemingly around the 4 Go boundary
(after reading the problematic first line), for some
lines (not all), the li returned the correct content
but with the first word of the next line also within li
(see below)

As a result a simple
file1=open('1')
file2=open('2','w')
li=file1.readline()
while li!='':
    file2.write(li) 
    li=file1.readline()

produced a second file of only
163754385 lines
problem lines were "seemingly random", i.e. not in a
row, with the last line being OK.


The same code on the same file but on my OSX
64-dualcore machine went fine, despite the use of
default Python 2.2.3 and "file Python" showing it is a
Mach-0 executable ppc, i.e. a 32 bit app.

Everything was run from the command line.


the first file looks like that
...
TCAGCCACAGCAGAAAGTGA:\t33240 551212 751185
TCAGCCACAGCAGAAAGTGC:\t131324047
TCAGCCACAGCACTGTGTTA:\t61641912
....

the second file contains lines like these :
TCAGCCACAGCAGAAAGTGC:\t131324047TCAGCCACAGCAGAAGAAGA:  

which is 'first line'+'1rst word of next line'

PS1 : no problem to read the big file with UEdit on the
windows machine. Therefore the OS itself is not the
problem (also I transfered the bigfile from the Windows
to the Mac, if the file had had problems, it would have
been corrupted on the Mac)
PS2 : I tried python 2.3.5 on windows with the same
problem.
PS3: If needed, I can run the same test on a similar
file but for chromosome 8 which is slightly below the 4
Go limit (3.99).
PS4: I think I remember having done a similar parsing
on a Linux Athlon 64 monoCPU a month ago, with no trouble.

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-03-17 16:35

Message:
Logged In: YES 
user_id=341410

Sounds like an issue with file objects on certain platforms
not being able to handle offsets of 2**32 or larger.  I
personally have read and written files > 4gb on the windows
platform, but I seem to recall having issues on 32 bit linux
some time in the past.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451466&group_id=5470

From noreply at sourceforge.net  Sat Mar 18 01:38:31 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 17 Mar 2006 16:38:31 -0800
Subject: [ python-Feature Requests-1449496 ] Python should use 3GB Address
	Space on Windows
Message-ID: <E1FKPSh-0002iT-J4@sc8-sf-web4-b.sourceforge.net>

Feature Requests item #1449496, was opened at 2006-03-14 03:04
Message generated for change (Comment added) made by josiahcarlson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1449496&group_id=5470

Please note that this 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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin Gfeller (gfe)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python should use 3GB Address Space on Windows

Initial Comment:
Python runs fine using a 3GB address space on 32bit 
Windows.

To take advantage of this feature, Python should be 
linked using the /LARGEADDRESSAWARE flag of the 
linker. 

For details, please refer to:

http://msdn.microsoft.com/library/en-
us/memory/base/4gt_ram_tuning.asp

As most Windows users just use pre-built executables, 
this would be a worthwhile change. 

Best regards,
Martin Gfeller



----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-03-17 16:38

Message:
Logged In: YES 
user_id=341410

Microsoft claims that the switch does not negatively affect
users on systems without large amounts of memory, and the
extra gig of memory on platforms which could use it would be
nice.

Can you offer a patch?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1449496&group_id=5470

From noreply at sourceforge.net  Sat Mar 18 03:33:00 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 17 Mar 2006 18:33:00 -0800
Subject: [ python-Bugs-1451466 ] reading very large files
Message-ID: <E1FKRFU-0004jN-Ef@sc8-sf-web3.sourceforge.net>

Bugs item #1451466, was opened at 2006-03-16 12:21
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451466&group_id=5470

Please note that this message 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: christen (richardchristen)
Assigned to: Nobody/Anonymous (nobody)
Summary: reading very large files

Initial Comment:
I work on the human genome
I extracted words from chromosomes using a suffix tree
(C compiled for 64 done on a SUN with 300 Go RAM, since
my suffix tree requires 150 Go RAM for chromosome 1,
the largest one)

this gave some >5 Go files, for example with 163763326
lines for chr 4, the one presently analyzed.

Using python 2.4.2 on a windows 32-computer (1.5 Go
RAM), reading this file line by line either

for li in file:
    do something

or

while li!='':
    li=file.readline()

I got problems seemingly around the 4 Go boundary
(after reading the problematic first line), for some
lines (not all), the li returned the correct content
but with the first word of the next line also within li
(see below)

As a result a simple
file1=open('1')
file2=open('2','w')
li=file1.readline()
while li!='':
    file2.write(li) 
    li=file1.readline()

produced a second file of only
163754385 lines
problem lines were "seemingly random", i.e. not in a
row, with the last line being OK.


The same code on the same file but on my OSX
64-dualcore machine went fine, despite the use of
default Python 2.2.3 and "file Python" showing it is a
Mach-0 executable ppc, i.e. a 32 bit app.

Everything was run from the command line.


the first file looks like that
...
TCAGCCACAGCAGAAAGTGA:\t33240 551212 751185
TCAGCCACAGCAGAAAGTGC:\t131324047
TCAGCCACAGCACTGTGTTA:\t61641912
....

the second file contains lines like these :
TCAGCCACAGCAGAAAGTGC:\t131324047TCAGCCACAGCAGAAGAAGA:  

which is 'first line'+'1rst word of next line'

PS1 : no problem to read the big file with UEdit on the
windows machine. Therefore the OS itself is not the
problem (also I transfered the bigfile from the Windows
to the Mac, if the file had had problems, it would have
been corrupted on the Mac)
PS2 : I tried python 2.3.5 on windows with the same
problem.
PS3: If needed, I can run the same test on a similar
file but for chromosome 8 which is slightly below the 4
Go limit (3.99).
PS4: I think I remember having done a similar parsing
on a Linux Athlon 64 monoCPU a month ago, with no trouble.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-03-17 21:33

Message:
Logged In: YES 
user_id=31435

"windows 32-computer" is too vague.  Which operating system
(Win95, Win98, WinME, NT, Win2K, WinXP), and which
filesystem (FAT, FAT32, NTFS)?

Are you sure this is a text file?  If it's a binary file,
then  all sorts of bad things can happen opening it in text
mode (which your sample code does).

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-03-17 19:35

Message:
Logged In: YES 
user_id=341410

Sounds like an issue with file objects on certain platforms
not being able to handle offsets of 2**32 or larger.  I
personally have read and written files > 4gb on the windows
platform, but I seem to recall having issues on 32 bit linux
some time in the past.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451466&group_id=5470

From noreply at sourceforge.net  Sat Mar 18 03:38:33 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 17 Mar 2006 18:38:33 -0800
Subject: [ python-Feature Requests-1449496 ] Python should use 3GB Address
	Space on Windows
Message-ID: <E1FKRKr-00056F-Vv@sc8-sf-web3.sourceforge.net>

Feature Requests item #1449496, was opened at 2006-03-14 06:04
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1449496&group_id=5470

Please note that this 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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin Gfeller (gfe)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python should use 3GB Address Space on Windows

Initial Comment:
Python runs fine using a 3GB address space on 32bit 
Windows.

To take advantage of this feature, Python should be 
linked using the /LARGEADDRESSAWARE flag of the 
linker. 

For details, please refer to:

http://msdn.microsoft.com/library/en-
us/memory/base/4gt_ram_tuning.asp

As most Windows users just use pre-built executables, 
this would be a worthwhile change. 

Best regards,
Martin Gfeller



----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-03-17 21:38

Message:
Logged In: YES 
user_id=31435

MS also says "However, the file cache, paged pool, and
non-paged pool are smaller, which can adversely affect
applications with heavy networking or I/O", so the rationale
for making this change is clear as mud.  That is, it's not a
pure win: some apps win at the expense of others.

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-03-17 19:38

Message:
Logged In: YES 
user_id=341410

Microsoft claims that the switch does not negatively affect
users on systems without large amounts of memory, and the
extra gig of memory on platforms which could use it would be
nice.

Can you offer a patch?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1449496&group_id=5470

From noreply at sourceforge.net  Sat Mar 18 04:21:57 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 17 Mar 2006 19:21:57 -0800
Subject: [ python-Bugs-1448042 ] Defining a class with __dict__ brakes
	attributes assignment
Message-ID: <E1FKS0r-0004QB-MN@sc8-sf-web1.sourceforge.net>

Bugs item #1448042, was opened at 2006-03-11 17:49
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448042&group_id=5470

Please note that this message 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: Michal Kwiatkowski (rubyjoker)
Assigned to: Nobody/Anonymous (nobody)
Summary: Defining a class with __dict__ brakes attributes assignment

Initial Comment:
When defining a class with __dict__ attribute, its 
instances can't rebind their __dict__ attributes.

--------------------------------------------------

class C(object): __dict__ = {}

obj = C()
obj.a = object()

import gc
gc.get_referrers(obj.a) # => [{'a': <object object at 
0x811d5b0>}]

obj.__dict__ = {} # doesn't really bind new __dict__

vars(obj) # => {}
object.__getattribute__(obj, '__dict__') # => {}
object.__getattribute__(C, '__dict__') # => {..., but 
without "a"}
obj.a  # => <object object at 0x811d5b0> (no exception
!)

gc.get_referrers(obj.a) # => [{'a': <object object at 
0x811d5b0>, '__dict__': {}}]

--------------------------------------------------

Although neither class nor object has an attribute "a", 
it's still accessible. It's also not possible to rebind 
__dict__ in that object, as it gets inside real object 
attributes dictionary.

This behaviour has been tested on Python 2.2, 2.3 and 
2.4, but may as well affect earlier versions.

----------------------------------------------------------------------

>Comment By: Terry J. Reedy (tjreedy)
Date: 2006-03-17 22:21

Message:
Logged In: YES 
user_id=593130

To me, this falls under the category of 'don't do that'.

http://docs.python.org/ref/id-classes.html
2.3.2 Reserved classes of identifiers 
__*__ 
System-defined names. These names are defined by the 
interpreter and its implementation ...

To me, this means to use them in the manner specified or 
you get what you get. 

http://docs.python.org/ref/types.html#l2h-120
defines the internal usage of '__dict__'.  There is, as 
far as I know, no specified usage for rebinding '__dict__'.

So unless someone has a better idea that won't slow down 
proper usage, I would close this as 'invalid' or 'wont 
fix'.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448042&group_id=5470

From noreply at sourceforge.net  Sat Mar 18 05:17:22 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 17 Mar 2006 20:17:22 -0800
Subject: [ python-Bugs-1452697 ] broken string on mbcs
Message-ID: <E1FKSsU-0007tG-4e@sc8-sf-web1.sourceforge.net>

Bugs item #1452697, was opened at 2006-03-18 05:07
Message generated for change (Comment added) made by ocean-city
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1452697&group_id=5470

Please note that this 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: ocean-city (ocean-city)
Assigned to: M.-A. Lemburg (lemburg)
Summary: broken string on mbcs

Initial Comment:
Hello. I noticed unicode conversion from mbcs was
sometimes broken. This happened when I used
codecs.open("foo", "r", "mbcs") as iterator.

# It's OK if I use "shift_jis" or "cp932".

I'll attach the script and text file to reproduce the
problem. I'm using Win2000SP4(Japanese).

Thank you.

----------------------------------------------------------------------

>Comment By: ocean-city (ocean-city)
Date: 2006-03-18 13:17

Message:
Logged In: YES 
user_id=1200846

Probably this patch will fix the problem. (for release24-maint)

Cause: MultiByteToWideChar returns non zero value for
incomplete multibyte character. (ex: if buffer terminates
with leading byte, MultiByteToWideChar returns 1 (not 0) for
it. It should return 0, otherwise result will be broken.

Solution: Set flag MB_ERR_INVALID_CHARS to avoid incorrect
handling of trailing incomplete multibyte part. If error
occurs, removes the trailing byte and tries again.

Caution: I have not tested this so intensibly.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1452697&group_id=5470

From noreply at sourceforge.net  Sat Mar 18 05:28:06 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 17 Mar 2006 20:28:06 -0800
Subject: [ python-Bugs-1452697 ] broken string on mbcs
Message-ID: <E1FKT2s-00012n-IE@sc8-sf-web6.sourceforge.net>

Bugs item #1452697, was opened at 2006-03-18 05:07
Message generated for change (Settings changed) made by ocean-city
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1452697&group_id=5470

Please note that this 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: 7
Submitted By: ocean-city (ocean-city)
Assigned to: M.-A. Lemburg (lemburg)
Summary: broken string on mbcs

Initial Comment:
Hello. I noticed unicode conversion from mbcs was
sometimes broken. This happened when I used
codecs.open("foo", "r", "mbcs") as iterator.

# It's OK if I use "shift_jis" or "cp932".

I'll attach the script and text file to reproduce the
problem. I'm using Win2000SP4(Japanese).

Thank you.

----------------------------------------------------------------------

Comment By: ocean-city (ocean-city)
Date: 2006-03-18 13:17

Message:
Logged In: YES 
user_id=1200846

Probably this patch will fix the problem. (for release24-maint)

Cause: MultiByteToWideChar returns non zero value for
incomplete multibyte character. (ex: if buffer terminates
with leading byte, MultiByteToWideChar returns 1 (not 0) for
it. It should return 0, otherwise result will be broken.

Solution: Set flag MB_ERR_INVALID_CHARS to avoid incorrect
handling of trailing incomplete multibyte part. If error
occurs, removes the trailing byte and tries again.

Caution: I have not tested this so intensibly.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1452697&group_id=5470

From noreply at sourceforge.net  Sat Mar 18 08:29:07 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 17 Mar 2006 23:29:07 -0800
Subject: [ python-Bugs-1451466 ] reading very large files
Message-ID: <E1FKVs3-0006DC-B8@sc8-sf-web3.sourceforge.net>

Bugs item #1451466, was opened at 2006-03-16 18:21
Message generated for change (Comment added) made by richardchristen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451466&group_id=5470

Please note that this message 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: christen (richardchristen)
Assigned to: Nobody/Anonymous (nobody)
Summary: reading very large files

Initial Comment:
I work on the human genome
I extracted words from chromosomes using a suffix tree
(C compiled for 64 done on a SUN with 300 Go RAM, since
my suffix tree requires 150 Go RAM for chromosome 1,
the largest one)

this gave some >5 Go files, for example with 163763326
lines for chr 4, the one presently analyzed.

Using python 2.4.2 on a windows 32-computer (1.5 Go
RAM), reading this file line by line either

for li in file:
    do something

or

while li!='':
    li=file.readline()

I got problems seemingly around the 4 Go boundary
(after reading the problematic first line), for some
lines (not all), the li returned the correct content
but with the first word of the next line also within li
(see below)

As a result a simple
file1=open('1')
file2=open('2','w')
li=file1.readline()
while li!='':
    file2.write(li) 
    li=file1.readline()

produced a second file of only
163754385 lines
problem lines were "seemingly random", i.e. not in a
row, with the last line being OK.


The same code on the same file but on my OSX
64-dualcore machine went fine, despite the use of
default Python 2.2.3 and "file Python" showing it is a
Mach-0 executable ppc, i.e. a 32 bit app.

Everything was run from the command line.


the first file looks like that
...
TCAGCCACAGCAGAAAGTGA:\t33240 551212 751185
TCAGCCACAGCAGAAAGTGC:\t131324047
TCAGCCACAGCACTGTGTTA:\t61641912
....

the second file contains lines like these :
TCAGCCACAGCAGAAAGTGC:\t131324047TCAGCCACAGCAGAAGAAGA:  

which is 'first line'+'1rst word of next line'

PS1 : no problem to read the big file with UEdit on the
windows machine. Therefore the OS itself is not the
problem (also I transfered the bigfile from the Windows
to the Mac, if the file had had problems, it would have
been corrupted on the Mac)
PS2 : I tried python 2.3.5 on windows with the same
problem.
PS3: If needed, I can run the same test on a similar
file but for chromosome 8 which is slightly below the 4
Go limit (3.99).
PS4: I think I remember having done a similar parsing
on a Linux Athlon 64 monoCPU a month ago, with no trouble.

----------------------------------------------------------------------

>Comment By: christen (richardchristen)
Date: 2006-03-18 08:29

Message:
Logged In: YES 
user_id=1477618

In reply to previous comment

Are you sure this is a text file?
Yes I made it myself.
Besides I transfered it from the UX machine to the windows
one by ftp with change of the end of line character to the
window's kind. I checked with type myfile, that the control
character was indeed changed. Also, I mentioned that I
manually checked with Uedit, both in ASCII and HEX modes for
the akward lines.

"windows 32-computer" is too vague."
I agree, I should have been more specific:
System: Microsoft Windows 2000 Professionnel
Version 5.0.2195 Service Pack 4 version 2195
Mother card : ASUSTek 
System Model A7N8X-E
BIOS Phoenix AwardBIOS v6-00PG
Memory 1.5Go
Swap 2.4 Go

File System NTFS

Best Regards

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-03-18 03:33

Message:
Logged In: YES 
user_id=31435

"windows 32-computer" is too vague.  Which operating system
(Win95, Win98, WinME, NT, Win2K, WinXP), and which
filesystem (FAT, FAT32, NTFS)?

Are you sure this is a text file?  If it's a binary file,
then  all sorts of bad things can happen opening it in text
mode (which your sample code does).

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-03-18 01:35

Message:
Logged In: YES 
user_id=341410

Sounds like an issue with file objects on certain platforms
not being able to handle offsets of 2**32 or larger.  I
personally have read and written files > 4gb on the windows
platform, but I seem to recall having issues on 32 bit linux
some time in the past.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451466&group_id=5470

From noreply at sourceforge.net  Sat Mar 18 09:22:19 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 18 Mar 2006 00:22:19 -0800
Subject: [ python-Bugs-1353504 ] Python drops core when stdin is bogus
Message-ID: <E1FKWhX-00019B-OI@sc8-sf-web3.sourceforge.net>

Bugs item #1353504, was opened at 2005-11-10 22:16
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353504&group_id=5470

Please note that this message 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: Skip Montanaro (montanaro)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Python drops core when stdin is bogus

Initial Comment:
Someone here at work had the bright idea to execute a
Python
script from a Solaris 10 ~/.dtprofile file. 
Apparently, at the time
that script is run stdin is bogus.  Python core dumps
with this
gdb backtrace:

#0  0x0807d290 in PyDict_SetItem (op=0x815b79c,
key=0x8163f20, value=0x0)
    at ../Objects/dictobject.c:549
#1  0x0807e0f7 in PyDict_SetItemString (v=0x815b79c,
key=0x8118df2 "stdin",
    item=0x0) at ../Objects/dictobject.c:1988
#2  0x080e0d03 in _PySys_Init () at
../Python/sysmodule.c:977
#3  0x080ddfdb in Py_InitializeEx (install_sigs=1) at
../Python/pythonrun.c:190
#4  0x080dfa89 in Py_Initialize () at
../Python/pythonrun.c:283
#5  0x0805cd55 in Py_Main (argc=3, argv=0x8047c08) at
../Modules/main.c:418
#6  0x0805ca13 in main (argc=3, argv=0x8047c08) at
../Modules/python.c:23

(This is from 2.4.2, but it also happens in 2.3.4.)

Looking at the code in _PySys_Init it calls

    sysin = PyFile_FromFile(stdin, "<stdin>", "r", NULL);

which returns NULL.  In PyFile_FromFile it creates a new
PyFileObject, then initializes it by calling a static
function,
fill_file_fields.  This apparently fails, causing a NULL
pointer return.  Back in _PySys_Init it checks
PyErr_Occurred,
but fill_file_fields never raised an except.  The NULL
pointer
is passed to PyDict_SetItemString and havoc ensues.

I haven't checked CVS, but 2.4 (and probably 2.3) should be
fixed.  I suggest raising an IOError in
fill_file_fields instead
of just setting f to NULL and returning it.


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-18 08:22

Message:
Logged In: YES 
user_id=849994

Closing then.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-09 06:03

Message:
Logged In: YES 
user_id=33168

I just changed this to print an error message and exit in 2.5.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-11-15 00:16

Message:
Logged In: YES 
user_id=33168

Ok, I understand that part.  But if you can't accept input
from the user, what can you do?

If all you are suggesting is to change Py_FatalError() to
raising a SystemError and still exiting, I'm fine with that
if it can work.  I agree this would probably be nicer too. 
Or am I still missing your point?  Do you want to work on a
patch?  I'm fine with any improvement, I'm just not sure how
much can be done.  If you want to improve the error message,
that would be good too.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2005-11-14 23:57

Message:
Logged In: YES 
user_id=44345

No, we're still discussing stdin.  My only point is that what
you do might be predicated on whether or not you think you
can communicate with the user on stderr.

My thought was that if stderr is valid you can raise an exception
that prints a traceback.  If not, Py_FatalError is your only
recourse.  Your code checks for the directori-ness of stdin as
the first thing, then bails if it is.  If it checked to see if stderr was
valid first, it could decide to raise SystemError instead of
calling Py_FatalError.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-11-14 22:08

Message:
Logged In: YES 
user_id=33168

Did you mistype and still mean stdin or are we talking about
stderr?

IIRC, calling Py_FatalError() was what I intended if stdin
is bogus.  I don't know what else to do.  If you can think
of scenarios where we could improve the behaviour, I think
that's fine to do.  I suppose you could set stdin to None,
but I'm not sure what that would do or if it would improve
anything.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2005-11-14 22:01

Message:
Logged In: YES 
user_id=44345

Well, I built from CVS^H^H^HSubversion HEAD at work and tried
again.  Still got a core dump, but that was a side-effect of
calling
Py_FatalError.  Is that the intended behavior?  I guess with a
bogus stderr that makes sense, but if stderr happened to be
valid at this point, I'd rather have it raise something more
meaningful for the user, like SystemError.


----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2005-11-12 13:18

Message:
Logged In: YES 
user_id=44345

Thanks Neal.  I'll check it out at work next week.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-11-11 07:24

Message:
Logged In: YES 
user_id=33168

This should be fixed in 2.4.3 and CVS (2.3.5 is probably
affected too).  I remember dealing with directories
specifically.  Checkout the current sysmodule.c.  Here's the
checkin:  

r39652 | nnorwitz | 2005-10-02 18:03:46 -0700 (Sun, 02 Oct
2005) | 5 lines

SF bug #887946.

Let me know if this bug is different and the patch doesn't
solve the problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353504&group_id=5470

From noreply at sourceforge.net  Sat Mar 18 09:24:49 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 18 Mar 2006 00:24:49 -0800
Subject: [ python-Bugs-1416477 ] Inconsistency between StringIO and cStringIO
Message-ID: <E1FKWjx-0001Gm-2R@sc8-sf-web3.sourceforge.net>

Bugs item #1416477, was opened at 2006-01-27 14:51
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1416477&group_id=5470

Please note that this 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.4
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Michael Kerrin (mkerrin)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Inconsistency between StringIO and cStringIO

Initial Comment:
The readline method for StringIO defalt argument for
the size arguement is None while for all other
file-like objects it is -1. So if we pass in -1 to the
StringIO readline method, all lines are returned, again
inconsistent with the other file-like objects, and if
we pass in None to any other file-like object we get a
TypeError, int required.

The attached python script is a very simple example of
what I mean.

Note that this is causing me a lot of grief in trying
to get tests to pass for a simple fix to an open source
project.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-18 08:24

Message:
Logged In: YES 
user_id=849994

Closing then.

----------------------------------------------------------------------

Comment By: Kent Hsu (cphsu)
Date: 2006-03-06 05:16

Message:
Logged In: YES 
user_id=1468643

Sorry, it seems the bug has been fixed in 2.4.

>>>>>>>>>>>>>>>>>>>
>>> import cStringIO as c
>>> sio = c.StringIO()
>>> sio.write("aaaaa")
>>> sio.truncate(0)
>>> print sio.getvalue()

>>> sio.write("bbbbb")
>>> print sio.getvalue()
aaaaabbbbb

which I get in StringIO module is "bbbbb".

----------------------------------------------------------------------

Comment By: Kent Hsu (cphsu)
Date: 2006-03-06 05:04

Message:
Logged In: YES 
user_id=1468643

BTW, another inconsistency between StringIO and cStringIO :-)

>>> import cStringIO as c
>>> sio = c.StringIO()
>>> sio.write("aaaaa")
>>> sio.truncate(0)
>>> print sio.getvalue()

>>> sio.write("bbbbb")
>>> print sio.getvalue()
aaaaabbbbb

which I get in StringIO module is "bbbbb".


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1416477&group_id=5470

From noreply at sourceforge.net  Sat Mar 18 09:26:12 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 18 Mar 2006 00:26:12 -0800
Subject: [ python-Bugs-1427552 ] tarfile.open bug / corrupt data
Message-ID: <E1FKWlI-0001Or-JN@sc8-sf-web3.sourceforge.net>

Bugs item #1427552, was opened at 2006-02-08 14:13
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1427552&group_id=5470

Please note that this message 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: None
Priority: 7
Submitted By: Chris86 (chris86)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile.open bug / corrupt data

Initial Comment:
Hi!

I want to create a bz2 compressed tar file.
Here is my code:
full="/home/test/test.sql"
tar = tarfile.open("test.tar.bz2", "w:bz2")
tarinfo = tar.gettarinfo(full,"blubb.sql")
tar.addfile(tarinfo,file(full))
tar.close()

i think this should work, but the sql file is corrupt:
- the created sql file in the compressed tar has only
4745 Lines, the original file has 4753


Regards,
Chris

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-12 06:21

Message:
Logged In: YES 
user_id=33168

Chris can you attach your sql file (or a small test case) so
we can reproduce the problem?

----------------------------------------------------------------------

Comment By: Lars Gust?bel (gustaebel)
Date: 2006-02-08 15:13

Message:
Logged In: YES 
user_id=642936

Just to identify whether this is a tarfile or bz2 module
related issue:
- Do you have the same problem without compression or with
gzip compression?
- Have you tried compressing your sql file directly with the
bz2 module? 

----------------------------------------------------------------------

Comment By: Chris86 (chris86)
Date: 2006-02-08 14:17

Message:
Logged In: YES 
user_id=1133569

same error with Python 2.3.5 (#2, Aug 30 2005, 15:50:26)
[GCC 4.0.2 20050821 (prerelease) (Debian 4.0.1-6)] on linux2


----------------------------------------------------------------------

Comment By: Chris86 (chris86)
Date: 2006-02-08 14:15

Message:
Logged In: YES 
user_id=1133569

I'm using Python 2.4.2 (#2, Nov 20 2005, 17:04:48)
[GCC 4.0.3 20051111 (prerelease) (Debian 4.0.2-4)] on linux2

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1427552&group_id=5470

From noreply at sourceforge.net  Sat Mar 18 09:26:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 18 Mar 2006 00:26:46 -0800
Subject: [ python-Bugs-1432838 ] optparse docs double-dash confusion
Message-ID: <E1FKWlq-0001Ow-5Z@sc8-sf-web3.sourceforge.net>

Bugs item #1432838, was opened at 2006-02-16 12:28
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1432838&group_id=5470

Please note that this 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: John Veness (pelago)
Assigned to: Greg Ward (gward)
Summary: optparse docs double-dash confusion

Initial Comment:
Page
http://docs.python.org/lib/optparse-terminology.html says:

The GNU project introduced "-" followed by a series of
hyphen-separated words, e.g. "-file" or "-dry-run".

but should say:

The GNU project introduced "--" followed by a series of
hyphen-separated words, e.g. "--file" or "--dry-run".

Also at the bottom of that page:

"-v" and "-report" are both options.

should be:

"-v" and "--report" are both options.

It looks in general that there is a documentation
rendering problem when double-dash appears in quotes.
Other double-dash items on that page are ok, when not
in quotes.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-18 08:26

Message:
Logged In: YES 
user_id=849994

Now fixed in SVN.

----------------------------------------------------------------------

Comment By: splitscreen (splitscreen)
Date: 2006-02-18 11:24

Message:
Logged In: YES 
user_id=1126061

Yeah, that's all that the patch that I provided does.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-17 09:05

Message:
Logged In: YES 
user_id=1188172

A suggested fix is to replace "-{}-" by "{--}" for long
options. Greg?

----------------------------------------------------------------------

Comment By: splitscreen (splitscreen)
Date: 2006-02-16 20:59

Message:
Logged In: YES 
user_id=1126061

Patch provided: #1433148

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1432838&group_id=5470

From noreply at sourceforge.net  Sat Mar 18 09:29:58 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 18 Mar 2006 00:29:58 -0800
Subject: [ python-Bugs-1448042 ] Defining a class with __dict__ brakes
	attributes assignment
Message-ID: <E1FKWow-0001aL-2L@sc8-sf-web3.sourceforge.net>

Bugs item #1448042, was opened at 2006-03-11 22:49
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448042&group_id=5470

Please note that this message 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: Wont Fix
Priority: 5
Submitted By: Michal Kwiatkowski (rubyjoker)
Assigned to: Nobody/Anonymous (nobody)
Summary: Defining a class with __dict__ brakes attributes assignment

Initial Comment:
When defining a class with __dict__ attribute, its 
instances can't rebind their __dict__ attributes.

--------------------------------------------------

class C(object): __dict__ = {}

obj = C()
obj.a = object()

import gc
gc.get_referrers(obj.a) # => [{'a': <object object at 
0x811d5b0>}]

obj.__dict__ = {} # doesn't really bind new __dict__

vars(obj) # => {}
object.__getattribute__(obj, '__dict__') # => {}
object.__getattribute__(C, '__dict__') # => {..., but 
without "a"}
obj.a  # => <object object at 0x811d5b0> (no exception
!)

gc.get_referrers(obj.a) # => [{'a': <object object at 
0x811d5b0>, '__dict__': {}}]

--------------------------------------------------

Although neither class nor object has an attribute "a", 
it's still accessible. It's also not possible to rebind 
__dict__ in that object, as it gets inside real object 
attributes dictionary.

This behaviour has been tested on Python 2.2, 2.3 and 
2.4, but may as well affect earlier versions.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-18 08:29

Message:
Logged In: YES 
user_id=849994

Agreed with Terry.

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2006-03-18 03:21

Message:
Logged In: YES 
user_id=593130

To me, this falls under the category of 'don't do that'.

http://docs.python.org/ref/id-classes.html
2.3.2 Reserved classes of identifiers 
__*__ 
System-defined names. These names are defined by the 
interpreter and its implementation ...

To me, this means to use them in the manner specified or 
you get what you get. 

http://docs.python.org/ref/types.html#l2h-120
defines the internal usage of '__dict__'.  There is, as 
far as I know, no specified usage for rebinding '__dict__'.

So unless someone has a better idea that won't slow down 
proper usage, I would close this as 'invalid' or 'wont 
fix'.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448042&group_id=5470

From noreply at sourceforge.net  Sat Mar 18 11:17:35 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 18 Mar 2006 02:17:35 -0800
Subject: [ python-Feature Requests-1437699 ] allow unicode arguments for
	robotparser.can_fetch
Message-ID: <E1FKYV5-0005p0-Dj@sc8-sf-web6.sourceforge.net>

Feature Requests item #1437699, was opened at 2006-02-23 21:07
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1437699&group_id=5470

Please note that this 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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: osvenskan (osvenskan)
Assigned to: M.-A. Lemburg (lemburg)
>Summary: allow unicode arguments for robotparser.can_fetch

Initial Comment:
One-line summary: If the robotparser module encounters
a robots.txt file that contains non-ASCII characters
AND I pass a Unicode user agent string to can_fetch(),
that function crashes with a TypeError under Python
2.4. Under Python 2.3, the error is a UnicodeDecodeError. 

More detail:
When one calls can_fetch(MyUserAgent, url), the
robotparser module compares  the UserAgent to each user
agent described in the robots.txt file. If
isinstance(MyUserAgent, str) == True then the
comparison does not raise an error regardless of the
contents of robots.txt. However, if
isinstance(MyUserAgent, unicode) == True, then Python
implicitly tries to convert the contents of the
robots.txt file to Unicode before comparing it to
MyUserAgent. By default, Python assumes a US-ASCII
encoding when converting, so if the contents of
robots.txt aren't ASCII, the conversion fails. In other
words, this works:
MyRobotParser.can_fetch('foobot', url)
but this fails:
MyRobotParser.can_fetch(u'foobot', url)

I recreated this with Python 2.4.1 on FreeBSD 6 and
Python 2.3 under Darwin/OS X. I'll attach examples from
both. The URLs that I use in the attachments are from
my Web site and will remain live. They reference
robots.txt files which contain an umlaut-ed 'a' (0xe4
in iso-8859-1). They're served up using a special
.htaccess file that adds a Content-Type header which
correctly identifies the encoding used for each file.
Here's the contents of the .htaccess file:

AddCharset iso-8859-1 .iso8859-1
AddCharset utf-8 .utf8


A suggested solution:
AFAICT, the construction of robots.txt is still defined
by "a consensus on 30 June 1994 on the robots mailing
list" [http://www.robotstxt.org/wc/norobots.html] and a
1996 draft proposal
[http://www.robotstxt.org/wc/norobots-rfc.html] that
has never evolved into a formal standard. Neither of
these mention character sets or encodings which is no
surprise considering that they date back to the days
when the Internet was poor but happy and we considered
even ASCII a luxury and we were grateful to have it.
("ASCII? We used to dream of having ASCII. We only had
one bit, and it was a zero. We lived in a shoebox in
the middle of the road..." etc.) A backwards-compatible
yet forward-looking solution would be to have the
robotparser module respect the Content-Type header sent
with robots.txt. If no such header is present,
robotparser should try to decode it using iso-8859-1
per section 3.7.1 of the HTTP 1.1 spec
(http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7.1)
which says, 'When no explicit charset parameter is
provided by the sender, media subtypes of the "text"
type are defined to have a default charset value of
"ISO-8859-1" when received via HTTP. Data in character
sets other than "ISO-8859-1" or its subsets MUST be
labeled with an appropriate charset value.' Section
3.6.1 of the HTTP 1.0 spec says the same. Since
ISO-8859-1 is a superset of US-ASCII, robots.txt files
that are pure ASCII won't be affected by the change.






----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-18 10:17

Message:
Logged In: YES 
user_id=849994

Turning into a Feature Request.

----------------------------------------------------------------------

Comment By: osvenskan (osvenskan)
Date: 2006-03-07 16:32

Message:
Logged In: YES 
user_id=1119995

Thanks for looking at this. I have some followup comments. 

The list at robotstxt.org is many years stale (note that
Google's bot is present only as Backrub which was still a
server at Stanford at the time:
http://www.robotstxt.org/wc/active/html/backrub.html) but
nevertheless AFAICT it is the most current bot list on the
Web. If you look carefully, the list *does* contain a
non-ASCII entry (#76 --easy to miss in that long list). That
Finnish bot is gone but it has left a legacy in the form of
many robots.txt files that were created by automated tools
based on the robotstxt.org list. Google helps us here:
http://www.google.com/search?q=allintext%3AH%C3%A4m%C3%A4h%C3%A4kki+disallow+filetype%3Atxt

And by Googling for some common non-ASCII words and letters
I can find more like this one (look at the end of the
alphabetical list):
http://paranormal.se/robots.txt

Robots.txt files that contain non-ASCII are few and far
between, it seems, but they're out there.

Which leads me to a nitpicky (but important!) point about
Unicode. As you point out, the spec doesn't mention Unicode;
it says nothing at all on the topic of encodings. My
argument is that just because the spec doesn't mention
encodings doesn't let us off the hook because the HTTP
1.0/1.1 specs are very clear that iso-8859-1, not US-ASCII,
is the default for text content delivered via HTTP. By my
interpretation, this means that the robots.txt examples
provided above are compliant with published specs, therefore
code that fails to interpret them does not comply. There's
no obvious need for robotparser to support full-blown
Unicode, just iso-8859-1. 

You might be interested in a replacement for this module
that I've implemented. It does everything that robotparser
does and also handles non-ASCII plus a few other things. It
is GPL; you're welcome to copy it in part or lock, stock and
barrel. So far I've only tested it "in the lab" but I've
done fairly extensive unit testing and I'll soon be testing
it on real-world data. The code and docs are here:
http://semanchuk.com/philip/boneyard/rerp/

Comments & feedback would be most welcome.



----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2006-03-06 03:01

Message:
Logged In: YES 
user_id=593130

To me, this is not a bug report but at best an RFE.  The 
reported behavior is what I would expect.  I read both 
module doc and the referenced web page and further links.  
The doc does not mention Unicode as allowed and the 300 
registered UserAgents at
http://www.robotstxt.org/wc/active/html/index.html
all have ascii names.

So I recomment closing this as a bug report but will give 
ML a chance to respond.  If switched instead to Feature 
Request, I would think it would need some 'in the wild' 
evidence of need.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1437699&group_id=5470

From noreply at sourceforge.net  Sat Mar 18 12:35:40 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 18 Mar 2006 03:35:40 -0800
Subject: [ python-Bugs-1353433 ] Http redirection error in urllib2.py
Message-ID: <E1FKZie-0001Qx-Fk@sc8-sf-web4-b.sourceforge.net>

Bugs item #1353433, was opened at 2005-11-10 20:25
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353433&group_id=5470

Please note that this message 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: Thomas Dehn (dehn)
Assigned to: Nobody/Anonymous (nobody)
Summary: Http redirection error in urllib2.py

Initial Comment:
A url request returns a redirect that contains a space '  ' 
character. Python urllib2.py does not replace this 
character with '%20' and fails.

Entering a line after line 507 of:
            newurl=re.sub(' ','%20',newurl)
         
Corrects my problem.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-18 11:35

Message:
Logged In: YES 
user_id=849994

Added a fix in rev. 43132.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2006-02-01 20:28

Message:
Logged In: YES 
user_id=261020

The problem is more general, so perhaps:

URLQUOTE_SAFE_URL_CHARS = "!*'();:@&=+$,/?%#[]~"
newurl = urllib.quote(url, URLQUOTE_SAFE_URL_CHARS)


Caveat: I still haven't read RFCs 3986/3987...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353433&group_id=5470

From noreply at sourceforge.net  Sat Mar 18 14:01:10 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 18 Mar 2006 05:01:10 -0800
Subject: [ python-Bugs-1448042 ] Defining a class with __dict__ brakes
	attributes assignment
Message-ID: <E1FKb3O-0001hM-Tt@sc8-sf-web3.sourceforge.net>

Bugs item #1448042, was opened at 2006-03-11 23:49
Message generated for change (Comment added) made by rubyjoker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448042&group_id=5470

Please note that this message 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: Wont Fix
Priority: 5
Submitted By: Michal Kwiatkowski (rubyjoker)
Assigned to: Nobody/Anonymous (nobody)
Summary: Defining a class with __dict__ brakes attributes assignment

Initial Comment:
When defining a class with __dict__ attribute, its 
instances can't rebind their __dict__ attributes.

--------------------------------------------------

class C(object): __dict__ = {}

obj = C()
obj.a = object()

import gc
gc.get_referrers(obj.a) # => [{'a': <object object at 
0x811d5b0>}]

obj.__dict__ = {} # doesn't really bind new __dict__

vars(obj) # => {}
object.__getattribute__(obj, '__dict__') # => {}
object.__getattribute__(C, '__dict__') # => {..., but 
without "a"}
obj.a  # => <object object at 0x811d5b0> (no exception
!)

gc.get_referrers(obj.a) # => [{'a': <object object at 
0x811d5b0>, '__dict__': {}}]

--------------------------------------------------

Although neither class nor object has an attribute "a", 
it's still accessible. It's also not possible to rebind 
__dict__ in that object, as it gets inside real object 
attributes dictionary.

This behaviour has been tested on Python 2.2, 2.3 and 
2.4, but may as well affect earlier versions.

----------------------------------------------------------------------

>Comment By: Michal Kwiatkowski (rubyjoker)
Date: 2006-03-18 14:01

Message:
Logged In: YES 
user_id=1310227

To see an example of rebinding __dict__ usage, go to:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/
66531
It's Alex Martelli implementation of Borg design pattern.

If rebinding __dict__ is forbidden, it should be clearly 
noted in the documetation. Either way, it's a bug.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-03-18 09:29

Message:
Logged In: YES 
user_id=849994

Agreed with Terry.

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2006-03-18 04:21

Message:
Logged In: YES 
user_id=593130

To me, this falls under the category of 'don't do that'.

http://docs.python.org/ref/id-classes.html
2.3.2 Reserved classes of identifiers 
__*__ 
System-defined names. These names are defined by the 
interpreter and its implementation ...

To me, this means to use them in the manner specified or 
you get what you get. 

http://docs.python.org/ref/types.html#l2h-120
defines the internal usage of '__dict__'.  There is, as 
far as I know, no specified usage for rebinding '__dict__'.

So unless someone has a better idea that won't slow down 
proper usage, I would close this as 'invalid' or 'wont 
fix'.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448042&group_id=5470

From noreply at sourceforge.net  Sat Mar 18 14:02:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 18 Mar 2006 05:02:46 -0800
Subject: [ python-Bugs-1453145 ] Unexpected module reloading
Message-ID: <E1FKb4w-0006s4-DZ@sc8-sf-web1.sourceforge.net>

Bugs item #1453145, was opened at 2006-03-18 16:32
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1453145&group_id=5470

Please note that this message 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: Ali Gholami Rudi (aligrudi)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unexpected module reloading

Initial Comment:
I'll demonstrate the problem:
Consider the following package hierarchy:
  
  p/
    __all__.py
    m1.py
    m2.py

The contents of m1 and m2 modules are:
-----m1.py----
import m2
import p.m2
--------------

-----m2.py----
print 'Loading m2 module'
--------------

Running the m1 module would yield the output
  Loading m2 module
  Loading m2 module
. As it is obvious from the output the module m2 is
loaded twice. The problem arrises when you want to do
things such as implementing a singleton class:

-----Alternate m2.py-----
class Singleton(object):
  _instance = None
  @staticmethod
  def getInstance():
    if Singleton._instance is None:
      Singleton._instance = Singleton()
    return _instace
-------------------------

-----Alternate m1.py-----
import m2
import p.m2

print m2.Singleton.getInstance()
print p.m2.Singleton.getInstance()
-------------------------

If you run m1 module, the output shows that the two
instaces are not the same objects. That is m2.Singleton
and p.m2.Singleton are not the same classes. 

I think this is a bug.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1453145&group_id=5470

From noreply at sourceforge.net  Sat Mar 18 18:57:51 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 18 Mar 2006 09:57:51 -0800
Subject: [ python-Bugs-1448042 ] Defining a class with __dict__ brakes
	attributes assignment
Message-ID: <E1FKfgV-0002Mb-4Q@sc8-sf-web2.sourceforge.net>

Bugs item #1448042, was opened at 2006-03-11 22:49
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448042&group_id=5470

Please note that this message 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: 6
Submitted By: Michal Kwiatkowski (rubyjoker)
Assigned to: Nobody/Anonymous (nobody)
Summary: Defining a class with __dict__ brakes attributes assignment

Initial Comment:
When defining a class with __dict__ attribute, its 
instances can't rebind their __dict__ attributes.

--------------------------------------------------

class C(object): __dict__ = {}

obj = C()
obj.a = object()

import gc
gc.get_referrers(obj.a) # => [{'a': <object object at 
0x811d5b0>}]

obj.__dict__ = {} # doesn't really bind new __dict__

vars(obj) # => {}
object.__getattribute__(obj, '__dict__') # => {}
object.__getattribute__(C, '__dict__') # => {..., but 
without "a"}
obj.a  # => <object object at 0x811d5b0> (no exception
!)

gc.get_referrers(obj.a) # => [{'a': <object object at 
0x811d5b0>, '__dict__': {}}]

--------------------------------------------------

Although neither class nor object has an attribute "a", 
it's still accessible. It's also not possible to rebind 
__dict__ in that object, as it gets inside real object 
attributes dictionary.

This behaviour has been tested on Python 2.2, 2.3 and 
2.4, but may as well affect earlier versions.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-18 17:57

Message:
Logged In: YES 
user_id=849994

Reopening. This is a bug, confirmed by Alex Martelli.

----------------------------------------------------------------------

Comment By: Michal Kwiatkowski (rubyjoker)
Date: 2006-03-18 13:01

Message:
Logged In: YES 
user_id=1310227

To see an example of rebinding __dict__ usage, go to:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/
66531
It's Alex Martelli implementation of Borg design pattern.

If rebinding __dict__ is forbidden, it should be clearly 
noted in the documetation. Either way, it's a bug.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-03-18 08:29

Message:
Logged In: YES 
user_id=849994

Agreed with Terry.

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2006-03-18 03:21

Message:
Logged In: YES 
user_id=593130

To me, this falls under the category of 'don't do that'.

http://docs.python.org/ref/id-classes.html
2.3.2 Reserved classes of identifiers 
__*__ 
System-defined names. These names are defined by the 
interpreter and its implementation ...

To me, this means to use them in the manner specified or 
you get what you get. 

http://docs.python.org/ref/types.html#l2h-120
defines the internal usage of '__dict__'.  There is, as 
far as I know, no specified usage for rebinding '__dict__'.

So unless someone has a better idea that won't slow down 
proper usage, I would close this as 'invalid' or 'wont 
fix'.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448042&group_id=5470

From noreply at sourceforge.net  Sat Mar 18 20:52:34 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 18 Mar 2006 11:52:34 -0800
Subject: [ python-Feature Requests-1453341 ] sys.setatomicexecution - for
	critical sections
Message-ID: <E1FKhTW-0007Jc-66@sc8-sf-web4-b.sourceforge.net>

Feature Requests item #1453341, was opened at 2006-03-18 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=355470&aid=1453341&group_id=5470

Please note that this message 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: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.setatomicexecution -  for critical sections

Initial Comment:
In order to maintain threaded code uncomplicated (VHL)
and in order to avoid massive use of locks, when
introducing few critical non-atomic sections, it should
be possible to put out that practical hammer ..

    try:
        last_ci=sys.setcheckinterval(sys.maxint)
        critical_function()  # now runs atomically
    finally:
        sys.setcheckinterval(last_ci)
    #(sys.setcheckinterval assumed to return the last
value)


..by an official function/class (in sys or thread):


Maybe:
======

atomic = sys.setatomicexecution(mode)
try:
    print "Executing critical section"
finally:
    sys.setatomicexecution(atomic)

there should be different modes/levels for blocking :

* 0=None
* 1=block only python execution in other threads
* 2=block signals
* 4/5/7/15=block threads at OS level (if OS supports)
* 8=(reserved: block future sub-/stackless switching
inside current thread..)

see:
http://groups.google.de/group/comp.lang.python/browse_frm/thread/bf5461507803975e/3bd7dfa9422a1200

compare:
http://www.stackless.com/wiki/Tasklets#critical-sections

---

Also Python could define officially its time atoms
beyond CPU atoms in the docs (That also defines the VHL
usability of the language).

Thus thinks like single-element changes ...

obj.var=x  , d[key]=x , l.append(x) .pop()

should be guaranteed to work atomic/correct FOR EVER. 

l[slice],  d.keys() .items(), .. questionable? 
If not guaranteed for the future, offer duplicates for
speed critical key building blocks like: 
l.slice_atomic(slice), d.keys_atomic() ,...  in order
to make code compatible for the future. 

---

Extra fun for blowing up python libs for poeple who
don't want to learn that try..finally all the time:

copy/deepcopy/dump maybe could be enriched by
copy_atomic , deepcopy_atomic, dump_atomic - or just
RuntimeError tolerant versions,   deepcopy_save  (no
use of .iterxxx)



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1453341&group_id=5470

From noreply at sourceforge.net  Sat Mar 18 22:54:50 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 18 Mar 2006 13:54:50 -0800
Subject: [ python-Feature Requests-1453341 ] sys.setatomicexecution - for
	critical sections
Message-ID: <E1FKjNq-0007Ks-Qa@sc8-sf-web6.sourceforge.net>

Feature Requests item #1453341, was opened at 2006-03-18 20:52
Message generated for change (Comment added) made by kxroberto
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1453341&group_id=5470

Please note that this message 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: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.setatomicexecution -  for critical sections

Initial Comment:
In order to maintain threaded code uncomplicated (VHL)
and in order to avoid massive use of locks, when
introducing few critical non-atomic sections, it should
be possible to put out that practical hammer ..

    try:
        last_ci=sys.setcheckinterval(sys.maxint)
        critical_function()  # now runs atomically
    finally:
        sys.setcheckinterval(last_ci)
    #(sys.setcheckinterval assumed to return the last
value)


..by an official function/class (in sys or thread):


Maybe:
======

atomic = sys.setatomicexecution(mode)
try:
    print "Executing critical section"
finally:
    sys.setatomicexecution(atomic)

there should be different modes/levels for blocking :

* 0=None
* 1=block only python execution in other threads
* 2=block signals
* 4/5/7/15=block threads at OS level (if OS supports)
* 8=(reserved: block future sub-/stackless switching
inside current thread..)

see:
http://groups.google.de/group/comp.lang.python/browse_frm/thread/bf5461507803975e/3bd7dfa9422a1200

compare:
http://www.stackless.com/wiki/Tasklets#critical-sections

---

Also Python could define officially its time atoms
beyond CPU atoms in the docs (That also defines the VHL
usability of the language).

Thus thinks like single-element changes ...

obj.var=x  , d[key]=x , l.append(x) .pop()

should be guaranteed to work atomic/correct FOR EVER. 

l[slice],  d.keys() .items(), .. questionable? 
If not guaranteed for the future, offer duplicates for
speed critical key building blocks like: 
l.slice_atomic(slice), d.keys_atomic() ,...  in order
to make code compatible for the future. 

---

Extra fun for blowing up python libs for poeple who
don't want to learn that try..finally all the time:

copy/deepcopy/dump maybe could be enriched by
copy_atomic , deepcopy_atomic, dump_atomic - or just
RuntimeError tolerant versions,   deepcopy_save  (no
use of .iterxxx)



----------------------------------------------------------------------

>Comment By: kxroberto (kxroberto)
Date: 2006-03-18 22:54

Message:
Logged In: YES 
user_id=972995

or:

>>> atomic = sys.acquireatomicexecution(mode)
>>> try: 
... 	print 'critical section'
... finally:
... 	atomic.release()

>>> with sys.acquireatomicexecution(mode):
...     print 'critical section'



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1453341&group_id=5470

From noreply at sourceforge.net  Sun Mar 19 00:58:14 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 18 Mar 2006 15:58:14 -0800
Subject: [ python-Bugs-1295808 ] expat symbols should be namespaced in pyexpat
Message-ID: <E1FKlJG-0006e0-IJ@sc8-sf-web6.sourceforge.net>

Bugs item #1295808, was opened at 2005-09-19 21:44
Message generated for change (Comment added) made by tmick
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295808&group_id=5470

Please note that this 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: Trent Mick (tmick)
Assigned to: Martin v. L??wis (loewis)
Summary: expat symbols should be namespaced in pyexpat

Initial Comment:
The Problem:
- you embed Python in some app
- the app dynamically loads libexpat of version X
- the embedded Python imports pyexpat (which was built
against
  libexpat version X+n)
--> pyexpat gets the expat symbols from the already
loaded and *older*
    libexpat: crash (Specifically the crash we observed
was in
    getting an old XML_ErrorString (from xmlparse.c)
and then calling
    it with newer values in the XML_Error enum:

      // pyexpat.c, line 1970
      ...
      // Added in Expat 1.95.7.
      MYCONST(XML_ERROR_UNBOUND_PREFIX);
      ...


The Solution:
Prefix all a exported symbols with "PyExpat_". This is
similar to
what Mozilla does for some common libs:
http://lxr.mozilla.org/seamonkey/source/modules/libimg/png/mozpngconf.h#115


I'll attach the gdb backtrace that we were getting and
a patch.

----------------------------------------------------------------------

>Comment By: Trent Mick (tmick)
Date: 2006-03-18 23:58

Message:
Logged In: YES 
user_id=34892

Attempted summary to get this patch into Python 2.5:

As Neal points out this is a duplicate of
<http://python.org/sf/1075984>. The patch on *that* bug
fixes the specific issue, but does not solve the general
problem (as  'mwh' pointed out in the comments there).

I think we should 
1. apply this patch
2. then perhaps update our expat version (see
http://python.org/sf/1433435,
http://mail.python.org/pipermail/python-dev/2006-March/062287.html),
3. then update Modules/expat/pyexpatns.h (that this patch
adds) for any new symbols in the new version of Expat.

Neal, Martin, Michael, what do you think?


----------------------------------------------------------------------

Comment By: Trent Mick (tmick)
Date: 2006-01-24 23:34

Message:
Logged In: YES 
user_id=34892

> This seems to be a duplicate of bug #1075984. 

You are right.

> Trent, is this patch sufficient to meet your embedding
> needs so that nothing else needs to be done?

Yes.

> I do not think this patch can be applied to 2.4.

That's fine. Getting this into Python >=2.5 would be good
enough.

Martin,
Have you had a chance to review this?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-30 06:01

Message:
Logged In: YES 
user_id=33168

This seems to be a duplicate of bug #1075984.  I like this
patch better, but perhaps both patches (the one here and the
other bug report) should be implemented?

I think Martin helps maintain pyexpat.  Maybe he has some
ideas about either or both of these bugs/patches.  Martin,
do you think these are safe to apply?  I can apply the
patch(es) if you think it's safe.

Trent, is this patch sufficient to meet your embedding needs
so that nothing else needs to be done?

I do not think this patch can be applied to 2.4.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295808&group_id=5470

From noreply at sourceforge.net  Sun Mar 19 01:25:32 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 18 Mar 2006 16:25:32 -0800
Subject: [ python-Bugs-1295808 ] expat symbols should be namespaced in pyexpat
Message-ID: <E1FKljg-0007QG-SU@sc8-sf-web4-b.sourceforge.net>

Bugs item #1295808, was opened at 2005-09-19 21:44
Message generated for change (Comment added) made by tmick
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295808&group_id=5470

Please note that this 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: Trent Mick (tmick)
Assigned to: Martin v. L??wis (loewis)
Summary: expat symbols should be namespaced in pyexpat

Initial Comment:
The Problem:
- you embed Python in some app
- the app dynamically loads libexpat of version X
- the embedded Python imports pyexpat (which was built
against
  libexpat version X+n)
--> pyexpat gets the expat symbols from the already
loaded and *older*
    libexpat: crash (Specifically the crash we observed
was in
    getting an old XML_ErrorString (from xmlparse.c)
and then calling
    it with newer values in the XML_Error enum:

      // pyexpat.c, line 1970
      ...
      // Added in Expat 1.95.7.
      MYCONST(XML_ERROR_UNBOUND_PREFIX);
      ...


The Solution:
Prefix all a exported symbols with "PyExpat_". This is
similar to
what Mozilla does for some common libs:
http://lxr.mozilla.org/seamonkey/source/modules/libimg/png/mozpngconf.h#115


I'll attach the gdb backtrace that we were getting and
a patch.

----------------------------------------------------------------------

>Comment By: Trent Mick (tmick)
Date: 2006-03-19 00:25

Message:
Logged In: YES 
user_id=34892

As well, *possibly* the same should be done for Python's
bz2.so, although the only relevant exported symbol is
Util_UnivNewlineRead

  nm bz2.so \
    | grep -v " [a-zBUA] " \
    | grep -v "_fini\|_init\|initbz2"



----------------------------------------------------------------------

Comment By: Trent Mick (tmick)
Date: 2006-03-18 23:58

Message:
Logged In: YES 
user_id=34892

Attempted summary to get this patch into Python 2.5:

As Neal points out this is a duplicate of
<http://python.org/sf/1075984>. The patch on *that* bug
fixes the specific issue, but does not solve the general
problem (as  'mwh' pointed out in the comments there).

I think we should 
1. apply this patch
2. then perhaps update our expat version (see
http://python.org/sf/1433435,
http://mail.python.org/pipermail/python-dev/2006-March/062287.html),
3. then update Modules/expat/pyexpatns.h (that this patch
adds) for any new symbols in the new version of Expat.

Neal, Martin, Michael, what do you think?


----------------------------------------------------------------------

Comment By: Trent Mick (tmick)
Date: 2006-01-24 23:34

Message:
Logged In: YES 
user_id=34892

> This seems to be a duplicate of bug #1075984. 

You are right.

> Trent, is this patch sufficient to meet your embedding
> needs so that nothing else needs to be done?

Yes.

> I do not think this patch can be applied to 2.4.

That's fine. Getting this into Python >=2.5 would be good
enough.

Martin,
Have you had a chance to review this?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-30 06:01

Message:
Logged In: YES 
user_id=33168

This seems to be a duplicate of bug #1075984.  I like this
patch better, but perhaps both patches (the one here and the
other bug report) should be implemented?

I think Martin helps maintain pyexpat.  Maybe he has some
ideas about either or both of these bugs/patches.  Martin,
do you think these are safe to apply?  I can apply the
patch(es) if you think it's safe.

Trent, is this patch sufficient to meet your embedding needs
so that nothing else needs to be done?

I do not think this patch can be applied to 2.4.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295808&group_id=5470

From noreply at sourceforge.net  Sun Mar 19 03:08:11 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 18 Mar 2006 18:08:11 -0800
Subject: [ python-Bugs-1452697 ] broken string on mbcs
Message-ID: <E1FKnL1-0007n7-WD@sc8-sf-web2.sourceforge.net>

Bugs item #1452697, was opened at 2006-03-18 05:07
Message generated for change (Comment added) made by ocean-city
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1452697&group_id=5470

Please note that this 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: 7
Submitted By: ocean-city (ocean-city)
Assigned to: M.-A. Lemburg (lemburg)
Summary: broken string on mbcs

Initial Comment:
Hello. I noticed unicode conversion from mbcs was
sometimes broken. This happened when I used
codecs.open("foo", "r", "mbcs") as iterator.

# It's OK if I use "shift_jis" or "cp932".

I'll attach the script and text file to reproduce the
problem. I'm using Win2000SP4(Japanese).

Thank you.

----------------------------------------------------------------------

>Comment By: ocean-city (ocean-city)
Date: 2006-03-19 11:08

Message:
Logged In: YES 
user_id=1200846

I updated the patch. Compared to version1...

  * [bug] consumed should be 0 if the length of string is 0

  * [enhancement] use IsDBCSLeadByte to detect incomplete
    buffer termination instead of trying MultiByteToWideChar
    with MB_ERR_INVALID_CHARS. This could cause performance
    hit if string contains invalid chars in early part.


----------------------------------------------------------------------

Comment By: ocean-city (ocean-city)
Date: 2006-03-18 13:17

Message:
Logged In: YES 
user_id=1200846

Probably this patch will fix the problem. (for release24-maint)

Cause: MultiByteToWideChar returns non zero value for
incomplete multibyte character. (ex: if buffer terminates
with leading byte, MultiByteToWideChar returns 1 (not 0) for
it. It should return 0, otherwise result will be broken.

Solution: Set flag MB_ERR_INVALID_CHARS to avoid incorrect
handling of trailing incomplete multibyte part. If error
occurs, removes the trailing byte and tries again.

Caution: I have not tested this so intensibly.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1452697&group_id=5470

From noreply at sourceforge.net  Sun Mar 19 05:36:02 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 18 Mar 2006 20:36:02 -0800
Subject: [ python-Bugs-1453570 ] try-except-finally in the tutorial
Message-ID: <E1FKpe6-0006Fx-Ky@sc8-sf-web1.sourceforge.net>

Bugs item #1453570, was opened at 2006-03-19 13:36
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1453570&group_id=5470

Please note that this 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: George Yoshida (quiver)
Assigned to: Nobody/Anonymous (nobody)
Summary: try-except-finally in the tutorial

Initial Comment:
Doc/tut/tut.tex describes "finally" statement as ::

  A try statement must either have one or more except 
clauses or one finally clause, but not both ...

But now that PEP 341[*] has been accepted and merged, 
this part needs a rewrite.

Adding a new section or an example using try-except-
(else-)finally will be required.

* http://www.python.org/peps/pep-0341.html


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1453570&group_id=5470

From noreply at sourceforge.net  Sun Mar 19 06:06:13 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 18 Mar 2006 21:06:13 -0800
Subject: [ python-Bugs-1453579 ] conditional expression documentation
	missing/incorrect
Message-ID: <E1FKq7J-0007hQ-1R@sc8-sf-web5.sourceforge.net>

Bugs item #1453579, was opened at 2006-03-19 00: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=1453579&group_id=5470

Please note that this 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: Alan (aisaac0)
Assigned to: Nobody/Anonymous (nobody)
Summary: conditional expression documentation missing/incorrect

Initial Comment:
PEP 308
http://www.python.org/doc/peps/pep-0308/
says Python 2.5 will add a conditional expression.

The Programming FAQ is as a result now wrong:
http://www.python.org/doc/faq/programming/#is-there-an-equivalent-of-c-s-ternary-operator

Also I do not see mention of this on the What's New page,
especially 
http://www.python.org/dev/doc/devel/whatsnew/node5.html
where it seems naturally to belong.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1453579&group_id=5470

From noreply at sourceforge.net  Sun Mar 19 11:44:59 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 19 Mar 2006 02:44:59 -0800
Subject: [ python-Bugs-1453145 ] Unexpected module reloading
Message-ID: <E1FKvP9-0004i2-3R@sc8-sf-web6.sourceforge.net>

Bugs item #1453145, was opened at 2006-03-18 14:02
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1453145&group_id=5470

Please note that this message 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: Invalid
Priority: 5
Submitted By: Ali Gholami Rudi (aligrudi)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unexpected module reloading

Initial Comment:
I'll demonstrate the problem:
Consider the following package hierarchy:
  
  p/
    __all__.py
    m1.py
    m2.py

The contents of m1 and m2 modules are:
-----m1.py----
import m2
import p.m2
--------------

-----m2.py----
print 'Loading m2 module'
--------------

Running the m1 module would yield the output
  Loading m2 module
  Loading m2 module
. As it is obvious from the output the module m2 is
loaded twice. The problem arrises when you want to do
things such as implementing a singleton class:

-----Alternate m2.py-----
class Singleton(object):
  _instance = None
  @staticmethod
  def getInstance():
    if Singleton._instance is None:
      Singleton._instance = Singleton()
    return _instace
-------------------------

-----Alternate m1.py-----
import m2
import p.m2

print m2.Singleton.getInstance()
print p.m2.Singleton.getInstance()
-------------------------

If you run m1 module, the output shows that the two
instaces are not the same objects. That is m2.Singleton
and p.m2.Singleton are not the same classes. 

I think this is a bug.


----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-03-19 11:44

Message:
Logged In: YES 
user_id=21627

At first, I could reproduce the problem; look at this
transcript to see what I did.

martin at mira:~/tmp$ mkdir p
martin at mira:~/tmp$ echo >p/__init__.py
martin at mira:~/tmp$ cat >p/m1.py
import m2
import p.m2
martin at mira:~/tmp$ cat >p/m2.py
print 'Loading m2 module'
martin at mira:~/tmp$ python
Python 2.3.5 (#2, Mar  6 2006, 10:12:24)
[GCC 4.0.3 20060304 (prerelease) (Debian 4.0.2-10)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
py> import p.m1
Loading m2 module
py>

As you can see, the "Loading" output is printed only once.

This might happen if you run p/m1.py as the main program,
but I cannot reproduce it:

martin at mira:~/tmp$ python p/m1.py
Loading m2 module
Traceback (most recent call last):
  File "p/m1.py", line 2, in ?
    import p.m2
ImportError: No module named p.m2

As the current directory is not on sys.path, it won't find
the package p.

Now, if you also change that (e.g. by setting PYTHONPATH), I get

martin at mira:~/tmp$ export PYTHONPATH=`pwd`
martin at mira:~/tmp$ python p/m1.py
Loading m2 module
Loading m2 module

This is not a bug: Now *both* the current directory, and the
directory ~/tmp/p are on sys.path (print sys.path inside m1
to see what I mean).

When you do "import m2", it searches for a module named m2
on sys.path, and it finds p/m2.py. When you then import
p.m2, it searches for a package p on sys.path, finds the
package, and then imports the module m2. It happens that
both modules have the same source file - yet they are
different modules.

If you change the print statement to

print 'Loading', __name__, 'module'

you get

Loading m2 module
Loading p.m2 module

So in short: this is not a bug. Don't try running a module
in a package as the main program.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1453145&group_id=5470

From noreply at sourceforge.net  Sun Mar 19 11:49:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 19 Mar 2006 02:49:25 -0800
Subject: [ python-Bugs-1451503 ] os.startfile() still doesn't work with
	Unicode filenames
Message-ID: <E1FKvTR-000513-IC@sc8-sf-web6.sourceforge.net>

Bugs item #1451503, was opened at 2006-03-16 19:08
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451503&group_id=5470

Please note that this 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: roee88 (roee88)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.startfile() still doesn't work with Unicode filenames

Initial Comment:
>From 2.4.2 changelog:
>>>Bug #1007046: os.startfile() did not accept 
unicode strings encoded in the file system encoding. 

If the filename is unicode type and the encoding 
isn't the default system encoding, all "unknown" (to 
system encoding) characters are replaced by "?".
This is causing the os.startfile() to fail with 
WindowsError: [Errno2] 
Because the filename doesn't really have the "?".

----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-03-19 11:49

Message:
Logged In: YES 
user_id=21627

Well, it does work on Unicode strings when all characters
from the string come from the system code page; this got
implemented in response to bug #1007046.

To fix this, the implementation should use ShellExecuteW
(except on Win9x). Would you like to work on a patch?

As a work-around, change your system code page so your file
names are supported.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451503&group_id=5470

From noreply at sourceforge.net  Sun Mar 19 12:21:39 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 19 Mar 2006 03:21:39 -0800
Subject: [ python-Bugs-1453570 ] try-except-finally in the tutorial
Message-ID: <E1FKvyd-0006G9-1M@sc8-sf-web1.sourceforge.net>

Bugs item #1453570, was opened at 2006-03-19 04:36
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1453570&group_id=5470

Please note that this 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: George Yoshida (quiver)
Assigned to: Nobody/Anonymous (nobody)
Summary: try-except-finally in the tutorial

Initial Comment:
Doc/tut/tut.tex describes "finally" statement as ::

  A try statement must either have one or more except 
clauses or one finally clause, but not both ...

But now that PEP 341[*] has been accepted and merged, 
this part needs a rewrite.

Adding a new section or an example using try-except-
(else-)finally will be required.

* http://www.python.org/peps/pep-0341.html


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-19 11:21

Message:
Logged In: YES 
user_id=849994

I updated that section. try-except-finally should be made
clear now. [rev. 43142]

Thanks for spotting!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1453570&group_id=5470

From noreply at sourceforge.net  Sun Mar 19 12:24:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 19 Mar 2006 03:24:05 -0800
Subject: [ python-Bugs-1453579 ] conditional expression documentation
	missing/incorrect
Message-ID: <E1FKw0z-0006QN-TL@sc8-sf-web1.sourceforge.net>

Bugs item #1453579, was opened at 2006-03-19 05:06
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1453579&group_id=5470

Please note that this 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: Alan (aisaac0)
Assigned to: Nobody/Anonymous (nobody)
Summary: conditional expression documentation missing/incorrect

Initial Comment:
PEP 308
http://www.python.org/doc/peps/pep-0308/
says Python 2.5 will add a conditional expression.

The Programming FAQ is as a result now wrong:
http://www.python.org/doc/faq/programming/#is-there-an-equivalent-of-c-s-ternary-operator

Also I do not see mention of this on the What's New page,
especially 
http://www.python.org/dev/doc/devel/whatsnew/node5.html
where it seems naturally to belong.



----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-19 11:24

Message:
Logged In: YES 
user_id=849994

The new up-to-date devel docs are at
http://docs.python.org/dev/. In the whatsnew there, PEP308
is included.

I've sent a mail to pydotorg at python.org about the
programming FAQ.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1453579&group_id=5470

From noreply at sourceforge.net  Sun Mar 19 12:51:04 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 19 Mar 2006 03:51:04 -0800
Subject: [ python-Bugs-1448060 ] gettext.py breaks on plural-forms header
	(PATCH)
Message-ID: <E1FKwR6-0002py-Bt@sc8-sf-web3.sourceforge.net>

Bugs item #1448060, was opened at 2006-03-12 00:20
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448060&group_id=5470

Please note that this message 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: Danilo Segan (dsegan)
Assigned to: Nobody/Anonymous (nobody)
Summary: gettext.py breaks on plural-forms header (PATCH)

Initial Comment:
See http://bugzilla.gnome.org/show_bug.cgi?id=334256

The problem is a PO file like the following:

test.po:
msgid ""
msgstr ""
"Content-Type: text/plain; charset=UTF-8\n"
"Plural-Forms:  nplurals=2; plural=(n != 1);\n"
"#-#-#-#-#  plo.po (PACKAGE VERSION)  #-#-#-#-#\n"

(these kinds of entries are sometimes inserted by
msgmerge, so they're somewhat common)

Any Python program trying to access this breaks:

$ python test.py
Traceback (most recent call last):
  File "test.py", line 7, in ?
    gt = gettext.GNUTranslations(file)
  File "/usr/lib/python2.4/gettext.py", line 177, in
__init__
    self._parse(fp)
  File "/usr/lib/python2.4/gettext.py", line 300, in _parse
    v = v.split(';')
AttributeError: 'list' object has no attribute 'split'


test.py is simple:
#!/usr/bin/env python
import gettext
file = open("test.mo", "rb")
if file:
    gt = gettext.GNUTranslations(file)


The problem is the corner-case: plural-forms precedes
this kind of comment, so "v" is split (v=v.split(";")).
In the next instance, lastk is "plural-forms", yet the
entry doesn't contain ":", so it tries to set plural
forms to v.split(";") again, which fails since v is
already a list.

The attached simple patch fixes this.


----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-03-19 12:51

Message:
Logged In: YES 
user_id=21627

Several things seem to be going on here:

1. gettext.py is clearly wrong; it shouldn't break on that file.

2. it is trying to process multi-line fields here. So the
patch is also wrong, as it just sets k and v to None.

3. I believe that the PO file presented is also wrong. I
believe the intention of the header is that it should have
the RFC822 style syntax, which doesn't allow for # comment
lines. The tool should use a syntax like

X-Filename: plo.po; package=PACKAGE; version=VERSION;

To summarize, I think the attempt to process multi-line
fields in the header is misguided, and gettext.py should
just fetch the first line of content-type and plural-forms.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448060&group_id=5470

From noreply at sourceforge.net  Sun Mar 19 13:25:21 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 19 Mar 2006 04:25:21 -0800
Subject: [ python-Bugs-1448640 ] datetime.__init__ cannot be overridden
Message-ID: <E1FKwyH-0002sJ-WC@sc8-sf-web3.sourceforge.net>

Bugs item #1448640, was opened at 2006-03-13 04:54
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448640&group_id=5470

Please note that this message 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: Martin Blais (blais)
Assigned to: Michael Hudson (mwh)
Summary: datetime.__init__ cannot be overridden

Initial Comment:
Hi

The following code does not work properly:

#!/usr/bin/env python
"""
Test overriding constructor of datetime classes.
"""

import sys, datetime

class MyDate(datetime.date):

    def __init__( self, year, month, day ):
        print >> sys.stderr, 'lose data'

d = MyDate(2006, 11, 29)
print d

class MyDate(datetime.date):

    def __new__( self, year, month, day ):
        print 'lose data'

    def __init__( self, year, month, day ):
        print 'lose data again'

d = MyDate(2006, 11, 29)
print d



The output is:

lose data
2006-11-29
lose data
None



The problem is that the initialization of the object is
done in its time_new() method which is registered for
__new__ rather than using an __init__ method.  This
prevent one from overriding the date/datetime/time
constructors.

cheers,


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-19 12:25

Message:
Logged In: YES 
user_id=849994

blais: your mistake was that you didn't call
datetime.date.__new__() in your overridden __new__() and did
return None from __new__ whereas __new__ must return a new
object of type MyDate.

----------------------------------------------------------------------

Comment By: Martin Blais (blais)
Date: 2006-03-13 21:45

Message:
Logged In: YES 
user_id=10996

Hmmmm... that's not quite true.  If I derive from datetime
in order to add new data members (e.g. in my case I add
"seq" which is used as a sequence number on top of datetime
for storing the names of photographs, the sequence number is
in case I have a panorama or multiple photographs in burst
mode--all within one second), I might want a different
constructor.

I tried overriding __new__ and had some troubles, cannot
remember what exactly, will reproduce and send code soon.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2006-03-13 16:42

Message:
Logged In: YES 
user_id=6656

datetime.date objects are immutable, so this is the same as not being able to 
override __init__ in a subclass of int.  Override __new__ instead.

----------------------------------------------------------------------

Comment By: splitscreen (splitscreen)
Date: 2006-03-13 15:40

Message:
Logged In: YES 
user_id=1126061

Isn't this an abuse of __new__ ?

Taken from the documentation:

"__new__ must return an object. There's nothing that
requires that it return a new object that is an instance of
its class argument, although that is the convention. If you
return an existing object, the constructor call will still
call its __init__ method. If you return an object of a
different class, its __init__ method will be called. If you
forget to return something, Python will unhelpfully return
None, and your caller will probably be very confused."

So, you're actually calling __init__ with None?

Or have i misunderstood?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448640&group_id=5470

From noreply at sourceforge.net  Sun Mar 19 14:50:37 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 19 Mar 2006 05:50:37 -0800
Subject: [ python-Bugs-1448042 ] Defining a class with __dict__ brakes
	attributes assignment
Message-ID: <E1FKyIn-0008GO-0s@sc8-sf-web3.sourceforge.net>

Bugs item #1448042, was opened at 2006-03-11 23:49
Message generated for change (Comment added) made by zseil
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448042&group_id=5470

Please note that this message 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: 6
Submitted By: Michal Kwiatkowski (rubyjoker)
Assigned to: Nobody/Anonymous (nobody)
Summary: Defining a class with __dict__ brakes attributes assignment

Initial Comment:
When defining a class with __dict__ attribute, its 
instances can't rebind their __dict__ attributes.

--------------------------------------------------

class C(object): __dict__ = {}

obj = C()
obj.a = object()

import gc
gc.get_referrers(obj.a) # => [{'a': <object object at 
0x811d5b0>}]

obj.__dict__ = {} # doesn't really bind new __dict__

vars(obj) # => {}
object.__getattribute__(obj, '__dict__') # => {}
object.__getattribute__(C, '__dict__') # => {..., but 
without "a"}
obj.a  # => <object object at 0x811d5b0> (no exception
!)

gc.get_referrers(obj.a) # => [{'a': <object object at 
0x811d5b0>, '__dict__': {}}]

--------------------------------------------------

Although neither class nor object has an attribute "a", 
it's still accessible. It's also not possible to rebind 
__dict__ in that object, as it gets inside real object 
attributes dictionary.

This behaviour has been tested on Python 2.2, 2.3 and 
2.4, but may as well affect earlier versions.

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-03-19 14:50

Message:
Logged In: YES 
user_id=1326842

Maybe this shows that it is actually a feature?

>>> class C(object):
...     pass
...

'__dict__' is not a normal attribute, it's a descriptor
(a "getset_descriptor") generated by object's type.
You can get to this object if you try hard enough:

>>> C_dict_descriptor = C.__dict__['__dict__']
>>> type(C_dict_descriptor).__name__
'getset_descriptor'

This descriptor is automatically created for most of the
python classes (except for those, that have __slots__
without __dict__) by 'type' object.

Since 'type' is an instance of itself, it also has it:

>>> type_dict_descriptor = type.__dict__['__dict__']

And we can see, that it is responsible for creating
the C's __dict__ attribute:

>>> C.__dict__ == type_dict_descriptor.__get__(C, type)
True

As is normal for most of the special named attributes,
this one is looked up in object's type, not in its dict,
and it isn't a normal dict, but a dictproxy:

>>> type(C.__dict__).__name__
'dictproxy'

Now in your case, you create a class attribute '__dict__':

>>> class D(C):
...     __dict__ = {'a': 1}
...

Which basically does something like:

>>> name = 'E'
>>> bases = (C,)
>>> E_namespace = {
...     '__dict__': {'a': 1},
...     '__doc__': "set to None by type if not provided",
...     '__module__': "globals()['__name__'] if missing",
...     '__weakref__': "another descriptor",
... }
>>> E = type(name, bases, E_namespace)

The '__dict__' attribute of this class is still provided by
its type (type 'type'), and is basicaly just a dictproxy of
the E_namespace:

>>> type(E.__dict__).__name__
'dictproxy'
>>> E.__dict__ == E_namespace
True

What your class definition actually did, is it has
overwritten the __dict__ descriptor that would be
normaly created by type; compare:

>>> C.__dict__['__dict__']
<attribute '__dict__' of 'C' objects>
>>> E.__dict__['__dict__']
{'a': 1}

Now watch what happens if you create an instance of E class:
>>> e = E()
>>> e.__dict__
{'a': 1}
>>> e.a = 2
>>> e.__dict__
{'a': 1}

Basically, now the '__dict__' attribute is a normal
attribute, that behaves just as any other attribute,
while you have lost acces to the instance's inner dict:

>>> e.__dict__ = {}
>>> e.__dict__
{}
>>> e.a
2

If you inherit directly from object, which doesn't have
this descriptor:

>>> object.__dict__['__dict__']
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
KeyError: '__dict__'

there would be no way of accesing instance's dictinary.
But since we inherited from class C, we can stil acces it:

>>> C_dict_descriptor.__get__(e)
{'a': 2, '__dict__': {}}


----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-03-18 18:57

Message:
Logged In: YES 
user_id=849994

Reopening. This is a bug, confirmed by Alex Martelli.

----------------------------------------------------------------------

Comment By: Michal Kwiatkowski (rubyjoker)
Date: 2006-03-18 14:01

Message:
Logged In: YES 
user_id=1310227

To see an example of rebinding __dict__ usage, go to:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/
66531
It's Alex Martelli implementation of Borg design pattern.

If rebinding __dict__ is forbidden, it should be clearly 
noted in the documetation. Either way, it's a bug.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-03-18 09:29

Message:
Logged In: YES 
user_id=849994

Agreed with Terry.

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2006-03-18 04:21

Message:
Logged In: YES 
user_id=593130

To me, this falls under the category of 'don't do that'.

http://docs.python.org/ref/id-classes.html
2.3.2 Reserved classes of identifiers 
__*__ 
System-defined names. These names are defined by the 
interpreter and its implementation ...

To me, this means to use them in the manner specified or 
you get what you get. 

http://docs.python.org/ref/types.html#l2h-120
defines the internal usage of '__dict__'.  There is, as 
far as I know, no specified usage for rebinding '__dict__'.

So unless someone has a better idea that won't slow down 
proper usage, I would close this as 'invalid' or 'wont 
fix'.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448042&group_id=5470

From noreply at sourceforge.net  Sun Mar 19 19:55:38 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 19 Mar 2006 10:55:38 -0800
Subject: [ python-Feature Requests-1453973 ] addheaders for urlopen / open /
	xxxx_open
Message-ID: <E1FL33y-0006om-Gl@sc8-sf-web5.sourceforge.net>

Feature Requests item #1453973, was opened at 2006-03-19 19:55
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=1453973&group_id=5470

Please note that this message 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: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: addheaders for urlopen / open / xxxx_open

Initial Comment:
Adding a header also for each open call is a frequent
need for me (much more than e.g. proxies per call in
urllib1/urlopen). 

For example:

urlopen(url,data,addheaders=[('Referer':lasturl)])

So far one is forced to set the _complete_ re-rendered
bunch of opener.addheaders each time (and to maintain a
separate opener for each thread )

open/OpenerDirector.open maybe should distribute
*args,**kwargs

---

Note on disciplined use of protocol modules in urllib2
( see also #1046077 ):

urllib2 still draws in all kind of (future?) protocol
modules all in advance =>  slows down app startup / cgi
script's ...; ugly non-pythonic/non-modular; unused
prots cannot be excluded for cx_Freeze,setup ... 
Now the fat cookielib was also added in that manner.
Thus, when you use urllib2 for "ftp://xy", you load
also all kind of fun (down to things like
_MozillaCookieJar) into Python. 

The need for those imports is very local (search e.g.
"ftplib."). ==> local import in those few places.

I saw, this jam style already encouraged more
undisciplined dependencies like :
"origin_req_host = cookielib.request_host(self)"
(~urllib2-py2.4/line 191) in the general Request.__init__ 


Robert

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1453973&group_id=5470

From noreply at sourceforge.net  Mon Mar 20 05:07:54 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 19 Mar 2006 20:07:54 -0800
Subject: [ python-Bugs-1448060 ] gettext.py breaks on plural-forms header
	(PATCH)
Message-ID: <E1FLBgQ-0000mG-K7@sc8-sf-web6.sourceforge.net>

Bugs item #1448060, was opened at 2006-03-12 00:20
Message generated for change (Comment added) made by dsegan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448060&group_id=5470

Please note that this message 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: Danilo Segan (dsegan)
Assigned to: Nobody/Anonymous (nobody)
Summary: gettext.py breaks on plural-forms header (PATCH)

Initial Comment:
See http://bugzilla.gnome.org/show_bug.cgi?id=334256

The problem is a PO file like the following:

test.po:
msgid ""
msgstr ""
"Content-Type: text/plain; charset=UTF-8\n"
"Plural-Forms:  nplurals=2; plural=(n != 1);\n"
"#-#-#-#-#  plo.po (PACKAGE VERSION)  #-#-#-#-#\n"

(these kinds of entries are sometimes inserted by
msgmerge, so they're somewhat common)

Any Python program trying to access this breaks:

$ python test.py
Traceback (most recent call last):
  File "test.py", line 7, in ?
    gt = gettext.GNUTranslations(file)
  File "/usr/lib/python2.4/gettext.py", line 177, in
__init__
    self._parse(fp)
  File "/usr/lib/python2.4/gettext.py", line 300, in _parse
    v = v.split(';')
AttributeError: 'list' object has no attribute 'split'


test.py is simple:
#!/usr/bin/env python
import gettext
file = open("test.mo", "rb")
if file:
    gt = gettext.GNUTranslations(file)


The problem is the corner-case: plural-forms precedes
this kind of comment, so "v" is split (v=v.split(";")).
In the next instance, lastk is "plural-forms", yet the
entry doesn't contain ":", so it tries to set plural
forms to v.split(";") again, which fails since v is
already a list.

The attached simple patch fixes this.


----------------------------------------------------------------------

>Comment By: Danilo Segan (dsegan)
Date: 2006-03-20 05:07

Message:
Logged In: YES 
user_id=219596

Agreed on all points, except the "summary": multi-line
plural forms are actually supported and widely used.

Anyway, gettext.py should fail gracefully in case of any
problem in the header, instead of running into exception.


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-03-19 12:51

Message:
Logged In: YES 
user_id=21627

Several things seem to be going on here:

1. gettext.py is clearly wrong; it shouldn't break on that file.

2. it is trying to process multi-line fields here. So the
patch is also wrong, as it just sets k and v to None.

3. I believe that the PO file presented is also wrong. I
believe the intention of the header is that it should have
the RFC822 style syntax, which doesn't allow for # comment
lines. The tool should use a syntax like

X-Filename: plo.po; package=PACKAGE; version=VERSION;

To summarize, I think the attempt to process multi-line
fields in the header is misguided, and gettext.py should
just fetch the first line of content-type and plural-forms.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448060&group_id=5470

From noreply at sourceforge.net  Mon Mar 20 06:11:58 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 19 Mar 2006 21:11:58 -0800
Subject: [ python-Bugs-1454227 ] makesetup fails to tolerate valid linker
	options
Message-ID: <E1FLCgQ-0006u4-9f@sc8-sf-web3.sourceforge.net>

Bugs item #1454227, was opened at 2006-03-20 00: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=1454227&group_id=5470

Please note that this 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: Jeff Blaine (jblaine)
Assigned to: Nobody/Anonymous (nobody)
Summary: makesetup fails to tolerate valid linker options

Initial Comment:
Using something like the following (in Setup.local)
will generate 'bad word' when makesetup runs:

-L/whatever -Xlinker -rpath /whatever

The '/whatever' after -rpath is the bad word, yet it is
completely valid syntax.

I have to edit makesetup to get it to tolerate library
directories and add them to $libs.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1454227&group_id=5470

From noreply at sourceforge.net  Mon Mar 20 08:47:31 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 19 Mar 2006 23:47:31 -0800
Subject: [ python-Bugs-1454285 ]
	test_parsedate_acceptable_to_time_functions+DST == :-(
Message-ID: <E1FLF6x-000625-Bu@sc8-sf-web6.sourceforge.net>

Bugs item #1454285, was opened at 2006-03-20 18: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=1454285&group_id=5470

Please note that this 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: Anthony Baxter (anthonybaxter)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: test_parsedate_acceptable_to_time_functions+DST == :-(

Initial Comment:
TZ=UTC ./python ./Lib/test/test_email.py works fine.
But "TZ=Australia/Melbourne ./python
./Lib/test/test_email.py" breaks - the date used in
this test (5 Feb 2003) is during daylight savings time
here. It's unclear to me what the test is trying to do,
so assigning to Barry to look at.

FAILED (failures=1)
Traceback (most recent call last):
  File "./Lib/test/test_email.py", line 13, in <module>
    test_main()
  File "./Lib/test/test_email.py", line 10, in test_main
    run_suite(suite())
  File
"/home/anthony/src/py/pytrunk/python/Lib/test/test_support.py",
line 285, in run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent
call last):
  File
"/home/anthony/src/py/pytrunk/python/Lib/email/test/test_email.py",
line 2127, in test_parsedate_acceptable_to_time_functions
    eq(time.localtime(t)[:6], timetup[:6])
AssertionError: (2003, 2, 5, 14, 47, 26) != (2003, 2,
5, 13, 47, 26)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1454285&group_id=5470

From noreply at sourceforge.net  Mon Mar 20 08:50:47 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 19 Mar 2006 23:50:47 -0800
Subject: [ python-Bugs-1448060 ] gettext.py breaks on plural-forms header
	(PATCH)
Message-ID: <E1FLFA7-0005vx-E5@sc8-sf-web1.sourceforge.net>

Bugs item #1448060, was opened at 2006-03-12 00:20
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448060&group_id=5470

Please note that this message 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: Danilo Segan (dsegan)
Assigned to: Nobody/Anonymous (nobody)
Summary: gettext.py breaks on plural-forms header (PATCH)

Initial Comment:
See http://bugzilla.gnome.org/show_bug.cgi?id=334256

The problem is a PO file like the following:

test.po:
msgid ""
msgstr ""
"Content-Type: text/plain; charset=UTF-8\n"
"Plural-Forms:  nplurals=2; plural=(n != 1);\n"
"#-#-#-#-#  plo.po (PACKAGE VERSION)  #-#-#-#-#\n"

(these kinds of entries are sometimes inserted by
msgmerge, so they're somewhat common)

Any Python program trying to access this breaks:

$ python test.py
Traceback (most recent call last):
  File "test.py", line 7, in ?
    gt = gettext.GNUTranslations(file)
  File "/usr/lib/python2.4/gettext.py", line 177, in
__init__
    self._parse(fp)
  File "/usr/lib/python2.4/gettext.py", line 300, in _parse
    v = v.split(';')
AttributeError: 'list' object has no attribute 'split'


test.py is simple:
#!/usr/bin/env python
import gettext
file = open("test.mo", "rb")
if file:
    gt = gettext.GNUTranslations(file)


The problem is the corner-case: plural-forms precedes
this kind of comment, so "v" is split (v=v.split(";")).
In the next instance, lastk is "plural-forms", yet the
entry doesn't contain ":", so it tries to set plural
forms to v.split(";") again, which fails since v is
already a list.

The attached simple patch fixes this.


----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-03-20 08:50

Message:
Logged In: YES 
user_id=21627

dsegan: Can you give a real-world (i.e. non-documentation)
example of a PO file with a multi-line plural formula?

----------------------------------------------------------------------

Comment By: Danilo Segan (dsegan)
Date: 2006-03-20 05:07

Message:
Logged In: YES 
user_id=219596

Agreed on all points, except the "summary": multi-line
plural forms are actually supported and widely used.

Anyway, gettext.py should fail gracefully in case of any
problem in the header, instead of running into exception.


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-03-19 12:51

Message:
Logged In: YES 
user_id=21627

Several things seem to be going on here:

1. gettext.py is clearly wrong; it shouldn't break on that file.

2. it is trying to process multi-line fields here. So the
patch is also wrong, as it just sets k and v to None.

3. I believe that the PO file presented is also wrong. I
believe the intention of the header is that it should have
the RFC822 style syntax, which doesn't allow for # comment
lines. The tool should use a syntax like

X-Filename: plo.po; package=PACKAGE; version=VERSION;

To summarize, I think the attempt to process multi-line
fields in the header is misguided, and gettext.py should
just fetch the first line of content-type and plural-forms.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448060&group_id=5470

From noreply at sourceforge.net  Mon Mar 20 09:02:06 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Mar 2006 00:02:06 -0800
Subject: [ python-Bugs-1391872 ] floating point literals don't work in non-US
	locale in 2.5
Message-ID: <E1FLFL4-0005p0-Gq@sc8-sf-web4-b.sourceforge.net>

Bugs item #1391872, was opened at 2005-12-28 03:01
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1391872&group_id=5470

Please note that this message 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: Fredrik Lundh (effbot)
Assigned to: Neal Norwitz (nnorwitz)
Summary: floating point literals don't work in non-US locale in 2.5

Initial Comment:
According to reports on comp.lang.python, the current 
SVN trunk fails to handle floating point literals if 
the locale is changed:

>>> import locale 
>>> locale.setlocale(locale.LC_ALL, '') 
'German_Germany.1252' 
>>> 3.141592 
3.0 

This works just fine in 2.4.2.

See the later portions of the thread "build 
curiosities of svn head (on WinXP)" for more details:

http://groups.google.com/group/comp.lang.python/browse_
frm/thread/226584dd47047bb6/e609cb1a0d47e98f

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-20 00:02

Message:
Logged In: YES 
user_id=33168

Keeping open as a reminder to fix the regression tests
running  on the PSF box every 12 hours.  Need to have a run
in a different locale.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-20 00:11

Message:
Logged In: YES 
user_id=1188172

Neal, you checked in a workaround in test__locale for eu_ES.
Can this be closed then?

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2006-01-18 23:12

Message:
Logged In: YES 
user_id=357491

This still fails on OS X 10.4.4:

AssertionError: using eval('3.14') failed for eu_ES

This is using rev. 42094.

----------------------------------------------------------------------

Comment By: Fredrik Lundh (effbot)
Date: 2005-12-29 12:37

Message:
Logged In: YES 
user_id=38376

Verified and fixed in SVN.  Assinging to Neal, in case
he wants to add an extra locale test pass to his build
robot.

----------------------------------------------------------------------

Comment By: Fredrik Lundh (effbot)
Date: 2005-12-29 10:52

Message:
Logged In: YES 
user_id=38376

Looks good to me.  I'll check this in shortly.

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2005-12-29 00:22

Message:
Logged In: YES 
user_id=55188

The new patch tests it along with other locale-dependent 
tests on test__locale. How about this?

----------------------------------------------------------------------

Comment By: Fredrik Lundh (effbot)
Date: 2005-12-28 11:00

Message:
Logged In: YES 
user_id=38376

I'm not sure you can make too many assumptions about
the locale in the test suite, but I'm pretty sure that
it would be a good idea to let your "build robot" run
the test suite twice; once with the standard C locale,
and once with a non-US locale (e.g. sv_SE.utf8 which
does include some odd characters, different date and
money formats, and a decimal comma).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-12-28 10:16

Message:
Logged In: YES 
user_id=33168

Wow, I thought for sure I broke it with my recent patch to remove support for 
hex floats.  But it looks like just an AST problem (which I can be blamed for 
too :-).  The patch looks fine, but could you add tests so this doesn't happen 
again.  Thanks!

I'll be back in a week and try to fix it then if no one gets back to it.

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2005-12-28 06:04

Message:
Logged In: YES 
user_id=55188

Okay. Here's a fix.

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2005-12-28 05:41

Message:
Logged In: YES 
user_id=55188

This looks like a bug introduced by AST import;
r39757 is okay but r39762 has such an error.

----------------------------------------------------------------------

Comment By: Fredrik Lundh (effbot)
Date: 2005-12-28 03:02

Message:
Logged In: YES 
user_id=38376

I just confirmed this on Unix:

$ export LANG=sv_SE.utf8
$ ./python
Python 2.5a0 (41806M, Dec 25 2005, 12:12:29)
[GCC 2.96 20000731 (Red Hat Linux 7.2 2.96-112.7.2)] on 
linux2
Type "help", "copyright", "credits" or "license" for more 
information.
>>> 3.14
3.1400000000000001
>>> import locale
>>> locale.setlocale(locale.LC_ALL, "")
'sv_SE.utf8'
>>> 3.14
3.0
>>>


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1391872&group_id=5470

From noreply at sourceforge.net  Mon Mar 20 09:04:36 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Mar 2006 00:04:36 -0800
Subject: [ python-Bugs-1367183 ] inspect.getdoc fails on objs that use
	property for __doc__
Message-ID: <E1FLFNU-0005xD-NT@sc8-sf-web4-b.sourceforge.net>

Bugs item #1367183, was opened at 2005-11-26 13:42
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1367183&group_id=5470

Please note that this message 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: Drew Perttula (drewp)
>Assigned to: Nobody/Anonymous (nobody)
Summary: inspect.getdoc fails on objs that use property for __doc__

Initial Comment:
inspect.getdoc has these lines:

     if not isinstance(doc, types.StringTypes):
         return None

which interfere with the case where __doc__ is some
other thing that has a good __str__. I wanted to make a
lazy __doc__ that did an expensive lookup of some
external documentation only when it was str()'d, but
since doc displayers often (correctly) use
inspect.getdoc, they were getting None.

I think the intention of the test in getdoc() is to
avoid trying string operations on a __doc__ that is
None. I think that a more lenient version would allow
me to do my fancy docstrings but still solve the
'__doc__ is None' problem. Please consider the
following patch:

if doc is None:
     return None
doc = str(doc)



----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-20 00:04

Message:
Logged In: YES 
user_id=33168

That code doesn't work if doc is unicode.  I'm not sure how
to achieve what you want.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-20 00:21

Message:
Logged In: YES 
user_id=1188172

I don't know. Neal, do you have an opinion about property
docstrings?

----------------------------------------------------------------------

Comment By: Collin Winter (collinwinter)
Date: 2006-02-01 03:35

Message:
Logged In: YES 
user_id=1344176

It's not a good idea to use properties for __doc__:

"""
>>> class Foo(object):
...    def _get(self):
...        return 'the docstring'
...    __doc__ = property(_get)
...
>>> print Foo().__doc__
the docstring
>>> print Foo.__doc__
<property object at 0xb7b3a234>
>>>
"""

In this light, I don't view inspect.getdoc's lack of support
for __doc__-as-property as a bug.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1367183&group_id=5470

From noreply at sourceforge.net  Mon Mar 20 09:05:41 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Mar 2006 00:05:41 -0800
Subject: [ python-Bugs-1227955 ] shelve/bsddb crash on db close
Message-ID: <E1FLFOX-0000q9-4p@sc8-sf-web3.sourceforge.net>

Bugs item #1227955, was opened at 2005-06-26 16:38
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1227955&group_id=5470

Please note that this 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: None
Priority: 5
Submitted By: Scott (ses4j)
Assigned to: Neal Norwitz (nnorwitz)
Summary: shelve/bsddb crash on db close

Initial Comment:
I have a 300 meg bsddb/hash db created and accessed by
shelve.  No problems when running python only.  But I
started accessing the code that opens it via a windows
DLL, opening and closing the DB on PROCESS_ATTACH and
DETACH.  All of a sudden, it would crash in the bsddb
module on closing/del'ing the db.  

Found a workaround by opening the db with
shelve.BsddbShelf(..) instead of shelve.open(..) - then
it closed fine when the DLL unloaded, no crash.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-20 00:05

Message:
Logged In: YES 
user_id=33168

Assuming this is fixed since there was no response.  Closing.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-01-24 22:12

Message:
Logged In: YES 
user_id=33168

If we don't hear back within a month, we should close this
as probably fixed by the patch that was checked in.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-01-24 00:03

Message:
Logged In: YES 
user_id=33168

Perhaps this is related to bug 1413192?  Could you try the
patch there and see if it fixes this problem?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1227955&group_id=5470

From noreply at sourceforge.net  Mon Mar 20 09:28:55 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Mar 2006 00:28:55 -0800
Subject: [ python-Bugs-1115379 ] Built-in compile function with PEP 0263
	encoding bug
Message-ID: <E1FLFl1-000719-Py@sc8-sf-web5.sourceforge.net>

Bugs item #1115379, was opened at 2005-02-03 05:11
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115379&group_id=5470

Please note that this 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: 7
Submitted By: Christoph Zwerschke (cito)
>Assigned to: Martin v. L??wis (loewis)
Summary: Built-in compile function with PEP 0263 encoding bug

Initial Comment:
a = 'print "Hello, World"'
u = '# -*- coding: utf-8 -*-\n' + a

print compile(a, '<string>', 'exec') # ok
print compile(u, '<string>', 'exec') # ok
print compile(unicode(a), '<string>', 'exec') # ok
print compile(unicode(u), '<string>', 'exec') # error

# The last line gives a SystemError.
# Think this is a bug.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-20 00:28

Message:
Logged In: YES 
user_id=33168

Martin, the attached patches (2.4 and 2.5) fix the problem.
 However, it seems that the patches would violate the PEP
according to one of your notes.  I'm not sure about all the
details, but ISTM based on your comment that if (flags &&
flags->cf_flags & PyCF_SOURCE_IS_UTF8) and (TYPE(n) ==
encoding_decl) this is an error that should be returned?

I would like to get this fixed for 2.4.3, so we need to move
fast for it.  2.5 can wait and is trivial to fix once we
know what this is supposed to do.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 13:37

Message:
Logged In: YES 
user_id=849994

This even aborts the interpreter in 2.5 HEAD with a failing
assertion.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-09-27 22:48

Message:
Logged In: YES 
user_id=21627

If you load the files manually, why is it that you want to
decode them to Unicode before compile()ing them? Couldn't
you just pass the bytes you read from the file to compile()?

----------------------------------------------------------------------

Comment By: V?gv?lgyi Attila (wigy)
Date: 2005-09-27 21:29

Message:
Logged In: YES 
user_id=156682

If this special case is a feature, not a bug, than it breaks
some symmetry for sure.

If I run a script having utf-8 encoding from a file with

  python script.py

then it has to have an encoding declaration. Now if I would
like to load the same file manually, decode it to a unicode
object, I also have to remove the encoding declaration at
the beginning of the file before I can give it to the
compile() function.

What special advantage comes from the fact that the compiler
does not simply ignore encoding declaration nodes from
unicode objects? Does this error message catch some possible
errors or does it make the compiler code simpler?

----------------------------------------------------------------------

Comment By: V?gv?lgyi Attila (wigy)
Date: 2005-09-27 21:20

Message:
Logged In: YES 
user_id=156682

If this special case is a feature, not a bug, than it breaks
some symmetry for sure.

If I run a script having utf-8 encoding from a file with

  python script.py

then it has to have an encoding declaration. Now if I would
like to load the same file manually, decode it to a unicode
object, I also have to remove the encoding declaration at
the beginning of the file before I can give it to the
compile() function.

What special advantage comes from the fact that the compiler
does not simply ignore encoding declaration nodes from
unicode objects? Does this error message catch some possible
errors or does it make the compiler code simpler?

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-02-09 16:37

Message:
Logged In: YES 
user_id=21627

There is a bug somewhere, certainly. However, I believe it
is in PEP 263, which should point out that unicode strings
in compile are only legal if they do *not* contain an
encoding declaration, as such strings are implicitly encoded
as UTF-8.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115379&group_id=5470

From noreply at sourceforge.net  Mon Mar 20 10:03:26 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Mar 2006 01:03:26 -0800
Subject: [ python-Bugs-1115379 ] Built-in compile function with PEP 0263
	encoding bug
Message-ID: <E1FLGIQ-0004TY-MX@sc8-sf-web3.sourceforge.net>

Bugs item #1115379, was opened at 2005-02-03 14:11
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115379&group_id=5470

Please note that this 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: 7
Submitted By: Christoph Zwerschke (cito)
Assigned to: Martin v. L??wis (loewis)
Summary: Built-in compile function with PEP 0263 encoding bug

Initial Comment:
a = 'print "Hello, World"'
u = '# -*- coding: utf-8 -*-\n' + a

print compile(a, '<string>', 'exec') # ok
print compile(u, '<string>', 'exec') # ok
print compile(unicode(a), '<string>', 'exec') # ok
print compile(unicode(u), '<string>', 'exec') # error

# The last line gives a SystemError.
# Think this is a bug.

----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-03-20 10:03

Message:
Logged In: YES 
user_id=21627

I still wonder why anybody would want to do that, so I don't
see it as a big problem that it gives an error in 2.4: it
*should* give an error, although not the one it currently gives.

It seems that wigy would expect that the encoding
declaration is ignored, whereas you (nnorwitz) are
suggesting that the UTF-8 default should be ignored. In the
face of ambiguity, refuse the temptation to guess.

So I still think it should give a SyntaxError instead. I'll
attach an alternative patch.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-20 09:28

Message:
Logged In: YES 
user_id=33168

Martin, the attached patches (2.4 and 2.5) fix the problem.
 However, it seems that the patches would violate the PEP
according to one of your notes.  I'm not sure about all the
details, but ISTM based on your comment that if (flags &&
flags->cf_flags & PyCF_SOURCE_IS_UTF8) and (TYPE(n) ==
encoding_decl) this is an error that should be returned?

I would like to get this fixed for 2.4.3, so we need to move
fast for it.  2.5 can wait and is trivial to fix once we
know what this is supposed to do.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 22:37

Message:
Logged In: YES 
user_id=849994

This even aborts the interpreter in 2.5 HEAD with a failing
assertion.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-09-28 07:48

Message:
Logged In: YES 
user_id=21627

If you load the files manually, why is it that you want to
decode them to Unicode before compile()ing them? Couldn't
you just pass the bytes you read from the file to compile()?

----------------------------------------------------------------------

Comment By: V?gv?lgyi Attila (wigy)
Date: 2005-09-28 06:29

Message:
Logged In: YES 
user_id=156682

If this special case is a feature, not a bug, than it breaks
some symmetry for sure.

If I run a script having utf-8 encoding from a file with

  python script.py

then it has to have an encoding declaration. Now if I would
like to load the same file manually, decode it to a unicode
object, I also have to remove the encoding declaration at
the beginning of the file before I can give it to the
compile() function.

What special advantage comes from the fact that the compiler
does not simply ignore encoding declaration nodes from
unicode objects? Does this error message catch some possible
errors or does it make the compiler code simpler?

----------------------------------------------------------------------

Comment By: V?gv?lgyi Attila (wigy)
Date: 2005-09-28 06:20

Message:
Logged In: YES 
user_id=156682

If this special case is a feature, not a bug, than it breaks
some symmetry for sure.

If I run a script having utf-8 encoding from a file with

  python script.py

then it has to have an encoding declaration. Now if I would
like to load the same file manually, decode it to a unicode
object, I also have to remove the encoding declaration at
the beginning of the file before I can give it to the
compile() function.

What special advantage comes from the fact that the compiler
does not simply ignore encoding declaration nodes from
unicode objects? Does this error message catch some possible
errors or does it make the compiler code simpler?

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-02-10 01:37

Message:
Logged In: YES 
user_id=21627

There is a bug somewhere, certainly. However, I believe it
is in PEP 263, which should point out that unicode strings
in compile are only legal if they do *not* contain an
encoding declaration, as such strings are implicitly encoded
as UTF-8.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115379&group_id=5470

From noreply at sourceforge.net  Mon Mar 20 10:24:58 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Mar 2006 01:24:58 -0800
Subject: [ python-Feature Requests-1454344 ] Make more out of 'as' : general
	ad-hoc right-assignment
Message-ID: <E1FLGdG-0002aU-Bi@sc8-sf-web4-b.sourceforge.net>

Feature Requests item #1454344, was opened at 2006-03-20 10:24
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1454344&group_id=5470

Please note that this message 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: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: Make more out of 'as' :  general ad-hoc right-assignment

Initial Comment:
"with EXPR as VAR" introduces 'as' as keyword.
Occupying a new 2-letter kw, Python could maybe make
more out of this:

* it was often asked for transitive assignments to
speed up the interrupted style of typing in Python

* yet transitive left-assignments = += *= ... would
indeed be an impact on pythonic discipline, create bad
readable syntax, which can easyly be confused with ==
etc inside of Expressions. It would be not intuitive,
with what value we are computing. Think e.g. of ugly
things like:
> a = ( 1+ (b.=2/x) ) 


Now trying a right-hand-assignment method using 'as'
everywhere:

> with open(x) as f:
>    f.write(s)

> if re.search(x,s) as m:
>    print m.group(1)
> elif re.search(y,s) as m:
>    print m.group(1)

> while (x+1 as x) not in l:
>    do()

> a = ( 1+ ( 2/x as b ) ), 2+b, 3+b 
> 

> print 'comment number', (id+1 as id)


* I cannot see any uglyness in this kind of
right-hand-assignment. Its intuitive 'english', speeds
up typing tremendously, the computed thing on left side
is still that, what is in the focus of reading.
And maybe most important: it supports a natural
evolutionary style of thinking: First you think about
what you want compute in expressions, then you can
store aside usefull stuff to somewhere happily.

* 'as'-evolution with extra operator is not too
tempting and clearly separated from the main =
'planning' doctrin

* The operator priority of 'as' right-assignments
should be higher than that of left-assignments and be
next before brackets and commas. Execution order from
left to right - that resolves as expected :

> a += b as c
> l=[ 1 as one, one+1 as two, {key as mykey:3 as three} ]
> d=dict(var1=pi/2 as pi_2, )

The later 'as' would of course set pi_2 in caller's
context.

A transitive 'as' would be more important than having
'is' for the same as '=='. In fact, if "with .. as .."
is possible, but "if .. as .." not, this would appear
as broken syntax design to python newcomers.

Robert


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1454344&group_id=5470

From noreply at sourceforge.net  Mon Mar 20 10:43:44 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Mar 2006 01:43:44 -0800
Subject: [ python-Feature Requests-1454364 ] Python space syntax & pythonic
	long lambda's
Message-ID: <E1FLGvQ-0006n1-L5@sc8-sf-web2.sourceforge.net>

Feature Requests item #1454364, was opened at 2006-03-20 10:43
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=1454364&group_id=5470

Please note that this 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: Open
Resolution: None
Priority: 5
Submitted By: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python space syntax & pythonic long lambda's

Initial Comment:
(see also c.l.p
http://groups.google.de/group/comp.lang.python/browse_frm/thread/fc2df1723f499eb7/f7e9b2ac5a6b5f16
)

After I had often nasty bugs because of mixup with the
global statement, my home made
"_global=sys.modules[__name__]" method (see also c.l.p
http://groups.google.de/group/comp.lang.python/browse_frm/thread/fc2df1723f499eb7/f7e9b2ac5a6b5f16
) prevents effectively such errors from my experience.
And code is better readable.

Despite maybe similar suggestions have already been
disregard, I put for discussion this version of
(compatible) extended space syntax for: better atomic
python expressions, improved readability, new key
capabilites for inter-frame/"block" access and
functional programming support:

See attached .txt document.

Robert


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1454364&group_id=5470

From noreply at sourceforge.net  Mon Mar 20 13:08:14 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Mar 2006 04:08:14 -0800
Subject: [ python-Feature Requests-1449496 ] Python should use 3GB Address
	Space on Windows
Message-ID: <E1FLJBG-0004EN-Ig@sc8-sf-web5.sourceforge.net>

Feature Requests item #1449496, was opened at 2006-03-14 12:04
Message generated for change (Comment added) made by gfe
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1449496&group_id=5470

Please note that this 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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin Gfeller (gfe)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python should use 3GB Address Space on Windows

Initial Comment:
Python runs fine using a 3GB address space on 32bit 
Windows.

To take advantage of this feature, Python should be 
linked using the /LARGEADDRESSAWARE flag of the 
linker. 

For details, please refer to:

http://msdn.microsoft.com/library/en-
us/memory/base/4gt_ram_tuning.asp

As most Windows users just use pre-built executables, 
this would be a worthwhile change. 

Best regards,
Martin Gfeller



----------------------------------------------------------------------

>Comment By: Martin Gfeller (gfe)
Date: 2006-03-20 13:08

Message:
Logged In: YES 
user_id=884167

Tim, the /LARGEADDRESSAWARE flag just specifies whether 
python.exe is enabled for #GB addresses, i.e. doesn't use 
dubious pointer manipulations that make it fail with a 3GB 
address space. 

It does not cause Windows to provide the 3GB address space, 
nor to reduce cache and pool size - that is controlled 
separately by the /3GB boot switch (and various registry 
settings for finer control of cache and pool sizes).

In other words, it is an enabling declaration, not a 
control parameter. 

Josiah, I don't compile on Windows, hence cannot provide a 
patch. What I did is applying the flag to the executable by 
using editbin.exe. 

Brgds, Martin

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-03-18 03:38

Message:
Logged In: YES 
user_id=31435

MS also says "However, the file cache, paged pool, and
non-paged pool are smaller, which can adversely affect
applications with heavy networking or I/O", so the rationale
for making this change is clear as mud.  That is, it's not a
pure win: some apps win at the expense of others.

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-03-18 01:38

Message:
Logged In: YES 
user_id=341410

Microsoft claims that the switch does not negatively affect
users on systems without large amounts of memory, and the
extra gig of memory on platforms which could use it would be
nice.

Can you offer a patch?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1449496&group_id=5470

From noreply at sourceforge.net  Mon Mar 20 13:17:04 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Mar 2006 04:17:04 -0800
Subject: [ python-Feature Requests-1453341 ] sys.setatomicexecution - for
	critical sections
Message-ID: <E1FLJJo-00065u-FG@sc8-sf-web1.sourceforge.net>

Feature Requests item #1453341, was opened at 2006-03-18 20:52
Message generated for change (Comment added) made by gfe
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1453341&group_id=5470

Please note that this message 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: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.setatomicexecution -  for critical sections

Initial Comment:
In order to maintain threaded code uncomplicated (VHL)
and in order to avoid massive use of locks, when
introducing few critical non-atomic sections, it should
be possible to put out that practical hammer ..

    try:
        last_ci=sys.setcheckinterval(sys.maxint)
        critical_function()  # now runs atomically
    finally:
        sys.setcheckinterval(last_ci)
    #(sys.setcheckinterval assumed to return the last
value)


..by an official function/class (in sys or thread):


Maybe:
======

atomic = sys.setatomicexecution(mode)
try:
    print "Executing critical section"
finally:
    sys.setatomicexecution(atomic)

there should be different modes/levels for blocking :

* 0=None
* 1=block only python execution in other threads
* 2=block signals
* 4/5/7/15=block threads at OS level (if OS supports)
* 8=(reserved: block future sub-/stackless switching
inside current thread..)

see:
http://groups.google.de/group/comp.lang.python/browse_frm/thread/bf5461507803975e/3bd7dfa9422a1200

compare:
http://www.stackless.com/wiki/Tasklets#critical-sections

---

Also Python could define officially its time atoms
beyond CPU atoms in the docs (That also defines the VHL
usability of the language).

Thus thinks like single-element changes ...

obj.var=x  , d[key]=x , l.append(x) .pop()

should be guaranteed to work atomic/correct FOR EVER. 

l[slice],  d.keys() .items(), .. questionable? 
If not guaranteed for the future, offer duplicates for
speed critical key building blocks like: 
l.slice_atomic(slice), d.keys_atomic() ,...  in order
to make code compatible for the future. 

---

Extra fun for blowing up python libs for poeple who
don't want to learn that try..finally all the time:

copy/deepcopy/dump maybe could be enriched by
copy_atomic , deepcopy_atomic, dump_atomic - or just
RuntimeError tolerant versions,   deepcopy_save  (no
use of .iterxxx)



----------------------------------------------------------------------

Comment By: Martin Gfeller (gfe)
Date: 2006-03-20 13:17

Message:
Logged In: YES 
user_id=884167

- sys.setcheckinterval(sys.maxint) does not prevent 
  thread switching when doing IO, does it? There is
  no way that I know of to prevent thread switching
  in this situation.

- When calling back into Python from C Code, there is
  no way to tell Python not to relinquish the GIL; such
  an option could be useful for some C code, because
  the GIL provides a "global critical section". 

Martin


----------------------------------------------------------------------

Comment By: kxroberto (kxroberto)
Date: 2006-03-18 22:54

Message:
Logged In: YES 
user_id=972995

or:

>>> atomic = sys.acquireatomicexecution(mode)
>>> try: 
... 	print 'critical section'
... finally:
... 	atomic.release()

>>> with sys.acquireatomicexecution(mode):
...     print 'critical section'



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1453341&group_id=5470

From noreply at sourceforge.net  Mon Mar 20 16:24:53 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Mar 2006 07:24:53 -0800
Subject: [ python-Feature Requests-1453341 ] sys.setatomicexecution - for
	critical sections
Message-ID: <E1FLMFZ-0000UJ-JW@sc8-sf-web4-b.sourceforge.net>

Feature Requests item #1453341, was opened at 2006-03-18 20:52
Message generated for change (Comment added) made by kxroberto
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1453341&group_id=5470

Please note that this message 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: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.setatomicexecution -  for critical sections

Initial Comment:
In order to maintain threaded code uncomplicated (VHL)
and in order to avoid massive use of locks, when
introducing few critical non-atomic sections, it should
be possible to put out that practical hammer ..

    try:
        last_ci=sys.setcheckinterval(sys.maxint)
        critical_function()  # now runs atomically
    finally:
        sys.setcheckinterval(last_ci)
    #(sys.setcheckinterval assumed to return the last
value)


..by an official function/class (in sys or thread):


Maybe:
======

atomic = sys.setatomicexecution(mode)
try:
    print "Executing critical section"
finally:
    sys.setatomicexecution(atomic)

there should be different modes/levels for blocking :

* 0=None
* 1=block only python execution in other threads
* 2=block signals
* 4/5/7/15=block threads at OS level (if OS supports)
* 8=(reserved: block future sub-/stackless switching
inside current thread..)

see:
http://groups.google.de/group/comp.lang.python/browse_frm/thread/bf5461507803975e/3bd7dfa9422a1200

compare:
http://www.stackless.com/wiki/Tasklets#critical-sections

---

Also Python could define officially its time atoms
beyond CPU atoms in the docs (That also defines the VHL
usability of the language).

Thus thinks like single-element changes ...

obj.var=x  , d[key]=x , l.append(x) .pop()

should be guaranteed to work atomic/correct FOR EVER. 

l[slice],  d.keys() .items(), .. questionable? 
If not guaranteed for the future, offer duplicates for
speed critical key building blocks like: 
l.slice_atomic(slice), d.keys_atomic() ,...  in order
to make code compatible for the future. 

---

Extra fun for blowing up python libs for poeple who
don't want to learn that try..finally all the time:

copy/deepcopy/dump maybe could be enriched by
copy_atomic , deepcopy_atomic, dump_atomic - or just
RuntimeError tolerant versions,   deepcopy_save  (no
use of .iterxxx)



----------------------------------------------------------------------

>Comment By: kxroberto (kxroberto)
Date: 2006-03-20 16:24

Message:
Logged In: YES 
user_id=972995

thus the GIL could simply have a harder state 2 : "locked
hard for PyEval_AcquireThread/PyEval_AcquireLock/.." ?

Only PyEval_RestoreThread gets the lock again after
PyEval_SaveThread.

Robert




----------------------------------------------------------------------

Comment By: Martin Gfeller (gfe)
Date: 2006-03-20 13:17

Message:
Logged In: YES 
user_id=884167

- sys.setcheckinterval(sys.maxint) does not prevent 
  thread switching when doing IO, does it? There is
  no way that I know of to prevent thread switching
  in this situation.

- When calling back into Python from C Code, there is
  no way to tell Python not to relinquish the GIL; such
  an option could be useful for some C code, because
  the GIL provides a "global critical section". 

Martin


----------------------------------------------------------------------

Comment By: kxroberto (kxroberto)
Date: 2006-03-18 22:54

Message:
Logged In: YES 
user_id=972995

or:

>>> atomic = sys.acquireatomicexecution(mode)
>>> try: 
... 	print 'critical section'
... finally:
... 	atomic.release()

>>> with sys.acquireatomicexecution(mode):
...     print 'critical section'



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1453341&group_id=5470

From noreply at sourceforge.net  Mon Mar 20 16:28:34 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Mar 2006 07:28:34 -0800
Subject: [ python-Feature Requests-1453341 ] sys.setatomicexecution - for
	critical sections
Message-ID: <E1FLMJ8-0000kT-B1@sc8-sf-web4-b.sourceforge.net>

Feature Requests item #1453341, was opened at 2006-03-18 20:52
Message generated for change (Comment added) made by kxroberto
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1453341&group_id=5470

Please note that this message 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: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.setatomicexecution -  for critical sections

Initial Comment:
In order to maintain threaded code uncomplicated (VHL)
and in order to avoid massive use of locks, when
introducing few critical non-atomic sections, it should
be possible to put out that practical hammer ..

    try:
        last_ci=sys.setcheckinterval(sys.maxint)
        critical_function()  # now runs atomically
    finally:
        sys.setcheckinterval(last_ci)
    #(sys.setcheckinterval assumed to return the last
value)


..by an official function/class (in sys or thread):


Maybe:
======

atomic = sys.setatomicexecution(mode)
try:
    print "Executing critical section"
finally:
    sys.setatomicexecution(atomic)

there should be different modes/levels for blocking :

* 0=None
* 1=block only python execution in other threads
* 2=block signals
* 4/5/7/15=block threads at OS level (if OS supports)
* 8=(reserved: block future sub-/stackless switching
inside current thread..)

see:
http://groups.google.de/group/comp.lang.python/browse_frm/thread/bf5461507803975e/3bd7dfa9422a1200

compare:
http://www.stackless.com/wiki/Tasklets#critical-sections

---

Also Python could define officially its time atoms
beyond CPU atoms in the docs (That also defines the VHL
usability of the language).

Thus thinks like single-element changes ...

obj.var=x  , d[key]=x , l.append(x) .pop()

should be guaranteed to work atomic/correct FOR EVER. 

l[slice],  d.keys() .items(), .. questionable? 
If not guaranteed for the future, offer duplicates for
speed critical key building blocks like: 
l.slice_atomic(slice), d.keys_atomic() ,...  in order
to make code compatible for the future. 

---

Extra fun for blowing up python libs for poeple who
don't want to learn that try..finally all the time:

copy/deepcopy/dump maybe could be enriched by
copy_atomic , deepcopy_atomic, dump_atomic - or just
RuntimeError tolerant versions,   deepcopy_save  (no
use of .iterxxx)



----------------------------------------------------------------------

>Comment By: kxroberto (kxroberto)
Date: 2006-03-20 16:28

Message:
Logged In: YES 
user_id=972995

... only PyEval_RestoreThread with the harder execution
level in its tstate

----------------------------------------------------------------------

Comment By: kxroberto (kxroberto)
Date: 2006-03-20 16:24

Message:
Logged In: YES 
user_id=972995

thus the GIL could simply have a harder state 2 : "locked
hard for PyEval_AcquireThread/PyEval_AcquireLock/.." ?

Only PyEval_RestoreThread gets the lock again after
PyEval_SaveThread.

Robert




----------------------------------------------------------------------

Comment By: Martin Gfeller (gfe)
Date: 2006-03-20 13:17

Message:
Logged In: YES 
user_id=884167

- sys.setcheckinterval(sys.maxint) does not prevent 
  thread switching when doing IO, does it? There is
  no way that I know of to prevent thread switching
  in this situation.

- When calling back into Python from C Code, there is
  no way to tell Python not to relinquish the GIL; such
  an option could be useful for some C code, because
  the GIL provides a "global critical section". 

Martin


----------------------------------------------------------------------

Comment By: kxroberto (kxroberto)
Date: 2006-03-18 22:54

Message:
Logged In: YES 
user_id=972995

or:

>>> atomic = sys.acquireatomicexecution(mode)
>>> try: 
... 	print 'critical section'
... finally:
... 	atomic.release()

>>> with sys.acquireatomicexecution(mode):
...     print 'critical section'



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1453341&group_id=5470

From noreply at sourceforge.net  Mon Mar 20 18:41:50 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Mar 2006 09:41:50 -0800
Subject: [ python-Bugs-1436428 ] urllib has trouble with Windows filenames
Message-ID: <E1FLOO6-00029x-QI@sc8-sf-web6.sourceforge.net>

Bugs item #1436428, was opened at 2006-02-22 06:03
Message generated for change (Comment added) made by bobince
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436428&group_id=5470

Please note that this message 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: Donovan Eastman (dpeastman)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib has trouble with Windows filenames

Initial Comment:
When you pass urllib the name of a local file including
a Windows drive letter (e.g. 'C:\dir\My File.txt')
URLopener.open() incorrectly interprets the drive
letter as the scheme of a URL.  Of course, given that
there is no scheme 'C', this fails.

I have solved this in my own code by putting the
following test before calling urllib.urlopen():

if url[1] == ':' and url[0].isalpha():
    url = 'file:' + url

Although this works fine in my particular case, it
seems like urllib should just simply "do the right
thing" without having to worry about it.  Therefore I
propose that urllib should automatically assume that
any URL that begins with a single alpha followed by a
colon is a local file.

The only potential downside would be that it would
preclude the use of single letter scheme names.  I did
a little research on this.  RFC 3986 suggests, but does
not explicitly state that scheme names must be more
than one character.
(http://www.gbiv.com/protocols/uri/rfc/rfc3986.html#scheme)
.  That said, there are no currently recognized single
letter scheme names
(http://www.iana.org/assignments/uri-schemes.html) and
it seems very unlikely that there every would be.

I would gladly write the code for this myself -- but I
suspect that it would take someone longer to review and
integrate my changes than it would to just write the code.

Thanks,
Donovan


----------------------------------------------------------------------

Comment By: Andrew Clover (bobince)
Date: 2006-03-20 17:41

Message:
Logged In: YES 
user_id=311085

Filepaths aren't URIs and attempting to hide the difference
in the backend is doomed to fail (as it did for SAX).

Throw filenames with colons in, network paths, Mac paths and
RISC OS paths into the mix, and you've got a situation where
it is all but impossible to handle correctly.

In any case, the docs *don't* say you can pass in a filepath:

  If the URL does not have a scheme identifier, or if
  it has file: as its scheme identifier, this opens a
  local file

This means the string you pass in is unequivocally a URL
*not* a pathname... just that you can leave the scheme
prefix off for file: URLs. Effectively this is a relative URL.

r'C:\spam' is *not* a valid way to refer to a local file
using a relative URL. Pass it through pathname2url and
you'll get '///C|/spam', which is okay; 'C|/spam' and
'/C|span' will also work.

Even on Unix, a filepath won't always work when passed to
urlopen. Filenames can have percent signs in, which have to
be encoded in URLs, for example. Always use pathname2url or
you're going to trip up.

(Suggest setting status INVALID, possible clarification to
docs to warn against passing a filepath to urlopen?)


----------------------------------------------------------------------

Comment By: Donovan Eastman (dpeastman)
Date: 2006-03-14 02:32

Message:
Logged In: YES 
user_id=757799

OK - Here's my suggested fix:
This can be fixed with a single if statement (and a comment
to explain it to confused unix programmers).

In splittype(), right after the line that reads: 
scheme = match.group(1)
add the following:
#ignore single char schemes to avoid confusion with win32
drive letters
if len(scheme) > 1:

...and indent the next line.

Alternatively, the if statement could read:
if len(scheme) > 1 or sys.platform != 'win32':
...which would allow single letter scheme names on
non-Windows systems.  I would argue that it is better to be
consistent and have it work the same way on all OS's.

----------------------------------------------------------------------

Comment By: Donovan Eastman (dpeastman)
Date: 2006-03-14 01:56

Message:
Logged In: YES 
user_id=757799

Reasons why urllib should open local files:
1) This allows you to write code that handles local files
and Internet files equally well -- without having to do any
special magic of your own.
2) The docs all say that it should.

I believe this would work just fine under Unix. In
URLopener.open() it looks for the protocol prefix and if it
can't find one, it assumes that it is a local file.

The problem on Windows is that you have these pesky drive
letters.  The form 'C:\location' ends up looking a lot like
the form 'http://location'.  Therefore it looks for a
protocol called 'c' -- which obviously isn't going to work.

----------------------------------------------------------------------

Comment By: Koen van de Sande (shadowmorpher)
Date: 2006-03-13 19:19

Message:
Logged In: YES 
user_id=270334

Why should the URL lib module support opening of local 
files? It already does so through the file: protocol prefix, 
and do not see why it should support automatic detection of 
Windows filenames. AFAIK it does not do automatic detection 
of Unix filenames (one could recognize it from /home/
something), so why would Windows work differently?

I'm not an expert or anything, so I might be wrong.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436428&group_id=5470

From noreply at sourceforge.net  Mon Mar 20 20:33:50 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Mar 2006 11:33:50 -0800
Subject: [ python-Feature Requests-1437699 ] allow unicode arguments for
	robotparser.can_fetch
Message-ID: <E1FLQ8U-00085a-3J@sc8-sf-web4-b.sourceforge.net>

Feature Requests item #1437699, was opened at 2006-02-23 22:07
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1437699&group_id=5470

Please note that this 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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: osvenskan (osvenskan)
>Assigned to: Skip Montanaro (montanaro)
Summary: allow unicode arguments for robotparser.can_fetch

Initial Comment:
One-line summary: If the robotparser module encounters
a robots.txt file that contains non-ASCII characters
AND I pass a Unicode user agent string to can_fetch(),
that function crashes with a TypeError under Python
2.4. Under Python 2.3, the error is a UnicodeDecodeError. 

More detail:
When one calls can_fetch(MyUserAgent, url), the
robotparser module compares  the UserAgent to each user
agent described in the robots.txt file. If
isinstance(MyUserAgent, str) == True then the
comparison does not raise an error regardless of the
contents of robots.txt. However, if
isinstance(MyUserAgent, unicode) == True, then Python
implicitly tries to convert the contents of the
robots.txt file to Unicode before comparing it to
MyUserAgent. By default, Python assumes a US-ASCII
encoding when converting, so if the contents of
robots.txt aren't ASCII, the conversion fails. In other
words, this works:
MyRobotParser.can_fetch('foobot', url)
but this fails:
MyRobotParser.can_fetch(u'foobot', url)

I recreated this with Python 2.4.1 on FreeBSD 6 and
Python 2.3 under Darwin/OS X. I'll attach examples from
both. The URLs that I use in the attachments are from
my Web site and will remain live. They reference
robots.txt files which contain an umlaut-ed 'a' (0xe4
in iso-8859-1). They're served up using a special
.htaccess file that adds a Content-Type header which
correctly identifies the encoding used for each file.
Here's the contents of the .htaccess file:

AddCharset iso-8859-1 .iso8859-1
AddCharset utf-8 .utf8


A suggested solution:
AFAICT, the construction of robots.txt is still defined
by "a consensus on 30 June 1994 on the robots mailing
list" [http://www.robotstxt.org/wc/norobots.html] and a
1996 draft proposal
[http://www.robotstxt.org/wc/norobots-rfc.html] that
has never evolved into a formal standard. Neither of
these mention character sets or encodings which is no
surprise considering that they date back to the days
when the Internet was poor but happy and we considered
even ASCII a luxury and we were grateful to have it.
("ASCII? We used to dream of having ASCII. We only had
one bit, and it was a zero. We lived in a shoebox in
the middle of the road..." etc.) A backwards-compatible
yet forward-looking solution would be to have the
robotparser module respect the Content-Type header sent
with robots.txt. If no such header is present,
robotparser should try to decode it using iso-8859-1
per section 3.7.1 of the HTTP 1.1 spec
(http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7.1)
which says, 'When no explicit charset parameter is
provided by the sender, media subtypes of the "text"
type are defined to have a default charset value of
"ISO-8859-1" when received via HTTP. Data in character
sets other than "ISO-8859-1" or its subsets MUST be
labeled with an appropriate charset value.' Section
3.6.1 of the HTTP 1.0 spec says the same. Since
ISO-8859-1 is a superset of US-ASCII, robots.txt files
that are pure ASCII won't be affected by the change.






----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2006-03-20 20:33

Message:
Logged In: YES 
user_id=38388

Reassigning to Skip: I don't use robotparser.

Skip, perhaps you can have a look ? (Didn't you write the
robotparser ?)


----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-03-18 11:17

Message:
Logged In: YES 
user_id=849994

Turning into a Feature Request.

----------------------------------------------------------------------

Comment By: osvenskan (osvenskan)
Date: 2006-03-07 17:32

Message:
Logged In: YES 
user_id=1119995

Thanks for looking at this. I have some followup comments. 

The list at robotstxt.org is many years stale (note that
Google's bot is present only as Backrub which was still a
server at Stanford at the time:
http://www.robotstxt.org/wc/active/html/backrub.html) but
nevertheless AFAICT it is the most current bot list on the
Web. If you look carefully, the list *does* contain a
non-ASCII entry (#76 --easy to miss in that long list). That
Finnish bot is gone but it has left a legacy in the form of
many robots.txt files that were created by automated tools
based on the robotstxt.org list. Google helps us here:
http://www.google.com/search?q=allintext%3AH%C3%A4m%C3%A4h%C3%A4kki+disallow+filetype%3Atxt

And by Googling for some common non-ASCII words and letters
I can find more like this one (look at the end of the
alphabetical list):
http://paranormal.se/robots.txt

Robots.txt files that contain non-ASCII are few and far
between, it seems, but they're out there.

Which leads me to a nitpicky (but important!) point about
Unicode. As you point out, the spec doesn't mention Unicode;
it says nothing at all on the topic of encodings. My
argument is that just because the spec doesn't mention
encodings doesn't let us off the hook because the HTTP
1.0/1.1 specs are very clear that iso-8859-1, not US-ASCII,
is the default for text content delivered via HTTP. By my
interpretation, this means that the robots.txt examples
provided above are compliant with published specs, therefore
code that fails to interpret them does not comply. There's
no obvious need for robotparser to support full-blown
Unicode, just iso-8859-1. 

You might be interested in a replacement for this module
that I've implemented. It does everything that robotparser
does and also handles non-ASCII plus a few other things. It
is GPL; you're welcome to copy it in part or lock, stock and
barrel. So far I've only tested it "in the lab" but I've
done fairly extensive unit testing and I'll soon be testing
it on real-world data. The code and docs are here:
http://semanchuk.com/philip/boneyard/rerp/

Comments & feedback would be most welcome.



----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2006-03-06 04:01

Message:
Logged In: YES 
user_id=593130

To me, this is not a bug report but at best an RFE.  The 
reported behavior is what I would expect.  I read both 
module doc and the referenced web page and further links.  
The doc does not mention Unicode as allowed and the 300 
registered UserAgents at
http://www.robotstxt.org/wc/active/html/index.html
all have ascii names.

So I recomment closing this as a bug report but will give 
ML a chance to respond.  If switched instead to Feature 
Request, I would think it would need some 'in the wild' 
evidence of need.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1437699&group_id=5470

From noreply at sourceforge.net  Mon Mar 20 20:54:47 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Mar 2006 11:54:47 -0800
Subject: [ python-Bugs-1454855 ] Explanation of pow() in lib
Message-ID: <E1FLQSl-0004AK-He@sc8-sf-web3.sourceforge.net>

Bugs item #1454855, was opened at 2006-03-20 20:54
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1454855&group_id=5470

Please note that this 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: Not a Bug
Status: Open
Resolution: None
Priority: 5
Submitted By: Christoph Zwerschke (cito)
Assigned to: Nobody/Anonymous (nobody)
Summary: Explanation of pow() in lib

Initial Comment:
The Python Lib Reference explains the pow() function in
section 2.1 like that:

>>>
pow(  	x, y[, z])
    Return x to the power y; if z is present, return x
to the power y, modulo z (computed more efficiently
than pow(x, y) % z). The arguments must have numeric
types. With mixed operand types, the coercion rules for
binary arithmetic operators apply. For int and long int
operands, the result has the same type as the operands
(after coercion) unless the second argument is
negative; in that case, all arguments are converted to
float and a float result is delivered. For example,
10**2 returns 100, but 10**-2 returns 0.01.
<<<

The problem is here that the notation 10**2 is used in
the example without prior explanation that it is
equivalent to pow(10,2). A newbie reading the docs in
linear order may not know this here (many other
languages write x^y instead of x**y). The notation x**y
is only introduced later in section 2.3.4.

I recommend adding a short remark to this paragraph
explaining that instead of writing pow(x,y) you can
also write x**y.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1454855&group_id=5470

From noreply at sourceforge.net  Mon Mar 20 20:55:50 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Mar 2006 11:55:50 -0800
Subject: [ python-Bugs-1454855 ] Explanation of pow() in lib
Message-ID: <E1FLQTm-00013G-62@sc8-sf-web4-b.sourceforge.net>

Bugs item #1454855, was opened at 2006-03-20 20:54
Message generated for change (Settings changed) made by cito
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1454855&group_id=5470

Please note that this 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: Not a Bug
Status: Open
Resolution: None
>Priority: 2
Submitted By: Christoph Zwerschke (cito)
Assigned to: Nobody/Anonymous (nobody)
Summary: Explanation of pow() in lib

Initial Comment:
The Python Lib Reference explains the pow() function in
section 2.1 like that:

>>>
pow(  	x, y[, z])
    Return x to the power y; if z is present, return x
to the power y, modulo z (computed more efficiently
than pow(x, y) % z). The arguments must have numeric
types. With mixed operand types, the coercion rules for
binary arithmetic operators apply. For int and long int
operands, the result has the same type as the operands
(after coercion) unless the second argument is
negative; in that case, all arguments are converted to
float and a float result is delivered. For example,
10**2 returns 100, but 10**-2 returns 0.01.
<<<

The problem is here that the notation 10**2 is used in
the example without prior explanation that it is
equivalent to pow(10,2). A newbie reading the docs in
linear order may not know this here (many other
languages write x^y instead of x**y). The notation x**y
is only introduced later in section 2.3.4.

I recommend adding a short remark to this paragraph
explaining that instead of writing pow(x,y) you can
also write x**y.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1454855&group_id=5470

From noreply at sourceforge.net  Mon Mar 20 21:07:36 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Mar 2006 12:07:36 -0800
Subject: [ python-Bugs-1454855 ] Explanation of pow() in lib
Message-ID: <E1FLQfA-0002UV-JE@sc8-sf-web1.sourceforge.net>

Bugs item #1454855, was opened at 2006-03-20 14:54
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1454855&group_id=5470

Please note that this 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: Not a Bug
>Status: Closed
>Resolution: Works For Me
Priority: 2
Submitted By: Christoph Zwerschke (cito)
Assigned to: Nobody/Anonymous (nobody)
Summary: Explanation of pow() in lib

Initial Comment:
The Python Lib Reference explains the pow() function in
section 2.1 like that:

>>>
pow(  	x, y[, z])
    Return x to the power y; if z is present, return x
to the power y, modulo z (computed more efficiently
than pow(x, y) % z). The arguments must have numeric
types. With mixed operand types, the coercion rules for
binary arithmetic operators apply. For int and long int
operands, the result has the same type as the operands
(after coercion) unless the second argument is
negative; in that case, all arguments are converted to
float and a float result is delivered. For example,
10**2 returns 100, but 10**-2 returns 0.01.
<<<

The problem is here that the notation 10**2 is used in
the example without prior explanation that it is
equivalent to pow(10,2). A newbie reading the docs in
linear order may not know this here (many other
languages write x^y instead of x**y). The notation x**y
is only introduced later in section 2.3.4.

I recommend adding a short remark to this paragraph
explaining that instead of writing pow(x,y) you can
also write x**y.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2006-03-20 15:07

Message:
Logged In: YES 
user_id=80475

The Lib Reference is like an encylopaedia; it does not 
purport to avoid forward references and be read linearly 
start to finish.

Also, in this case the meaning is 100% clear from the 
context.  IOW, given a discussion about x raised to the y 
power and an expression "10**2 returns 100, but 10**-2 
returns 0.01", the meaning of the operator is self-evident.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1454855&group_id=5470

From noreply at sourceforge.net  Mon Mar 20 22:14:52 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Mar 2006 13:14:52 -0800
Subject: [ python-Bugs-1115379 ] Built-in compile function with PEP 0263
	encoding bug
Message-ID: <E1FLRiG-0006mC-6q@sc8-sf-web1.sourceforge.net>

Bugs item #1115379, was opened at 2005-02-03 05:11
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115379&group_id=5470

Please note that this 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: 7
Submitted By: Christoph Zwerschke (cito)
Assigned to: Martin v. L??wis (loewis)
Summary: Built-in compile function with PEP 0263 encoding bug

Initial Comment:
a = 'print "Hello, World"'
u = '# -*- coding: utf-8 -*-\n' + a

print compile(a, '<string>', 'exec') # ok
print compile(u, '<string>', 'exec') # ok
print compile(unicode(a), '<string>', 'exec') # ok
print compile(unicode(u), '<string>', 'exec') # error

# The last line gives a SystemError.
# Think this is a bug.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-20 13:14

Message:
Logged In: YES 
user_id=33168

Actually, I don't much care about the answer as long as it
isn't a core dump/assert or a SystemError.  I'm fine with a
syntax error.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-03-20 01:03

Message:
Logged In: YES 
user_id=21627

I still wonder why anybody would want to do that, so I don't
see it as a big problem that it gives an error in 2.4: it
*should* give an error, although not the one it currently gives.

It seems that wigy would expect that the encoding
declaration is ignored, whereas you (nnorwitz) are
suggesting that the UTF-8 default should be ignored. In the
face of ambiguity, refuse the temptation to guess.

So I still think it should give a SyntaxError instead. I'll
attach an alternative patch.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-20 00:28

Message:
Logged In: YES 
user_id=33168

Martin, the attached patches (2.4 and 2.5) fix the problem.
 However, it seems that the patches would violate the PEP
according to one of your notes.  I'm not sure about all the
details, but ISTM based on your comment that if (flags &&
flags->cf_flags & PyCF_SOURCE_IS_UTF8) and (TYPE(n) ==
encoding_decl) this is an error that should be returned?

I would like to get this fixed for 2.4.3, so we need to move
fast for it.  2.5 can wait and is trivial to fix once we
know what this is supposed to do.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 13:37

Message:
Logged In: YES 
user_id=849994

This even aborts the interpreter in 2.5 HEAD with a failing
assertion.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-09-27 22:48

Message:
Logged In: YES 
user_id=21627

If you load the files manually, why is it that you want to
decode them to Unicode before compile()ing them? Couldn't
you just pass the bytes you read from the file to compile()?

----------------------------------------------------------------------

Comment By: V?gv?lgyi Attila (wigy)
Date: 2005-09-27 21:29

Message:
Logged In: YES 
user_id=156682

If this special case is a feature, not a bug, than it breaks
some symmetry for sure.

If I run a script having utf-8 encoding from a file with

  python script.py

then it has to have an encoding declaration. Now if I would
like to load the same file manually, decode it to a unicode
object, I also have to remove the encoding declaration at
the beginning of the file before I can give it to the
compile() function.

What special advantage comes from the fact that the compiler
does not simply ignore encoding declaration nodes from
unicode objects? Does this error message catch some possible
errors or does it make the compiler code simpler?

----------------------------------------------------------------------

Comment By: V?gv?lgyi Attila (wigy)
Date: 2005-09-27 21:20

Message:
Logged In: YES 
user_id=156682

If this special case is a feature, not a bug, than it breaks
some symmetry for sure.

If I run a script having utf-8 encoding from a file with

  python script.py

then it has to have an encoding declaration. Now if I would
like to load the same file manually, decode it to a unicode
object, I also have to remove the encoding declaration at
the beginning of the file before I can give it to the
compile() function.

What special advantage comes from the fact that the compiler
does not simply ignore encoding declaration nodes from
unicode objects? Does this error message catch some possible
errors or does it make the compiler code simpler?

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-02-09 16:37

Message:
Logged In: YES 
user_id=21627

There is a bug somewhere, certainly. However, I believe it
is in PEP 263, which should point out that unicode strings
in compile are only legal if they do *not* contain an
encoding declaration, as such strings are implicitly encoded
as UTF-8.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115379&group_id=5470

From noreply at sourceforge.net  Mon Mar 20 22:22:33 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Mar 2006 13:22:33 -0800
Subject: [ python-Bugs-1433877 ] string parameter to ioctl not null terminated,
	includes fix
Message-ID: <E1FLRph-0006aL-Ob@sc8-sf-web4-b.sourceforge.net>

Bugs item #1433877, was opened at 2006-02-17 23:29
Message generated for change (Comment added) made by twouters
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433877&group_id=5470

Please note that this 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: 6
Submitted By: Quentin Barnes (qbarnes)
Assigned to: Thomas Wouters (twouters)
Summary: string parameter to ioctl not null terminated, includes fix

Initial Comment:
I ran across this problem in Python 2.3.3 and see it is
still there in 2.4.2.

When running the test_pty.py test case, I would get
intermittant failures depending on how the test was
invoked or the compiler flags used on Solaris. 
Trussing the interpreter while running the test revealed:
ioctl(4, I_PUSH, "ptem\xff^T^F^H")  Err#22 EINVAL

There was garbage on the end of the string when it
would fail.

I tracked the problem back to fcntl_ioctl() in
fcntlmodule.c.  The string was not being NULL
terminated, but relied on having zeroed gargage on the
stack to work.

I checked the source for 2.4.2 and noticed the same
problem.  Patch to fix the problem is attached.


----------------------------------------------------------------------

>Comment By: Thomas Wouters (twouters)
Date: 2006-03-20 22:22

Message:
Logged In: YES 
user_id=34209

Huh, I never even saw this patch, in spite of the high
priority and it being assigned to me. <insert comment about
SF bugtracker>

We didn't discuss it at PyCon (at least, I wasn't party to
the discussion) but I guess this patch doesn't really hurt,
and does fix actual problems. I'm wary of fudging
fcntl/ioctl too much; I'd _much_ rather try and come up with
a decent interface for Py3k, with mutable bytestrings and
all that, maybe some nice automatic argument-type-conversion
or higher-level interface for common features (like advisory
locks) -- and only keep 2.x's fcntl working as well as it does.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2006-02-20 21:52

Message:
Logged In: YES 
user_id=6380

mwh: Sorry about the docstring gripe -- I read the fcntl()
docstring which is right above the ioctl() implementation
and never realized that this particular C module places the
doc strings *after* the functions. (I think that's bad style
but there it is.)

I think the priority was set to 9 by Neal to get Thomas'
attention.

gbarnes: We'll decide this one at PyCon.

----------------------------------------------------------------------

Comment By: Quentin Barnes (qbarnes)
Date: 2006-02-20 19:00

Message:
Logged In: YES 
user_id=288734

I didn't write new code that causes this problem by calling
ioctl with a string that needed to be null terminated.  It
was already in Python code itself.  See Lib/pty.py for the
code.

I reworked the patch as discussed below and retested it.
All built-in tests passed.

I've attached it.  I hae no idea of Python coding
conventions or style.  Hopefully I didn't violate them
too badly.

(This was weird.  SF rejected the text above when I
submitted it, but it took the patch file.  The patch
file shows up as "nobody".  Resubmitting this text.)

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2006-02-20 11:54

Message:
Logged In: YES 
user_id=6656

Seeing as some of this is my code...

Guido, the ioctl docstring *does* mention mutate_arg.  I agree that the 
documentation should have been updated for 2.4 and 2.5... and the situation 
is a mess, yes, but one that I couldn't see a better way around when the 
feature was added (it was much discussed in the bug report at the time).

It certainly never occurred to me that you might need/want to pass a NULL 
terminated string to ioctl. 

I don't think this is a priority 9 report.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2006-02-20 06:04

Message:
Logged In: YES 
user_id=6380

Sorry for the confusion. I was in part responding to an
off-line discussion I had with Neal Norwitz, to which you
weren't a party. You can ignore my comments about safety and
crashing.

The difference in marshalling Python data to C data for
ioctl(), compared to the many other places where (indeed)
this problem has been solved before, is that almost
everywhere else, we *know* what the data is supposed to
mean.  C has many more data types than Python, and the
choice of how to convert a string, or an int, to C data
depends on what is expected by the receiver of the C data. 
Unfortunately for ioctl we don't know the required C data
type because it's defined by the kernel module that handles
the particular ioctl opcode.  Some of these (like the one
you apparently ran into when porting the pty code to
Solaris) require a null-terminated string; others (like the
classic tty ioctls) require a C structure, which in Python
can be created by using the struct module.  Both return
Python strings.

I tend to agree with your conclusion that we should extend
the buffer to 1025 bytes and not bother null-terminating
non-string data.  Would you like to attempt another patch?

----------------------------------------------------------------------

Comment By: Quentin Barnes (qbarnes)
Date: 2006-02-20 01:31

Message:
Logged In: YES 
user_id=288734

I've practically never used python.  I just found
this bug in the interpreter while porting the
tool to the current Solaris compiler release, so please
keep that in mind about my lack of python knowledge.
I also have no idea who's who as well in the python
world so forgive me if I've stepped on anyone's
toes.

I don't follow the remark about "making ioctl
'safe'".  I never said anything about making it
"safe".  It's about a bug.

I also never said anything about the interpreter
crashing.  The interpreter never crashed.  The
pty test just simply failed since the module
name passed to the OS's ioctl was corrupted.

Are you sure you responded to the right bug
report with these remarks?

Anyways...

This problem should be reduced to a classic
data marshaling problem between python data
space and C data space which should have already
been addressed in many contexts many times before
in the interpreter.  How are python strings
converted for use by C in similar situations?

This problem I encountered is either a bug in
the code that passed the string to the ioctl
service by not putting an explicit '\0' on the
end of the "ptem" string, or it is a bug in the
fcntlmodule.c which should have done it for it.
Which is it?

If a python code isn't expected to put a literal
null at the end of their string when passing to
a C service, then ioctl needs to be fixed similar
to the way in my patch.

As for null-terminating other raw data, I don't
see the point other than a defensive programming
practice.

The problem I ran across is limited to just
a data marshaling problem.  The patch only
touched the case when the type of data passed
to ioctl is known to be a string.

As for the buffer vs. documentation, the
buffer could be changed to 1025 for the string
case, or the documentation could be updated
to clarify that, unlike raw data, strings are
limited to 1023 to leave room for the
requisite null that conversion to a C string
requires.  I don't think anyone would care
either way as long as it is qualified.

Since python strings serve dual roles of being
both raw data and being just textual containers,
one can't assume that a string passed to ioctl
is always meant to be just a textual string.  Going
the 1025 route is probably a 'better' approach due to
python string's duality.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2006-02-19 21:03

Message:
Logged In: YES 
user_id=6380

One problem with ioctl() is that the required length of the
buffer is unknown unless you parse the operation code
argument in a very platform- (and probably even kernel- and
driver-) dependent way.  Whether null-terminating it makes
sense or not depends on the particular operation code.

I don't think the patch makes ioctl "safe", and I'm not sure
it even ought to be applied.  A quick code review reveals a
few more issues:

- the docstring doesn't explain the optional "mutate_flag"
argument (which BTW is a mess -- read the online docs -- why
are we changing the default to true?)

- the online docs ought to be updated for 2.4 and again for
2.5 -- they still speak of 2.4 in the future tense!  Also,
it's a bit strong to say this function is "identical" to
fcntl() -- "similar" sounds more like it.

- In the first branch of the function, this line:

    if (mutate_arg && (len < sizeof buf)) {

ought to test (len <= sizeof buf) to match the test earlier;
but probably better is to use

    if (mutate_arg && arg == buf) {

- If it's important to null-terminate the data in the buffer
when a string is passed in, shouldn't we null-terminate it
also when a writable buffer-interface object is passed in? 
If not in the latter case, why if a string is passed?  One
could argue that a string with an explicit \0 (visible to
Python code) at the end ought to be passed in if the
semantics of the op code requires a null-terminated argument
(which most ioctl op codes don't -- the typical argument is
a C struct).

- The proposed patch reduces the maximum buffer size to
1023, which violates the docs. (Yes the docs explicitly
mention 1024.)

- The best we can do seems to be: increase the buffer size
to 1025; null-pad it in all cases; change the code for
mutable buffers to test for sizeof buf - 1.  This still
leaves the case where the buffer isn't used because a
mutable buffer is passed that's longer than 1024.  Which
suggests that we can't completely fix this -- it will always
be possible to crash Python using this function by passing
an op code that encodes a buffer length > 1024 while passing
a shorter argument, so the internal buffer is used.  I guess
we could do the null-padding as long as we document it and
document that when a mutable buffer is passed we don't
guarantee it.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-18 08:14

Message:
Logged In: YES 
user_id=33168

Thomas, could this have caused the flakiness that you just
fixed with test_pty?  This patch seems correct to me and I
think it should be applied.  (If you want I can do that, but
I wanted you to see this first.)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433877&group_id=5470

From noreply at sourceforge.net  Mon Mar 20 22:26:19 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Mar 2006 13:26:19 -0800
Subject: [ python-Bugs-1454912 ] import email fails
Message-ID: <E1FLRtL-0007XG-C2@sc8-sf-web1.sourceforge.net>

Bugs item #1454912, was opened at 2006-03-20 22: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=1454912&group_id=5470

Please note that this 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: Sjoerd Mullender (sjoerd)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: import email fails

Initial Comment:
After Barry's merge of the email 4.0 package, importing
email fails with the message that mime cannot be
imported.  The reason seems to be that email/mime
should be added to LIBSUBDIRS in the top-level
Makefile.pre.in.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1454912&group_id=5470

From noreply at sourceforge.net  Mon Mar 20 23:23:04 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Mar 2006 14:23:04 -0800
Subject: [ python-Bugs-1454855 ] Explanation of pow() in lib
Message-ID: <E1FLSmG-0001eX-Kh@sc8-sf-web5.sourceforge.net>

Bugs item #1454855, was opened at 2006-03-20 20:54
Message generated for change (Comment added) made by cito
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1454855&group_id=5470

Please note that this 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: Not a Bug
Status: Closed
Resolution: Works For Me
Priority: 2
Submitted By: Christoph Zwerschke (cito)
Assigned to: Nobody/Anonymous (nobody)
Summary: Explanation of pow() in lib

Initial Comment:
The Python Lib Reference explains the pow() function in
section 2.1 like that:

>>>
pow(  	x, y[, z])
    Return x to the power y; if z is present, return x
to the power y, modulo z (computed more efficiently
than pow(x, y) % z). The arguments must have numeric
types. With mixed operand types, the coercion rules for
binary arithmetic operators apply. For int and long int
operands, the result has the same type as the operands
(after coercion) unless the second argument is
negative; in that case, all arguments are converted to
float and a float result is delivered. For example,
10**2 returns 100, but 10**-2 returns 0.01.
<<<

The problem is here that the notation 10**2 is used in
the example without prior explanation that it is
equivalent to pow(10,2). A newbie reading the docs in
linear order may not know this here (many other
languages write x^y instead of x**y). The notation x**y
is only introduced later in section 2.3.4.

I recommend adding a short remark to this paragraph
explaining that instead of writing pow(x,y) you can
also write x**y.

----------------------------------------------------------------------

>Comment By: Christoph Zwerschke (cito)
Date: 2006-03-20 23:23

Message:
Logged In: YES 
user_id=193957

I'm not sure about that. You are thinking too much from an
expert/insider point of view, not from a newbie/learner
point of view.

For newbies, this is not so clear. See for example:
http://groups.google.com/group/comp.lang.python/browse_frm/thread/c82eb3c3a6068b7d

Even if the reader understands what 10**2 is, it is still
not clear at this place whether this is a Python expression
or simply a mathematical notation, and whether pow(x,y)
behaves exactly like x**y or not.

I still think a short note like "Note that you can also
write x**y as an abbreviation for pow(x,y)." makes all of
this clear and may be a help or a hint for newbies and
non-mathematicians.

Your argument that the Lib reference is not meant to be read
like a novel is true, but the introduction says explicitely
that reading it as a novel *is* an option, and encourages
people to read at least chapter 2 which is actually one of
the core parts of the whole Python documentation. So I think
many newbies will read the Tutorial (where the equivalence
of x**y and pow(x,y) is not mentioned either) and then at
least chapter 2 from the Lib reference. And even if you take
it only as a reference and just read the explanation of
pow() it may be a good reminder that pow(x,y) is actually
the same as x**y.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-03-20 21:07

Message:
Logged In: YES 
user_id=80475

The Lib Reference is like an encylopaedia; it does not 
purport to avoid forward references and be read linearly 
start to finish.

Also, in this case the meaning is 100% clear from the 
context.  IOW, given a discussion about x raised to the y 
power and an expression "10**2 returns 100, but 10**-2 
returns 0.01", the meaning of the operator is self-evident.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1454855&group_id=5470

From noreply at sourceforge.net  Tue Mar 21 01:54:53 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Mar 2006 16:54:53 -0800
Subject: [ python-Feature Requests-1449496 ] Python should use 3GB Address
	Space on Windows
Message-ID: <E1FLV9B-0006VZ-8h@sc8-sf-web3.sourceforge.net>

Feature Requests item #1449496, was opened at 2006-03-14 06:04
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1449496&group_id=5470

Please note that this 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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin Gfeller (gfe)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python should use 3GB Address Space on Windows

Initial Comment:
Python runs fine using a 3GB address space on 32bit 
Windows.

To take advantage of this feature, Python should be 
linked using the /LARGEADDRESSAWARE flag of the 
linker. 

For details, please refer to:

http://msdn.microsoft.com/library/en-
us/memory/base/4gt_ram_tuning.asp

As most Windows users just use pre-built executables, 
this would be a worthwhile change. 

Best regards,
Martin Gfeller



----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-03-20 19:54

Message:
Logged In: YES 
user_id=31435

Thanks, Martin.  Raymond Chen notes that some C code can
fail when this is enabled:

http://blogs.msdn.com/oldnewthing/archive/2004/08/12/213468.aspx

I doubt that core Python's C has 2GB assumptions, but
extension modules might.  Provided that whoever cares enough
to write the patch (sorry, I don't) points to that info (in
the NEWS file would be good enough), this is fine by me.

----------------------------------------------------------------------

Comment By: Martin Gfeller (gfe)
Date: 2006-03-20 07:08

Message:
Logged In: YES 
user_id=884167

Tim, the /LARGEADDRESSAWARE flag just specifies whether 
python.exe is enabled for #GB addresses, i.e. doesn't use 
dubious pointer manipulations that make it fail with a 3GB 
address space. 

It does not cause Windows to provide the 3GB address space, 
nor to reduce cache and pool size - that is controlled 
separately by the /3GB boot switch (and various registry 
settings for finer control of cache and pool sizes).

In other words, it is an enabling declaration, not a 
control parameter. 

Josiah, I don't compile on Windows, hence cannot provide a 
patch. What I did is applying the flag to the executable by 
using editbin.exe. 

Brgds, Martin

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-03-17 21:38

Message:
Logged In: YES 
user_id=31435

MS also says "However, the file cache, paged pool, and
non-paged pool are smaller, which can adversely affect
applications with heavy networking or I/O", so the rationale
for making this change is clear as mud.  That is, it's not a
pure win: some apps win at the expense of others.

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-03-17 19:38

Message:
Logged In: YES 
user_id=341410

Microsoft claims that the switch does not negatively affect
users on systems without large amounts of memory, and the
extra gig of memory on platforms which could use it would be
nice.

Can you offer a patch?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1449496&group_id=5470

From noreply at sourceforge.net  Tue Mar 21 11:42:33 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 21 Mar 2006 02:42:33 -0800
Subject: [ python-Bugs-1454855 ] Explanation of pow() in lib
Message-ID: <E1FLeJt-0006xg-DB@sc8-sf-web1.sourceforge.net>

Bugs item #1454855, was opened at 2006-03-20 20:54
Message generated for change (Comment added) made by cito
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1454855&group_id=5470

Please note that this 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: Not a Bug
Status: Closed
Resolution: Works For Me
Priority: 2
Submitted By: Christoph Zwerschke (cito)
Assigned to: Nobody/Anonymous (nobody)
Summary: Explanation of pow() in lib

Initial Comment:
The Python Lib Reference explains the pow() function in
section 2.1 like that:

>>>
pow(  	x, y[, z])
    Return x to the power y; if z is present, return x
to the power y, modulo z (computed more efficiently
than pow(x, y) % z). The arguments must have numeric
types. With mixed operand types, the coercion rules for
binary arithmetic operators apply. For int and long int
operands, the result has the same type as the operands
(after coercion) unless the second argument is
negative; in that case, all arguments are converted to
float and a float result is delivered. For example,
10**2 returns 100, but 10**-2 returns 0.01.
<<<

The problem is here that the notation 10**2 is used in
the example without prior explanation that it is
equivalent to pow(10,2). A newbie reading the docs in
linear order may not know this here (many other
languages write x^y instead of x**y). The notation x**y
is only introduced later in section 2.3.4.

I recommend adding a short remark to this paragraph
explaining that instead of writing pow(x,y) you can
also write x**y.

----------------------------------------------------------------------

>Comment By: Christoph Zwerschke (cito)
Date: 2006-03-21 11:42

Message:
Logged In: YES 
user_id=193957

Now I understand why the Lib Reference suddenly uses the **
notation when it speaks about the pow() function: The
passage has been simply copied over to the Lib Reference
from section 5.4 of the Lang Reference about the ** operator.

By the way, this section 5.4 in the Lang reference mentions
the pow() function as well. So I think it would be only
consequent if the Lib reference about pow() reciprocates
that and refers to the power operator in turn.

Anyway, somebody has changed it in the SVN already; I think
it is now ok and hope you agree.

----------------------------------------------------------------------

Comment By: Christoph Zwerschke (cito)
Date: 2006-03-20 23:23

Message:
Logged In: YES 
user_id=193957

I'm not sure about that. You are thinking too much from an
expert/insider point of view, not from a newbie/learner
point of view.

For newbies, this is not so clear. See for example:
http://groups.google.com/group/comp.lang.python/browse_frm/thread/c82eb3c3a6068b7d

Even if the reader understands what 10**2 is, it is still
not clear at this place whether this is a Python expression
or simply a mathematical notation, and whether pow(x,y)
behaves exactly like x**y or not.

I still think a short note like "Note that you can also
write x**y as an abbreviation for pow(x,y)." makes all of
this clear and may be a help or a hint for newbies and
non-mathematicians.

Your argument that the Lib reference is not meant to be read
like a novel is true, but the introduction says explicitely
that reading it as a novel *is* an option, and encourages
people to read at least chapter 2 which is actually one of
the core parts of the whole Python documentation. So I think
many newbies will read the Tutorial (where the equivalence
of x**y and pow(x,y) is not mentioned either) and then at
least chapter 2 from the Lib reference. And even if you take
it only as a reference and just read the explanation of
pow() it may be a good reminder that pow(x,y) is actually
the same as x**y.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-03-20 21:07

Message:
Logged In: YES 
user_id=80475

The Lib Reference is like an encylopaedia; it does not 
purport to avoid forward references and be read linearly 
start to finish.

Also, in this case the meaning is 100% clear from the 
context.  IOW, given a discussion about x raised to the y 
power and an expression "10**2 returns 100, but 10**-2 
returns 0.01", the meaning of the operator is self-evident.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1454855&group_id=5470

From noreply at sourceforge.net  Tue Mar 21 14:08:45 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 21 Mar 2006 05:08:45 -0800
Subject: [ python-Bugs-1455357 ] Incompatible size for long (int) in Python
	Win and Linux?
Message-ID: <E1FLgbN-0006ks-Ji@sc8-sf-web5.sourceforge.net>

Bugs item #1455357, was opened at 2006-03-21 08: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=1455357&group_id=5470

Please note that this 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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Yanowitz (yanowitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incompatible size for long (int) in Python Win and Linux?

Initial Comment:
   There appears to be a problem with 
packing/unpacking long (and int) values when sending 
data from Windows to Linux.
   I am not sure if it is a bug or just due to 
incompatibleness. Normally we think of long as being 4 
bytes. However, on Linux, it might be 8 bytes (in 
Python).

Here are good results in Windows, packing and 
unpacking a long:
$ python
Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for 
more information.
>>> import struct
>>> p = struct.pack("L", 12345)
>>> p
'90\x00\x00'
>>> u = struct.unpack("L",p)
>>> u
(12345L,)

 However, on Linux, I get slightly different results:

Python 2.4.1 (#1, May 16 2005, 15:15:14)
[GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2
Type "help", "copyright", "credits" or "license" for 
more information>>> import struct
>>> p = struct.pack("L", 12345)
>>> p
'90\x00\x00\x00\x00\x00\x00'
>>> u = struct.unpack("L",p)
>>> u
(12345L,)
 

   This is annoying, because I want to be able to
send data from Windows to Linux (and vice-versa)
over a socket. I am new to Python, and the only
way I know of of doing that is by packing and
unpacking the data.
  
   Please email me m.yanowitz at kearfott.com if this
isn't a bug or there is a known work-around for
this problem.


Thanks in advance:
Michael Yanowitz



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1455357&group_id=5470

From noreply at sourceforge.net  Tue Mar 21 14:30:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 21 Mar 2006 05:30:23 -0800
Subject: [ python-Bugs-1455357 ] Incompatible size for long (int) in Python
	Win and Linux?
Message-ID: <E1FLgwJ-00089K-Cz@sc8-sf-web5.sourceforge.net>

Bugs item #1455357, was opened at 2006-03-21 22:08
Message generated for change (Settings changed) made by perky
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1455357&group_id=5470

Please note that this 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.4
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Michael Yanowitz (yanowitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incompatible size for long (int) in Python Win and Linux?

Initial Comment:
   There appears to be a problem with 
packing/unpacking long (and int) values when sending 
data from Windows to Linux.
   I am not sure if it is a bug or just due to 
incompatibleness. Normally we think of long as being 4 
bytes. However, on Linux, it might be 8 bytes (in 
Python).

Here are good results in Windows, packing and 
unpacking a long:
$ python
Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for 
more information.
>>> import struct
>>> p = struct.pack("L", 12345)
>>> p
'90\x00\x00'
>>> u = struct.unpack("L",p)
>>> u
(12345L,)

 However, on Linux, I get slightly different results:

Python 2.4.1 (#1, May 16 2005, 15:15:14)
[GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2
Type "help", "copyright", "credits" or "license" for 
more information>>> import struct
>>> p = struct.pack("L", 12345)
>>> p
'90\x00\x00\x00\x00\x00\x00'
>>> u = struct.unpack("L",p)
>>> u
(12345L,)
 

   This is annoying, because I want to be able to
send data from Windows to Linux (and vice-versa)
over a socket. I am new to Python, and the only
way I know of of doing that is by packing and
unpacking the data.
  
   Please email me m.yanowitz at kearfott.com if this
isn't a bug or there is a known work-around for
this problem.


Thanks in advance:
Michael Yanowitz



----------------------------------------------------------------------

>Comment By: Hye-Shik Chang (perky)
Date: 2006-03-21 22:30

Message:
Logged In: YES 
user_id=55188

In C, the size of long depends on platform ABI.  If you are
on a 64bit platform, long may be 8 bytes while you got 4
bytes in 32bit platforms.  It's not Python's problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1455357&group_id=5470

From noreply at sourceforge.net  Tue Mar 21 19:07:30 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 21 Mar 2006 10:07:30 -0800
Subject: [ python-Bugs-1455357 ] Incompatible size for long (int) in Python
	Win and Linux?
Message-ID: <E1FLlGU-0001pq-D3@sc8-sf-web4-b.sourceforge.net>

Bugs item #1455357, was opened at 2006-03-21 08:08
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1455357&group_id=5470

Please note that this 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.4
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Michael Yanowitz (yanowitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incompatible size for long (int) in Python Win and Linux?

Initial Comment:
   There appears to be a problem with 
packing/unpacking long (and int) values when sending 
data from Windows to Linux.
   I am not sure if it is a bug or just due to 
incompatibleness. Normally we think of long as being 4 
bytes. However, on Linux, it might be 8 bytes (in 
Python).

Here are good results in Windows, packing and 
unpacking a long:
$ python
Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for 
more information.
>>> import struct
>>> p = struct.pack("L", 12345)
>>> p
'90\x00\x00'
>>> u = struct.unpack("L",p)
>>> u
(12345L,)

 However, on Linux, I get slightly different results:

Python 2.4.1 (#1, May 16 2005, 15:15:14)
[GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2
Type "help", "copyright", "credits" or "license" for 
more information>>> import struct
>>> p = struct.pack("L", 12345)
>>> p
'90\x00\x00\x00\x00\x00\x00'
>>> u = struct.unpack("L",p)
>>> u
(12345L,)
 

   This is annoying, because I want to be able to
send data from Windows to Linux (and vice-versa)
over a socket. I am new to Python, and the only
way I know of of doing that is by packing and
unpacking the data.
  
   Please email me m.yanowitz at kearfott.com if this
isn't a bug or there is a known work-around for
this problem.


Thanks in advance:
Michael Yanowitz



----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-03-21 13:07

Message:
Logged In: YES 
user_id=31435

I agree with closing this report, but we should point out
that Python _does_ solve most of this problem:  don't use
"native mode" pack/unpack, use "standard mode" pack/unpack,
to transport values across architectures.  Read the `struct`
docs for details.  For example, struct.pack("!L", 12345)
uses 4-byte big-endian ("network") format regardless of the
platform it runs on.

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2006-03-21 08:30

Message:
Logged In: YES 
user_id=55188

In C, the size of long depends on platform ABI.  If you are
on a 64bit platform, long may be 8 bytes while you got 4
bytes in 32bit platforms.  It's not Python's problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1455357&group_id=5470

From noreply at sourceforge.net  Tue Mar 21 21:43:56 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 21 Mar 2006 12:43:56 -0800
Subject: [ python-Bugs-1455641 ] pyport.h freebsd inconsistent
Message-ID: <E1FLnhs-0006tT-VJ@sc8-sf-web2.sourceforge.net>

Bugs item #1455641, was opened at 2006-03-21 15:43
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=1455641&group_id=5470

Please note that this 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: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: pyport.h freebsd inconsistent

Initial Comment:
pyport.h redefines isalnum and friends 

#if __FreeBSD_version > 500039

but the comment just above says not to do so in 
FreeBSD 6 (which is now available).  Add an extra 
guard clause?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1455641&group_id=5470

From noreply at sourceforge.net  Tue Mar 21 22:36:08 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 21 Mar 2006 13:36:08 -0800
Subject: [ python-Bugs-1455676 ] Simplify use of Queues with consumer threads
Message-ID: <E1FLoWO-0006hi-P6@sc8-sf-web4-b.sourceforge.net>

Bugs item #1455676, was opened at 2006-03-21 16:36
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1455676&group_id=5470

Please note that this 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: Raymond Hettinger (rhettinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: Simplify use of Queues with consumer threads

Initial Comment:
When Queues are used to communicate between producer 
and consumer threads, there is often a need to 
determine when all of the enqueued tasks have been 
completed.

With this small patch, determining when all work is 
done is as simple as adding q.task_done() to each 
consumer thread and q.join() to the main thread.

Without the patch, the next best approach is to count 
the number of puts, create a second queue filled by 
the consumer when a task is done, and for the main 
thread to call successive blocking gets on the result 
queue until all of the puts have been accounted for:

    def worker(): 
        while 1: 
            task = tasks_in.get() 
            do_work(task) 
            tasks_out.put(None)

    tasks_in = Queue() 
    tasks_out = Queue() 
    for i in range(num_worker_threads): 
         Thread(target=worker).start()

    n = 0 
    for elem in source():
        n += 1
        tasks_in.put(elem) 

    # block until tasks are done 
    for i in range(n): 
        tasks_out.get()

That approach is not complicated but it does entail 
more lines of code and tracking some auxiliary data.
This becomes cumersome and error-prone when an app 
has multiple occurences of q.put() and q.get().

The patch essentially encapsulates this approach into 
two methods, making it effortless to use and easy to 
graft on to existing uses of Queue. So, the above 
code simplies to:

    def worker(): 
        while 1: 
            task = q.get() 
            do_work(task) 
            q.task_done() 

    q = Queue() 
    for i in range(num_worker_threads): 
         Thread(target=worker).start() 

    for elem in source():
        q.put(elem) 

    # block until tasks are done 
    q.join() 

The put counting is automatic, there is no need for a 
separate queue object, the code readably expresses 
its intent with clarity.  Also, it is easy to inpect 
for accuracy, each get() followed by a task_done().  
The ease of inspection remains even when there are 
multiple gets and puts scattered through the code (a 
situtation which would become complicated for the two 
Queue approach).

If accepted, will add docs with an example.

Besides being a fast, lean, elegant solution, the 
other reason to accept the patch is that the 
underlying problem appears again and again, requiring 
some measure to invention to solve it each time.  
There are a number of approaches but none as simple, 
fast, or as broadly applicable as having the queue 
itself track items loaded and items completed.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1455676&group_id=5470

From noreply at sourceforge.net  Tue Mar 21 23:27:28 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 21 Mar 2006 14:27:28 -0800
Subject: [ python-Bugs-1455676 ] Simplify using Queues with consumer threads
Message-ID: <E1FLpK4-0001Tn-VM@sc8-sf-web4-b.sourceforge.net>

Bugs item #1455676, was opened at 2006-03-21 16:36
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1455676&group_id=5470

Please note that this 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: Raymond Hettinger (rhettinger)
>Assigned to: Tim Peters (tim_one)
>Summary: Simplify using Queues with consumer threads

Initial Comment:
When Queues are used to communicate between producer 
and consumer threads, there is often a need to 
determine when all of the enqueued tasks have been 
completed.

With this small patch, determining when all work is 
done is as simple as adding q.task_done() to each 
consumer thread and q.join() to the main thread.

Without the patch, the next best approach is to count 
the number of puts, create a second queue filled by 
the consumer when a task is done, and for the main 
thread to call successive blocking gets on the result 
queue until all of the puts have been accounted for:

    def worker(): 
        while 1: 
            task = tasks_in.get() 
            do_work(task) 
            tasks_out.put(None)

    tasks_in = Queue() 
    tasks_out = Queue() 
    for i in range(num_worker_threads): 
         Thread(target=worker).start()

    n = 0 
    for elem in source():
        n += 1
        tasks_in.put(elem) 

    # block until tasks are done 
    for i in range(n): 
        tasks_out.get()

That approach is not complicated but it does entail 
more lines of code and tracking some auxiliary data.
This becomes cumersome and error-prone when an app 
has multiple occurences of q.put() and q.get().

The patch essentially encapsulates this approach into 
two methods, making it effortless to use and easy to 
graft on to existing uses of Queue. So, the above 
code simplies to:

    def worker(): 
        while 1: 
            task = q.get() 
            do_work(task) 
            q.task_done() 

    q = Queue() 
    for i in range(num_worker_threads): 
         Thread(target=worker).start() 

    for elem in source():
        q.put(elem) 

    # block until tasks are done 
    q.join() 

The put counting is automatic, there is no need for a 
separate queue object, the code readably expresses 
its intent with clarity.  Also, it is easy to inpect 
for accuracy, each get() followed by a task_done().  
The ease of inspection remains even when there are 
multiple gets and puts scattered through the code (a 
situtation which would become complicated for the two 
Queue approach).

If accepted, will add docs with an example.

Besides being a fast, lean, elegant solution, the 
other reason to accept the patch is that the 
underlying problem appears again and again, requiring 
some measure to invention to solve it each time.  
There are a number of approaches but none as simple, 
fast, or as broadly applicable as having the queue 
itself track items loaded and items completed.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2006-03-21 17:27

Message:
Logged In: YES 
user_id=80475

Tim, do you have a chance to look at this?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1455676&group_id=5470

From noreply at sourceforge.net  Wed Mar 22 00:28:29 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 21 Mar 2006 15:28:29 -0800
Subject: [ python-Bugs-1448060 ] gettext.py breaks on plural-forms header
	(PATCH)
Message-ID: <E1FLqH7-0000SO-Mo@sc8-sf-web2.sourceforge.net>

Bugs item #1448060, was opened at 2006-03-12 00:20
Message generated for change (Comment added) made by dsegan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448060&group_id=5470

Please note that this message 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: Danilo Segan (dsegan)
Assigned to: Nobody/Anonymous (nobody)
Summary: gettext.py breaks on plural-forms header (PATCH)

Initial Comment:
See http://bugzilla.gnome.org/show_bug.cgi?id=334256

The problem is a PO file like the following:

test.po:
msgid ""
msgstr ""
"Content-Type: text/plain; charset=UTF-8\n"
"Plural-Forms:  nplurals=2; plural=(n != 1);\n"
"#-#-#-#-#  plo.po (PACKAGE VERSION)  #-#-#-#-#\n"

(these kinds of entries are sometimes inserted by
msgmerge, so they're somewhat common)

Any Python program trying to access this breaks:

$ python test.py
Traceback (most recent call last):
  File "test.py", line 7, in ?
    gt = gettext.GNUTranslations(file)
  File "/usr/lib/python2.4/gettext.py", line 177, in
__init__
    self._parse(fp)
  File "/usr/lib/python2.4/gettext.py", line 300, in _parse
    v = v.split(';')
AttributeError: 'list' object has no attribute 'split'


test.py is simple:
#!/usr/bin/env python
import gettext
file = open("test.mo", "rb")
if file:
    gt = gettext.GNUTranslations(file)


The problem is the corner-case: plural-forms precedes
this kind of comment, so "v" is split (v=v.split(";")).
In the next instance, lastk is "plural-forms", yet the
entry doesn't contain ":", so it tries to set plural
forms to v.split(";") again, which fails since v is
already a list.

The attached simple patch fixes this.


----------------------------------------------------------------------

>Comment By: Danilo Segan (dsegan)
Date: 2006-03-22 00:28

Message:
Logged In: YES 
user_id=219596

No.  And based on what Bruno said, it's obviously not
supported (and since it's a GNU thingy, Bruno would probably
know best ;).

[btw, we need no plural forms in documentation at all, at
least not in static content translation; Yelp's
gnome-doc-utils stylesheets provide plural forms for where
they are appropriate]


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-03-20 08:50

Message:
Logged In: YES 
user_id=21627

dsegan: Can you give a real-world (i.e. non-documentation)
example of a PO file with a multi-line plural formula?

----------------------------------------------------------------------

Comment By: Danilo Segan (dsegan)
Date: 2006-03-20 05:07

Message:
Logged In: YES 
user_id=219596

Agreed on all points, except the "summary": multi-line
plural forms are actually supported and widely used.

Anyway, gettext.py should fail gracefully in case of any
problem in the header, instead of running into exception.


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-03-19 12:51

Message:
Logged In: YES 
user_id=21627

Several things seem to be going on here:

1. gettext.py is clearly wrong; it shouldn't break on that file.

2. it is trying to process multi-line fields here. So the
patch is also wrong, as it just sets k and v to None.

3. I believe that the PO file presented is also wrong. I
believe the intention of the header is that it should have
the RFC822 style syntax, which doesn't allow for # comment
lines. The tool should use a syntax like

X-Filename: plo.po; package=PACKAGE; version=VERSION;

To summarize, I think the attempt to process multi-line
fields in the header is misguided, and gettext.py should
just fetch the first line of content-type and plural-forms.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448060&group_id=5470

From noreply at sourceforge.net  Wed Mar 22 02:42:37 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 21 Mar 2006 17:42:37 -0800
Subject: [ python-Bugs-1455676 ] Simplify using Queues with consumer threads
Message-ID: <E1FLsMv-0006Vd-4u@sc8-sf-web6.sourceforge.net>

Bugs item #1455676, was opened at 2006-03-21 16:36
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1455676&group_id=5470

Please note that this 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: Raymond Hettinger (rhettinger)
Assigned to: Tim Peters (tim_one)
Summary: Simplify using Queues with consumer threads

Initial Comment:
When Queues are used to communicate between producer 
and consumer threads, there is often a need to 
determine when all of the enqueued tasks have been 
completed.

With this small patch, determining when all work is 
done is as simple as adding q.task_done() to each 
consumer thread and q.join() to the main thread.

Without the patch, the next best approach is to count 
the number of puts, create a second queue filled by 
the consumer when a task is done, and for the main 
thread to call successive blocking gets on the result 
queue until all of the puts have been accounted for:

    def worker(): 
        while 1: 
            task = tasks_in.get() 
            do_work(task) 
            tasks_out.put(None)

    tasks_in = Queue() 
    tasks_out = Queue() 
    for i in range(num_worker_threads): 
         Thread(target=worker).start()

    n = 0 
    for elem in source():
        n += 1
        tasks_in.put(elem) 

    # block until tasks are done 
    for i in range(n): 
        tasks_out.get()

That approach is not complicated but it does entail 
more lines of code and tracking some auxiliary data.
This becomes cumersome and error-prone when an app 
has multiple occurences of q.put() and q.get().

The patch essentially encapsulates this approach into 
two methods, making it effortless to use and easy to 
graft on to existing uses of Queue. So, the above 
code simplies to:

    def worker(): 
        while 1: 
            task = q.get() 
            do_work(task) 
            q.task_done() 

    q = Queue() 
    for i in range(num_worker_threads): 
         Thread(target=worker).start() 

    for elem in source():
        q.put(elem) 

    # block until tasks are done 
    q.join() 

The put counting is automatic, there is no need for a 
separate queue object, the code readably expresses 
its intent with clarity.  Also, it is easy to inpect 
for accuracy, each get() followed by a task_done().  
The ease of inspection remains even when there are 
multiple gets and puts scattered through the code (a 
situtation which would become complicated for the two 
Queue approach).

If accepted, will add docs with an example.

Besides being a fast, lean, elegant solution, the 
other reason to accept the patch is that the 
underlying problem appears again and again, requiring 
some measure to invention to solve it each time.  
There are a number of approaches but none as simple, 
fast, or as broadly applicable as having the queue 
itself track items loaded and items completed.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-03-21 20:42

Message:
Logged In: YES 
user_id=31435

Yup, I'll try to make time tomorrow (can't today). 
_Offhand_ it sounds like a nice addition to me.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-03-21 17:27

Message:
Logged In: YES 
user_id=80475

Tim, do you have a chance to look at this?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1455676&group_id=5470

From noreply at sourceforge.net  Wed Mar 22 07:02:08 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 21 Mar 2006 22:02:08 -0800
Subject: [ python-Bugs-1455676 ] Simplify using Queues with consumer threads
Message-ID: <E1FLwQ4-0004Ja-TA@sc8-sf-web5.sourceforge.net>

Bugs item #1455676, was opened at 2006-03-21 16:36
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1455676&group_id=5470

Please note that this 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: Raymond Hettinger (rhettinger)
Assigned to: Tim Peters (tim_one)
Summary: Simplify using Queues with consumer threads

Initial Comment:
When Queues are used to communicate between producer 
and consumer threads, there is often a need to 
determine when all of the enqueued tasks have been 
completed.

With this small patch, determining when all work is 
done is as simple as adding q.task_done() to each 
consumer thread and q.join() to the main thread.

Without the patch, the next best approach is to count 
the number of puts, create a second queue filled by 
the consumer when a task is done, and for the main 
thread to call successive blocking gets on the result 
queue until all of the puts have been accounted for:

    def worker(): 
        while 1: 
            task = tasks_in.get() 
            do_work(task) 
            tasks_out.put(None)

    tasks_in = Queue() 
    tasks_out = Queue() 
    for i in range(num_worker_threads): 
         Thread(target=worker).start()

    n = 0 
    for elem in source():
        n += 1
        tasks_in.put(elem) 

    # block until tasks are done 
    for i in range(n): 
        tasks_out.get()

That approach is not complicated but it does entail 
more lines of code and tracking some auxiliary data.
This becomes cumersome and error-prone when an app 
has multiple occurences of q.put() and q.get().

The patch essentially encapsulates this approach into 
two methods, making it effortless to use and easy to 
graft on to existing uses of Queue. So, the above 
code simplies to:

    def worker(): 
        while 1: 
            task = q.get() 
            do_work(task) 
            q.task_done() 

    q = Queue() 
    for i in range(num_worker_threads): 
         Thread(target=worker).start() 

    for elem in source():
        q.put(elem) 

    # block until tasks are done 
    q.join() 

The put counting is automatic, there is no need for a 
separate queue object, the code readably expresses 
its intent with clarity.  Also, it is easy to inpect 
for accuracy, each get() followed by a task_done().  
The ease of inspection remains even when there are 
multiple gets and puts scattered through the code (a 
situtation which would become complicated for the two 
Queue approach).

If accepted, will add docs with an example.

Besides being a fast, lean, elegant solution, the 
other reason to accept the patch is that the 
underlying problem appears again and again, requiring 
some measure to invention to solve it each time.  
There are a number of approaches but none as simple, 
fast, or as broadly applicable as having the queue 
itself track items loaded and items completed.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2006-03-22 01:02

Message:
Logged In: YES 
user_id=80475

Thanks.  There are two particular areas for extra 
attention.  

First, should the waiter acquire/release pairs be in a 
try/finally (iow, is there some behavior in notify() or 
release() that potentially needs to be trapped)?

Second, should the notify() in task_done() really be a 
notifyAll() (iow, does it make sense that multiple joins 
may be pending)?

Thanks again.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-03-21 20:42

Message:
Logged In: YES 
user_id=31435

Yup, I'll try to make time tomorrow (can't today). 
_Offhand_ it sounds like a nice addition to me.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-03-21 17:27

Message:
Logged In: YES 
user_id=80475

Tim, do you have a chance to look at this?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1455676&group_id=5470

From noreply at sourceforge.net  Wed Mar 22 08:14:07 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 21 Mar 2006 23:14:07 -0800
Subject: [ python-Bugs-1452697 ] broken string on mbcs
Message-ID: <E1FLxXj-0001rZ-U1@sc8-sf-web6.sourceforge.net>

Bugs item #1452697, was opened at 2006-03-18 05:07
Message generated for change (Comment added) made by ocean-city
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1452697&group_id=5470

Please note that this 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: Deleted
Resolution: None
Priority: 7
Submitted By: ocean-city (ocean-city)
Assigned to: M.-A. Lemburg (lemburg)
Summary: broken string on mbcs

Initial Comment:
Hello. I noticed unicode conversion from mbcs was
sometimes broken. This happened when I used
codecs.open("foo", "r", "mbcs") as iterator.

# It's OK if I use "shift_jis" or "cp932".

I'll attach the script and text file to reproduce the
problem. I'm using Win2000SP4(Japanese).

Thank you.

----------------------------------------------------------------------

>Comment By: ocean-city (ocean-city)
Date: 2006-03-22 16:14

Message:
Logged In: YES 
user_id=1200846

I'll move this to "Patches" tracker.

----------------------------------------------------------------------

Comment By: ocean-city (ocean-city)
Date: 2006-03-19 11:08

Message:
Logged In: YES 
user_id=1200846

I updated the patch. Compared to version1...

  * [bug] consumed should be 0 if the length of string is 0

  * [enhancement] use IsDBCSLeadByte to detect incomplete
    buffer termination instead of trying MultiByteToWideChar
    with MB_ERR_INVALID_CHARS. This could cause performance
    hit if string contains invalid chars in early part.


----------------------------------------------------------------------

Comment By: ocean-city (ocean-city)
Date: 2006-03-18 13:17

Message:
Logged In: YES 
user_id=1200846

Probably this patch will fix the problem. (for release24-maint)

Cause: MultiByteToWideChar returns non zero value for
incomplete multibyte character. (ex: if buffer terminates
with leading byte, MultiByteToWideChar returns 1 (not 0) for
it. It should return 0, otherwise result will be broken.

Solution: Set flag MB_ERR_INVALID_CHARS to avoid incorrect
handling of trailing incomplete multibyte part. If error
occurs, removes the trailing byte and tries again.

Caution: I have not tested this so intensibly.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1452697&group_id=5470

From noreply at sourceforge.net  Wed Mar 22 08:54:30 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 21 Mar 2006 23:54:30 -0800
Subject: [ python-Bugs-1455641 ] pyport.h freebsd inconsistent
Message-ID: <E1FLyAo-0006vB-LC@sc8-sf-web3.sourceforge.net>

Bugs item #1455641, was opened at 2006-03-21 20:43
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1455641&group_id=5470

Please note that this 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: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Jewett (jimjjewett)
>Assigned to: Hye-Shik Chang (perky)
Summary: pyport.h freebsd inconsistent

Initial Comment:
pyport.h redefines isalnum and friends 

#if __FreeBSD_version > 500039

but the comment just above says not to do so in 
FreeBSD 6 (which is now available).  Add an extra 
guard clause?


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-22 07:54

Message:
Logged In: YES 
user_id=849994

perky, you added that comment to pyport.h.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1455641&group_id=5470

From noreply at sourceforge.net  Wed Mar 22 09:55:13 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 22 Mar 2006 00:55:13 -0800
Subject: [ python-Bugs-1455641 ] pyport.h freebsd inconsistent
Message-ID: <E1FLz7Z-00028r-HN@sc8-sf-web2.sourceforge.net>

Bugs item #1455641, was opened at 2006-03-22 05:43
Message generated for change (Comment added) made by perky
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1455641&group_id=5470

Please note that this 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: Platform-specific
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Hye-Shik Chang (perky)
Summary: pyport.h freebsd inconsistent

Initial Comment:
pyport.h redefines isalnum and friends 

#if __FreeBSD_version > 500039

but the comment just above says not to do so in 
FreeBSD 6 (which is now available).  Add an extra 
guard clause?


----------------------------------------------------------------------

>Comment By: Hye-Shik Chang (perky)
Date: 2006-03-22 17:55

Message:
Logged In: YES 
user_id=55188

The workaround is still needed for FreeBSD 6 and 7 even.

>>> import locale
>>> locale.setlocale(locale.LC_ALL, 'de_DE.UTF-8')
'de_DE.UTF-8'
>>> import ctypes
>>> ctypes.cdll.c.isspace(0xa0)
1

This should be 0 to get a correct result from str.split.
I fixed the comment in r43219.  Thank you!

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-03-22 16:54

Message:
Logged In: YES 
user_id=849994

perky, you added that comment to pyport.h.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1455641&group_id=5470

From noreply at sourceforge.net  Wed Mar 22 13:00:51 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 22 Mar 2006 04:00:51 -0800
Subject: [ python-Bugs-1451503 ] os.startfile() still doesn't work with
	Unicode filenames
Message-ID: <E1FM21D-0002x8-4j@sc8-sf-web6.sourceforge.net>

Bugs item #1451503, was opened at 2006-03-16 18:08
Message generated for change (Comment added) made by roee88
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451503&group_id=5470

Please note that this 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: roee88 (roee88)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.startfile() still doesn't work with Unicode filenames

Initial Comment:
>From 2.4.2 changelog:
>>>Bug #1007046: os.startfile() did not accept 
unicode strings encoded in the file system encoding. 

If the filename is unicode type and the encoding 
isn't the default system encoding, all "unknown" (to 
system encoding) characters are replaced by "?".
This is causing the os.startfile() to fail with 
WindowsError: [Errno2] 
Because the filename doesn't really have the "?".

----------------------------------------------------------------------

>Comment By: roee88 (roee88)
Date: 2006-03-22 12:00

Message:
Logged In: YES 
user_id=1111143

Sorry, but I can't work on a patch.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-03-19 10:49

Message:
Logged In: YES 
user_id=21627

Well, it does work on Unicode strings when all characters
from the string come from the system code page; this got
implemented in response to bug #1007046.

To fix this, the implementation should use ShellExecuteW
(except on Win9x). Would you like to work on a patch?

As a work-around, change your system code page so your file
names are supported.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451503&group_id=5470

From noreply at sourceforge.net  Wed Mar 22 14:56:36 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 22 Mar 2006 05:56:36 -0800
Subject: [ python-Bugs-1115379 ] Built-in compile function with PEP 0263
	encoding bug
Message-ID: <E1FM3pE-0001zq-Rc@sc8-sf-web6.sourceforge.net>

Bugs item #1115379, was opened at 2005-02-03 14:11
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115379&group_id=5470

Please note that this 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: 7
Submitted By: Christoph Zwerschke (cito)
Assigned to: Martin v. L??wis (loewis)
Summary: Built-in compile function with PEP 0263 encoding bug

Initial Comment:
a = 'print "Hello, World"'
u = '# -*- coding: utf-8 -*-\n' + a

print compile(a, '<string>', 'exec') # ok
print compile(u, '<string>', 'exec') # ok
print compile(unicode(a), '<string>', 'exec') # ok
print compile(unicode(u), '<string>', 'exec') # error

# The last line gives a SystemError.
# Think this is a bug.

----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-03-22 14:56

Message:
Logged In: YES 
user_id=21627

I've committed this patch (along with a test case) as 43227
into the 2.4 branch; the trunk still needs fixing.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-20 22:14

Message:
Logged In: YES 
user_id=33168

Actually, I don't much care about the answer as long as it
isn't a core dump/assert or a SystemError.  I'm fine with a
syntax error.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-03-20 10:03

Message:
Logged In: YES 
user_id=21627

I still wonder why anybody would want to do that, so I don't
see it as a big problem that it gives an error in 2.4: it
*should* give an error, although not the one it currently gives.

It seems that wigy would expect that the encoding
declaration is ignored, whereas you (nnorwitz) are
suggesting that the UTF-8 default should be ignored. In the
face of ambiguity, refuse the temptation to guess.

So I still think it should give a SyntaxError instead. I'll
attach an alternative patch.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-20 09:28

Message:
Logged In: YES 
user_id=33168

Martin, the attached patches (2.4 and 2.5) fix the problem.
 However, it seems that the patches would violate the PEP
according to one of your notes.  I'm not sure about all the
details, but ISTM based on your comment that if (flags &&
flags->cf_flags & PyCF_SOURCE_IS_UTF8) and (TYPE(n) ==
encoding_decl) this is an error that should be returned?

I would like to get this fixed for 2.4.3, so we need to move
fast for it.  2.5 can wait and is trivial to fix once we
know what this is supposed to do.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 22:37

Message:
Logged In: YES 
user_id=849994

This even aborts the interpreter in 2.5 HEAD with a failing
assertion.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-09-28 07:48

Message:
Logged In: YES 
user_id=21627

If you load the files manually, why is it that you want to
decode them to Unicode before compile()ing them? Couldn't
you just pass the bytes you read from the file to compile()?

----------------------------------------------------------------------

Comment By: V?gv?lgyi Attila (wigy)
Date: 2005-09-28 06:29

Message:
Logged In: YES 
user_id=156682

If this special case is a feature, not a bug, than it breaks
some symmetry for sure.

If I run a script having utf-8 encoding from a file with

  python script.py

then it has to have an encoding declaration. Now if I would
like to load the same file manually, decode it to a unicode
object, I also have to remove the encoding declaration at
the beginning of the file before I can give it to the
compile() function.

What special advantage comes from the fact that the compiler
does not simply ignore encoding declaration nodes from
unicode objects? Does this error message catch some possible
errors or does it make the compiler code simpler?

----------------------------------------------------------------------

Comment By: V?gv?lgyi Attila (wigy)
Date: 2005-09-28 06:20

Message:
Logged In: YES 
user_id=156682

If this special case is a feature, not a bug, than it breaks
some symmetry for sure.

If I run a script having utf-8 encoding from a file with

  python script.py

then it has to have an encoding declaration. Now if I would
like to load the same file manually, decode it to a unicode
object, I also have to remove the encoding declaration at
the beginning of the file before I can give it to the
compile() function.

What special advantage comes from the fact that the compiler
does not simply ignore encoding declaration nodes from
unicode objects? Does this error message catch some possible
errors or does it make the compiler code simpler?

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-02-10 01:37

Message:
Logged In: YES 
user_id=21627

There is a bug somewhere, certainly. However, I believe it
is in PEP 263, which should point out that unicode strings
in compile are only legal if they do *not* contain an
encoding declaration, as such strings are implicitly encoded
as UTF-8.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115379&group_id=5470

From noreply at sourceforge.net  Wed Mar 22 15:58:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 22 Mar 2006 06:58:05 -0800
Subject: [ python-Bugs-1454912 ] import email fails
Message-ID: <E1FM4mj-0006Fi-Vz@sc8-sf-web1.sourceforge.net>

Bugs item #1454912, was opened at 2006-03-20 16:26
Message generated for change (Comment added) made by bwarsaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1454912&group_id=5470

Please note that this 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: 5
Submitted By: Sjoerd Mullender (sjoerd)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: import email fails

Initial Comment:
After Barry's merge of the email 4.0 package, importing
email fails with the message that mime cannot be
imported.  The reason seems to be that email/mime
should be added to LIBSUBDIRS in the top-level
Makefile.pre.in.

----------------------------------------------------------------------

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2006-03-22 09:58

Message:
Logged In: YES 
user_id=12800

r43228

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1454912&group_id=5470

From noreply at sourceforge.net  Wed Mar 22 16:12:53 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 22 Mar 2006 07:12:53 -0800
Subject: [ python-Bugs-1436532 ] length of unicode string changes print
	behaviour
Message-ID: <E1FM513-0005Xg-VS@sc8-sf-web5.sourceforge.net>

Bugs item #1436532, was opened at 2006-02-22 10:45
Message generated for change (Comment added) made by hover_boy
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: Kurt B. Kaiser (kbk)
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: 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  Wed Mar 22 16:21:29 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 22 Mar 2006 07:21:29 -0800
Subject: [ python-Bugs-1436532 ] length of unicode string changes print
	behaviour
Message-ID: <E1FM59N-0007p4-W2@sc8-sf-web1.sourceforge.net>

Bugs item #1436532, was opened at 2006-02-22 10:45
Message generated for change (Comment added) made by hover_boy
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: Kurt B. Kaiser (kbk)
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: 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  Wed Mar 22 16:47:18 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 22 Mar 2006 07:47:18 -0800
Subject: [ python-Bugs-1456209 ] dictobject.c:dictresize() vulnerability
Message-ID: <E1FM5YM-0007w1-OJ@sc8-sf-web4-b.sourceforge.net>

Bugs item #1456209, was opened at 2006-03-22 15: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=1456209&group_id=5470

Please note that this message 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: Nobody/Anonymous (nobody)
Summary: dictobject.c:dictresize() vulnerability

Initial Comment:
We thought we squashed the last of the
modify-the-dict-from-a-custom-eq kind of bugs long ago. 
Too bad.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456209&group_id=5470

From noreply at sourceforge.net  Wed Mar 22 17:32:27 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 22 Mar 2006 08:32:27 -0800
Subject: [ python-Bugs-1456209 ] dictobject.c:dictresize() vulnerability
Message-ID: <E1FM6G3-0006Cu-FL@sc8-sf-web2.sourceforge.net>

Bugs item #1456209, was opened at 2006-03-22 15:47
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456209&group_id=5470

Please note that this message 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: Nobody/Anonymous (nobody)
Summary: dictobject.c:dictresize() vulnerability

Initial Comment:
We thought we squashed the last of the
modify-the-dict-from-a-custom-eq kind of bugs long ago. 
Too bad.

----------------------------------------------------------------------

>Comment By: Armin Rigo (arigo)
Date: 2006-03-22 16:32

Message:
Logged In: YES 
user_id=4771

The cause of the bug is that if oldtable == mp->ma_smalltable
then pure Python code can mangle with mp->ma_smalltable while
it is being walked on.  A simple fix would be to always make
a copy of the oldtable if it is mp->ma_smalltable (not only
if oldtable == newtable).

Attached a more efficient fix, which should also make dict
resizing somehow faster.  It requires yet another version
of the lookup algorithm, though.  It's a very simple version
that assumes that all items are different and the dict
contains no dummy entries.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456209&group_id=5470

From noreply at sourceforge.net  Wed Mar 22 18:34:26 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 22 Mar 2006 09:34:26 -0800
Subject: [ python-Bugs-1456280 ] Traceback error when compiling Regex 
Message-ID: <E1FM7E2-0007Ve-IC@sc8-sf-web6.sourceforge.net>

Bugs item #1456280, was opened at 2006-03-22 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=1456280&group_id=5470

Please note that this 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: Wolfgang Grafen (grafen)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: Traceback error when compiling Regex 

Initial Comment:
Traceback error when compiling the following regular
expression. Error discovered with Python 2.4.2.
Used pre from python2.3 to check the validity of
re_fmt. With pre it works fine.

Question:
I submitted a sre error report before and I warned
to take off pre from the library. It is of advantage
to be able to check a failing re with pre. Personally
I feel sre has still too many bugs to completely
substitute pre.

Regards

Wolfgang Grafen

======================================================

chios scalar 582 % ./fmtscalar.py
Traceback (most recent call last):
  File "./fmtscalar.py", line 21, in ?
    re_fmt = re.compile(
  File "/user/freepool/local/lib/python2.3/sre.py",
line 179, in compile
    return _compile(pattern, flags)
  File "/user/freepool/local/lib/python2.3/sre.py",
line 230, in _compile
    raise error, v # invalid expression
sre_constants.error: nothing to repeat

---- cut here ----
#!/usr/bin/env python2.3
# -*- coding: Latin-1 -*-

import sre as re

re_fmt = re.compile(
                        "("
                            "%"
                            "(?P<precision>"
                                "\d+"
                                "(?:"
                                    "[.]"
                                    "\d+"
                                ")"
                            ")?"
                            "(?:"
                                "[(]"
                                "(?P<key>"
                                    "[^)]*"
                                ")?"
                                "[)]"
                            ")?"
                            "(?P<c>[a-z])"
                        ")"
                    )

a="%s"
b="aber%sxyz"
c="aber%3.1i"
c="aber%(quengel)s"

for i in a,b,c:
    m = re_fmt.findall(i)
    print i,m
---- cut here ---

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456280&group_id=5470

From noreply at sourceforge.net  Wed Mar 22 20:09:12 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 22 Mar 2006 11:09:12 -0800
Subject: [ python-Bugs-1284316 ] Win32: Security problem with default
	installation directory
Message-ID: <E1FM8hk-0005d9-MS@sc8-sf-web1.sourceforge.net>

Bugs item #1284316, was opened at 2005-09-07 23:34
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1284316&group_id=5470

Please note that this 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: Platform-specific
Status: Open
Resolution: None
Priority: 7
Submitted By: Mika Eloranta (mel)
Assigned to: Martin v. L??wis (loewis)
Summary: Win32: Security problem with default installation directory

Initial Comment:
(Sorry, this is a bit long since the issue is not
entirely trivial.)

This problem only exists on Windows operating systems
installed on an NTFS file system. Confirmed on several
Windows 2000, XP and Windows 2003 Server systems. All
Python versions (at least 2.x) are affected.

The default installation target directory where Python
is installation on Windows is directly under the system
drive's root directory (e.g. "C:\python24"). The file
and directory permissions inherited by the
python24-directory from the root directory are not
secure enough for keeping application binaries.

Microsoft has, in their infinite wisdom, decided that
the root directory of the system drive should allow
regular (non-admin) users to create directories and
files there. This set of permissions is inherited by
the python directory when it is created in the default
location (i.e. "C:\python24" or whatever).

This "feature" allows a regular (non-admin) user to
perform a priviledge escalation attack for example in
the following manner:

1. Figure out the name of some DLL python (or some
extension .PYD) loads using LoadLibrary() without an
absolute path.

2. Copy a DLL with the same name into the
python-directory (this should not be allowed, but it
is!) containing some code the attacker wants to run
with escalated priviledges.

3. Wait until python is run by an admin in the same
machine or by the LocalSystem account.

How to view the problematic part of the ACL:
1. Right-click the "C:\python24" directory in Windows
Explorer
2. select Properties... -> Security -> Advanced
3. In the "Permissions" tab you will see an entry for
the "Users" group, it says "Special" in the
"Permissions" column
4. Select the above entry and click "Edit..."
5. Well hidden? I think so, too.

The fix:
The proper (default) location where application
binaries should be installed is under the "c:\program
files\" directory. This directory has properly set
permissions by default.

PS. The same problem exists in ActivePerl, Ruby and
many other tools.


----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-03-22 20:09

Message:
Logged In: YES 
user_id=21627

I completely disagree. It was wrong to give the system
default binary directory a name with a space in it, on a
system that doesn't provide command line argument vectors in
its standard API.

----------------------------------------------------------------------

Comment By: Mika Eloranta (mel)
Date: 2005-11-19 09:46

Message:
Logged In: YES 
user_id=109057

Wow, even easy_install.exe from setuptools fails if python
is installed under "c:\program files":

C:\temp>easy_install
C:\program: can't open file 'files\Python24\python.exe':
[Errno 2] No such file or directory

IMHO the root cause to all these problems is the wrong
default installation directory. If the installation
directory would conform to Windows guidelines, these kind of
problems would have been easily spotted by python library
developers.

    - Mika


----------------------------------------------------------------------

Comment By: Mika Eloranta (mel)
Date: 2005-11-15 12:39

Message:
Logged In: YES 
user_id=109057

Please consider these points as well:

* The "program files" directory has "sensible" ACLs set by
default (the defaults are different in different OS
versions). If you install your application under "program
files", you do not need to worry about the permissions.

* The installation directory can be added to the PATH
environment variable instead of typing it every time from
console...

* The current default installation directory is teaching
python library developers bad habits of not handling Python
installed into a directory that contains spaces properly. It
is actually a miracle to find a third party library that
installs a working script (batch file) to "python/scripts"
if the python directory contains spaces.

* The "program files" directory is the standard location
where applications should be installed in Windows. This is
what Microsoft requires in their guidelines and most
applications obey them. You would not install python to
"/python24" by default in Unix would you?



----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-10-08 11:48

Message:
Logged In: YES 
user_id=21627

I disagree that the default location of Python should be
c:\Program Files. The Python interpreter's path name is
often typed into a terminal, batch file, etc., so it needs
to be convenient to type.

I agree that the permissions are problematic; the proper
solution would be to give c:\python24 more restrictive
permissions. You can do this yourself: in the security tab,
edit the permission. In "Advanced", unselect the "Inherit
permission" checkbox, and choose "copy" when asked. Then
edit the permissions to your liking.

I can consider supporting such permission setting during
installation in the future - an invocation of cacls.exe
should do. 

Notice that this is an incompatible change: as currently all
users can create files in the tree, the .pyc files are often
not created during installation, but on first use. If write
permissions are denied, normal users could not cause .pyc
creation anymore, causing increased startup costs unless the
.pyc files are created during installation.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-30 08:26

Message:
Logged In: YES 
user_id=33168

Martin, do you know anything about this?  (Sorry, don't know
who else might know.)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1284316&group_id=5470

From noreply at sourceforge.net  Wed Mar 22 20:32:08 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 22 Mar 2006 11:32:08 -0800
Subject: [ python-Bugs-1448058 ] problems with too many sockets in FreeBSD
Message-ID: <E1FM93w-0000sl-8K@sc8-sf-web3.sourceforge.net>

Bugs item #1448058, was opened at 2006-03-12 02:19
Message generated for change (Comment added) made by aix-d
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448058&group_id=5470

Please note that this 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: aix-d (aix-d)
Assigned to: Nobody/Anonymous (nobody)
Summary: problems with too many sockets in FreeBSD

Initial Comment:
When there are about 200 sockets, or so, i'm getting
errors: "unable to select on socket"
We are running multithread application, for each thread
there is one socket.

TRACEBACK contains:
  r = self.connection.recv(1024)
error: unable to select on socket.

This error appeared after fixing this problem:
http://sourceforge.net/tracker/index.php?func=detail&aid=1429585&group_id=5470&atid=105470

Python version: 2.5a0 (trunk, Mar  8 2006, 18:28:30)
OS version: FreeBSD 6.1-PRERELEASE

Soon we will make program that will reproduce this
error if needed.

----------------------------------------------------------------------

>Comment By: aix-d (aix-d)
Date: 2006-03-22 22:32

Message:
Logged In: YES 
user_id=1449422

Thank you very much!

It was fixed by increasing FD_SETSIZE.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-14 10:37

Message:
Logged In: YES 
user_id=33168

What is the value of FD_SETSIZE?  Perhaps you should
increase this value before including any headers on FreeBSD?
 If you are using a lot of sockets, you may prefer to use
poll() instead of select() as poll() doesn't have the
FD_SETSIZE limitation.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448058&group_id=5470

From noreply at sourceforge.net  Wed Mar 22 21:27:17 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 22 Mar 2006 12:27:17 -0800
Subject: [ python-Bugs-1284316 ] Win32: Security problem with default
	installation directory
Message-ID: <E1FM9vJ-0004RG-Mq@sc8-sf-web2.sourceforge.net>

Bugs item #1284316, was opened at 2005-09-07 17:34
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1284316&group_id=5470

Please note that this 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: Platform-specific
Status: Open
Resolution: None
Priority: 7
Submitted By: Mika Eloranta (mel)
Assigned to: Martin v. L??wis (loewis)
Summary: Win32: Security problem with default installation directory

Initial Comment:
(Sorry, this is a bit long since the issue is not
entirely trivial.)

This problem only exists on Windows operating systems
installed on an NTFS file system. Confirmed on several
Windows 2000, XP and Windows 2003 Server systems. All
Python versions (at least 2.x) are affected.

The default installation target directory where Python
is installation on Windows is directly under the system
drive's root directory (e.g. "C:\python24"). The file
and directory permissions inherited by the
python24-directory from the root directory are not
secure enough for keeping application binaries.

Microsoft has, in their infinite wisdom, decided that
the root directory of the system drive should allow
regular (non-admin) users to create directories and
files there. This set of permissions is inherited by
the python directory when it is created in the default
location (i.e. "C:\python24" or whatever).

This "feature" allows a regular (non-admin) user to
perform a priviledge escalation attack for example in
the following manner:

1. Figure out the name of some DLL python (or some
extension .PYD) loads using LoadLibrary() without an
absolute path.

2. Copy a DLL with the same name into the
python-directory (this should not be allowed, but it
is!) containing some code the attacker wants to run
with escalated priviledges.

3. Wait until python is run by an admin in the same
machine or by the LocalSystem account.

How to view the problematic part of the ACL:
1. Right-click the "C:\python24" directory in Windows
Explorer
2. select Properties... -> Security -> Advanced
3. In the "Permissions" tab you will see an entry for
the "Users" group, it says "Special" in the
"Permissions" column
4. Select the above entry and click "Edit..."
5. Well hidden? I think so, too.

The fix:
The proper (default) location where application
binaries should be installed is under the "c:\program
files\" directory. This directory has properly set
permissions by default.

PS. The same problem exists in ActivePerl, Ruby and
many other tools.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-03-22 15:27

Message:
Logged In: YES 
user_id=31435

A long time ago, Python did install (by default) under
"Program Files".  I changed that, because of the endless
problems created by the frickin' embedded space, and rarer
but subtler problems due to "Program Files" not being a
DOSish 8.3 name.  Overall I still think it was a good change.

Note that, unlike most Windows applications (which are
GUI-based), programming languages are _intended_ to be used
heavily from the command line, invoked by scripts, and so
on.  That's what makes a space in the path endlessly
error-prone.  In WinXP Pro, I noticed that MS was still
careful to put its own command-line/script tools (sort.exe,
ipconfig.exe, cscript.exe, ..., even notepad.exe) under pure
DOSish 8.3 space-free paths ;-)

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-03-22 14:09

Message:
Logged In: YES 
user_id=21627

I completely disagree. It was wrong to give the system
default binary directory a name with a space in it, on a
system that doesn't provide command line argument vectors in
its standard API.

----------------------------------------------------------------------

Comment By: Mika Eloranta (mel)
Date: 2005-11-19 03:46

Message:
Logged In: YES 
user_id=109057

Wow, even easy_install.exe from setuptools fails if python
is installed under "c:\program files":

C:\temp>easy_install
C:\program: can't open file 'files\Python24\python.exe':
[Errno 2] No such file or directory

IMHO the root cause to all these problems is the wrong
default installation directory. If the installation
directory would conform to Windows guidelines, these kind of
problems would have been easily spotted by python library
developers.

    - Mika


----------------------------------------------------------------------

Comment By: Mika Eloranta (mel)
Date: 2005-11-15 06:39

Message:
Logged In: YES 
user_id=109057

Please consider these points as well:

* The "program files" directory has "sensible" ACLs set by
default (the defaults are different in different OS
versions). If you install your application under "program
files", you do not need to worry about the permissions.

* The installation directory can be added to the PATH
environment variable instead of typing it every time from
console...

* The current default installation directory is teaching
python library developers bad habits of not handling Python
installed into a directory that contains spaces properly. It
is actually a miracle to find a third party library that
installs a working script (batch file) to "python/scripts"
if the python directory contains spaces.

* The "program files" directory is the standard location
where applications should be installed in Windows. This is
what Microsoft requires in their guidelines and most
applications obey them. You would not install python to
"/python24" by default in Unix would you?



----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-10-08 05:48

Message:
Logged In: YES 
user_id=21627

I disagree that the default location of Python should be
c:\Program Files. The Python interpreter's path name is
often typed into a terminal, batch file, etc., so it needs
to be convenient to type.

I agree that the permissions are problematic; the proper
solution would be to give c:\python24 more restrictive
permissions. You can do this yourself: in the security tab,
edit the permission. In "Advanced", unselect the "Inherit
permission" checkbox, and choose "copy" when asked. Then
edit the permissions to your liking.

I can consider supporting such permission setting during
installation in the future - an invocation of cacls.exe
should do. 

Notice that this is an incompatible change: as currently all
users can create files in the tree, the .pyc files are often
not created during installation, but on first use. If write
permissions are denied, normal users could not cause .pyc
creation anymore, causing increased startup costs unless the
.pyc files are created during installation.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-30 02:26

Message:
Logged In: YES 
user_id=33168

Martin, do you know anything about this?  (Sorry, don't know
who else might know.)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1284316&group_id=5470

From noreply at sourceforge.net  Wed Mar 22 23:04:16 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 22 Mar 2006 14:04:16 -0800
Subject: [ python-Bugs-1115379 ] Built-in compile function with PEP 0263
	encoding bug
Message-ID: <E1FMBRA-00027z-S7@sc8-sf-web2.sourceforge.net>

Bugs item #1115379, was opened at 2005-02-03 05:11
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115379&group_id=5470

Please note that this 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: 7
Submitted By: Christoph Zwerschke (cito)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: Built-in compile function with PEP 0263 encoding bug

Initial Comment:
a = 'print "Hello, World"'
u = '# -*- coding: utf-8 -*-\n' + a

print compile(a, '<string>', 'exec') # ok
print compile(u, '<string>', 'exec') # ok
print compile(unicode(a), '<string>', 'exec') # ok
print compile(unicode(u), '<string>', 'exec') # error

# The last line gives a SystemError.
# Think this is a bug.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-03-22 05:56

Message:
Logged In: YES 
user_id=21627

I've committed this patch (along with a test case) as 43227
into the 2.4 branch; the trunk still needs fixing.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-20 13:14

Message:
Logged In: YES 
user_id=33168

Actually, I don't much care about the answer as long as it
isn't a core dump/assert or a SystemError.  I'm fine with a
syntax error.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-03-20 01:03

Message:
Logged In: YES 
user_id=21627

I still wonder why anybody would want to do that, so I don't
see it as a big problem that it gives an error in 2.4: it
*should* give an error, although not the one it currently gives.

It seems that wigy would expect that the encoding
declaration is ignored, whereas you (nnorwitz) are
suggesting that the UTF-8 default should be ignored. In the
face of ambiguity, refuse the temptation to guess.

So I still think it should give a SyntaxError instead. I'll
attach an alternative patch.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-20 00:28

Message:
Logged In: YES 
user_id=33168

Martin, the attached patches (2.4 and 2.5) fix the problem.
 However, it seems that the patches would violate the PEP
according to one of your notes.  I'm not sure about all the
details, but ISTM based on your comment that if (flags &&
flags->cf_flags & PyCF_SOURCE_IS_UTF8) and (TYPE(n) ==
encoding_decl) this is an error that should be returned?

I would like to get this fixed for 2.4.3, so we need to move
fast for it.  2.5 can wait and is trivial to fix once we
know what this is supposed to do.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 13:37

Message:
Logged In: YES 
user_id=849994

This even aborts the interpreter in 2.5 HEAD with a failing
assertion.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-09-27 22:48

Message:
Logged In: YES 
user_id=21627

If you load the files manually, why is it that you want to
decode them to Unicode before compile()ing them? Couldn't
you just pass the bytes you read from the file to compile()?

----------------------------------------------------------------------

Comment By: V?gv?lgyi Attila (wigy)
Date: 2005-09-27 21:29

Message:
Logged In: YES 
user_id=156682

If this special case is a feature, not a bug, than it breaks
some symmetry for sure.

If I run a script having utf-8 encoding from a file with

  python script.py

then it has to have an encoding declaration. Now if I would
like to load the same file manually, decode it to a unicode
object, I also have to remove the encoding declaration at
the beginning of the file before I can give it to the
compile() function.

What special advantage comes from the fact that the compiler
does not simply ignore encoding declaration nodes from
unicode objects? Does this error message catch some possible
errors or does it make the compiler code simpler?

----------------------------------------------------------------------

Comment By: V?gv?lgyi Attila (wigy)
Date: 2005-09-27 21:20

Message:
Logged In: YES 
user_id=156682

If this special case is a feature, not a bug, than it breaks
some symmetry for sure.

If I run a script having utf-8 encoding from a file with

  python script.py

then it has to have an encoding declaration. Now if I would
like to load the same file manually, decode it to a unicode
object, I also have to remove the encoding declaration at
the beginning of the file before I can give it to the
compile() function.

What special advantage comes from the fact that the compiler
does not simply ignore encoding declaration nodes from
unicode objects? Does this error message catch some possible
errors or does it make the compiler code simpler?

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-02-09 16:37

Message:
Logged In: YES 
user_id=21627

There is a bug somewhere, certainly. However, I believe it
is in PEP 263, which should point out that unicode strings
in compile are only legal if they do *not* contain an
encoding declaration, as such strings are implicitly encoded
as UTF-8.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115379&group_id=5470

From noreply at sourceforge.net  Wed Mar 22 23:06:13 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 22 Mar 2006 14:06:13 -0800
Subject: [ python-Bugs-1456470 ] sliceobject ssize_t (and index) not completed
Message-ID: <E1FMBT3-0006w1-RV@sc8-sf-web5.sourceforge.net>

Bugs item #1456470, was opened at 2006-03-22 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=1456470&group_id=5470

Please note that this 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: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: sliceobject ssize_t (and index) not completed

Initial Comment:
sliceobject and ceval changed the parameter types of 
slice objects to ssize_t, but the code still requires 
an int (sometimes not even a long); it should use the 
new __index__ slot; at the very least, it should be 
consistent about what it does accept.

In http://svn.python.org/view/python/trunk/Objects/
sliceobject.c?rev=42382&view=markup

[issue 1] function PySlice_GetIndices takes Py_ssize_t 
parameters for (length, start, stop, step)

but then does a PyInt_Check on each of start, stop, 
step.  (An XXX to allow longs was also removed.)  It *
should* use the new __index__ slot.

[issue 2] Later in the same file, function slice_
indices takes a PyObject len parameter, but then uses 
PyInt_AsLong rather than __index__ (or even PyInt_
AsSsize_t) to create Py_ssize_t ilen.

[issue 3]

http://svn.python.org/view/python/trunk/Python/ceval.c?
rev=42382&view=markup

function _PyEval_SliceIndex accepts only ints and 
longs, and longs will be converted to ints with 
clipping.  

It should allow anything with __index__, and clip only 
to ssize_t rather than int.

[issue 4] ISINT still insists on int or long -- I 
thought I saw a fix for this already in the index 
patches.

[issue 5]
apply_slice and assign_slice changed the types of ilow 
and ihigh, but still initializes them to INT_MAX 
rather than ssize_t max.




----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456470&group_id=5470

From noreply at sourceforge.net  Wed Mar 22 23:40:56 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 22 Mar 2006 14:40:56 -0800
Subject: [ python-Bugs-1448058 ] problems with too many sockets in FreeBSD
Message-ID: <E1FMC0e-0001sP-3o@sc8-sf-web6.sourceforge.net>

Bugs item #1448058, was opened at 2006-03-11 15:19
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448058&group_id=5470

Please note that this 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: Closed
>Resolution: Invalid
Priority: 5
Submitted By: aix-d (aix-d)
Assigned to: Nobody/Anonymous (nobody)
Summary: problems with too many sockets in FreeBSD

Initial Comment:
When there are about 200 sockets, or so, i'm getting
errors: "unable to select on socket"
We are running multithread application, for each thread
there is one socket.

TRACEBACK contains:
  r = self.connection.recv(1024)
error: unable to select on socket.

This error appeared after fixing this problem:
http://sourceforge.net/tracker/index.php?func=detail&aid=1429585&group_id=5470&atid=105470

Python version: 2.5a0 (trunk, Mar  8 2006, 18:28:30)
OS version: FreeBSD 6.1-PRERELEASE

Soon we will make program that will reproduce this
error if needed.

----------------------------------------------------------------------

Comment By: aix-d (aix-d)
Date: 2006-03-22 11:32

Message:
Logged In: YES 
user_id=1449422

Thank you very much!

It was fixed by increasing FD_SETSIZE.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-13 23:37

Message:
Logged In: YES 
user_id=33168

What is the value of FD_SETSIZE?  Perhaps you should
increase this value before including any headers on FreeBSD?
 If you are using a lot of sockets, you may prefer to use
poll() instead of select() as poll() doesn't have the
FD_SETSIZE limitation.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448058&group_id=5470

From noreply at sourceforge.net  Thu Mar 23 02:15:34 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 22 Mar 2006 17:15:34 -0800
Subject: [ python-Bugs-1456609 ] PEP Links broken on new website
Message-ID: <E1FMEQI-0005kd-Ij@sc8-sf-web3.sourceforge.net>

Bugs item #1456609, was opened at 2006-03-22 19: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=1456609&group_id=5470

Please note that this 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: Grant Olson (logistix)
Assigned to: Nobody/Anonymous (nobody)
Summary: PEP Links broken on new website

Initial Comment:
The links genereated are in the form:

http://www.python.org/dev/peps/pep-0340/pep-0288.html

when they should be:

http://www.python.org/dev/peps/pep-0288/



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456609&group_id=5470

From noreply at sourceforge.net  Thu Mar 23 04:24:47 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 22 Mar 2006 19:24:47 -0800
Subject: [ python-Bugs-1444893 ] Pointer freed twice in Py_InitializeEx()
Message-ID: <200603230324.k2N3Ol6v029862@sc8-sf-db2-new-b.sourceforge.net>

Bugs item #1444893, was opened at 03/07/06 06:39
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1444893&group_id=5470

Please note that this 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: None
Priority: 5
Submitted By: athorp (athorp)
Assigned to: Nobody/Anonymous (nobody)
Summary: Pointer freed twice in Py_InitializeEx()

Initial Comment:
saved_locale is freed twice in
pythonrun.c:Py_InitializeEx().

Example code attached.

----------------------------------------------------------------------

>Comment By: SourceForge Robot (sf-robot)
Date: 03/22/06 19:24

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: Neal Norwitz (nnorwitz)
Date: 03/08/06 00:19

Message:
Logged In: YES 
user_id=33168

Also, what system are you running on?  Mine amd64 is Linux.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 03/08/06 00:16

Message:
Logged In: YES 
user_id=33168

I don't see a problem with the code in SVN (either head or
2.4 branch).  When I run 2.5 (HEAD) code with your test (but
not debug malloc) under valgrind on amd64, it doesn't report
any problems.

Can you review the code in SVN to see if you think this is
still a problem.  If so, can you provide a patch that you
believe fixes this problem?

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 03/08/06 00:14

Message:
Logged In: YES 
user_id=849994

Your example is not very instructive. It only segfaults on
my box.

Can you tell where exactly the problem is, and how you would
solve it?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1444893&group_id=5470

From noreply at sourceforge.net  Thu Mar 23 06:40:27 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 22 Mar 2006 21:40:27 -0800
Subject: [ python-Bugs-1115379 ] Built-in compile function with PEP 0263
	encoding bug
Message-ID: <E1FMIYd-0005UQ-KL@sc8-sf-web3.sourceforge.net>

Bugs item #1115379, was opened at 2005-02-03 05:11
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115379&group_id=5470

Please note that this 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: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Christoph Zwerschke (cito)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Built-in compile function with PEP 0263 encoding bug

Initial Comment:
a = 'print "Hello, World"'
u = '# -*- coding: utf-8 -*-\n' + a

print compile(a, '<string>', 'exec') # ok
print compile(u, '<string>', 'exec') # ok
print compile(unicode(a), '<string>', 'exec') # ok
print compile(unicode(u), '<string>', 'exec') # error

# The last line gives a SystemError.
# Think this is a bug.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-22 21:40

Message:
Logged In: YES 
user_id=33168

Updated PEP.

Committed revision 43243.


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-03-22 05:56

Message:
Logged In: YES 
user_id=21627

I've committed this patch (along with a test case) as 43227
into the 2.4 branch; the trunk still needs fixing.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-20 13:14

Message:
Logged In: YES 
user_id=33168

Actually, I don't much care about the answer as long as it
isn't a core dump/assert or a SystemError.  I'm fine with a
syntax error.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-03-20 01:03

Message:
Logged In: YES 
user_id=21627

I still wonder why anybody would want to do that, so I don't
see it as a big problem that it gives an error in 2.4: it
*should* give an error, although not the one it currently gives.

It seems that wigy would expect that the encoding
declaration is ignored, whereas you (nnorwitz) are
suggesting that the UTF-8 default should be ignored. In the
face of ambiguity, refuse the temptation to guess.

So I still think it should give a SyntaxError instead. I'll
attach an alternative patch.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-20 00:28

Message:
Logged In: YES 
user_id=33168

Martin, the attached patches (2.4 and 2.5) fix the problem.
 However, it seems that the patches would violate the PEP
according to one of your notes.  I'm not sure about all the
details, but ISTM based on your comment that if (flags &&
flags->cf_flags & PyCF_SOURCE_IS_UTF8) and (TYPE(n) ==
encoding_decl) this is an error that should be returned?

I would like to get this fixed for 2.4.3, so we need to move
fast for it.  2.5 can wait and is trivial to fix once we
know what this is supposed to do.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 13:37

Message:
Logged In: YES 
user_id=849994

This even aborts the interpreter in 2.5 HEAD with a failing
assertion.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-09-27 22:48

Message:
Logged In: YES 
user_id=21627

If you load the files manually, why is it that you want to
decode them to Unicode before compile()ing them? Couldn't
you just pass the bytes you read from the file to compile()?

----------------------------------------------------------------------

Comment By: V?gv?lgyi Attila (wigy)
Date: 2005-09-27 21:29

Message:
Logged In: YES 
user_id=156682

If this special case is a feature, not a bug, than it breaks
some symmetry for sure.

If I run a script having utf-8 encoding from a file with

  python script.py

then it has to have an encoding declaration. Now if I would
like to load the same file manually, decode it to a unicode
object, I also have to remove the encoding declaration at
the beginning of the file before I can give it to the
compile() function.

What special advantage comes from the fact that the compiler
does not simply ignore encoding declaration nodes from
unicode objects? Does this error message catch some possible
errors or does it make the compiler code simpler?

----------------------------------------------------------------------

Comment By: V?gv?lgyi Attila (wigy)
Date: 2005-09-27 21:20

Message:
Logged In: YES 
user_id=156682

If this special case is a feature, not a bug, than it breaks
some symmetry for sure.

If I run a script having utf-8 encoding from a file with

  python script.py

then it has to have an encoding declaration. Now if I would
like to load the same file manually, decode it to a unicode
object, I also have to remove the encoding declaration at
the beginning of the file before I can give it to the
compile() function.

What special advantage comes from the fact that the compiler
does not simply ignore encoding declaration nodes from
unicode objects? Does this error message catch some possible
errors or does it make the compiler code simpler?

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-02-09 16:37

Message:
Logged In: YES 
user_id=21627

There is a bug somewhere, certainly. However, I believe it
is in PEP 263, which should point out that unicode strings
in compile are only legal if they do *not* contain an
encoding declaration, as such strings are implicitly encoded
as UTF-8.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115379&group_id=5470

From noreply at sourceforge.net  Thu Mar 23 09:02:41 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 23 Mar 2006 00:02:41 -0800
Subject: [ python-Bugs-1456609 ] PEP Links broken on new website
Message-ID: <E1FMKmH-0005tq-2R@sc8-sf-web3.sourceforge.net>

Bugs item #1456609, was opened at 2006-03-23 01:15
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456609&group_id=5470

Please note that this 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: None
Priority: 5
Submitted By: Grant Olson (logistix)
Assigned to: Nobody/Anonymous (nobody)
Summary: PEP Links broken on new website

Initial Comment:
The links genereated are in the form:

http://www.python.org/dev/peps/pep-0340/pep-0288.html

when they should be:

http://www.python.org/dev/peps/pep-0288/



----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-23 08:02

Message:
Logged In: YES 
user_id=849994

The pydotorg website has its own tracker.

Please look at
http://psf.pollenation.net/cgi-bin/trac.cgi/report/1 whether
this problem is already reported and if not, please open a
ticket there.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456609&group_id=5470

From noreply at sourceforge.net  Thu Mar 23 09:41:29 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 23 Mar 2006 00:41:29 -0800
Subject: [ python-Bugs-1183780 ] Popen4 wait() fails sporadically with threads
Message-ID: <E1FMLNp-0006CR-Cs@sc8-sf-web1.sourceforge.net>

Bugs item #1183780, was opened at 2005-04-15 07:27
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183780&group_id=5470

Please note that this message 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: Taale Skogan (tskogan)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: Popen4 wait() fails sporadically with threads

Initial Comment:
Calling wait() on a popen2.Popen4 object fails 
intermittently with the error

Traceback (most recent call last):
  ...
  File "/usr/local/lib/python2.3/popen2.py", line 90, in wait
    pid, sts = os.waitpid(self.pid, 0)
OSError: [Errno 10] No child processes

when using threads. 

The problem seems to be a race condition when a thread 
calls wait() on a popen2.Popen4 object. This also apllies 
to Popen3 objects. 

The constructor of Popen4. calls _cleanup() which calls 
poll() which calls the system call waitpid() for all acitve 
child processes. If another thread calls poll() before the 
current thread calls wait() on it's child process and the 
child process has terminated, the child process is no 
longer waitable and the second call to wait() fails.

Code to replicate this behavoir is attached in popen_bug.
py.

Solution: Popen4 and Popen3 should be threadsafe.

Related modules: A seemingly related error occurs with 
Popen from the new subprocess module. Use the -s 
option in the popen_bug.py script to test this. 

Tested on Linux RedHat Enterprise 3 for Python 2.3.3, 
Python 2.3.5 and Python 2.4.1 and Solaris for Python 2.
4.1. The error did not occur on a RedHat 7.3 machine 
with Python 2.3.5. See the attached file popen_bug.py for 
details on the platforms.



----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-23 00:41

Message:
Logged In: YES 
user_id=33168

The attached patch fixes the problem for me.  It also
addresses another issue where wait could be called from
outside the popen2 module.  I'm not sure this is the best
solution.  I'm not sure there really is a good solution. 
Perhaps it's best to allow an exception to be raised?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183780&group_id=5470

From noreply at sourceforge.net  Thu Mar 23 09:45:36 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 23 Mar 2006 00:45:36 -0800
Subject: [ python-Bugs-998246 ] Popen3.poll race condition
Message-ID: <E1FMLRo-0006S3-O4@sc8-sf-web1.sourceforge.net>

Bugs item #998246, was opened at 2004-07-26 12:14
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=998246&group_id=5470

Please note that this message 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: Tres Seaver (tseaver)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: Popen3.poll race condition

Initial Comment:
poll() swallows all IOErrors, including ENOCHILD;  if
the child process exits before poll is called, then an
applications which loops on
poll() will never exit.

I am working around this (against Python 2.3.3) via the
following:


                try:
                    pid, status = os.waitpid(proc.pid,
os.WNOHANG)
                except os.error, e:
                    if e.errno == 10:  # ENOCHILD
                        result = 0
                    else:
                        raise
                else:
                    if pid == proc.pid:
                        result = status


where 'proc' is an instance of Popen3.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-23 00:45

Message:
Logged In: YES 
user_id=33168

I believe this is basically a duplicate of 1183780.  There
is a patch attached there.  Can you verify if it fixes your
problem?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=998246&group_id=5470

From noreply at sourceforge.net  Thu Mar 23 09:47:15 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 23 Mar 2006 00:47:15 -0800
Subject: [ python-Bugs-892939 ] Race condition in popen2
Message-ID: <E1FMLTP-0006Zh-M1@sc8-sf-web1.sourceforge.net>

Bugs item #892939, was opened at 2004-02-08 09:31
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=892939&group_id=5470

Please note that this message 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: 6
Submitted By: Ken McNeil (kenmcneil)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: Race condition in popen2

Initial Comment:
The "fix" for bug #761888 created a race condition in
Popen3  . The interaction between wait and _cleanup is
the root of the problem.

def wait(self):
  """Wait for and return the exit status of the child
process."""
  if self.sts < 0:
    pid, sts = os.waitpid(self.pid, 0)
    if pid == self.pid:
      self.sts = sts
  return self.sts

def _cleanup():
    for inst in _active[:]:
        inst.poll()

In wait, between the check of self.sts and the call to
os.waitpid a new Popen3 object can be created in
another thread which will trigger a call to _cleanup.
Since the call to _cleanup polls the process, when the
thread running wait starts back up again it will try to
poll the process using os.waitpid, which will throw an
OSError because os.waitpid has already been called for
the PID indirectly in _cleanup.

A work around is for the caller of wait to catch the
OSError and check the sts field, and if sts is
non-negative then the OSError is most likely because of
this problem and can be ignored. However, sts is
undocumented and should probably stay that way.

My suggestion is that the patch that added _active, 
_cleanup, and all  be removed and a more suitable
mechanism for fixing bug #761888 be found. As it has
been said in the discussion of bug #761888, magically
closing FDs is not a "good thing". It seems to me that
surrounding the call to os.fork with a try/except, and
closing the pipes in the except, would be suitable but
I don't know how this would interact with a failed call
to fork, therefore I wont provide a patch.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-23 00:47

Message:
Logged In: YES 
user_id=33168

I believe this is basically a duplicate of 1183780.  There
is a patch attached there.  Can you verify if it fixes your
problem?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=892939&group_id=5470

From noreply at sourceforge.net  Thu Mar 23 09:50:17 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 23 Mar 2006 00:50:17 -0800
Subject: [ python-Bugs-886492 ] Python 2.2.3 crashes using popen2 to spawn
	lots of children
Message-ID: <E1FMLWL-0006lk-T5@sc8-sf-web1.sourceforge.net>

Bugs item #886492, was opened at 2004-01-28 12:33
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=886492&group_id=5470

Please note that this 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.2.3
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Frank Terhaar-Yonkers (frankty)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.2.3 crashes using popen2 to spawn lots of children

Initial Comment:
WinPython 2.3.3 crashes when using popen2 to spawn
*lots* of children > 100.

Running the test case on either W2k or Wxp causes
Python 2.3.3 to crash.  Looking at the drwatson file,
it appears to be a race condition where the child is in
the process of crashing, while the popen2 code in
posixmodule.c is attempting to PyFile_SetBufSize() on
one of the pipes.  Evil juju in ntdll.dll ..

I've no idea what system resource is being exhausted
(heap memory?) causing the crash.

If you look at the hacks in posixmodule.c, the Python
crash can be eliminated by simply commenting out the
calls to PyFile_SetBufSize.  There is still the problem
of resource exhaustion.  To gain more child processes I
included a hack such that with the setting of an
env-var (NOPYCMD) popen2 will NOT use cmd.exe /c to run
a child, but simply run the child command as passed
(yeah, I know that is has to be an absolute path or in
the CWD then ..).

I'm sure there is a better way to eliminate the cmd.exe
/c - like maybe a new method: popen2.popenXabspath ..

In any case, it appears we have an NT kernel bug
combined with an inefficient way of doing popen2 that
is making a mess.  I started doing some exploration of
heap_chunk_size to attack to resource issue but haven't
gotten very far.

As for *why* I'm doing this, it's because we're using
Pyton as a system simulator tool to emulate a large
pile of PCs.  The actual work *must* be done by
external .exe code that cannot be changed.

The attached zip contains a test case, the posixmodule
hack, drwatson file and a sample program written in
VisC++ which does basically the same as the Python test
case.

cheers,

- Frank



----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-23 00:50

Message:
Logged In: YES 
user_id=33168

Dupe of 886488

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=886492&group_id=5470

From noreply at sourceforge.net  Thu Mar 23 09:53:59 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 23 Mar 2006 00:53:59 -0800
Subject: [ python-Bugs-1456775 ] round not rounding correctly
Message-ID: <E1FMLZv-0005Hz-Ea@sc8-sf-web5.sourceforge.net>

Bugs item #1456775, was opened at 2006-03-23 09: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=1456775&group_id=5470

Please note that this message 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: Norbert Sebok (seboknorbi)
Assigned to: Nobody/Anonymous (nobody)
Summary: round not rounding correctly

Initial Comment:
For example:
print 72.805, round(72.805,2)
print 72.815, round(72.815,2)
print 72.825, round(72.825,2)
print 72.835, round(72.835,2)
print 72.845, round(72.845,2)
print 72.855, round(72.855,2)
print 72.865, round(72.865,2)
print 72.875, round(72.875,2)
print 72.885, round(72.885,2)
print 72.895, round(72.895,2)

The results:
72.805 72.81
72.815 72.82
72.825 72.83
72.835 72.83 !!! not 72.84
72.845 72.85
72.855 72.86
72.865 72.86 !!! not 72.87
72.875 72.88
72.885 72.89
72.895 72.9

The problem seems to exists with numbers ending with 5.
Another examples:
round(0.015,2) == 0.01 != 0.02
round(0.045,2) == 0.04 != 0.05
round(0.075,2) == 0.07 != 0.08
round(0.105,2) == 0.1 != 0.11
round(0.145,2) == 0.14 != 0.15
round(0.155,2) == 0.15 != 0.16
round(0.175,2) == 0.17 != 0.18
round(0.185,2) == 0.18 != 0.19
round(0.205,2) == 0.2 != 0.21
round(0.215,2) == 0.21 != 0.22
round(0.235,2) == 0.23 != 0.24
round(0.245,2) == 0.24 != 0.25
round(0.285,2) == 0.28 != 0.29
round(0.295,2) == 0.29 != 0.3
round(0.305,2) == 0.3 != 0.31
round(0.345,2) == 0.34 != 0.35

It's the same on Linux and Win32.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456775&group_id=5470

From noreply at sourceforge.net  Thu Mar 23 10:33:34 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 23 Mar 2006 01:33:34 -0800
Subject: [ python-Bugs-1456775 ] round not rounding correctly
Message-ID: <E1FMMCE-0003Ei-EM@sc8-sf-web3.sourceforge.net>

Bugs item #1456775, was opened at 2006-03-23 08:53
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456775&group_id=5470

Please note that this message 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: Norbert Sebok (seboknorbi)
Assigned to: Nobody/Anonymous (nobody)
Summary: round not rounding correctly

Initial Comment:
For example:
print 72.805, round(72.805,2)
print 72.815, round(72.815,2)
print 72.825, round(72.825,2)
print 72.835, round(72.835,2)
print 72.845, round(72.845,2)
print 72.855, round(72.855,2)
print 72.865, round(72.865,2)
print 72.875, round(72.875,2)
print 72.885, round(72.885,2)
print 72.895, round(72.895,2)

The results:
72.805 72.81
72.815 72.82
72.825 72.83
72.835 72.83 !!! not 72.84
72.845 72.85
72.855 72.86
72.865 72.86 !!! not 72.87
72.875 72.88
72.885 72.89
72.895 72.9

The problem seems to exists with numbers ending with 5.
Another examples:
round(0.015,2) == 0.01 != 0.02
round(0.045,2) == 0.04 != 0.05
round(0.075,2) == 0.07 != 0.08
round(0.105,2) == 0.1 != 0.11
round(0.145,2) == 0.14 != 0.15
round(0.155,2) == 0.15 != 0.16
round(0.175,2) == 0.17 != 0.18
round(0.185,2) == 0.18 != 0.19
round(0.205,2) == 0.2 != 0.21
round(0.215,2) == 0.21 != 0.22
round(0.235,2) == 0.23 != 0.24
round(0.245,2) == 0.24 != 0.25
round(0.285,2) == 0.28 != 0.29
round(0.295,2) == 0.29 != 0.3
round(0.305,2) == 0.3 != 0.31
round(0.345,2) == 0.34 != 0.35

It's the same on Linux and Win32.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-23 09:33

Message:
Logged In: YES 
user_id=849994

Actually:
>>> 72.835
72.834999999999994
>>> 

This is due to the computer's internal floating point
representation, which is not decimal, but binary. So round()
behaves correctly. See
http://www.python.org/doc/faq/general/#why-are-floating-point-calculations-so-inaccurate
for more information.

If you need these calculations to be exact, use Decimals,
available in the decimal module.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456775&group_id=5470

From noreply at sourceforge.net  Thu Mar 23 10:34:06 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 23 Mar 2006 01:34:06 -0800
Subject: [ python-Bugs-1456470 ] sliceobject ssize_t (and index) not completed
Message-ID: <E1FMMCk-0003Gy-UP@sc8-sf-web3.sourceforge.net>

Bugs item #1456470, was opened at 2006-03-22 22:06
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456470&group_id=5470

Please note that this 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: 6
Submitted By: Jim Jewett (jimjjewett)
>Assigned to: Martin v. L??wis (loewis)
Summary: sliceobject ssize_t (and index) not completed

Initial Comment:
sliceobject and ceval changed the parameter types of 
slice objects to ssize_t, but the code still requires 
an int (sometimes not even a long); it should use the 
new __index__ slot; at the very least, it should be 
consistent about what it does accept.

In http://svn.python.org/view/python/trunk/Objects/
sliceobject.c?rev=42382&view=markup

[issue 1] function PySlice_GetIndices takes Py_ssize_t 
parameters for (length, start, stop, step)

but then does a PyInt_Check on each of start, stop, 
step.  (An XXX to allow longs was also removed.)  It *
should* use the new __index__ slot.

[issue 2] Later in the same file, function slice_
indices takes a PyObject len parameter, but then uses 
PyInt_AsLong rather than __index__ (or even PyInt_
AsSsize_t) to create Py_ssize_t ilen.

[issue 3]

http://svn.python.org/view/python/trunk/Python/ceval.c?
rev=42382&view=markup

function _PyEval_SliceIndex accepts only ints and 
longs, and longs will be converted to ints with 
clipping.  

It should allow anything with __index__, and clip only 
to ssize_t rather than int.

[issue 4] ISINT still insists on int or long -- I 
thought I saw a fix for this already in the index 
patches.

[issue 5]
apply_slice and assign_slice changed the types of ilow 
and ihigh, but still initializes them to INT_MAX 
rather than ssize_t max.




----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456470&group_id=5470

From noreply at sourceforge.net  Thu Mar 23 13:21:51 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 23 Mar 2006 04:21:51 -0800
Subject: [ python-Bugs-998246 ] Popen3.poll race condition
Message-ID: <E1FMOp5-0001ad-Rb@sc8-sf-web4-b.sourceforge.net>

Bugs item #998246, was opened at 2004-07-26 15:14
Message generated for change (Comment added) made by tseaver
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=998246&group_id=5470

Please note that this message 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: Tres Seaver (tseaver)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Popen3.poll race condition

Initial Comment:
poll() swallows all IOErrors, including ENOCHILD;  if
the child process exits before poll is called, then an
applications which loops on
poll() will never exit.

I am working around this (against Python 2.3.3) via the
following:


                try:
                    pid, status = os.waitpid(proc.pid,
os.WNOHANG)
                except os.error, e:
                    if e.errno == 10:  # ENOCHILD
                        result = 0
                    else:
                        raise
                else:
                    if pid == proc.pid:
                        result = status


where 'proc' is an instance of Popen3.

----------------------------------------------------------------------

>Comment By: Tres Seaver (tseaver)
Date: 2006-03-23 07:21

Message:
Logged In: YES 
user_id=127625

1183780 is indeed a similar bug, although he reports it
against Popen4 rather than Popen3.  His patch needs to be
modified to re-raise errors which are not ENOCHILD, however.

I no longer have accees to either the application or the
machine where I found this issue, and hence can't verify that
the patch fixes the code which triggered the problem.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-23 03:45

Message:
Logged In: YES 
user_id=33168

I believe this is basically a duplicate of 1183780.  There
is a patch attached there.  Can you verify if it fixes your
problem?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=998246&group_id=5470

From noreply at sourceforge.net  Thu Mar 23 18:29:52 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 23 Mar 2006 09:29:52 -0800
Subject: [ python-Bugs-1457119 ] Unifying pickle and cPickle exception class
	hierarchies
Message-ID: <E1FMTdA-000606-JV@sc8-sf-web6.sourceforge.net>

Bugs item #1457119, was opened at 2006-03-23 19: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=1457119&group_id=5470

Please note that this 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: Ori Peleg (oripel)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unifying pickle and cPickle exception class hierarchies

Initial Comment:
Should the pickle and cPickle exception class
hierarchies be unified? Perhaps just subclass one
grandparent PickleError class? That way module copy_reg
can throw exceptions from this hierarchy.

Here's the experience that led to the thought:

(1) confusing exception types when a class can't be pickled

When an object can't be pickled, sometimes a TypeError
is raised, and sometimes an exception derived from
pickle.PickleError or cPickle.PickleError, a screenshot
is pasted below.

(2) copy_reg raises TypeError
When a pickle-related exception occurs in copy_reg, a
TypeError is raised, e.g. in line 69:

raise TypeError, "can't pickle %s objects" % base.__name__

but if copy_reg wants to raise an exception from the
pickle module's hierarchy...

(3) copy_reg doesn't know if pickle or cPickle are used

It can't choose between the two, therefore it chooses
TypeError.

=== screenshot ===
>>> import sys, pickle, cPickle
>>> try: raise RuntimeError
... except: tb = sys.exc_info()[-1]
...
>>> frame = tb.tb_frame
>>> pickle.dumps(frame)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.4/pickle.py", line 1386, in dumps
    Pickler(file, protocol, bin).dump(obj)
  File "/usr/lib/python2.4/pickle.py", line 231, in dump
    self.save(obj)
  File "/usr/lib/python2.4/pickle.py", line 313, in save
    rv = reduce(self.proto)
  File "/usr/lib/python2.4/copy_reg.py", line 69, in
_reduce_ex
    raise TypeError, "can't pickle %s objects" %
base.__name__
TypeError: can't pickle frame objects
>>> cPickle.dumps(frame)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.4/copy_reg.py", line 69, in
_reduce_ex
    raise TypeError, "can't pickle %s objects" %
base.__name__
TypeError: can't pickle frame objects
>>> pickle.dumps(tb)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.4/pickle.py", line 1386, in dumps
    Pickler(file, protocol, bin).dump(obj)
  File "/usr/lib/python2.4/pickle.py", line 231, in dump
    self.save(obj)
  File "/usr/lib/python2.4/pickle.py", line 319, in save
    raise PicklingError("Can't pickle %r object: %r" %
pickle.PicklingError: Can't pickle 'traceback' object:
<traceback object at 0xb7d1d324>
>>> cPickle.dumps(tb)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
cPickle.UnpickleableError: Cannot pickle <type
'traceback'> objects
>>>


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457119&group_id=5470

From noreply at sourceforge.net  Thu Mar 23 21:49:08 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 23 Mar 2006 12:49:08 -0800
Subject: [ python-Bugs-1457264 ] urllib.splithost parses incorrectly
Message-ID: <E1FMWk0-0004Ur-OG@sc8-sf-web3.sourceforge.net>

Bugs item #1457264, was opened at 2006-03-23 20: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=1457264&group_id=5470

Please note that this message 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: Steve (onlynone)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib.splithost parses incorrectly

Initial Comment:
urllib.splithost(url) requires that the url passed in
be of the form '//host[:port]/path'. Yet I've run
across some urls that are of the form
'//host[:port]?querystring'. This causes splithost to
return everything as the host and nothing as the path.


Section 3.2 of rfc2396 (Uniform Resource Identifiers:
Generic Syntax) states that 'The authority component is
preceded by a double slash "//" and is terminated by
the next slash "/", question-mark "?", or by the end of
the URI.'

Also, this is how it defines a URI:

absoluteURI   = scheme ":" ( hier_part | opaque_part )
hier_part     = ( net_path | abs_path ) [ "?" query ]
net_path      = "//" authority [ abs_path ]
abs_path      = "/"  path_segments

Based on the above, you could certainly have:
'http://authority?query' as a valid url.


In python2.3 you would just need to change line 939 in
urllib.py from:

        _hostprog = re.compile('^//([^/]*)(.*)$')

to:

        _hostprog = re.compile('^//([^/?]*)(.*)$')

This appears to affect all python versions, I just
happened to be using 2.3.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457264&group_id=5470

From noreply at sourceforge.net  Thu Mar 23 22:33:29 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 23 Mar 2006 13:33:29 -0800
Subject: [ python-Bugs-1457312 ] AttributeError in upload_file on interrupted
	connection
Message-ID: <E1FMXQv-0005Ds-30@sc8-sf-web1.sourceforge.net>

Bugs item #1457312, was opened at 2006-03-23 22: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=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: Open
Resolution: None
Priority: 5
Submitted By: Stefan Behnel (scoder)
Assigned to: Nobody/Anonymous (nobody)
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.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457312&group_id=5470

From noreply at sourceforge.net  Thu Mar 23 23:36:43 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 23 Mar 2006 14:36:43 -0800
Subject: [ python-Bugs-1457358 ] floor division not documented
Message-ID: <E1FMYQ7-0000MX-2m@sc8-sf-web6.sourceforge.net>

Bugs item #1457358, was opened at 2006-03-23 23:36
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457358&group_id=5470

Please note that this 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: Christoph Zwerschke (cito)
Assigned to: Nobody/Anonymous (nobody)
Summary: floor division not documented

Initial Comment:
In chapter 2.3.4 of the Lib Reference
(2.3.4 Numeric Types -- int, float, long, complex),
the floor division operator (//) is missing.
It is only referred to in the explanation of the divmod
operator, but without explaining the meaning of //
itself. I think it would be good to make the //
operator more popular, so people can start to make
their code future proof.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457358&group_id=5470

From noreply at sourceforge.net  Thu Mar 23 23:37:22 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 23 Mar 2006 14:37:22 -0800
Subject: [ python-Bugs-1457358 ] floor division not documented
Message-ID: <E1FMYQk-0002y6-3Z@sc8-sf-web3.sourceforge.net>

Bugs item #1457358, was opened at 2006-03-23 23:36
Message generated for change (Settings changed) made by cito
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457358&group_id=5470

Please note that this 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: 3
Submitted By: Christoph Zwerschke (cito)
Assigned to: Nobody/Anonymous (nobody)
Summary: floor division not documented

Initial Comment:
In chapter 2.3.4 of the Lib Reference
(2.3.4 Numeric Types -- int, float, long, complex),
the floor division operator (//) is missing.
It is only referred to in the explanation of the divmod
operator, but without explaining the meaning of //
itself. I think it would be good to make the //
operator more popular, so people can start to make
their code future proof.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457358&group_id=5470

From noreply at sourceforge.net  Fri Mar 24 00:45:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 23 Mar 2006 15:45:46 -0800
Subject: [ python-Bugs-1457411 ] byext.py errors
Message-ID: <E1FMZUw-00059O-7C@sc8-sf-web1.sourceforge.net>

Bugs item #1457411, was opened at 2006-03-23 23: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=1457411&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Demos and Tools
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Lowery (jlowery2006)
Assigned to: Nobody/Anonymous (nobody)
Summary: byext.py errors

Initial Comment:
statdir() method make reference to undefined 'ext' 
variable:

    def statdir(self, dir):
        self.addstats("<dir>", "dirs", 1)
        try:
            names = os.listdir(dir)
        except os.error, err:
            sys.stderr.write("Can't list %s: %s\n" % 
(file, err))
            self.addstats(ext, "unlistable", 1)
            return
        names.sort()
        ...

also, a number of the error strings throughout the 
program refer to 'file', which I believe is the built-
in (shouldn't it be the name of a parameter?).

This file is in the Tools/Scripts directory of the 
Python install folder.




----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457411&group_id=5470

From noreply at sourceforge.net  Fri Mar 24 01:17:11 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 23 Mar 2006 16:17:11 -0800
Subject: [ python-Bugs-1455676 ] Simplify using Queues with consumer threads
Message-ID: <E1FMZzL-0005Gw-2A@sc8-sf-web4-b.sourceforge.net>

Bugs item #1455676, was opened at 2006-03-21 16:36
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1455676&group_id=5470

Please note that this 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: Accepted
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: Simplify using Queues with consumer threads

Initial Comment:
When Queues are used to communicate between producer 
and consumer threads, there is often a need to 
determine when all of the enqueued tasks have been 
completed.

With this small patch, determining when all work is 
done is as simple as adding q.task_done() to each 
consumer thread and q.join() to the main thread.

Without the patch, the next best approach is to count 
the number of puts, create a second queue filled by 
the consumer when a task is done, and for the main 
thread to call successive blocking gets on the result 
queue until all of the puts have been accounted for:

    def worker(): 
        while 1: 
            task = tasks_in.get() 
            do_work(task) 
            tasks_out.put(None)

    tasks_in = Queue() 
    tasks_out = Queue() 
    for i in range(num_worker_threads): 
         Thread(target=worker).start()

    n = 0 
    for elem in source():
        n += 1
        tasks_in.put(elem) 

    # block until tasks are done 
    for i in range(n): 
        tasks_out.get()

That approach is not complicated but it does entail 
more lines of code and tracking some auxiliary data.
This becomes cumersome and error-prone when an app 
has multiple occurences of q.put() and q.get().

The patch essentially encapsulates this approach into 
two methods, making it effortless to use and easy to 
graft on to existing uses of Queue. So, the above 
code simplies to:

    def worker(): 
        while 1: 
            task = q.get() 
            do_work(task) 
            q.task_done() 

    q = Queue() 
    for i in range(num_worker_threads): 
         Thread(target=worker).start() 

    for elem in source():
        q.put(elem) 

    # block until tasks are done 
    q.join() 

The put counting is automatic, there is no need for a 
separate queue object, the code readably expresses 
its intent with clarity.  Also, it is easy to inpect 
for accuracy, each get() followed by a task_done().  
The ease of inspection remains even when there are 
multiple gets and puts scattered through the code (a 
situtation which would become complicated for the two 
Queue approach).

If accepted, will add docs with an example.

Besides being a fast, lean, elegant solution, the 
other reason to accept the patch is that the 
underlying problem appears again and again, requiring 
some measure to invention to solve it each time.  
There are a number of approaches but none as simple, 
fast, or as broadly applicable as having the queue 
itself track items loaded and items completed.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-03-23 19:17

Message:
Logged In: YES 
user_id=31435

I marked this as Accepted, but there are some things I'd
like to see changed:

- A Condition is best named after the predicate it
represents.  So, e.g., instead of the generic "waiter", a
better name would be "all_tasks_done".  When you eventually
.notify() the Condition, you're notifing its wait()er that
"all tasks (may be) done", and "all tasks (may be) done" is
what the wait()er is waiting _for_.  "all_tasks_done.wait()"
 makes that much clearer than "waiter.wait()".

- A Condition.wait() can be interrupted by (at least)
KeyboardInterrupt, so the acquire/release around a
Condition.wait() call should always be in a try/finally (so
that the Condition is release()d no matter what).  All other
Condition.wait()s in Queue do protect themselves this way. 
I don't see a need for try/finally around other uses, except
possibly that:

- Given the intended semantics, it would be good to raise an
exception if .unfinished_tasks becomes negative; i.e., make
it a detected programmer error if task_done() is called "too
often" (although again the Condition needs to be release()d
no matter what, and a try/finally may be expedient toward
that end).

- Since any number of threads _may_ be waiting in
Queue.join(), yes, .notifyAll() is better.  The other
conditions in Queue don't do that because there's a key
difference:  at most one thread waiting on not_full or
not_empty can make progress when one of those is "signaled",
so it would be wasteful to wake up more than one thread
waiting on those.  In contrast, all threads waiting on
.waiter can make progress when all tasks are in fact done. 
You can do that with a notifyAll() in task_done(), or by
adding a notify() near the end of join() (then all threads
waiting on this condition will get notified in domino
fashion).  The notifyAll() way is "purer".

- It's inevitable that someone will ask Queue.join() to grow
an optional timeout argument.  OK by me if that waits ;-).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-03-22 01:02

Message:
Logged In: YES 
user_id=80475

Thanks.  There are two particular areas for extra 
attention.  

First, should the waiter acquire/release pairs be in a 
try/finally (iow, is there some behavior in notify() or 
release() that potentially needs to be trapped)?

Second, should the notify() in task_done() really be a 
notifyAll() (iow, does it make sense that multiple joins 
may be pending)?

Thanks again.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-03-21 20:42

Message:
Logged In: YES 
user_id=31435

Yup, I'll try to make time tomorrow (can't today). 
_Offhand_ it sounds like a nice addition to me.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-03-21 17:27

Message:
Logged In: YES 
user_id=80475

Tim, do you have a chance to look at this?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1455676&group_id=5470

From noreply at sourceforge.net  Fri Mar 24 01:37:04 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 23 Mar 2006 16:37:04 -0800
Subject: [ python-Bugs-1183780 ] Popen4 wait() fails sporadically with threads
Message-ID: <E1FMaIa-0006yM-7h@sc8-sf-web5.sourceforge.net>

Bugs item #1183780, was opened at 2005-04-15 16:27
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183780&group_id=5470

Please note that this message 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: Taale Skogan (tskogan)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Popen4 wait() fails sporadically with threads

Initial Comment:
Calling wait() on a popen2.Popen4 object fails 
intermittently with the error

Traceback (most recent call last):
  ...
  File "/usr/local/lib/python2.3/popen2.py", line 90, in wait
    pid, sts = os.waitpid(self.pid, 0)
OSError: [Errno 10] No child processes

when using threads. 

The problem seems to be a race condition when a thread 
calls wait() on a popen2.Popen4 object. This also apllies 
to Popen3 objects. 

The constructor of Popen4. calls _cleanup() which calls 
poll() which calls the system call waitpid() for all acitve 
child processes. If another thread calls poll() before the 
current thread calls wait() on it's child process and the 
child process has terminated, the child process is no 
longer waitable and the second call to wait() fails.

Code to replicate this behavoir is attached in popen_bug.
py.

Solution: Popen4 and Popen3 should be threadsafe.

Related modules: A seemingly related error occurs with 
Popen from the new subprocess module. Use the -s 
option in the popen_bug.py script to test this. 

Tested on Linux RedHat Enterprise 3 for Python 2.3.3, 
Python 2.3.5 and Python 2.4.1 and Solaris for Python 2.
4.1. The error did not occur on a RedHat 7.3 machine 
with Python 2.3.5. See the attached file popen_bug.py for 
details on the platforms.



----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-03-24 01:37

Message:
Logged In: YES 
user_id=21627

I don't understand why you are setting self.sts to 0 if wait
fails: most likely, there was a simultaneous call to .poll,
which should have set self.sts to the real return value. So
we should return that instead.

I think the whole issue can be avoid if we use resurrection:
If __del__ would put unwaited objects into _active, rather
than __init__, it would not happen that _cleanup polls a pid
which a thread still intends to wait for. In fact, it would
be sufficient to only put the pid into _active (avoiding the
need for resurrection).

If then a thread calls poll explicitly, and another calls
wait, they deserve to lose (with ECHILD). I would claim the
same error exists if part of the application calls
os.wait[3,4](), and another calls .wait later - they also
deserve the exception.

With that approach, I don't think further thread
synchronization would be needed.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-23 09:41

Message:
Logged In: YES 
user_id=33168

The attached patch fixes the problem for me.  It also
addresses another issue where wait could be called from
outside the popen2 module.  I'm not sure this is the best
solution.  I'm not sure there really is a good solution. 
Perhaps it's best to allow an exception to be raised?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183780&group_id=5470

From noreply at sourceforge.net  Fri Mar 24 02:41:54 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 23 Mar 2006 17:41:54 -0800
Subject: [ python-Bugs-1457470 ] regs attribute on regex objects not documented
Message-ID: <E1FMbJK-0002C2-PS@sc8-sf-web4-b.sourceforge.net>

Bugs item #1457470, was opened at 2006-03-24 01: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=1457470&group_id=5470

Please note that this 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: Jeff Lowery (jlowery2006)
Assigned to: Nobody/Anonymous (nobody)
Summary: regs attribute on regex objects not documented

Initial Comment:
Came across the use of <regex object>.regs attribute in 
the tools/scripts/classfix.py program (line 162), but 
it's not an attribute that's documented in the Python 
Library Reference.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457470&group_id=5470

From noreply at sourceforge.net  Fri Mar 24 06:17:12 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 23 Mar 2006 21:17:12 -0800
Subject: [ python-Bugs-1183780 ] Popen4 wait() fails sporadically with threads
Message-ID: <E1FMefg-0007BT-JO@sc8-sf-web4-b.sourceforge.net>

Bugs item #1183780, was opened at 2005-04-15 07:27
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183780&group_id=5470

Please note that this message 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: Taale Skogan (tskogan)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Popen4 wait() fails sporadically with threads

Initial Comment:
Calling wait() on a popen2.Popen4 object fails 
intermittently with the error

Traceback (most recent call last):
  ...
  File "/usr/local/lib/python2.3/popen2.py", line 90, in wait
    pid, sts = os.waitpid(self.pid, 0)
OSError: [Errno 10] No child processes

when using threads. 

The problem seems to be a race condition when a thread 
calls wait() on a popen2.Popen4 object. This also apllies 
to Popen3 objects. 

The constructor of Popen4. calls _cleanup() which calls 
poll() which calls the system call waitpid() for all acitve 
child processes. If another thread calls poll() before the 
current thread calls wait() on it's child process and the 
child process has terminated, the child process is no 
longer waitable and the second call to wait() fails.

Code to replicate this behavoir is attached in popen_bug.
py.

Solution: Popen4 and Popen3 should be threadsafe.

Related modules: A seemingly related error occurs with 
Popen from the new subprocess module. Use the -s 
option in the popen_bug.py script to test this. 

Tested on Linux RedHat Enterprise 3 for Python 2.3.3, 
Python 2.3.5 and Python 2.4.1 and Solaris for Python 2.
4.1. The error did not occur on a RedHat 7.3 machine 
with Python 2.3.5. See the attached file popen_bug.py for 
details on the platforms.



----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-23 21:17

Message:
Logged In: YES 
user_id=33168

I agree with your comment about setting self.sts to 0.  That
was the problem I alluded to on python-dev.

Although I dislike __del__, this does seem like an
appropriate place to do the modification of _active.

Note that currently all os.error's are swallowed in poll().
 I'm not sure if that was the best idea, but that's the
current interface.  wait() does *not* catch any exceptions.

I wasn't really sure what to do about threads.  The threads
could always manage their calls into a popen object like you
propose (don't try to handle simultaneous calls to poll and
wait).  Another question I had was if popen should be
deprecated in favor of subprocess?

I've attached a patch which I think implements your
suggestion.  It also seems to fix all the problems.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-03-23 16:37

Message:
Logged In: YES 
user_id=21627

I don't understand why you are setting self.sts to 0 if wait
fails: most likely, there was a simultaneous call to .poll,
which should have set self.sts to the real return value. So
we should return that instead.

I think the whole issue can be avoid if we use resurrection:
If __del__ would put unwaited objects into _active, rather
than __init__, it would not happen that _cleanup polls a pid
which a thread still intends to wait for. In fact, it would
be sufficient to only put the pid into _active (avoiding the
need for resurrection).

If then a thread calls poll explicitly, and another calls
wait, they deserve to lose (with ECHILD). I would claim the
same error exists if part of the application calls
os.wait[3,4](), and another calls .wait later - they also
deserve the exception.

With that approach, I don't think further thread
synchronization would be needed.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-23 00:41

Message:
Logged In: YES 
user_id=33168

The attached patch fixes the problem for me.  It also
addresses another issue where wait could be called from
outside the popen2 module.  I'm not sure this is the best
solution.  I'm not sure there really is a good solution. 
Perhaps it's best to allow an exception to be raised?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183780&group_id=5470

From noreply at sourceforge.net  Fri Mar 24 06:42:07 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 23 Mar 2006 21:42:07 -0800
Subject: [ python-Bugs-1457411 ] byext.py errors
Message-ID: <E1FMf3n-0004Hb-8u@sc8-sf-web2.sourceforge.net>

Bugs item #1457411, was opened at 2006-03-23 15:45
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457411&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Demos and Tools
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jeff Lowery (jlowery2006)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: byext.py errors

Initial Comment:
statdir() method make reference to undefined 'ext' 
variable:

    def statdir(self, dir):
        self.addstats("<dir>", "dirs", 1)
        try:
            names = os.listdir(dir)
        except os.error, err:
            sys.stderr.write("Can't list %s: %s\n" % 
(file, err))
            self.addstats(ext, "unlistable", 1)
            return
        names.sort()
        ...

also, a number of the error strings throughout the 
program refer to 'file', which I believe is the built-
in (shouldn't it be the name of a parameter?).

This file is in the Tools/Scripts directory of the 
Python install folder.




----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-23 21:42

Message:
Logged In: YES 
user_id=33168

Thanks!

Committed revision 43269.
Committed revision 43270. (2.4)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457411&group_id=5470

From noreply at sourceforge.net  Fri Mar 24 08:40:38 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 23 Mar 2006 23:40:38 -0800
Subject: [ python-Bugs-1183780 ] Popen4 wait() fails sporadically with threads
Message-ID: <E1FMguU-0000g1-G9@sc8-sf-web6.sourceforge.net>

Bugs item #1183780, was opened at 2005-04-15 16:27
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183780&group_id=5470

Please note that this message 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: Taale Skogan (tskogan)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Popen4 wait() fails sporadically with threads

Initial Comment:
Calling wait() on a popen2.Popen4 object fails 
intermittently with the error

Traceback (most recent call last):
  ...
  File "/usr/local/lib/python2.3/popen2.py", line 90, in wait
    pid, sts = os.waitpid(self.pid, 0)
OSError: [Errno 10] No child processes

when using threads. 

The problem seems to be a race condition when a thread 
calls wait() on a popen2.Popen4 object. This also apllies 
to Popen3 objects. 

The constructor of Popen4. calls _cleanup() which calls 
poll() which calls the system call waitpid() for all acitve 
child processes. If another thread calls poll() before the 
current thread calls wait() on it's child process and the 
child process has terminated, the child process is no 
longer waitable and the second call to wait() fails.

Code to replicate this behavoir is attached in popen_bug.
py.

Solution: Popen4 and Popen3 should be threadsafe.

Related modules: A seemingly related error occurs with 
Popen from the new subprocess module. Use the -s 
option in the popen_bug.py script to test this. 

Tested on Linux RedHat Enterprise 3 for Python 2.3.3, 
Python 2.3.5 and Python 2.4.1 and Solaris for Python 2.
4.1. The error did not occur on a RedHat 7.3 machine 
with Python 2.3.5. See the attached file popen_bug.py for 
details on the platforms.



----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-03-24 08:40

Message:
Logged In: YES 
user_id=21627

This looks all fine.

As a further issue, I think _cleanup should also clean
processes which already have been waited on. So if waitpid
gives ECHILD (in _cleanup), I think the object should get
removed from _active - otherwise, it would stay there
forever. Of course, care is then need to avoid __del__
adding it back to _active.

Putting these all together, I propose v3 of the patch.

Another aspect that puzzles me is the repeated test that
waitpid() really returns the pid you asked for. How could it
not? If it fails, you get an os.error.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-24 06:17

Message:
Logged In: YES 
user_id=33168

I agree with your comment about setting self.sts to 0.  That
was the problem I alluded to on python-dev.

Although I dislike __del__, this does seem like an
appropriate place to do the modification of _active.

Note that currently all os.error's are swallowed in poll().
 I'm not sure if that was the best idea, but that's the
current interface.  wait() does *not* catch any exceptions.

I wasn't really sure what to do about threads.  The threads
could always manage their calls into a popen object like you
propose (don't try to handle simultaneous calls to poll and
wait).  Another question I had was if popen should be
deprecated in favor of subprocess?

I've attached a patch which I think implements your
suggestion.  It also seems to fix all the problems.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-03-24 01:37

Message:
Logged In: YES 
user_id=21627

I don't understand why you are setting self.sts to 0 if wait
fails: most likely, there was a simultaneous call to .poll,
which should have set self.sts to the real return value. So
we should return that instead.

I think the whole issue can be avoid if we use resurrection:
If __del__ would put unwaited objects into _active, rather
than __init__, it would not happen that _cleanup polls a pid
which a thread still intends to wait for. In fact, it would
be sufficient to only put the pid into _active (avoiding the
need for resurrection).

If then a thread calls poll explicitly, and another calls
wait, they deserve to lose (with ECHILD). I would claim the
same error exists if part of the application calls
os.wait[3,4](), and another calls .wait later - they also
deserve the exception.

With that approach, I don't think further thread
synchronization would be needed.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-23 09:41

Message:
Logged In: YES 
user_id=33168

The attached patch fixes the problem for me.  It also
addresses another issue where wait could be called from
outside the popen2 module.  I'm not sure this is the best
solution.  I'm not sure there really is a good solution. 
Perhaps it's best to allow an exception to be raised?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183780&group_id=5470

From noreply at sourceforge.net  Fri Mar 24 08:56:45 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 23 Mar 2006 23:56:45 -0800
Subject: [ python-Bugs-1183780 ] Popen4 wait() fails sporadically with threads
Message-ID: <E1FMhA5-0004Am-Da@sc8-sf-web3.sourceforge.net>

Bugs item #1183780, was opened at 2005-04-15 07:27
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183780&group_id=5470

Please note that this message 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: Accepted
Priority: 5
Submitted By: Taale Skogan (tskogan)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Popen4 wait() fails sporadically with threads

Initial Comment:
Calling wait() on a popen2.Popen4 object fails 
intermittently with the error

Traceback (most recent call last):
  ...
  File "/usr/local/lib/python2.3/popen2.py", line 90, in wait
    pid, sts = os.waitpid(self.pid, 0)
OSError: [Errno 10] No child processes

when using threads. 

The problem seems to be a race condition when a thread 
calls wait() on a popen2.Popen4 object. This also apllies 
to Popen3 objects. 

The constructor of Popen4. calls _cleanup() which calls 
poll() which calls the system call waitpid() for all acitve 
child processes. If another thread calls poll() before the 
current thread calls wait() on it's child process and the 
child process has terminated, the child process is no 
longer waitable and the second call to wait() fails.

Code to replicate this behavoir is attached in popen_bug.
py.

Solution: Popen4 and Popen3 should be threadsafe.

Related modules: A seemingly related error occurs with 
Popen from the new subprocess module. Use the -s 
option in the popen_bug.py script to test this. 

Tested on Linux RedHat Enterprise 3 for Python 2.3.3, 
Python 2.3.5 and Python 2.4.1 and Solaris for Python 2.
4.1. The error did not occur on a RedHat 7.3 machine 
with Python 2.3.5. See the attached file popen_bug.py for 
details on the platforms.



----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-23 23:56

Message:
Logged In: YES 
user_id=33168

It makes sense to remove from _active on ECHILD.

I wondered the same thing about waitpid(), but left it as it
was.  I don't believe it's possible for waitpid to return
any pid other than what you ask for unless the O/S is very,
very broken.

This patch is fine with me, feel free to check it in.  BTW,
nice comments and precondition checks in the test.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-03-23 23:40

Message:
Logged In: YES 
user_id=21627

This looks all fine.

As a further issue, I think _cleanup should also clean
processes which already have been waited on. So if waitpid
gives ECHILD (in _cleanup), I think the object should get
removed from _active - otherwise, it would stay there
forever. Of course, care is then need to avoid __del__
adding it back to _active.

Putting these all together, I propose v3 of the patch.

Another aspect that puzzles me is the repeated test that
waitpid() really returns the pid you asked for. How could it
not? If it fails, you get an os.error.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-23 21:17

Message:
Logged In: YES 
user_id=33168

I agree with your comment about setting self.sts to 0.  That
was the problem I alluded to on python-dev.

Although I dislike __del__, this does seem like an
appropriate place to do the modification of _active.

Note that currently all os.error's are swallowed in poll().
 I'm not sure if that was the best idea, but that's the
current interface.  wait() does *not* catch any exceptions.

I wasn't really sure what to do about threads.  The threads
could always manage their calls into a popen object like you
propose (don't try to handle simultaneous calls to poll and
wait).  Another question I had was if popen should be
deprecated in favor of subprocess?

I've attached a patch which I think implements your
suggestion.  It also seems to fix all the problems.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-03-23 16:37

Message:
Logged In: YES 
user_id=21627

I don't understand why you are setting self.sts to 0 if wait
fails: most likely, there was a simultaneous call to .poll,
which should have set self.sts to the real return value. So
we should return that instead.

I think the whole issue can be avoid if we use resurrection:
If __del__ would put unwaited objects into _active, rather
than __init__, it would not happen that _cleanup polls a pid
which a thread still intends to wait for. In fact, it would
be sufficient to only put the pid into _active (avoiding the
need for resurrection).

If then a thread calls poll explicitly, and another calls
wait, they deserve to lose (with ECHILD). I would claim the
same error exists if part of the application calls
os.wait[3,4](), and another calls .wait later - they also
deserve the exception.

With that approach, I don't think further thread
synchronization would be needed.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-23 00:41

Message:
Logged In: YES 
user_id=33168

The attached patch fixes the problem for me.  It also
addresses another issue where wait could be called from
outside the popen2 module.  I'm not sure this is the best
solution.  I'm not sure there really is a good solution. 
Perhaps it's best to allow an exception to be raised?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183780&group_id=5470

From noreply at sourceforge.net  Fri Mar 24 09:16:15 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 24 Mar 2006 00:16:15 -0800
Subject: [ python-Bugs-1183780 ] Popen4 wait() fails sporadically with threads
Message-ID: <E1FMhSx-0005RD-Rj@sc8-sf-web3.sourceforge.net>

Bugs item #1183780, was opened at 2005-04-15 16:27
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183780&group_id=5470

Please note that this message 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: Accepted
Priority: 5
Submitted By: Taale Skogan (tskogan)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Popen4 wait() fails sporadically with threads

Initial Comment:
Calling wait() on a popen2.Popen4 object fails 
intermittently with the error

Traceback (most recent call last):
  ...
  File "/usr/local/lib/python2.3/popen2.py", line 90, in wait
    pid, sts = os.waitpid(self.pid, 0)
OSError: [Errno 10] No child processes

when using threads. 

The problem seems to be a race condition when a thread 
calls wait() on a popen2.Popen4 object. This also apllies 
to Popen3 objects. 

The constructor of Popen4. calls _cleanup() which calls 
poll() which calls the system call waitpid() for all acitve 
child processes. If another thread calls poll() before the 
current thread calls wait() on it's child process and the 
child process has terminated, the child process is no 
longer waitable and the second call to wait() fails.

Code to replicate this behavoir is attached in popen_bug.
py.

Solution: Popen4 and Popen3 should be threadsafe.

Related modules: A seemingly related error occurs with 
Popen from the new subprocess module. Use the -s 
option in the popen_bug.py script to test this. 

Tested on Linux RedHat Enterprise 3 for Python 2.3.3, 
Python 2.3.5 and Python 2.4.1 and Solaris for Python 2.
4.1. The error did not occur on a RedHat 7.3 machine 
with Python 2.3.5. See the attached file popen_bug.py for 
details on the platforms.



----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-03-24 09:16

Message:
Logged In: YES 
user_id=21627

Committed as 43286. I also added .cmd to Popen4.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-24 08:56

Message:
Logged In: YES 
user_id=33168

It makes sense to remove from _active on ECHILD.

I wondered the same thing about waitpid(), but left it as it
was.  I don't believe it's possible for waitpid to return
any pid other than what you ask for unless the O/S is very,
very broken.

This patch is fine with me, feel free to check it in.  BTW,
nice comments and precondition checks in the test.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-03-24 08:40

Message:
Logged In: YES 
user_id=21627

This looks all fine.

As a further issue, I think _cleanup should also clean
processes which already have been waited on. So if waitpid
gives ECHILD (in _cleanup), I think the object should get
removed from _active - otherwise, it would stay there
forever. Of course, care is then need to avoid __del__
adding it back to _active.

Putting these all together, I propose v3 of the patch.

Another aspect that puzzles me is the repeated test that
waitpid() really returns the pid you asked for. How could it
not? If it fails, you get an os.error.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-24 06:17

Message:
Logged In: YES 
user_id=33168

I agree with your comment about setting self.sts to 0.  That
was the problem I alluded to on python-dev.

Although I dislike __del__, this does seem like an
appropriate place to do the modification of _active.

Note that currently all os.error's are swallowed in poll().
 I'm not sure if that was the best idea, but that's the
current interface.  wait() does *not* catch any exceptions.

I wasn't really sure what to do about threads.  The threads
could always manage their calls into a popen object like you
propose (don't try to handle simultaneous calls to poll and
wait).  Another question I had was if popen should be
deprecated in favor of subprocess?

I've attached a patch which I think implements your
suggestion.  It also seems to fix all the problems.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-03-24 01:37

Message:
Logged In: YES 
user_id=21627

I don't understand why you are setting self.sts to 0 if wait
fails: most likely, there was a simultaneous call to .poll,
which should have set self.sts to the real return value. So
we should return that instead.

I think the whole issue can be avoid if we use resurrection:
If __del__ would put unwaited objects into _active, rather
than __init__, it would not happen that _cleanup polls a pid
which a thread still intends to wait for. In fact, it would
be sufficient to only put the pid into _active (avoiding the
need for resurrection).

If then a thread calls poll explicitly, and another calls
wait, they deserve to lose (with ECHILD). I would claim the
same error exists if part of the application calls
os.wait[3,4](), and another calls .wait later - they also
deserve the exception.

With that approach, I don't think further thread
synchronization would be needed.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-23 09:41

Message:
Logged In: YES 
user_id=33168

The attached patch fixes the problem for me.  It also
addresses another issue where wait could be called from
outside the popen2 module.  I'm not sure this is the best
solution.  I'm not sure there really is a good solution. 
Perhaps it's best to allow an exception to be raised?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183780&group_id=5470

From noreply at sourceforge.net  Fri Mar 24 09:33:07 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 24 Mar 2006 00:33:07 -0800
Subject: [ python-Bugs-1456470 ] sliceobject ssize_t (and index) not completed
Message-ID: <E1FMhjH-0002uK-5W@sc8-sf-web5.sourceforge.net>

Bugs item #1456470, was opened at 2006-03-22 23:06
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456470&group_id=5470

Please note that this 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: 6
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Martin v. L??wis (loewis)
Summary: sliceobject ssize_t (and index) not completed

Initial Comment:
sliceobject and ceval changed the parameter types of 
slice objects to ssize_t, but the code still requires 
an int (sometimes not even a long); it should use the 
new __index__ slot; at the very least, it should be 
consistent about what it does accept.

In http://svn.python.org/view/python/trunk/Objects/
sliceobject.c?rev=42382&view=markup

[issue 1] function PySlice_GetIndices takes Py_ssize_t 
parameters for (length, start, stop, step)

but then does a PyInt_Check on each of start, stop, 
step.  (An XXX to allow longs was also removed.)  It *
should* use the new __index__ slot.

[issue 2] Later in the same file, function slice_
indices takes a PyObject len parameter, but then uses 
PyInt_AsLong rather than __index__ (or even PyInt_
AsSsize_t) to create Py_ssize_t ilen.

[issue 3]

http://svn.python.org/view/python/trunk/Python/ceval.c?
rev=42382&view=markup

function _PyEval_SliceIndex accepts only ints and 
longs, and longs will be converted to ints with 
clipping.  

It should allow anything with __index__, and clip only 
to ssize_t rather than int.

[issue 4] ISINT still insists on int or long -- I 
thought I saw a fix for this already in the index 
patches.

[issue 5]
apply_slice and assign_slice changed the types of ilow 
and ihigh, but still initializes them to INT_MAX 
rather than ssize_t max.




----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-03-24 09:33

Message:
Logged In: YES 
user_id=21627

Would you like to work on a patch?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456470&group_id=5470

From noreply at sourceforge.net  Fri Mar 24 16:10:52 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 24 Mar 2006 07:10:52 -0800
Subject: [ python-Bugs-1457783 ] Malloc error on MacOSX/imaplib
Message-ID: <E1FMnwC-0002mJ-PV@sc8-sf-web5.sourceforge.net>

Bugs item #1457783, was opened at 2006-03-24 10: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=1457783&group_id=5470

Please note that this message 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: Andreas Jung (ajung)
Assigned to: Nobody/Anonymous (nobody)
Summary: Malloc error on MacOSX/imaplib

Initial Comment:
I am using Python 2.4.2 on MacOSX (10.4.5). Fetching
mails with larger attachments (2MB or so) using IMAP
(with getmail) fails:

python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
    File "/opt/python-2.4.2/bin/getmail", line 558, in main
    go(configs)
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
    File "/opt/python-2.4.2/bin/getmail", line 112, in go
    msg = retriever.getmsg(msgid)
    File
"/opt/python-2.4.2/lib/python2.4/site-packages/getmailcore/_retrieverbases.py",
line 383, in getmsg
    return self._getmsgbyid(msgid)
    File
"/opt/python-2.4.2/lib/python2.4/site-packages/getmailcore/_retrieverbases.py",
line 750, in _getmsgbyid
    return self._getmsgpartbyid(msgid, '(RFC822)')
    File
"/opt/python-2.4.2/lib/python2.4/site-packages/getmailcore/_retrieverbases.py",
line 731, in _getmsgpartbyid
    response = self._parse_imapuidcmdresponse('FETCH',
uid, part)
    File
"/opt/python-2.4.2/lib/python2.4/site-packages/getmailcore/_retrieverbases.py",
line 621, in _parse_imapuidcmdresponse
    result, resplist = self.conn.uid(cmd, *args)
    File "/opt/python-2.4.2/lib/python2.4/imaplib.py",
line 725, in uid
    typ, dat = self._simple_command(name, command, *args)
    File "/opt/python-2.4.2/lib/python2.4/imaplib.py",
line 1028, in _simple_command
    return self._command_complete(name,
self._command(name, *args))
    File "/opt/python-2.4.2/lib/python2.4/imaplib.py",
line 858, in _command_complete
    typ, data = self._get_tagged_response(tag)
    File "/opt/python-2.4.2/lib/python2.4/imaplib.py",
line 959, in _get_tagged_response
    self._get_response()
    File "/opt/python-2.4.2/lib/python2.4/imaplib.py",
line 921, in _get_response
    data = self.read(size)
    File "/opt/python-2.4.2/lib/python2.4/imaplib.py",
line 1123, in read
    data = self.sslobj.read(size-read)
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
  MemoryError



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457783&group_id=5470

From noreply at sourceforge.net  Fri Mar 24 17:10:50 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 24 Mar 2006 08:10:50 -0800
Subject: [ python-Bugs-1457823 ] cgi.FormContentDict constructor should
	support parse options
Message-ID: <E1FMosE-0006aq-Oq@sc8-sf-web5.sourceforge.net>

Bugs item #1457823, was opened at 2006-03-25 01: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=1457823&group_id=5470

Please note that this message 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 Belmonte (jbelmonte)
Assigned to: Nobody/Anonymous (nobody)
Summary: cgi.FormContentDict constructor should support parse options

Initial Comment:
cgi.FormContentDict (and cgi.SvFormContentDict) should
take optional keep_blank_values and strict_parsing args
and pass them on to cgi.parse().  In my use case
neither of the parse defaults is what I want, so I'm
faced with having to hack or re-implement
SvFormContentDict.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457823&group_id=5470

From noreply at sourceforge.net  Fri Mar 24 18:12:43 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 24 Mar 2006 09:12:43 -0800
Subject: [ python-Bugs-1457264 ] urllib.splithost parses incorrectly
Message-ID: <E1FMpq7-0002M4-SQ@sc8-sf-web4-b.sourceforge.net>

Bugs item #1457264, was opened at 2006-03-23 20:49
Message generated for change (Comment added) made by onlynone
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457264&group_id=5470

Please note that this message 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: Steve (onlynone)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib.splithost parses incorrectly

Initial Comment:
urllib.splithost(url) requires that the url passed in
be of the form '//host[:port]/path'. Yet I've run
across some urls that are of the form
'//host[:port]?querystring'. This causes splithost to
return everything as the host and nothing as the path.


Section 3.2 of rfc2396 (Uniform Resource Identifiers:
Generic Syntax) states that 'The authority component is
preceded by a double slash "//" and is terminated by
the next slash "/", question-mark "?", or by the end of
the URI.'

Also, this is how it defines a URI:

absoluteURI   = scheme ":" ( hier_part | opaque_part )
hier_part     = ( net_path | abs_path ) [ "?" query ]
net_path      = "//" authority [ abs_path ]
abs_path      = "/"  path_segments

Based on the above, you could certainly have:
'http://authority?query' as a valid url.


In python2.3 you would just need to change line 939 in
urllib.py from:

        _hostprog = re.compile('^//([^/]*)(.*)$')

to:

        _hostprog = re.compile('^//([^/?]*)(.*)$')

This appears to affect all python versions, I just
happened to be using 2.3.

----------------------------------------------------------------------

>Comment By: Steve (onlynone)
Date: 2006-03-24 17:12

Message:
Logged In: YES 
user_id=1299996

The problem I was having specifically was that the url had a
colon in the query string. Since the query string was being
parsed as part of the host, the text after the colon was
being treated as the port when urllib.splitport was called
later. The following is a simple testcase:

import urllib2
webpage = urllib2.urlopen("http://host.com?a=b:3b")

You will then get a "httplib.InvalidURL: nonnumeric port: '3b'"

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457264&group_id=5470

From noreply at sourceforge.net  Fri Mar 24 20:21:37 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 24 Mar 2006 11:21:37 -0800
Subject: [ python-Bugs-1457470 ] regs attribute on regex objects not documented
Message-ID: <E1FMrqr-0002Az-0y@sc8-sf-web4-b.sourceforge.net>

Bugs item #1457470, was opened at 2006-03-24 01:41
Message generated for change (Comment added) made by jlowery2006
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457470&group_id=5470

Please note that this 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: Jeff Lowery (jlowery2006)
Assigned to: Nobody/Anonymous (nobody)
Summary: regs attribute on regex objects not documented

Initial Comment:
Came across the use of <regex object>.regs attribute in 
the tools/scripts/classfix.py program (line 162), but 
it's not an attribute that's documented in the Python 
Library Reference.



----------------------------------------------------------------------

>Comment By: Jeff Lowery (jlowery2006)
Date: 2006-03-24 19:21

Message:
Logged In: YES 
user_id=1484419

It was pointed out to me on the comp.lang.python list that 
regs is part of the now-defunction regex package.

Perhaps it would be possible to denote the module as 
deprecated in the regex.py code?  Dunno, but I do know that 
PyLint didn't pick up on it as being deprecated.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457470&group_id=5470

From noreply at sourceforge.net  Fri Mar 24 22:17:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 24 Mar 2006 13:17:23 -0800
Subject: [ python-Bugs-1458017 ] Log._log needs to be more forgiving...
Message-ID: <E1FMtet-0001xf-PT@sc8-sf-web6.sourceforge.net>

Bugs item #1458017, was opened at 2006-03-24 15: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=1458017&group_id=5470

Please note that this 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: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: Log._log needs to be more forgiving...

Initial Comment:
The _log method of distutils' Log class executes

    print msg % args

where args might be an empty tuple (the methods that
call _log all
have varargs signatures).  If that's the case and msg
happens to
contain a % sign, it barfs.  It should be more
forgiving, for
instance:

    def _log(self, level, msg, args):
        if level >= self.threshold:
            try:
                print msg % args
            except TypeError:
                if not args:
                    print msg
                else:
                    raise
            sys.stdout.flush()

I just corrected this locally for our 2.3 and 2.4
installations.  The
above is a bit ugly, but it does allow the common case
(msg contains a
% but an empty args list) to pass while still catching
most programmer
errors.  Distutils is trying to log this message (wrapped):

  gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes
  -fPIC -I/opt/app/mysql-5.0.19/include
  -I/opt/app/mysql-5.0.19/include
-I/opt/lang/python/include/python2.3
  -c _mysql.c -o build/temp.solaris-2.8-i86pc-2.3/_mysql.o
  -I/opt/app/mysql-5.0.19/include -xO3 -mt -fsimple=1
-ftrap=%none
  -nofstore -xbuiltin=%all -xlibmil -xlibmopt
-xtarget=generic

I suppose it would be better if all the places in
distutils which log
compiler commands without extra args escaped their %
signs.  This
seems like an acceptable compromise though.

Skip


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1458017&group_id=5470

From noreply at sourceforge.net  Sat Mar 25 05:56:58 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 24 Mar 2006 20:56:58 -0800
Subject: [ python-Bugs-892939 ] Race condition in popen2
Message-ID: <E1FN0pe-0005NP-Oo@sc8-sf-web6.sourceforge.net>

Bugs item #892939, was opened at 2004-02-08 09:31
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=892939&group_id=5470

Please note that this message 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: Pending
>Resolution: Fixed
Priority: 6
Submitted By: Ken McNeil (kenmcneil)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Race condition in popen2

Initial Comment:
The "fix" for bug #761888 created a race condition in
Popen3  . The interaction between wait and _cleanup is
the root of the problem.

def wait(self):
  """Wait for and return the exit status of the child
process."""
  if self.sts < 0:
    pid, sts = os.waitpid(self.pid, 0)
    if pid == self.pid:
      self.sts = sts
  return self.sts

def _cleanup():
    for inst in _active[:]:
        inst.poll()

In wait, between the check of self.sts and the call to
os.waitpid a new Popen3 object can be created in
another thread which will trigger a call to _cleanup.
Since the call to _cleanup polls the process, when the
thread running wait starts back up again it will try to
poll the process using os.waitpid, which will throw an
OSError because os.waitpid has already been called for
the PID indirectly in _cleanup.

A work around is for the caller of wait to catch the
OSError and check the sts field, and if sts is
non-negative then the OSError is most likely because of
this problem and can be ignored. However, sts is
undocumented and should probably stay that way.

My suggestion is that the patch that added _active, 
_cleanup, and all  be removed and a more suitable
mechanism for fixing bug #761888 be found. As it has
been said in the discussion of bug #761888, magically
closing FDs is not a "good thing". It seems to me that
surrounding the call to os.fork with a try/except, and
closing the pipes in the except, would be suitable but
I don't know how this would interact with a failed call
to fork, therefore I wont provide a patch.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-24 20:56

Message:
Logged In: YES 
user_id=33168

Martin and I worked out a patch which should solve this
problem and it was committed.  For more info see bug
1183780,   If this does not solve the problem, change the
status from pending to open.  Otherwise, this bug report
should close automatically in a couple of weeks since it's
pending.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-23 00:47

Message:
Logged In: YES 
user_id=33168

I believe this is basically a duplicate of 1183780.  There
is a patch attached there.  Can you verify if it fixes your
problem?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=892939&group_id=5470

From noreply at sourceforge.net  Sat Mar 25 05:59:18 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 24 Mar 2006 20:59:18 -0800
Subject: [ python-Bugs-998246 ] Popen3.poll race condition
Message-ID: <E1FN0ru-00067S-VW@sc8-sf-web1.sourceforge.net>

Bugs item #998246, was opened at 2004-07-26 12:14
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=998246&group_id=5470

Please note that this message 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: Fixed
Priority: 5
Submitted By: Tres Seaver (tseaver)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Popen3.poll race condition

Initial Comment:
poll() swallows all IOErrors, including ENOCHILD;  if
the child process exits before poll is called, then an
applications which loops on
poll() will never exit.

I am working around this (against Python 2.3.3) via the
following:


                try:
                    pid, status = os.waitpid(proc.pid,
os.WNOHANG)
                except os.error, e:
                    if e.errno == 10:  # ENOCHILD
                        result = 0
                    else:
                        raise
                else:
                    if pid == proc.pid:
                        result = status


where 'proc' is an instance of Popen3.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-24 20:59

Message:
Logged In: YES 
user_id=33168

Tres, Martin and I worked out a patch that we thinks solves
the problem.  It's checked in.  See the other bug report for
more info.  If you don't believe the patch will fix your
problem, change the status from pending to open.  Otherwise,
this bug should automatically close in a couple of weeks.

----------------------------------------------------------------------

Comment By: Tres Seaver (tseaver)
Date: 2006-03-23 04:21

Message:
Logged In: YES 
user_id=127625

1183780 is indeed a similar bug, although he reports it
against Popen4 rather than Popen3.  His patch needs to be
modified to re-raise errors which are not ENOCHILD, however.

I no longer have accees to either the application or the
machine where I found this issue, and hence can't verify that
the patch fixes the code which triggered the problem.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-23 00:45

Message:
Logged In: YES 
user_id=33168

I believe this is basically a duplicate of 1183780.  There
is a patch attached there.  Can you verify if it fixes your
problem?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=998246&group_id=5470

From noreply at sourceforge.net  Sat Mar 25 08:04:38 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 24 Mar 2006 23:04:38 -0800
Subject: [ python-Bugs-1033390 ] build doesn't pick up bsddb w/Mandrake 9.2
Message-ID: <E1FN2pC-0007Qh-VT@sc8-sf-web3.sourceforge.net>

Bugs item #1033390, was opened at 2004-09-23 06:58
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033390&group_id=5470

Please note that this 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: Alex Martelli (aleax)
Assigned to: Neal Norwitz (nnorwitz)
Summary: build doesn't pick up bsddb w/Mandrake 9.2

Initial Comment:
Mandrake 9.2 installs bsddb 4.1 under /usr/lib, and apparently 
Python 2.4a3's setup.py doesn't pick it up -- adding /usr/lib to the 
list of directories where bsddb 4 is being searched for, and 
rerunning make, seems to fix the problem.  (Problem does not 
appear on Mandrake 9.1, where I had installed sleepycat's stuff 
under /usr/local/BerkeleyDB.4.1 "by hand"; nor on MacOSX, where 
I had a fink-installed one in /sw/lib; no similar problem with any 
other module on any of these platforms, except bsddb).


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-01-24 22:10

Message:
Logged In: YES 
user_id=33168

Alex?  I suspect this isn't a problem any longer.  If we
don't hear back within a month, we'll close this report.

----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2004-12-13 04:15

Message:
Logged In: YES 
user_id=413

Could you try this again using python CVS HEAD.  I just committed a rework of setup.py's bsddb library+include file finding code that hopefully does the right thing for you.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033390&group_id=5470

From noreply at sourceforge.net  Sat Mar 25 11:42:41 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 25 Mar 2006 02:42:41 -0800
Subject: [ python-Bugs-1458220 ] sys.maxint should be mentioned in explanation
	of int type
Message-ID: <E1FN6ED-0000Ho-BJ@sc8-sf-web5.sourceforge.net>

Bugs item #1458220, was opened at 2006-03-25 11: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=1458220&group_id=5470

Please note that this 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: Christoph Zwerschke (cito)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.maxint should be mentioned in explanation of int type

Initial Comment:
The Lib Reference says in section 2.3.4 (Numeric Types
-- int, float, long, complex):

"Plain integers (also just called integers) are
implemented using long in C, which gives them at least
32 bits of precision."

I think it would be helpful to insert the following
sentence here: "The maximum value on your platform is
sys.maxint."

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1458220&group_id=5470

From noreply at sourceforge.net  Sat Mar 25 11:42:56 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 25 Mar 2006 02:42:56 -0800
Subject: [ python-Bugs-1458220 ] sys.maxint should be mentioned in explanation
	of int type
Message-ID: <E1FN6ES-0001XM-IG@sc8-sf-web6.sourceforge.net>

Bugs item #1458220, was opened at 2006-03-25 11:42
Message generated for change (Settings changed) made by cito
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1458220&group_id=5470

Please note that this 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: 2
Submitted By: Christoph Zwerschke (cito)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.maxint should be mentioned in explanation of int type

Initial Comment:
The Lib Reference says in section 2.3.4 (Numeric Types
-- int, float, long, complex):

"Plain integers (also just called integers) are
implemented using long in C, which gives them at least
32 bits of precision."

I think it would be helpful to insert the following
sentence here: "The maximum value on your platform is
sys.maxint."

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1458220&group_id=5470

From noreply at sourceforge.net  Sat Mar 25 22:29:13 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 25 Mar 2006 13:29:13 -0800
Subject: [ python-Bugs-1457358 ] floor division not documented
Message-ID: <E1FNGJt-0000ju-Qe@sc8-sf-web1.sourceforge.net>

Bugs item #1457358, was opened at 2006-03-23 14:36
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457358&group_id=5470

Please note that this 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: 3
Submitted By: Christoph Zwerschke (cito)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: floor division not documented

Initial Comment:
In chapter 2.3.4 of the Lib Reference
(2.3.4 Numeric Types -- int, float, long, complex),
the floor division operator (//) is missing.
It is only referred to in the explanation of the divmod
operator, but without explaining the meaning of //
itself. I think it would be good to make the //
operator more popular, so people can start to make
their code future proof.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-25 13:29

Message:
Logged In: YES 
user_id=33168

The change should appear within 12 hours in both places:
http://docs.python.org/dev/
http://docs.python.org/dev/2.4/

Committed revision 43312.
Committed revision 43313. (2.4)



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457358&group_id=5470

From noreply at sourceforge.net  Sun Mar 26 22:33:32 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 26 Mar 2006 12:33:32 -0800
Subject: [ python-Bugs-1458903 ] lambda with a parenthesized argument raises
	TypeError
Message-ID: <E1FNbvY-0007te-Vf@sc8-sf-web4-b.sourceforge.net>

Bugs item #1458903, was opened at 2006-03-27 05: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=1458903&group_id=5470

Please note that this 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: Jeong-Min Lee (falsetru)
Assigned to: Nobody/Anonymous (nobody)
Summary: lambda with a parenthesized argument raises TypeError

Initial Comment:
==================================================
falsetru at lj-lw20 ~ $ python2.5
Python 2.5a0 (trunk:43324, Mar 26 2006, 14:18:23)
[GCC 3.4.5 (Gentoo 3.4.5, ssp-3.4.5-1.0, pie-8.7.9)] on
linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> (lambda(x): x)(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 1, in <lambda>
TypeError: unpack non-sequence
>>> (lambda(x): x)((1,))
1
>>> (lambda(x): x)((1,2))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 1, in <lambda>
ValueError: too many values to unpack
>>>




not 2.4 compatible
==================================================
falsetru at lj-lw20 ~ $ python2.4
Python 2.4.2 (#1, Oct 15 2005, 13:17:32)
[GCC 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)] on
linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> (lambda(x): x)(1)
1
>>> (lambda(x): x)((1,))
(1,)
>>> (lambda(x): x)((1,2))
(1, 2)
>>>

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1458903&group_id=5470

From noreply at sourceforge.net  Sun Mar 26 22:34:43 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 26 Mar 2006 12:34:43 -0800
Subject: [ python-Bugs-1458903 ] lambda with a parenthesized argument raises
	TypeError
Message-ID: <E1FNbwh-0007ib-Mn@sc8-sf-web5.sourceforge.net>

Bugs item #1458903, was opened at 2006-03-26 20:33
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1458903&group_id=5470

Please note that this 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: Jeong-Min Lee (falsetru)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: lambda with a parenthesized argument raises TypeError

Initial Comment:
==================================================
falsetru at lj-lw20 ~ $ python2.5
Python 2.5a0 (trunk:43324, Mar 26 2006, 14:18:23)
[GCC 3.4.5 (Gentoo 3.4.5, ssp-3.4.5-1.0, pie-8.7.9)] on
linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> (lambda(x): x)(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 1, in <lambda>
TypeError: unpack non-sequence
>>> (lambda(x): x)((1,))
1
>>> (lambda(x): x)((1,2))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 1, in <lambda>
ValueError: too many values to unpack
>>>




not 2.4 compatible
==================================================
falsetru at lj-lw20 ~ $ python2.4
Python 2.4.2 (#1, Oct 15 2005, 13:17:32)
[GCC 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)] on
linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> (lambda(x): x)(1)
1
>>> (lambda(x): x)((1,))
(1,)
>>> (lambda(x): x)((1,2))
(1, 2)
>>>

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1458903&group_id=5470

From noreply at sourceforge.net  Sun Mar 26 22:37:55 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 26 Mar 2006 12:37:55 -0800
Subject: [ python-Bugs-1457470 ] regs attribute on regex objects not documented
Message-ID: <E1FNbzn-0007uQ-Rh@sc8-sf-web5.sourceforge.net>

Bugs item #1457470, was opened at 2006-03-24 01:41
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457470&group_id=5470

Please note that this 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: Out of Date
Priority: 5
Submitted By: Jeff Lowery (jlowery2006)
Assigned to: Nobody/Anonymous (nobody)
Summary: regs attribute on regex objects not documented

Initial Comment:
Came across the use of <regex object>.regs attribute in 
the tools/scripts/classfix.py program (line 162), but 
it's not an attribute that's documented in the Python 
Library Reference.



----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-26 20:37

Message:
Logged In: YES 
user_id=849994

regex will be removed in Python 2.5.

----------------------------------------------------------------------

Comment By: Jeff Lowery (jlowery2006)
Date: 2006-03-24 19:21

Message:
Logged In: YES 
user_id=1484419

It was pointed out to me on the comp.lang.python list that 
regs is part of the now-defunction regex package.

Perhaps it would be possible to denote the module as 
deprecated in the regex.py code?  Dunno, but I do know that 
PyLint didn't pick up on it as being deprecated.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457470&group_id=5470

From noreply at sourceforge.net  Sun Mar 26 22:42:06 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 26 Mar 2006 12:42:06 -0800
Subject: [ python-Feature Requests-1454344 ] Make more out of 'as' : general
	ad-hoc right-assignment
Message-ID: <E1FNc3q-0008Cz-Tk@sc8-sf-web5.sourceforge.net>

Feature Requests item #1454344, was opened at 2006-03-20 09:24
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1454344&group_id=5470

Please note that this message 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: Rejected
Priority: 5
Submitted By: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: Make more out of 'as' :  general ad-hoc right-assignment

Initial Comment:
"with EXPR as VAR" introduces 'as' as keyword.
Occupying a new 2-letter kw, Python could maybe make
more out of this:

* it was often asked for transitive assignments to
speed up the interrupted style of typing in Python

* yet transitive left-assignments = += *= ... would
indeed be an impact on pythonic discipline, create bad
readable syntax, which can easyly be confused with ==
etc inside of Expressions. It would be not intuitive,
with what value we are computing. Think e.g. of ugly
things like:
> a = ( 1+ (b.=2/x) ) 


Now trying a right-hand-assignment method using 'as'
everywhere:

> with open(x) as f:
>    f.write(s)

> if re.search(x,s) as m:
>    print m.group(1)
> elif re.search(y,s) as m:
>    print m.group(1)

> while (x+1 as x) not in l:
>    do()

> a = ( 1+ ( 2/x as b ) ), 2+b, 3+b 
> 

> print 'comment number', (id+1 as id)


* I cannot see any uglyness in this kind of
right-hand-assignment. Its intuitive 'english', speeds
up typing tremendously, the computed thing on left side
is still that, what is in the focus of reading.
And maybe most important: it supports a natural
evolutionary style of thinking: First you think about
what you want compute in expressions, then you can
store aside usefull stuff to somewhere happily.

* 'as'-evolution with extra operator is not too
tempting and clearly separated from the main =
'planning' doctrin

* The operator priority of 'as' right-assignments
should be higher than that of left-assignments and be
next before brackets and commas. Execution order from
left to right - that resolves as expected :

> a += b as c
> l=[ 1 as one, one+1 as two, {key as mykey:3 as three} ]
> d=dict(var1=pi/2 as pi_2, )

The later 'as' would of course set pi_2 in caller's
context.

A transitive 'as' would be more important than having
'is' for the same as '=='. In fact, if "with .. as .."
is possible, but "if .. as .." not, this would appear
as broken syntax design to python newcomers.

Robert


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-26 20:42

Message:
Logged In: YES 
user_id=849994

Rejecting this for now. It has been proposed on python-dev,
was not commented positively by Guido and won't be possible
without a PEP.

Regarding with .. as: In this context, "as" does _not_
assign the thing on its left to the name on its right. This
would lead to at least some confusion if "if .. as" did this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1454344&group_id=5470

From noreply at sourceforge.net  Sun Mar 26 22:47:55 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 26 Mar 2006 12:47:55 -0800
Subject: [ python-Feature Requests-1454364 ] Python space syntax & pythonic
	long lambda's
Message-ID: <E1FNc9T-00006H-S0@sc8-sf-web5.sourceforge.net>

Feature Requests item #1454364, was opened at 2006-03-20 09:43
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1454364&group_id=5470

Please note that this 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: Rejected
Priority: 5
Submitted By: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python space syntax & pythonic long lambda's

Initial Comment:
(see also c.l.p
http://groups.google.de/group/comp.lang.python/browse_frm/thread/fc2df1723f499eb7/f7e9b2ac5a6b5f16
)

After I had often nasty bugs because of mixup with the
global statement, my home made
"_global=sys.modules[__name__]" method (see also c.l.p
http://groups.google.de/group/comp.lang.python/browse_frm/thread/fc2df1723f499eb7/f7e9b2ac5a6b5f16
) prevents effectively such errors from my experience.
And code is better readable.

Despite maybe similar suggestions have already been
disregard, I put for discussion this version of
(compatible) extended space syntax for: better atomic
python expressions, improved readability, new key
capabilites for inter-frame/"block" access and
functional programming support:

See attached .txt document.

Robert


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-26 20:47

Message:
Logged In: YES 
user_id=849994

Rejecting this here. Please post to the python-dev or
python-3000 list with your suggestions and write a PEP if
you want to propose such a radical language change. (Of
course, your contribution is welcome!)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1454364&group_id=5470

From noreply at sourceforge.net  Sun Mar 26 23:00:34 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 26 Mar 2006 13:00:34 -0800
Subject: [ python-Bugs-1457264 ] urllib.splithost parses incorrectly
Message-ID: <E1FNcLi-0005Sx-FB@sc8-sf-web2.sourceforge.net>

Bugs item #1457264, was opened at 2006-03-23 20:49
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457264&group_id=5470

Please note that this message 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: 5
Submitted By: Steven Willis (onlynone)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib.splithost parses incorrectly

Initial Comment:
urllib.splithost(url) requires that the url passed in
be of the form '//host[:port]/path'. Yet I've run
across some urls that are of the form
'//host[:port]?querystring'. This causes splithost to
return everything as the host and nothing as the path.


Section 3.2 of rfc2396 (Uniform Resource Identifiers:
Generic Syntax) states that 'The authority component is
preceded by a double slash "//" and is terminated by
the next slash "/", question-mark "?", or by the end of
the URI.'

Also, this is how it defines a URI:

absoluteURI   = scheme ":" ( hier_part | opaque_part )
hier_part     = ( net_path | abs_path ) [ "?" query ]
net_path      = "//" authority [ abs_path ]
abs_path      = "/"  path_segments

Based on the above, you could certainly have:
'http://authority?query' as a valid url.


In python2.3 you would just need to change line 939 in
urllib.py from:

        _hostprog = re.compile('^//([^/]*)(.*)$')

to:

        _hostprog = re.compile('^//([^/?]*)(.*)$')

This appears to affect all python versions, I just
happened to be using 2.3.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-26 21:00

Message:
Logged In: YES 
user_id=849994

Fixed in rev. 43330.

----------------------------------------------------------------------

Comment By: Steven Willis (onlynone)
Date: 2006-03-24 17:12

Message:
Logged In: YES 
user_id=1299996

The problem I was having specifically was that the url had a
colon in the query string. Since the query string was being
parsed as part of the host, the text after the colon was
being treated as the port when urllib.splitport was called
later. The following is a simple testcase:

import urllib2
webpage = urllib2.urlopen("http://host.com?a=b:3b")

You will then get a "httplib.InvalidURL: nonnumeric port: '3b'"

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457264&group_id=5470

From noreply at sourceforge.net  Sun Mar 26 23:29:03 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 26 Mar 2006 13:29:03 -0800
Subject: [ python-Bugs-847665 ] XMLGenerator.startElementNS dies on
	EMPTY_NAMESPACE attribut
Message-ID: <E1FNcnH-0004Af-3y@sc8-sf-web6.sourceforge.net>

Bugs item #847665, was opened at 2003-11-23 18:21
Message generated for change (Comment added) made by ngrig
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=847665&group_id=5470

Please note that this 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.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Stuart Bishop (zenzen)
Assigned to: Nobody/Anonymous (nobody)
Summary: XMLGenerator.startElementNS dies on EMPTY_NAMESPACE attribut

Initial Comment:
from xml.sax.saxutils import XMLGenerator

g = XMLGenerator(encoding='utf8')
STREAM_NAMESPACE = 'http://etherx.jabber.org/streams'
CLIENT_NAMESPACE = 'jabber:client'
g.startDocument()
g.startPrefixMapping('stream', STREAM_NAMESPACE)
g.startPrefixMapping('client', CLIENT_NAMESPACE)
g.startElementNS( 
    (STREAM_NAMESPACE, 'stream'), 'stream',
    {(None,'xmlns'): CLIENT_NAMESPACE}
    )

Dies with:
Traceback (most recent call last):
  File &quot;tst.py&quot;, line 11, in ?
    g.startElementNS( 
  File &quot;/System/Library/Frameworks/Python.framework/
Versions/2.3/lib/python2.3/xml/sax/saxutils.py&quot;, line 124, in 
startElementNS
    name = self._current_context[name[0]] + &quot;:&quot; + name[1]
KeyError: 'x'


Changing the end of XMLGenerator.startElementNS to the 
following makes it work the way I expect:

        for (name, value) in attrs.items():
            if name[0] is None:
                name = name[1]
            else:
                name = self._current_context[name[0]] + &quot;:&quot; + 
name[1]
            self._out.write(' %s=%s' % (name, 
quoteattr(value)))
        self._out.write('&gt;')


----------------------------------------------------------------------

Comment By: Nikolai Grigoriev (ngrig)
Date: 2006-03-27 01:29

Message:
Logged In: YES 
user_id=195108

This issue lasts for 2.5 years already. I feel like it is
somewhat stalled.

The processing of XML namespaces in saxutils.XMLGenerator is
so blatantly broken that I wonder if it ever has been tested
at all. I wrote down a simple smoke test for it:


import sys
from xml import sax
from xml.sax.saxutils import XMLGenerator
from StringIO import StringIO

tests = [
("No namespace, no attributes",     "<a/>"),
("No namespace, with attributes",   "<a b='c'/>"),
("Empty prefix, no attributes",     "<a xmlns='qux'/>"),
("Empty prefix, unprefixed attributes", "<a xmlns='qux'
b='c'/>"),
("Prefixed, no attributes",         "<my:a xmlns:my='qux'/>"),
("Prefixed, unprefixed attributes", "<my:a xmlns:my='qux'
b='c'/>"),               
("Prefixed, prefixed attributes",   "<my:a xmlns:my='qux'
my:b='c'/>"),
]
          
for (caption, testdoc) in tests:
    try:
        parser = sax.make_parser()
        parser.setFeature(sax.handler.feature_namespaces, 1)
        parser.setContentHandler(XMLGenerator(StringIO()))
        parser.parse(StringIO(testdoc))
        print caption, "- OK"
    except StandardError, e:
        print caption, "- FAILED:", e.__class__.__name__


With the current version of saxutils (as of Python 2.4.1), I
get 4 failures out of 7. Stuart Bishop's patch fixes the
issue; could someone commit it please?


----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2005-12-04 23:15

Message:
Logged In: YES 
user_id=11375

Please provide your changes in the form of a patch.


----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2005-12-04 23:02

Message:
Logged In: YES 
user_id=11375

Never mind my previous comment; I just noticed the
setContentHandler call.


----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2005-12-04 23:01

Message:
Logged In: YES 
user_id=11375

I don't understand your second example; it uses saxutils to
parse a file.  What's it got to do with XMLGenerator?

----------------------------------------------------------------------

Comment By: Stuart Bishop (zenzen)
Date: 2003-11-24 22:36

Message:
Logged In: YES 
user_id=46639

This method also appears to have trouble emmitting tags without a 
namespace prefix:

import xml.sax
import xml.sax.handler
import xml.sax.saxutils
x = '''&lt;?xml version=&quot;1.0&quot;?&gt;&lt;mechanisms xmlns='urn:ietf:
params:xml:ns:xmpp-sasl'
&gt;'''
parser = xml.sax.make_parser()
parser.setFeature(xml.sax.handler.feature_namespaces, True)
parser.setContentHandler(xml.sax.saxutils.XMLGenerator())
parser.feed(x)

dies with:
Traceback (most recent call last):
  File &quot;tst.py&quot;, line 30, in ?
    parser.feed(x)
  File &quot;/System/Library/Frameworks/Python.framework/Versions/
2.3/lib/python2.3/xml/sax/expatreader.py&quot;, line 207, in feed
    self._parser.Parse(data, isFinal)
  File &quot;/System/Library/Frameworks/Python.framework/Versions/
2.3/lib/python2.3/xml/sax/expatreader.py&quot;, line 337, in 
start_element_ns
    AttributesNSImpl(newattrs, qnames))
  File &quot;/System/Library/Frameworks/Python.framework/Versions/
2.3/lib/python2.3/xml/sax/saxutils.py&quot;, line 116, in startElementNS
    name = self._current_context[name[0]] + &quot;:&quot; + name[1]
TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'



I've attached my current replacement startElementNS method 
which appears to fix both this and the previous issue.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=847665&group_id=5470

From noreply at sourceforge.net  Sun Mar 26 23:38:11 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 26 Mar 2006 13:38:11 -0800
Subject: [ python-Bugs-1458927 ] -Q warn option is still not default in 2.4
Message-ID: <E1FNcw7-0004mQ-3P@sc8-sf-web6.sourceforge.net>

Bugs item #1458927, was opened at 2006-03-26 23: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=1458927&group_id=5470

Please note that this message 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: Christoph Zwerschke (cito)
Assigned to: Nobody/Anonymous (nobody)
Summary: -Q warn option is still not default in 2.4

Initial Comment:
I noticed that contrary to what has been said in
http://www.python.org/doc/2.2.3/whatsnew/node7.html,
namely that integer divison should print deprecation
warnings beginning with Python 2.3, even Python 2.4
is still quiet about it, i.e. you still need to explicitely
set the -Q warn option to see the warnings.
Is that by intent or has it simply been forgotten?
If it has been forgotten, it should be probably changed
in Python 2.5.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1458927&group_id=5470

From noreply at sourceforge.net  Sun Mar 26 23:38:35 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 26 Mar 2006 13:38:35 -0800
Subject: [ python-Bugs-1458927 ] -Q warn option is still not default in 2.4
Message-ID: <E1FNcwV-0003WE-QT@sc8-sf-web4-b.sourceforge.net>

Bugs item #1458927, was opened at 2006-03-26 23:38
Message generated for change (Settings changed) made by cito
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1458927&group_id=5470

Please note that this message 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: 4
Submitted By: Christoph Zwerschke (cito)
Assigned to: Nobody/Anonymous (nobody)
Summary: -Q warn option is still not default in 2.4

Initial Comment:
I noticed that contrary to what has been said in
http://www.python.org/doc/2.2.3/whatsnew/node7.html,
namely that integer divison should print deprecation
warnings beginning with Python 2.3, even Python 2.4
is still quiet about it, i.e. you still need to explicitely
set the -Q warn option to see the warnings.
Is that by intent or has it simply been forgotten?
If it has been forgotten, it should be probably changed
in Python 2.5.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1458927&group_id=5470

From noreply at sourceforge.net  Mon Mar 27 04:54:38 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 26 Mar 2006 18:54:38 -0800
Subject: [ python-Bugs-1459029 ] Doubled backslash in repr() method for unicode
Message-ID: <E1FNhsM-0006Kc-DP@sc8-sf-web4-b.sourceforge.net>

Bugs item #1459029, was opened at 2006-03-27 04:54
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459029&group_id=5470

Please note that this 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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Christoph Zwerschke (cito)
Assigned to: Nobody/Anonymous (nobody)
Summary: Doubled backslash in repr() method for unicode

Initial Comment:
Here is an issue that caused Kid templates (used by
Turbogears) to malfunction in Python 2.4.3c1.

The problem shows up with the following code:

class s1:
    def __repr__(self):
        return '\\n'

class s2:
    def __repr__(self):
        return u'\\n'

print repr(s1()), repr(s2())

I get the following results:

Python 2.3.5: \n \n
Python 2.4.2: \n \n
Python 2.4.3c1: \n \\n 

In the output for Python 2.4.3c1, the backslash in the
representation of class2 appears doubled. This did not
happen in earlier Python versions and seems to be a bug.

My vague guess is that the issue may have crept in with
an attempted fix of Bug #1379994.

-- Christoph

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459029&group_id=5470

From noreply at sourceforge.net  Mon Mar 27 04:55:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 26 Mar 2006 18:55:46 -0800
Subject: [ python-Bugs-1459029 ] Doubled backslash in repr() method for unicode
Message-ID: <E1FNhtS-0006C2-Gb@sc8-sf-web5.sourceforge.net>

Bugs item #1459029, was opened at 2006-03-27 04:54
Message generated for change (Settings changed) made by cito
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459029&group_id=5470

Please note that this 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: 8
Submitted By: Christoph Zwerschke (cito)
Assigned to: Nobody/Anonymous (nobody)
Summary: Doubled backslash in repr() method for unicode

Initial Comment:
Here is an issue that caused Kid templates (used by
Turbogears) to malfunction in Python 2.4.3c1.

The problem shows up with the following code:

class s1:
    def __repr__(self):
        return '\\n'

class s2:
    def __repr__(self):
        return u'\\n'

print repr(s1()), repr(s2())

I get the following results:

Python 2.3.5: \n \n
Python 2.4.2: \n \n
Python 2.4.3c1: \n \\n 

In the output for Python 2.4.3c1, the backslash in the
representation of class2 appears doubled. This did not
happen in earlier Python versions and seems to be a bug.

My vague guess is that the issue may have crept in with
an attempted fix of Bug #1379994.

-- Christoph

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459029&group_id=5470

From noreply at sourceforge.net  Mon Mar 27 04:57:22 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 26 Mar 2006 18:57:22 -0800
Subject: [ python-Bugs-1459029 ] Doubled backslash in repr() method for unicode
Message-ID: <E1FNhv0-0006Jk-4f@sc8-sf-web5.sourceforge.net>

Bugs item #1459029, was opened at 2006-03-27 04:54
Message generated for change (Settings changed) made by cito
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459029&group_id=5470

Please note that this 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: 7
Submitted By: Christoph Zwerschke (cito)
Assigned to: Nobody/Anonymous (nobody)
Summary: Doubled backslash in repr() method for unicode

Initial Comment:
Here is an issue that caused Kid templates (used by
Turbogears) to malfunction in Python 2.4.3c1.

The problem shows up with the following code:

class s1:
    def __repr__(self):
        return '\\n'

class s2:
    def __repr__(self):
        return u'\\n'

print repr(s1()), repr(s2())

I get the following results:

Python 2.3.5: \n \n
Python 2.4.2: \n \n
Python 2.4.3c1: \n \\n 

In the output for Python 2.4.3c1, the backslash in the
representation of class2 appears doubled. This did not
happen in earlier Python versions and seems to be a bug.

My vague guess is that the issue may have crept in with
an attempted fix of Bug #1379994.

-- Christoph

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459029&group_id=5470

From noreply at sourceforge.net  Mon Mar 27 07:50:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 26 Mar 2006 21:50:42 -0800
Subject: [ python-Bugs-1443328 ] Pickle protocol 2 fails on private slots.
Message-ID: <E1FNkck-0000PW-Sr@sc8-sf-web4-b.sourceforge.net>

Bugs item #1443328, was opened at 2006-03-05 05:18
Message generated for change (Comment added) made by zseil
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1443328&group_id=5470

Please note that this message 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: Daniele Varrazzo (dvarrazzo)
Assigned to: Tim Peters (tim_one)
Summary: Pickle protocol 2 fails on private slots.

Initial Comment:
The pickling protocol 2 can manage new style objects
defining __slots__ and without __dict__. Anyway it
fails when one of the slots is "private".

>>> class C1(object):
	__slots__ = ["__priv"]
	def __init__(self):
		self.__priv = 42
	def get_priv(self):
		return self.__priv

>>> C1().get_priv()
42
>>> import pickle
>>> pickle.loads(pickle.dumps(C1(), 2)).get_priv()

Traceback (most recent call last):
  File "<pyshell#258>", line 1, in -toplevel-
    pickle.loads(pickle.dumps(C1(), 2)).get_priv()
  File "<pyshell#255>", line 6, in get_priv
    return self.__priv
AttributeError: _C1__priv

of course redefining __getstate__ and __setstate__
bypasses the problem.

the cPickle module shows the same issue.

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-03-27 07:50

Message:
Logged In: YES 
user_id=1326842

The bug is in the copy_reg module.
object.__reduce_ex__ calls function 
_slotnames in that module.
There is another bug when __slots__
is a single string. Examples below.

>>> import copy_reg
>>> class A(object):
...     __slots__ = ('__spam',)
...
>>> class B(object):
...     __slots__ = 'spam'
...
>>> copy_reg._slotnames(A) # should be ['_A__spam']
['__spam']
>>> copy_reg._slotnames(B) # should be ['spam']
['s', 'p', 'a', 'm']

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-03-09 09:21

Message:
Logged In: YES 
user_id=849994

Confirmed with pickle and cPickle here.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1443328&group_id=5470

From noreply at sourceforge.net  Mon Mar 27 07:53:22 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 26 Mar 2006 21:53:22 -0800
Subject: [ python-Bugs-1459029 ] Doubled backslash in repr() method for unicode
Message-ID: <E1FNkfK-0001u8-0V@sc8-sf-web6.sourceforge.net>

Bugs item #1459029, was opened at 2006-03-27 13:54
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459029&group_id=5470

Please note that this 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: 7
Submitted By: Christoph Zwerschke (cito)
>Assigned to: Hye-Shik Chang (perky)
Summary: Doubled backslash in repr() method for unicode

Initial Comment:
Here is an issue that caused Kid templates (used by
Turbogears) to malfunction in Python 2.4.3c1.

The problem shows up with the following code:

class s1:
    def __repr__(self):
        return '\\n'

class s2:
    def __repr__(self):
        return u'\\n'

print repr(s1()), repr(s2())

I get the following results:

Python 2.3.5: \n \n
Python 2.4.2: \n \n
Python 2.4.3c1: \n \\n 

In the output for Python 2.4.3c1, the backslash in the
representation of class2 appears doubled. This did not
happen in earlier Python versions and seems to be a bug.

My vague guess is that the issue may have crept in with
an attempted fix of Bug #1379994.

-- Christoph

----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-03-27 16:53

Message:
Logged In: YES 
user_id=29957

Confirmed - it's also broken in the trunk, and backing out
the patch for http://www.python.org/sf/1379994 (r41728)
fixes the problem. Perky, you checked this in - can you look
at this soon, please? I don't want to release 2.4.3 until
it's fixed, but I also want to get 2.4.3 out this week.

Thanks for the bug report!


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459029&group_id=5470

From noreply at sourceforge.net  Mon Mar 27 08:28:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 26 Mar 2006 22:28:24 -0800
Subject: [ python-Bugs-1459029 ] Doubled backslash in repr() method for unicode
Message-ID: <E1FNlDE-00056X-3X@sc8-sf-web1.sourceforge.net>

Bugs item #1459029, was opened at 2006-03-26 18:54
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459029&group_id=5470

Please note that this 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: 7
Submitted By: Christoph Zwerschke (cito)
Assigned to: Hye-Shik Chang (perky)
Summary: Doubled backslash in repr() method for unicode

Initial Comment:
Here is an issue that caused Kid templates (used by
Turbogears) to malfunction in Python 2.4.3c1.

The problem shows up with the following code:

class s1:
    def __repr__(self):
        return '\\n'

class s2:
    def __repr__(self):
        return u'\\n'

print repr(s1()), repr(s2())

I get the following results:

Python 2.3.5: \n \n
Python 2.4.2: \n \n
Python 2.4.3c1: \n \\n 

In the output for Python 2.4.3c1, the backslash in the
representation of class2 appears doubled. This did not
happen in earlier Python versions and seems to be a bug.

My vague guess is that the issue may have crept in with
an attempted fix of Bug #1379994.

-- Christoph

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-26 22:28

Message:
Logged In: YES 
user_id=33168

Attached a patch for the test case to be added with fix.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-03-26 21:53

Message:
Logged In: YES 
user_id=29957

Confirmed - it's also broken in the trunk, and backing out
the patch for http://www.python.org/sf/1379994 (r41728)
fixes the problem. Perky, you checked this in - can you look
at this soon, please? I don't want to release 2.4.3 until
it's fixed, but I also want to get 2.4.3 out this week.

Thanks for the bug report!


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459029&group_id=5470

From noreply at sourceforge.net  Mon Mar 27 08:38:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 26 Mar 2006 22:38:46 -0800
Subject: [ python-Bugs-1459029 ] Doubled backslash in repr() method for unicode
Message-ID: <E1FNlNG-0003Gd-LE@sc8-sf-web5.sourceforge.net>

Bugs item #1459029, was opened at 2006-03-27 11:54
Message generated for change (Comment added) made by perky
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459029&group_id=5470

Please note that this 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: 7
Submitted By: Christoph Zwerschke (cito)
Assigned to: Hye-Shik Chang (perky)
Summary: Doubled backslash in repr() method for unicode

Initial Comment:
Here is an issue that caused Kid templates (used by
Turbogears) to malfunction in Python 2.4.3c1.

The problem shows up with the following code:

class s1:
    def __repr__(self):
        return '\\n'

class s2:
    def __repr__(self):
        return u'\\n'

print repr(s1()), repr(s2())

I get the following results:

Python 2.3.5: \n \n
Python 2.4.2: \n \n
Python 2.4.3c1: \n \\n 

In the output for Python 2.4.3c1, the backslash in the
representation of class2 appears doubled. This did not
happen in earlier Python versions and seems to be a bug.

My vague guess is that the issue may have crept in with
an attempted fix of Bug #1379994.

-- Christoph

----------------------------------------------------------------------

>Comment By: Hye-Shik Chang (perky)
Date: 2006-03-27 15:38

Message:
Logged In: YES 
user_id=55188

Looking the C code, unicode_repr is doing correct.
But the inconsistency came from PyObject_Repr.
This change made it which is intended:

------------------------------------------------------------------------
r16198 | effbot | 2000-07-09 02:43:32 +0900 (???, 09  7 2000)
| 6 lines


- changed __repr__ to use "unicode escape" encoding for unicode
  strings, instead of the default encoding.
  (see "minidom" thread for discussion, and also patch #100706)


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-27 15:28

Message:
Logged In: YES 
user_id=33168

Attached a patch for the test case to be added with fix.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-03-27 14:53

Message:
Logged In: YES 
user_id=29957

Confirmed - it's also broken in the trunk, and backing out
the patch for http://www.python.org/sf/1379994 (r41728)
fixes the problem. Perky, you checked this in - can you look
at this soon, please? I don't want to release 2.4.3 until
it's fixed, but I also want to get 2.4.3 out this week.

Thanks for the bug report!


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459029&group_id=5470

From noreply at sourceforge.net  Mon Mar 27 08:56:35 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 26 Mar 2006 22:56:35 -0800
Subject: [ python-Bugs-1459029 ] Doubled backslash in repr() method for unicode
Message-ID: <E1FNleV-0004Oe-Fg@sc8-sf-web5.sourceforge.net>

Bugs item #1459029, was opened at 2006-03-27 11:54
Message generated for change (Comment added) made by perky
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459029&group_id=5470

Please note that this 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: 7
Submitted By: Christoph Zwerschke (cito)
Assigned to: Hye-Shik Chang (perky)
Summary: Doubled backslash in repr() method for unicode

Initial Comment:
Here is an issue that caused Kid templates (used by
Turbogears) to malfunction in Python 2.4.3c1.

The problem shows up with the following code:

class s1:
    def __repr__(self):
        return '\\n'

class s2:
    def __repr__(self):
        return u'\\n'

print repr(s1()), repr(s2())

I get the following results:

Python 2.3.5: \n \n
Python 2.4.2: \n \n
Python 2.4.3c1: \n \\n 

In the output for Python 2.4.3c1, the backslash in the
representation of class2 appears doubled. This did not
happen in earlier Python versions and seems to be a bug.

My vague guess is that the issue may have crept in with
an attempted fix of Bug #1379994.

-- Christoph

----------------------------------------------------------------------

>Comment By: Hye-Shik Chang (perky)
Date: 2006-03-27 15:56

Message:
Logged In: YES 
user_id=55188

Found it!:
http://mail.python.org/pipermail/python-dev/2000-July/005353.html
But their intention had never applied before 2.4.3.
What problem would be if we change PyObject_Repr to use the
default encoding not unicode-escape? (revert r16198)


----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2006-03-27 15:38

Message:
Logged In: YES 
user_id=55188

Looking the C code, unicode_repr is doing correct.
But the inconsistency came from PyObject_Repr.
This change made it which is intended:

------------------------------------------------------------------------
r16198 | effbot | 2000-07-09 02:43:32 +0900 (???, 09  7 2000)
| 6 lines


- changed __repr__ to use "unicode escape" encoding for unicode
  strings, instead of the default encoding.
  (see "minidom" thread for discussion, and also patch #100706)


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-27 15:28

Message:
Logged In: YES 
user_id=33168

Attached a patch for the test case to be added with fix.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-03-27 14:53

Message:
Logged In: YES 
user_id=29957

Confirmed - it's also broken in the trunk, and backing out
the patch for http://www.python.org/sf/1379994 (r41728)
fixes the problem. Perky, you checked this in - can you look
at this soon, please? I don't want to release 2.4.3 until
it's fixed, but I also want to get 2.4.3 out this week.

Thanks for the bug report!


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459029&group_id=5470

From noreply at sourceforge.net  Mon Mar 27 08:57:40 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 26 Mar 2006 22:57:40 -0800
Subject: [ python-Bugs-1459029 ] Doubled backslash in repr() method for unicode
Message-ID: <E1FNlfY-0007nR-2J@sc8-sf-web3.sourceforge.net>

Bugs item #1459029, was opened at 2006-03-27 13:54
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459029&group_id=5470

Please note that this 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: 7
Submitted By: Christoph Zwerschke (cito)
Assigned to: Hye-Shik Chang (perky)
Summary: Doubled backslash in repr() method for unicode

Initial Comment:
Here is an issue that caused Kid templates (used by
Turbogears) to malfunction in Python 2.4.3c1.

The problem shows up with the following code:

class s1:
    def __repr__(self):
        return '\\n'

class s2:
    def __repr__(self):
        return u'\\n'

print repr(s1()), repr(s2())

I get the following results:

Python 2.3.5: \n \n
Python 2.4.2: \n \n
Python 2.4.3c1: \n \\n 

In the output for Python 2.4.3c1, the backslash in the
representation of class2 appears doubled. This did not
happen in earlier Python versions and seems to be a bug.

My vague guess is that the issue may have crept in with
an attempted fix of Bug #1379994.

-- Christoph

----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-03-27 17:57

Message:
Logged In: YES 
user_id=29957

I'm confused how a checkin from 5+ years ago broke a change
from 3 months ago?

Or am I misunderstanding you?


----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2006-03-27 17:56

Message:
Logged In: YES 
user_id=55188

Found it!:
http://mail.python.org/pipermail/python-dev/2000-July/005353.html
But their intention had never applied before 2.4.3.
What problem would be if we change PyObject_Repr to use the
default encoding not unicode-escape? (revert r16198)


----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2006-03-27 17:38

Message:
Logged In: YES 
user_id=55188

Looking the C code, unicode_repr is doing correct.
But the inconsistency came from PyObject_Repr.
This change made it which is intended:

------------------------------------------------------------------------
r16198 | effbot | 2000-07-09 02:43:32 +0900 (???, 09  7 2000)
| 6 lines


- changed __repr__ to use "unicode escape" encoding for unicode
  strings, instead of the default encoding.
  (see "minidom" thread for discussion, and also patch #100706)


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-27 17:28

Message:
Logged In: YES 
user_id=33168

Attached a patch for the test case to be added with fix.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-03-27 16:53

Message:
Logged In: YES 
user_id=29957

Confirmed - it's also broken in the trunk, and backing out
the patch for http://www.python.org/sf/1379994 (r41728)
fixes the problem. Perky, you checked this in - can you look
at this soon, please? I don't want to release 2.4.3 until
it's fixed, but I also want to get 2.4.3 out this week.

Thanks for the bug report!


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459029&group_id=5470

From noreply at sourceforge.net  Mon Mar 27 09:03:59 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 26 Mar 2006 23:03:59 -0800
Subject: [ python-Bugs-1459103 ] missing links beetween strftime()'s...
Message-ID: <E1FNllf-0007Ii-BN@sc8-sf-web1.sourceforge.net>

Bugs item #1459103, was opened at 2006-03-27 09: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=1459103&group_id=5470

Please note that this 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: Jens Diemer (pylucid)
Assigned to: Nobody/Anonymous (nobody)
Summary: missing links beetween strftime()'s...

Initial Comment:
Ther are a few strftime():

strftime() (date method)
strftime() (datetime method)
strftime() (in module time)
strftime() (time method)

http://starship.python.net/crew/theller/pyhelp.cgi?keyword=strftime&version=current


But only in time.strftime() is the directives table:
http://docs.python.org/lib/module-time.html#l2h-1955

That's ok, if there is a Link directly to this table,
in the other modules.

I suggest: set Links in the other modules to the
directives table in module time.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459103&group_id=5470

From noreply at sourceforge.net  Mon Mar 27 09:05:21 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 26 Mar 2006 23:05:21 -0800
Subject: [ python-Bugs-1459029 ] Doubled backslash in repr() method for unicode
Message-ID: <E1FNlmz-00056A-KL@sc8-sf-web4-b.sourceforge.net>

Bugs item #1459029, was opened at 2006-03-27 11:54
Message generated for change (Comment added) made by perky
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459029&group_id=5470

Please note that this 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: 7
Submitted By: Christoph Zwerschke (cito)
Assigned to: Hye-Shik Chang (perky)
Summary: Doubled backslash in repr() method for unicode

Initial Comment:
Here is an issue that caused Kid templates (used by
Turbogears) to malfunction in Python 2.4.3c1.

The problem shows up with the following code:

class s1:
    def __repr__(self):
        return '\\n'

class s2:
    def __repr__(self):
        return u'\\n'

print repr(s1()), repr(s2())

I get the following results:

Python 2.3.5: \n \n
Python 2.4.2: \n \n
Python 2.4.3c1: \n \\n 

In the output for Python 2.4.3c1, the backslash in the
representation of class2 appears doubled. This did not
happen in earlier Python versions and seems to be a bug.

My vague guess is that the issue may have crept in with
an attempted fix of Bug #1379994.

-- Christoph

----------------------------------------------------------------------

>Comment By: Hye-Shik Chang (perky)
Date: 2006-03-27 16:05

Message:
Logged In: YES 
user_id=55188

Because unicode-escape codec didn't escape \,
PyObject_Repr(u'\\') bypassed backslashes.  But Martin and
Fredrik made PyObject_Repr to use unicode-escape codec for
unicode repr-returns 5 years ago.  So by fixing
unicode-escape codec, their intention could be applied for
the first time, 3 months ago.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-03-27 15:57

Message:
Logged In: YES 
user_id=29957

I'm confused how a checkin from 5+ years ago broke a change
from 3 months ago?

Or am I misunderstanding you?


----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2006-03-27 15:56

Message:
Logged In: YES 
user_id=55188

Found it!:
http://mail.python.org/pipermail/python-dev/2000-July/005353.html
But their intention had never applied before 2.4.3.
What problem would be if we change PyObject_Repr to use the
default encoding not unicode-escape? (revert r16198)


----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2006-03-27 15:38

Message:
Logged In: YES 
user_id=55188

Looking the C code, unicode_repr is doing correct.
But the inconsistency came from PyObject_Repr.
This change made it which is intended:

------------------------------------------------------------------------
r16198 | effbot | 2000-07-09 02:43:32 +0900 (???, 09  7 2000)
| 6 lines


- changed __repr__ to use "unicode escape" encoding for unicode
  strings, instead of the default encoding.
  (see "minidom" thread for discussion, and also patch #100706)


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-27 15:28

Message:
Logged In: YES 
user_id=33168

Attached a patch for the test case to be added with fix.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-03-27 14:53

Message:
Logged In: YES 
user_id=29957

Confirmed - it's also broken in the trunk, and backing out
the patch for http://www.python.org/sf/1379994 (r41728)
fixes the problem. Perky, you checked this in - can you look
at this soon, please? I don't want to release 2.4.3 until
it's fixed, but I also want to get 2.4.3 out this week.

Thanks for the bug report!


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459029&group_id=5470

From noreply at sourceforge.net  Mon Mar 27 09:09:41 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 26 Mar 2006 23:09:41 -0800
Subject: [ python-Bugs-1459029 ] Doubled backslash in repr() method for unicode
Message-ID: <E1FNlrB-0006fA-Ju@sc8-sf-web6.sourceforge.net>

Bugs item #1459029, was opened at 2006-03-26 18:54
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459029&group_id=5470

Please note that this 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: 7
Submitted By: Christoph Zwerschke (cito)
Assigned to: Hye-Shik Chang (perky)
Summary: Doubled backslash in repr() method for unicode

Initial Comment:
Here is an issue that caused Kid templates (used by
Turbogears) to malfunction in Python 2.4.3c1.

The problem shows up with the following code:

class s1:
    def __repr__(self):
        return '\\n'

class s2:
    def __repr__(self):
        return u'\\n'

print repr(s1()), repr(s2())

I get the following results:

Python 2.3.5: \n \n
Python 2.4.2: \n \n
Python 2.4.3c1: \n \\n 

In the output for Python 2.4.3c1, the backslash in the
representation of class2 appears doubled. This did not
happen in earlier Python versions and seems to be a bug.

My vague guess is that the issue may have crept in with
an attempted fix of Bug #1379994.

-- Christoph

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-26 23:09

Message:
Logged In: YES 
user_id=33168

We need to retain the old behaviour, but also fix the bug. 
How can we do that?  

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2006-03-26 23:05

Message:
Logged In: YES 
user_id=55188

Because unicode-escape codec didn't escape \,
PyObject_Repr(u'\\') bypassed backslashes.  But Martin and
Fredrik made PyObject_Repr to use unicode-escape codec for
unicode repr-returns 5 years ago.  So by fixing
unicode-escape codec, their intention could be applied for
the first time, 3 months ago.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-03-26 22:57

Message:
Logged In: YES 
user_id=29957

I'm confused how a checkin from 5+ years ago broke a change
from 3 months ago?

Or am I misunderstanding you?


----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2006-03-26 22:56

Message:
Logged In: YES 
user_id=55188

Found it!:
http://mail.python.org/pipermail/python-dev/2000-July/005353.html
But their intention had never applied before 2.4.3.
What problem would be if we change PyObject_Repr to use the
default encoding not unicode-escape? (revert r16198)


----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2006-03-26 22:38

Message:
Logged In: YES 
user_id=55188

Looking the C code, unicode_repr is doing correct.
But the inconsistency came from PyObject_Repr.
This change made it which is intended:

------------------------------------------------------------------------
r16198 | effbot | 2000-07-09 02:43:32 +0900 (???, 09  7 2000)
| 6 lines


- changed __repr__ to use "unicode escape" encoding for unicode
  strings, instead of the default encoding.
  (see "minidom" thread for discussion, and also patch #100706)


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-26 22:28

Message:
Logged In: YES 
user_id=33168

Attached a patch for the test case to be added with fix.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-03-26 21:53

Message:
Logged In: YES 
user_id=29957

Confirmed - it's also broken in the trunk, and backing out
the patch for http://www.python.org/sf/1379994 (r41728)
fixes the problem. Perky, you checked this in - can you look
at this soon, please? I don't want to release 2.4.3 until
it's fixed, but I also want to get 2.4.3 out this week.

Thanks for the bug report!


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459029&group_id=5470

From noreply at sourceforge.net  Mon Mar 27 10:59:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 27 Mar 2006 00:59:42 -0800
Subject: [ python-Bugs-1458903 ] lambda with a parenthesized argument raises
	TypeError
Message-ID: <E1FNnZe-0003pe-4q@sc8-sf-web4-b.sourceforge.net>

Bugs item #1458903, was opened at 2006-03-26 12:33
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1458903&group_id=5470

Please note that this 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: Jeong-Min Lee (falsetru)
Assigned to: Neal Norwitz (nnorwitz)
Summary: lambda with a parenthesized argument raises TypeError

Initial Comment:
==================================================
falsetru at lj-lw20 ~ $ python2.5
Python 2.5a0 (trunk:43324, Mar 26 2006, 14:18:23)
[GCC 3.4.5 (Gentoo 3.4.5, ssp-3.4.5-1.0, pie-8.7.9)] on
linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> (lambda(x): x)(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 1, in <lambda>
TypeError: unpack non-sequence
>>> (lambda(x): x)((1,))
1
>>> (lambda(x): x)((1,2))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 1, in <lambda>
ValueError: too many values to unpack
>>>




not 2.4 compatible
==================================================
falsetru at lj-lw20 ~ $ python2.4
Python 2.4.2 (#1, Oct 15 2005, 13:17:32)
[GCC 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)] on
linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> (lambda(x): x)(1)
1
>>> (lambda(x): x)((1,))
(1,)
>>> (lambda(x): x)((1,2))
(1, 2)
>>>

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-27 00:59

Message:
Logged In: YES 
user_id=33168

Thanks for the report!  The problem was more general.  This
code also broke:  def foo((x)): 

Committed revision 43341.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1458903&group_id=5470

From noreply at sourceforge.net  Mon Mar 27 11:05:54 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 27 Mar 2006 01:05:54 -0800
Subject: [ python-Bugs-1459159 ] inspect.getargspec() is wrong for def
	foo((x)):
Message-ID: <E1FNnfe-0005XS-F1@sc8-sf-web6.sourceforge.net>

Bugs item #1459159, was opened at 2006-03-27 01: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=1459159&group_id=5470

Please note that this message 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: Neal Norwitz (nnorwitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: inspect.getargspec() is wrong for def foo((x)):

Initial Comment:
See my recent checkin on HEAD for fixing def foo((x)):
in the AST compiler.  I had to modify test_inspect
because the above signature should not do tuple
unpacking.  inspect thinkgs it does though.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459159&group_id=5470

From noreply at sourceforge.net  Mon Mar 27 13:38:38 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 27 Mar 2006 03:38:38 -0800
Subject: [ python-Bugs-1459159 ] inspect.getargspec() is wrong for def
	foo((x)):
Message-ID: <E1FNq3S-0001PW-4j@sc8-sf-web2.sourceforge.net>

Bugs item #1459159, was opened at 2006-03-27 09:05
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459159&group_id=5470

Please note that this message 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: Neal Norwitz (nnorwitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: inspect.getargspec() is wrong for def foo((x)):

Initial Comment:
See my recent checkin on HEAD for fixing def foo((x)):
in the AST compiler.  I had to modify test_inspect
because the above signature should not do tuple
unpacking.  inspect thinkgs it does though.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-27 11:38

Message:
Logged In: YES 
user_id=849994

That's a bit odd. Following defs:

def bar((x)): pass
def foo(x): pass

In 2.4:

>>> dis.dis(bar)
  1           0 LOAD_FAST                0 (.0)
              3 STORE_FAST               1 (x)
              6 LOAD_CONST               0 (None)
              9 RETURN_VALUE
>>> dis.dis(foo)
  1           0 LOAD_CONST               0 (None)
              3 RETURN_VALUE

In 2.5:

>>> dis.dis(bar)
  1           0 LOAD_CONST               0 (None)
              3 RETURN_VALUE
>>> dis.dis(foo)
  1           0 LOAD_CONST               0 (None)
              3 RETURN_VALUE


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459159&group_id=5470

From noreply at sourceforge.net  Mon Mar 27 13:39:54 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 27 Mar 2006 03:39:54 -0800
Subject: [ python-Bugs-1459159 ] inspect.getargspec() is wrong for def
	foo((x)):
Message-ID: <E1FNq4g-0001TX-5p@sc8-sf-web2.sourceforge.net>

Bugs item #1459159, was opened at 2006-03-27 09:05
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459159&group_id=5470

Please note that this message 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: Neal Norwitz (nnorwitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: inspect.getargspec() is wrong for def foo((x)):

Initial Comment:
See my recent checkin on HEAD for fixing def foo((x)):
in the AST compiler.  I had to modify test_inspect
because the above signature should not do tuple
unpacking.  inspect thinkgs it does though.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-27 11:39

Message:
Logged In: YES 
user_id=849994

This at least explains why test_inspect didn't fail for 2.5
after you had fixed the bug and modified the test.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-03-27 11:38

Message:
Logged In: YES 
user_id=849994

That's a bit odd. Following defs:

def bar((x)): pass
def foo(x): pass

In 2.4:

>>> dis.dis(bar)
  1           0 LOAD_FAST                0 (.0)
              3 STORE_FAST               1 (x)
              6 LOAD_CONST               0 (None)
              9 RETURN_VALUE
>>> dis.dis(foo)
  1           0 LOAD_CONST               0 (None)
              3 RETURN_VALUE

In 2.5:

>>> dis.dis(bar)
  1           0 LOAD_CONST               0 (None)
              3 RETURN_VALUE
>>> dis.dis(foo)
  1           0 LOAD_CONST               0 (None)
              3 RETURN_VALUE


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459159&group_id=5470

From noreply at sourceforge.net  Mon Mar 27 14:51:59 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 27 Mar 2006 04:51:59 -0800
Subject: [ python-Bugs-1459279 ] sgmllib.SGMLparser and hexadecimal numeric
	character refs
Message-ID: <E1FNrCR-00030o-DQ@sc8-sf-web6.sourceforge.net>

Bugs item #1459279, was opened at 2006-03-27 14:51
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459279&group_id=5470

Please note that this message 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: Francesco Ricciardi (nerby)
Assigned to: Nobody/Anonymous (nobody)
Summary: sgmllib.SGMLparser and hexadecimal numeric character refs

Initial Comment:
According to HTML 4.0 specification it is possible to
have hexadecimal numeric character references, not only
decimal (see
http://www.w3.org/TR/REC-html40/charset.html#h-5.3.1).

However sgmllib.SGMLparser does not recognize the
hexadecimal form.

More and more HTML pages now use entities with a high
codepoint, not in the official HTML entity list, so
proper handling to these references should be implemented.

A possible solution could be:
- improving the "charref" regular expression, so to
include exadecimal values;
- considering all numeric references valid: those with
n < 255 should be converted to the corresponding
characters, those above 255 should be left as numerical
charrefs. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459279&group_id=5470

From noreply at sourceforge.net  Mon Mar 27 23:27:15 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 27 Mar 2006 13:27:15 -0800
Subject: [ python-Bugs-1458017 ] Log._log needs to be more forgiving...
Message-ID: <E1FNzF5-0002II-8R@sc8-sf-web6.sourceforge.net>

Bugs item #1458017, was opened at 2006-03-24 21:17
Message generated for change (Comment added) made by splitscreen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1458017&group_id=5470

Please note that this 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: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: Log._log needs to be more forgiving...

Initial Comment:
The _log method of distutils' Log class executes

    print msg % args

where args might be an empty tuple (the methods that
call _log all
have varargs signatures).  If that's the case and msg
happens to
contain a % sign, it barfs.  It should be more
forgiving, for
instance:

    def _log(self, level, msg, args):
        if level >= self.threshold:
            try:
                print msg % args
            except TypeError:
                if not args:
                    print msg
                else:
                    raise
            sys.stdout.flush()

I just corrected this locally for our 2.3 and 2.4
installations.  The
above is a bit ugly, but it does allow the common case
(msg contains a
% but an empty args list) to pass while still catching
most programmer
errors.  Distutils is trying to log this message (wrapped):

  gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes
  -fPIC -I/opt/app/mysql-5.0.19/include
  -I/opt/app/mysql-5.0.19/include
-I/opt/lang/python/include/python2.3
  -c _mysql.c -o build/temp.solaris-2.8-i86pc-2.3/_mysql.o
  -I/opt/app/mysql-5.0.19/include -xO3 -mt -fsimple=1
-ftrap=%none
  -nofstore -xbuiltin=%all -xlibmil -xlibmopt
-xtarget=generic

I suppose it would be better if all the places in
distutils which log
compiler commands without extra args escaped their %
signs.  This
seems like an acceptable compromise though.

Skip


----------------------------------------------------------------------

Comment By: splitscreen (splitscreen)
Date: 2006-03-27 21:27

Message:
Logged In: YES 
user_id=1126061

I can't reproduce on 2.4.2. Although maybe I misunderstood...

Are you saying that _log() barfs when you pass an empty tuple?

Passing an empty tuple to _log() works fine here..

I can understand it breaking when you pass some format
string to args and the msg contains an '%', that's the
developer's fault for not escaping the precentage sign.

Could you clarify? Or am I totally wrong?

Thanks

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1458017&group_id=5470

From noreply at sourceforge.net  Mon Mar 27 23:47:19 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 27 Mar 2006 13:47:19 -0800
Subject: [ python-Bugs-1459642 ] time.timezone / time.strftime('%z') problem
Message-ID: <E1FNzYV-0004py-3B@sc8-sf-web1.sourceforge.net>

Bugs item #1459642, was opened at 2006-03-27 23: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=1459642&group_id=5470

Please note that this 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: Simon Lanzmich (si_lan)
Assigned to: Nobody/Anonymous (nobody)
Summary: time.timezone / time.strftime('%z') problem

Initial Comment:
The information returned by time.timezone and
time.strftime('%z') are different!

I get the following results:

[simon at simon ~]$ date +%z
+0200
[simon at simon ~]$ date +%Z
CEST
[simon at simon ~]$ python
Python 2.4.2 (#1, Feb 12 2006, 03:45:41)
[GCC 4.1.0 20060210 (Red Hat 4.1.0-0.24)] on linux2
 [...]
>>> time.timezone
-3600
>>> time.strftime('%z')
'+0200'

Please correct me if I'm wrong, but shouldn't
"time.timezone" return -7200 ?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459642&group_id=5470

From noreply at sourceforge.net  Tue Mar 28 00:13:14 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 27 Mar 2006 14:13:14 -0800
Subject: [ python-Bugs-1459642 ] time.timezone / time.strftime('%z') problem
Message-ID: <E1FNzxa-0006Uy-0u@sc8-sf-web1.sourceforge.net>

Bugs item #1459642, was opened at 2006-03-27 21:47
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459642&group_id=5470

Please note that this 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: Invalid
Priority: 5
Submitted By: Simon Lanzmich (si_lan)
Assigned to: Nobody/Anonymous (nobody)
Summary: time.timezone / time.strftime('%z') problem

Initial Comment:
The information returned by time.timezone and
time.strftime('%z') are different!

I get the following results:

[simon at simon ~]$ date +%z
+0200
[simon at simon ~]$ date +%Z
CEST
[simon at simon ~]$ python
Python 2.4.2 (#1, Feb 12 2006, 03:45:41)
[GCC 4.1.0 20060210 (Red Hat 4.1.0-0.24)] on linux2
 [...]
>>> time.timezone
-3600
>>> time.strftime('%z')
'+0200'

Please correct me if I'm wrong, but shouldn't
"time.timezone" return -7200 ?


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-27 22:13

Message:
Logged In: YES 
user_id=849994

time.timezone is documented to return the offset for the
current non-DST timezone. Your timezone is CEST, which is
CET (+0100) plus DST, which is indicated by time.daylight
being nonzero.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459642&group_id=5470

From noreply at sourceforge.net  Tue Mar 28 00:14:33 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 27 Mar 2006 14:14:33 -0800
Subject: [ python-Bugs-1459103 ] missing links beetween strftime()'s...
Message-ID: <E1FNzyr-0006Z1-RV@sc8-sf-web1.sourceforge.net>

Bugs item #1459103, was opened at 2006-03-27 07:03
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459103&group_id=5470

Please note that this 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: Works For Me
Priority: 5
Submitted By: Jens Diemer (pylucid)
Assigned to: Nobody/Anonymous (nobody)
Summary: missing links beetween strftime()'s...

Initial Comment:
Ther are a few strftime():

strftime() (date method)
strftime() (datetime method)
strftime() (in module time)
strftime() (time method)

http://starship.python.net/crew/theller/pyhelp.cgi?keyword=strftime&version=current


But only in time.strftime() is the directives table:
http://docs.python.org/lib/module-time.html#l2h-1955

That's ok, if there is a Link directly to this table,
in the other modules.

I suggest: set Links in the other modules to the
directives table in module time.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-27 22:14

Message:
Logged In: YES 
user_id=849994

All the datetime methods refer to the "section of strftime()
behavior" which is important to know. From there, there is a
link to time.strftime.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459103&group_id=5470

From noreply at sourceforge.net  Tue Mar 28 00:16:09 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 27 Mar 2006 14:16:09 -0800
Subject: [ python-Bugs-1458927 ] -Q warn option is still not default in 2.4
Message-ID: <E1FO00P-0006gj-VK@sc8-sf-web1.sourceforge.net>

Bugs item #1458927, was opened at 2006-03-26 21:38
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1458927&group_id=5470

Please note that this message 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: Later
Priority: 4
Submitted By: Christoph Zwerschke (cito)
Assigned to: Nobody/Anonymous (nobody)
Summary: -Q warn option is still not default in 2.4

Initial Comment:
I noticed that contrary to what has been said in
http://www.python.org/doc/2.2.3/whatsnew/node7.html,
namely that integer divison should print deprecation
warnings beginning with Python 2.3, even Python 2.4
is still quiet about it, i.e. you still need to explicitely
set the -Q warn option to see the warnings.
Is that by intent or has it simply been forgotten?
If it has been forgotten, it should be probably changed
in Python 2.5.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-27 22:16

Message:
Logged In: YES 
user_id=849994

Anthony, release manager for 2.5, has decided to put this
off (most probably until 3.0).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1458927&group_id=5470

From noreply at sourceforge.net  Tue Mar 28 04:37:28 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 27 Mar 2006 18:37:28 -0800
Subject: [ python-Bugs-1459733 ] sets.Set can't be subclassed
Message-ID: <E1FO45I-0003Ry-AD@sc8-sf-web5.sourceforge.net>

Bugs item #1459733, was opened at 2006-03-28 04: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=1459733&group_id=5470

Please note that this message 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: Michal Kwiatkowski (rubyjoker)
Assigned to: Nobody/Anonymous (nobody)
Summary: sets.Set can't be subclassed

Initial Comment:
sets.Set class fail to hide its implementation. 
Subclassing it and overriding __init__ causes an 
exception during object creation.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459733&group_id=5470

From noreply at sourceforge.net  Tue Mar 28 04:41:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 27 Mar 2006 18:41:23 -0800
Subject: [ python-Bugs-1459733 ] sets.Set can't be subclassed
Message-ID: <E1FO495-0003hX-0w@sc8-sf-web5.sourceforge.net>

Bugs item #1459733, was opened at 2006-03-28 04:37
Message generated for change (Comment added) made by rubyjoker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459733&group_id=5470

Please note that this message 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: Michal Kwiatkowski (rubyjoker)
Assigned to: Nobody/Anonymous (nobody)
Summary: sets.Set can't be subclassed

Initial Comment:
sets.Set class fail to hide its implementation. 
Subclassing it and overriding __init__ causes an 
exception during object creation.

----------------------------------------------------------------------

>Comment By: Michal Kwiatkowski (rubyjoker)
Date: 2006-03-28 04:41

Message:
Logged In: YES 
user_id=1310227

I'm posting a proposed patch with a test case covering this 
bug (shouldn't all standard library modules have tests?). It 
may introduce performance lost, as it removes __slots__ 
definition.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459733&group_id=5470

From noreply at sourceforge.net  Tue Mar 28 05:58:40 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 27 Mar 2006 19:58:40 -0800
Subject: [ python-Bugs-1458017 ] Log._log needs to be more forgiving...
Message-ID: <E1FO5Ls-0008Tm-H6@sc8-sf-web5.sourceforge.net>

Bugs item #1458017, was opened at 2006-03-24 15:17
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1458017&group_id=5470

Please note that this 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: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: Log._log needs to be more forgiving...

Initial Comment:
The _log method of distutils' Log class executes

    print msg % args

where args might be an empty tuple (the methods that
call _log all
have varargs signatures).  If that's the case and msg
happens to
contain a % sign, it barfs.  It should be more
forgiving, for
instance:

    def _log(self, level, msg, args):
        if level >= self.threshold:
            try:
                print msg % args
            except TypeError:
                if not args:
                    print msg
                else:
                    raise
            sys.stdout.flush()

I just corrected this locally for our 2.3 and 2.4
installations.  The
above is a bit ugly, but it does allow the common case
(msg contains a
% but an empty args list) to pass while still catching
most programmer
errors.  Distutils is trying to log this message (wrapped):

  gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes
  -fPIC -I/opt/app/mysql-5.0.19/include
  -I/opt/app/mysql-5.0.19/include
-I/opt/lang/python/include/python2.3
  -c _mysql.c -o build/temp.solaris-2.8-i86pc-2.3/_mysql.o
  -I/opt/app/mysql-5.0.19/include -xO3 -mt -fsimple=1
-ftrap=%none
  -nofstore -xbuiltin=%all -xlibmil -xlibmopt
-xtarget=generic

I suppose it would be better if all the places in
distutils which log
compiler commands without extra args escaped their %
signs.  This
seems like an acceptable compromise though.

Skip


----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2006-03-27 21:58

Message:
Logged In: YES 
user_id=44345

It barfs if you pass an empty tuple and the msg argument contains a % escape.
For example, try:

    print "%s" % ()

In the particular case that tripped me up, it's trying to print a (bogus) gcc
command which contains % escapes while passing no args to map them.


----------------------------------------------------------------------

Comment By: splitscreen (splitscreen)
Date: 2006-03-27 15:27

Message:
Logged In: YES 
user_id=1126061

I can't reproduce on 2.4.2. Although maybe I misunderstood...

Are you saying that _log() barfs when you pass an empty tuple?

Passing an empty tuple to _log() works fine here..

I can understand it breaking when you pass some format
string to args and the msg contains an '%', that's the
developer's fault for not escaping the precentage sign.

Could you clarify? Or am I totally wrong?

Thanks

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1458017&group_id=5470

From noreply at sourceforge.net  Tue Mar 28 08:33:11 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 27 Mar 2006 22:33:11 -0800
Subject: [ python-Bugs-1459733 ] sets.Set can't be subclassed
Message-ID: <E1FO7lP-0001FU-93@sc8-sf-web5.sourceforge.net>

Bugs item #1459733, was opened at 2006-03-28 04:37
Message generated for change (Comment added) made by zseil
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459733&group_id=5470

Please note that this message 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: Michal Kwiatkowski (rubyjoker)
Assigned to: Nobody/Anonymous (nobody)
Summary: sets.Set can't be subclassed

Initial Comment:
sets.Set class fail to hide its implementation. 
Subclassing it and overriding __init__ causes an 
exception during object creation.

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-03-28 08:33

Message:
Logged In: YES 
user_id=1326842

This is a bug in your code, you have to call
the base class's __init__ method. The error
does not occur during the object creation,
but later when repr(obj) fails due to incorrect
initialization.

----------------------------------------------------------------------

Comment By: Michal Kwiatkowski (rubyjoker)
Date: 2006-03-28 04:41

Message:
Logged In: YES 
user_id=1310227

I'm posting a proposed patch with a test case covering this 
bug (shouldn't all standard library modules have tests?). It 
may introduce performance lost, as it removes __slots__ 
definition.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459733&group_id=5470

From noreply at sourceforge.net  Tue Mar 28 09:06:57 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 27 Mar 2006 23:06:57 -0800
Subject: [ python-Bugs-1458927 ] -Q warn option is still not default in 2.4
Message-ID: <E1FO8I5-0003Mh-SK@sc8-sf-web5.sourceforge.net>

Bugs item #1458927, was opened at 2006-03-27 08:38
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1458927&group_id=5470

Please note that this message 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: Later
Priority: 4
Submitted By: Christoph Zwerschke (cito)
Assigned to: Nobody/Anonymous (nobody)
Summary: -Q warn option is still not default in 2.4

Initial Comment:
I noticed that contrary to what has been said in
http://www.python.org/doc/2.2.3/whatsnew/node7.html,
namely that integer divison should print deprecation
warnings beginning with Python 2.3, even Python 2.4
is still quiet about it, i.e. you still need to explicitely
set the -Q warn option to see the warnings.
Is that by intent or has it simply been forgotten?
If it has been forgotten, it should be probably changed
in Python 2.5.

----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-03-28 18:06

Message:
Logged In: YES 
user_id=29957

It's too disruptive a change. If you try running the Python
testsuite with -Qnew, you'll see that we don't even get it
correct yet.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-03-28 09:16

Message:
Logged In: YES 
user_id=849994

Anthony, release manager for 2.5, has decided to put this
off (most probably until 3.0).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1458927&group_id=5470

From noreply at sourceforge.net  Tue Mar 28 09:13:31 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 27 Mar 2006 23:13:31 -0800
Subject: [ python-Bugs-1459808 ] test suite should pass with -Qnew ?
Message-ID: <E1FO8OR-0003ny-Pt@sc8-sf-web5.sourceforge.net>

Bugs item #1459808, was opened at 2006-03-28 18: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=1459808&group_id=5470

Please note that this message 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: Neal Norwitz (nnorwitz)
Summary: test suite should pass with -Qnew ?

Initial Comment:
Even though we're not going to change the default for
-Q in Python 2.x, I feel that the testsuite and the
stdlib should demonstrate best practices, and pass with
-Qnew, at least. The following fail under 2.5-HEAD:

    test_builtin test_coercion test_decimal test_doctest 



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459808&group_id=5470

From noreply at sourceforge.net  Tue Mar 28 09:29:13 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 27 Mar 2006 23:29:13 -0800
Subject: [ python-Bugs-1459808 ] test suite should pass with -Qnew ?
Message-ID: <E1FO8dd-0005Qs-Cu@sc8-sf-web4-b.sourceforge.net>

Bugs item #1459808, was opened at 2006-03-28 02:13
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459808&group_id=5470

Please note that this message 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: Neal Norwitz (nnorwitz)
Summary: test suite should pass with -Qnew ?

Initial Comment:
Even though we're not going to change the default for
-Q in Python 2.x, I feel that the testsuite and the
stdlib should demonstrate best practices, and pass with
-Qnew, at least. The following fail under 2.5-HEAD:

    test_builtin test_coercion test_decimal test_doctest 



----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-03-28 02:29

Message:
Logged In: YES 
user_id=31435

FYI, test_doctest works w/ -Qnew now.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459808&group_id=5470

From noreply at sourceforge.net  Tue Mar 28 09:38:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 27 Mar 2006 23:38:24 -0800
Subject: [ python-Bugs-1379994 ] "unicode_escape" and "raw_unicode_escape"
	encoding is broken
Message-ID: <E1FO8mW-0001Zs-T3@sc8-sf-web2.sourceforge.net>

Bugs item #1379994, was opened at 2005-12-14 11:47
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379994&group_id=5470

Please note that this 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: Closed
Resolution: Fixed
Priority: 5
Submitted By: Mark Mc Mahon (markmcmahon)
Assigned to: Hye-Shik Chang (perky)
Summary: "unicode_escape" and "raw_unicode_escape" encoding is broken

Initial Comment:
In Python 2.4.2 and Python 2.4.1 (Windows XP)

>>> "\t\\t".encode("string_escape")
'\\t\\\\t'

>>> "\t\\t".encode("unicode_escape")
'\\t\\t'
>>> "\t\\t".encode("raw_unicode_escape")
'\t\\t'
>>> u"\t\\t".encode("unicode_escape")
'\\t\\t'
>>> u"\t\\t".encode("raw_unicode_escape")
'\t\\t'

I would have expected all to produce the same result.

Also round-tripping with the encoding doesn't seem to work:
>>> "\t\\t".encode('string_escape').decode('string_escape')
'\t\\t'
>>>
u"\t\\t".encode('unicode_escape').decode('unicode_escape')
u'\t\t'

Thanks
   Mark

----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-03-28 18:38

Message:
Logged In: YES 
user_id=29957

This caused other issues (#1459029) and was reverted from
the 2.4 branch. Fix is still in 2.5. 


----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2005-12-17 15:39

Message:
Logged In: YES 
user_id=55188

Committed as r41728. Thank you!

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2005-12-17 02:01

Message:
Logged In: YES 
user_id=38388

Please add a test case and check in the patch.
Thanks.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-12-16 08:39

Message:
Logged In: YES 
user_id=1188172

Patch looks good.

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2005-12-14 12:41

Message:
Logged In: YES 
user_id=55188

Attached a patch. It looks like a simple typo. :)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379994&group_id=5470

From noreply at sourceforge.net  Tue Mar 28 09:39:36 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 27 Mar 2006 23:39:36 -0800
Subject: [ python-Bugs-1459808 ] test suite should pass with -Qnew ?
Message-ID: <E1FO8ng-00077A-OE@sc8-sf-web6.sourceforge.net>

Bugs item #1459808, was opened at 2006-03-28 02:13
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459808&group_id=5470

Please note that this message 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: Neal Norwitz (nnorwitz)
Summary: test suite should pass with -Qnew ?

Initial Comment:
Even though we're not going to change the default for
-Q in Python 2.x, I feel that the testsuite and the
stdlib should demonstrate best practices, and pass with
-Qnew, at least. The following fail under 2.5-HEAD:

    test_builtin test_coercion test_decimal test_doctest 



----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-03-28 02:39

Message:
Logged In: YES 
user_id=31435

FYI, test_builtin passes w/ or w/o -Qnew now, and I'm going
to sleep :-).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-03-28 02:29

Message:
Logged In: YES 
user_id=31435

FYI, test_doctest works w/ -Qnew now.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459808&group_id=5470

From noreply at sourceforge.net  Tue Mar 28 09:39:57 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 27 Mar 2006 23:39:57 -0800
Subject: [ python-Bugs-1459029 ] Doubled backslash in repr() method for unicode
Message-ID: <E1FO8o1-0001di-7i@sc8-sf-web2.sourceforge.net>

Bugs item #1459029, was opened at 2006-03-27 13:54
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459029&group_id=5470

Please note that this 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: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Christoph Zwerschke (cito)
Assigned to: Hye-Shik Chang (perky)
Summary: Doubled backslash in repr() method for unicode

Initial Comment:
Here is an issue that caused Kid templates (used by
Turbogears) to malfunction in Python 2.4.3c1.

The problem shows up with the following code:

class s1:
    def __repr__(self):
        return '\\n'

class s2:
    def __repr__(self):
        return u'\\n'

print repr(s1()), repr(s2())

I get the following results:

Python 2.3.5: \n \n
Python 2.4.2: \n \n
Python 2.4.3c1: \n \\n 

In the output for Python 2.4.3c1, the backslash in the
representation of class2 appears doubled. This did not
happen in earlier Python versions and seems to be a bug.

My vague guess is that the issue may have crept in with
an attempted fix of Bug #1379994.

-- Christoph

----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-03-28 18:39

Message:
Logged In: YES 
user_id=29957

Ok. After talking to perky, I reverted the fix for 1379994
on the release24-maint branch, and reverted /F's ancient
change on the trunk. This seemed the best combination of
practicality and purity. Fix will be in 2.4.3 final. 

Thanks for the bug report. Man, unicode and repr is a twisty
ball of horrors.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-27 18:09

Message:
Logged In: YES 
user_id=33168

We need to retain the old behaviour, but also fix the bug. 
How can we do that?  

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2006-03-27 18:05

Message:
Logged In: YES 
user_id=55188

Because unicode-escape codec didn't escape \,
PyObject_Repr(u'\\') bypassed backslashes.  But Martin and
Fredrik made PyObject_Repr to use unicode-escape codec for
unicode repr-returns 5 years ago.  So by fixing
unicode-escape codec, their intention could be applied for
the first time, 3 months ago.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-03-27 17:57

Message:
Logged In: YES 
user_id=29957

I'm confused how a checkin from 5+ years ago broke a change
from 3 months ago?

Or am I misunderstanding you?


----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2006-03-27 17:56

Message:
Logged In: YES 
user_id=55188

Found it!:
http://mail.python.org/pipermail/python-dev/2000-July/005353.html
But their intention had never applied before 2.4.3.
What problem would be if we change PyObject_Repr to use the
default encoding not unicode-escape? (revert r16198)


----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2006-03-27 17:38

Message:
Logged In: YES 
user_id=55188

Looking the C code, unicode_repr is doing correct.
But the inconsistency came from PyObject_Repr.
This change made it which is intended:

------------------------------------------------------------------------
r16198 | effbot | 2000-07-09 02:43:32 +0900 (???, 09  7 2000)
| 6 lines


- changed __repr__ to use "unicode escape" encoding for unicode
  strings, instead of the default encoding.
  (see "minidom" thread for discussion, and also patch #100706)


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-27 17:28

Message:
Logged In: YES 
user_id=33168

Attached a patch for the test case to be added with fix.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-03-27 16:53

Message:
Logged In: YES 
user_id=29957

Confirmed - it's also broken in the trunk, and backing out
the patch for http://www.python.org/sf/1379994 (r41728)
fixes the problem. Perky, you checked this in - can you look
at this soon, please? I don't want to release 2.4.3 until
it's fixed, but I also want to get 2.4.3 out this week.

Thanks for the bug report!


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459029&group_id=5470

From noreply at sourceforge.net  Tue Mar 28 09:48:40 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 27 Mar 2006 23:48:40 -0800
Subject: [ python-Bugs-1459733 ] sets.Set can't be subclassed
Message-ID: <E1FO8wS-00060B-T1@sc8-sf-web5.sourceforge.net>

Bugs item #1459733, was opened at 2006-03-28 02:37
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459733&group_id=5470

Please note that this message 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: Invalid
Priority: 5
Submitted By: Michal Kwiatkowski (rubyjoker)
Assigned to: Nobody/Anonymous (nobody)
Summary: sets.Set can't be subclassed

Initial Comment:
sets.Set class fail to hide its implementation. 
Subclassing it and overriding __init__ causes an 
exception during object creation.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-28 07:48

Message:
Logged In: YES 
user_id=849994

Ziga is correct, this is Invalid.

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-03-28 06:33

Message:
Logged In: YES 
user_id=1326842

This is a bug in your code, you have to call
the base class's __init__ method. The error
does not occur during the object creation,
but later when repr(obj) fails due to incorrect
initialization.

----------------------------------------------------------------------

Comment By: Michal Kwiatkowski (rubyjoker)
Date: 2006-03-28 02:41

Message:
Logged In: YES 
user_id=1310227

I'm posting a proposed patch with a test case covering this 
bug (shouldn't all standard library modules have tests?). It 
may introduce performance lost, as it removes __slots__ 
definition.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459733&group_id=5470

From noreply at sourceforge.net  Tue Mar 28 12:37:17 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 28 Mar 2006 02:37:17 -0800
Subject: [ python-Bugs-1459808 ] test suite should pass with -Qnew ?
Message-ID: <E1FOBZd-0008AX-20@sc8-sf-web5.sourceforge.net>

Bugs item #1459808, was opened at 2006-03-28 07:13
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459808&group_id=5470

Please note that this message 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: Neal Norwitz (nnorwitz)
Summary: test suite should pass with -Qnew ?

Initial Comment:
Even though we're not going to change the default for
-Q in Python 2.x, I feel that the testsuite and the
stdlib should demonstrate best practices, and pass with
-Qnew, at least. The following fail under 2.5-HEAD:

    test_builtin test_coercion test_decimal test_doctest 



----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-28 10:37

Message:
Logged In: YES 
user_id=849994

Made test_decimal pass in rev 43385.
Made test_coercion pass in revs 43385 and 43393.
Fixed xdrlib and made test_xdrlib pass in rev 43394.
Made test_augassign pass in rev 43395.
Fixed uu, which made test_email pass in rev 43396.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-03-28 07:39

Message:
Logged In: YES 
user_id=31435

FYI, test_builtin passes w/ or w/o -Qnew now, and I'm going
to sleep :-).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-03-28 07:29

Message:
Logged In: YES 
user_id=31435

FYI, test_doctest works w/ -Qnew now.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459808&group_id=5470

From noreply at sourceforge.net  Tue Mar 28 13:02:40 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 28 Mar 2006 03:02:40 -0800
Subject: [ python-Bugs-1459808 ] test suite should pass with -Qnew ?
Message-ID: <E1FOByC-0004vQ-DE@sc8-sf-web3.sourceforge.net>

Bugs item #1459808, was opened at 2006-03-28 07:13
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459808&group_id=5470

Please note that this message 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: Neal Norwitz (nnorwitz)
Summary: test suite should pass with -Qnew ?

Initial Comment:
Even though we're not going to change the default for
-Q in Python 2.x, I feel that the testsuite and the
stdlib should demonstrate best practices, and pass with
-Qnew, at least. The following fail under 2.5-HEAD:

    test_builtin test_coercion test_decimal test_doctest 



----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-28 11:02

Message:
Logged In: YES 
user_id=849994

Thomas fixed test_ctypes in rev 43397. Closing.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-03-28 10:37

Message:
Logged In: YES 
user_id=849994

Made test_decimal pass in rev 43385.
Made test_coercion pass in revs 43385 and 43393.
Fixed xdrlib and made test_xdrlib pass in rev 43394.
Made test_augassign pass in rev 43395.
Fixed uu, which made test_email pass in rev 43396.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-03-28 07:39

Message:
Logged In: YES 
user_id=31435

FYI, test_builtin passes w/ or w/o -Qnew now, and I'm going
to sleep :-).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-03-28 07:29

Message:
Logged In: YES 
user_id=31435

FYI, test_doctest works w/ -Qnew now.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459808&group_id=5470

From noreply at sourceforge.net  Tue Mar 28 14:02:55 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 28 Mar 2006 04:02:55 -0800
Subject: [ python-Bugs-1459963 ] urllib2 changes header names
Message-ID: <E1FOCuV-00087q-0c@sc8-sf-web1.sourceforge.net>

Bugs item #1459963, was opened at 2006-03-28 14: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=1459963&group_id=5470

Please note that this message 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: Michael Vert (vimico)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 changes header names

Initial Comment:
It seems that urllib2 changes the writing of any
additional supplied headers, i.e. "User-Agent" becomes
"User-agent", "TEST-HEADER" becomes "Test-header".

A few sites do not recognize "User-agent" and insist on
"User-Agent".

Fix: remove all occurences of capitalize() in urllib2.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459963&group_id=5470

From noreply at sourceforge.net  Tue Mar 28 14:10:49 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 28 Mar 2006 04:10:49 -0800
Subject: [ python-Bugs-1459103 ] missing links beetween strftime()'s...
Message-ID: <E1FOD29-0007KN-QG@sc8-sf-web6.sourceforge.net>

Bugs item #1459103, was opened at 2006-03-27 09:03
Message generated for change (Comment added) made by pylucid
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459103&group_id=5470

Please note that this 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: Works For Me
Priority: 5
Submitted By: Jens Diemer (pylucid)
Assigned to: Nobody/Anonymous (nobody)
Summary: missing links beetween strftime()'s...

Initial Comment:
Ther are a few strftime():

strftime() (date method)
strftime() (datetime method)
strftime() (in module time)
strftime() (time method)

http://starship.python.net/crew/theller/pyhelp.cgi?keyword=strftime&version=current


But only in time.strftime() is the directives table:
http://docs.python.org/lib/module-time.html#l2h-1955

That's ok, if there is a Link directly to this table,
in the other modules.

I suggest: set Links in the other modules to the
directives table in module time.

----------------------------------------------------------------------

>Comment By: Jens Diemer (pylucid)
Date: 2006-03-28 14:10

Message:
Logged In: YES 
user_id=1330780

Yes, there is the comment "See the section on strftime()
behavior." But that helps not much. I find it should be
called in such a way: "See strftime() in module time" or
similarly.

And there are no links! Not in the CHM version and not in
the online version... In the online Version the link should
go to this page:
http://docs.python.org/lib/module-time.html#l2h-1955

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-03-28 00:14

Message:
Logged In: YES 
user_id=849994

All the datetime methods refer to the "section of strftime()
behavior" which is important to know. From there, there is a
link to time.strftime.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459103&group_id=5470

From noreply at sourceforge.net  Tue Mar 28 14:16:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 28 Mar 2006 04:16:42 -0800
Subject: [ python-Bugs-1459963 ] urllib2 changes header names
Message-ID: <E1FOD7q-0007hy-R7@sc8-sf-web6.sourceforge.net>

Bugs item #1459963, was opened at 2006-03-28 14:02
Message generated for change (Comment added) made by pylucid
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459963&group_id=5470

Please note that this message 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: Michael Vert (vimico)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 changes header names

Initial Comment:
It seems that urllib2 changes the writing of any
additional supplied headers, i.e. "User-Agent" becomes
"User-agent", "TEST-HEADER" becomes "Test-header".

A few sites do not recognize "User-agent" and insist on
"User-Agent".

Fix: remove all occurences of capitalize() in urllib2.


----------------------------------------------------------------------

Comment By: Jens Diemer (pylucid)
Date: 2006-03-28 14:16

Message:
Logged In: YES 
user_id=1330780

There are old, closed Bug-Reports:
https://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=994101

?!?!?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459963&group_id=5470

From noreply at sourceforge.net  Tue Mar 28 14:18:10 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 28 Mar 2006 04:18:10 -0800
Subject: [ python-Bugs-994101 ] urllib2: improper capitalization of headers
Message-ID: <E1FOD9G-0007pe-4v@sc8-sf-web6.sourceforge.net>

Bugs item #994101, was opened at 2004-07-19 23:22
Message generated for change (Comment added) made by pylucid
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994101&group_id=5470

Please note that this message 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: Robert Sayre (franklinmint)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2: improper capitalization of headers

Initial Comment:
urllib2.py version 1.72 uses capitalize() on HTTP
header names. This results in headers like "User-agent"
instead of "User-Agent". This causes HTTP 400 errors on
some servers when the request has a body, because there
are two content length headers placed in the request:

"Content-Length" (inserted by httplib)
"Content-length" (inserted by
Request.add_unredirected_header)

The capitalization is incorrect, and httplib inserts
Content-Length anyway, so I'm not sure why urllib2 is
bothering.

----------------------------------------------------------------------

Comment By: Jens Diemer (pylucid)
Date: 2006-03-28 14:18

Message:
Logged In: YES 
user_id=1330780

This isn't fixed:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459963&group_id=5470

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2005-01-09 15:56

Message:
Logged In: YES 
user_id=469548

This was fixed by the new patch jjlee provided (#997626).

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2004-07-25 20:06

Message:
Logged In: YES 
user_id=261020

I've added a comment to 996159 which explains what's wrong 
and points to a new patch.


----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-07-22 22:48

Message:
Logged In: YES 
user_id=469548

Patch is available at http://python.org/sf/996159.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994101&group_id=5470

From noreply at sourceforge.net  Tue Mar 28 14:23:14 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 28 Mar 2006 04:23:14 -0800
Subject: [ python-Bugs-994101 ] urllib2: improper capitalization of headers
Message-ID: <E1FODEA-0007Bg-3C@sc8-sf-web4-b.sourceforge.net>

Bugs item #994101, was opened at 2004-07-19 21:22
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994101&group_id=5470

Please note that this message 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: Robert Sayre (franklinmint)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2: improper capitalization of headers

Initial Comment:
urllib2.py version 1.72 uses capitalize() on HTTP
header names. This results in headers like "User-agent"
instead of "User-Agent". This causes HTTP 400 errors on
some servers when the request has a body, because there
are two content length headers placed in the request:

"Content-Length" (inserted by httplib)
"Content-length" (inserted by
Request.add_unredirected_header)

The capitalization is incorrect, and httplib inserts
Content-Length anyway, so I'm not sure why urllib2 is
bothering.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-28 12:23

Message:
Logged In: YES 
user_id=849994

It is. This bug report was about duplicate headers in the
request, while the one you mention is about the
capitalization per se.

----------------------------------------------------------------------

Comment By: Jens Diemer (pylucid)
Date: 2006-03-28 12:18

Message:
Logged In: YES 
user_id=1330780

This isn't fixed:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459963&group_id=5470

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2005-01-09 14:56

Message:
Logged In: YES 
user_id=469548

This was fixed by the new patch jjlee provided (#997626).

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2004-07-25 18:06

Message:
Logged In: YES 
user_id=261020

I've added a comment to 996159 which explains what's wrong 
and points to a new patch.


----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-07-22 20:48

Message:
Logged In: YES 
user_id=469548

Patch is available at http://python.org/sf/996159.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994101&group_id=5470

From noreply at sourceforge.net  Tue Mar 28 14:24:33 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 28 Mar 2006 04:24:33 -0800
Subject: [ python-Bugs-994101 ] urllib2: improper capitalization of headers
Message-ID: <E1FODFR-0008Cv-IL@sc8-sf-web6.sourceforge.net>

Bugs item #994101, was opened at 2004-07-19 23:22
Message generated for change (Comment added) made by pylucid
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994101&group_id=5470

Please note that this message 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: Robert Sayre (franklinmint)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2: improper capitalization of headers

Initial Comment:
urllib2.py version 1.72 uses capitalize() on HTTP
header names. This results in headers like "User-agent"
instead of "User-Agent". This causes HTTP 400 errors on
some servers when the request has a body, because there
are two content length headers placed in the request:

"Content-Length" (inserted by httplib)
"Content-length" (inserted by
Request.add_unredirected_header)

The capitalization is incorrect, and httplib inserts
Content-Length anyway, so I'm not sure why urllib2 is
bothering.

----------------------------------------------------------------------

Comment By: Jens Diemer (pylucid)
Date: 2006-03-28 14:24

Message:
Logged In: YES 
user_id=1330780

Ah, OK... Sorry ;)

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-03-28 14:23

Message:
Logged In: YES 
user_id=849994

It is. This bug report was about duplicate headers in the
request, while the one you mention is about the
capitalization per se.

----------------------------------------------------------------------

Comment By: Jens Diemer (pylucid)
Date: 2006-03-28 14:18

Message:
Logged In: YES 
user_id=1330780

This isn't fixed:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459963&group_id=5470

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2005-01-09 15:56

Message:
Logged In: YES 
user_id=469548

This was fixed by the new patch jjlee provided (#997626).

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2004-07-25 20:06

Message:
Logged In: YES 
user_id=261020

I've added a comment to 996159 which explains what's wrong 
and points to a new patch.


----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-07-22 22:48

Message:
Logged In: YES 
user_id=469548

Patch is available at http://python.org/sf/996159.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994101&group_id=5470

From noreply at sourceforge.net  Tue Mar 28 14:40:35 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 28 Mar 2006 04:40:35 -0800
Subject: [ python-Bugs-1459963 ] urllib2 changes header names
Message-ID: <E1FODUx-0008GM-Mr@sc8-sf-web4-b.sourceforge.net>

Bugs item #1459963, was opened at 2006-03-28 12:02
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459963&group_id=5470

Please note that this message 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: Michael Vert (vimico)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 changes header names

Initial Comment:
It seems that urllib2 changes the writing of any
additional supplied headers, i.e. "User-Agent" becomes
"User-agent", "TEST-HEADER" becomes "Test-header".

A few sites do not recognize "User-agent" and insist on
"User-Agent".

Fix: remove all occurences of capitalize() in urllib2.


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-28 12:40

Message:
Logged In: YES 
user_id=849994

Some normalizing is important to prevent duplicate headers.
Changed capitalize() to title() to match the default casing
(now user-agent becomes User-Agent) in rev. 43399.

----------------------------------------------------------------------

Comment By: Jens Diemer (pylucid)
Date: 2006-03-28 12:16

Message:
Logged In: YES 
user_id=1330780

There are old, closed Bug-Reports:
https://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=994101

?!?!?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459963&group_id=5470

From noreply at sourceforge.net  Tue Mar 28 14:49:07 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 28 Mar 2006 04:49:07 -0800
Subject: [ python-Bugs-1459103 ] missing links beetween strftime()'s...
Message-ID: <E1FODdD-0003GK-AT@sc8-sf-web3.sourceforge.net>

Bugs item #1459103, was opened at 2006-03-27 07:03
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459103&group_id=5470

Please note that this 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: Jens Diemer (pylucid)
Assigned to: Nobody/Anonymous (nobody)
Summary: missing links beetween strftime()'s...

Initial Comment:
Ther are a few strftime():

strftime() (date method)
strftime() (datetime method)
strftime() (in module time)
strftime() (time method)

http://starship.python.net/crew/theller/pyhelp.cgi?keyword=strftime&version=current


But only in time.strftime() is the directives table:
http://docs.python.org/lib/module-time.html#l2h-1955

That's ok, if there is a Link directly to this table,
in the other modules.

I suggest: set Links in the other modules to the
directives table in module time.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-28 12:49

Message:
Logged In: YES 
user_id=849994

Added inter-section links in rev. 43400.

----------------------------------------------------------------------

Comment By: Jens Diemer (pylucid)
Date: 2006-03-28 12:10

Message:
Logged In: YES 
user_id=1330780

Yes, there is the comment "See the section on strftime()
behavior." But that helps not much. I find it should be
called in such a way: "See strftime() in module time" or
similarly.

And there are no links! Not in the CHM version and not in
the online version... In the online Version the link should
go to this page:
http://docs.python.org/lib/module-time.html#l2h-1955

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-03-27 22:14

Message:
Logged In: YES 
user_id=849994

All the datetime methods refer to the "section of strftime()
behavior" which is important to know. From there, there is a
link to time.strftime.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459103&group_id=5470

From noreply at sourceforge.net  Tue Mar 28 17:32:59 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 28 Mar 2006 07:32:59 -0800
Subject: [ python-Bugs-1459963 ] urllib2 changes header names
Message-ID: <E1FOGBn-0001uL-QY@sc8-sf-web5.sourceforge.net>

Bugs item #1459963, was opened at 2006-03-28 14:02
Message generated for change (Comment added) made by vimico
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459963&group_id=5470

Please note that this message 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: Michael Vert (vimico)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 changes header names

Initial Comment:
It seems that urllib2 changes the writing of any
additional supplied headers, i.e. "User-Agent" becomes
"User-agent", "TEST-HEADER" becomes "Test-header".

A few sites do not recognize "User-agent" and insist on
"User-Agent".

Fix: remove all occurences of capitalize() in urllib2.


----------------------------------------------------------------------

>Comment By: Michael Vert (vimico)
Date: 2006-03-28 17:32

Message:
Logged In: YES 
user_id=928834

I checked the database before submitting...  I admit, I
haven't gone back 2 years. :-)

It seems to be the same bug. But it was still present in
2.4.2 (version used in Ubuntu Breezy).

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-03-28 14:40

Message:
Logged In: YES 
user_id=849994

Some normalizing is important to prevent duplicate headers.
Changed capitalize() to title() to match the default casing
(now user-agent becomes User-Agent) in rev. 43399.

----------------------------------------------------------------------

Comment By: Jens Diemer (pylucid)
Date: 2006-03-28 14:16

Message:
Logged In: YES 
user_id=1330780

There are old, closed Bug-Reports:
https://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=994101

?!?!?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459963&group_id=5470

From noreply at sourceforge.net  Tue Mar 28 19:45:58 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 28 Mar 2006 09:45:58 -0800
Subject: [ python-Bugs-1458017 ] Log._log needs to be more forgiving...
Message-ID: <E1FOIGU-0003iK-2k@sc8-sf-web6.sourceforge.net>

Bugs item #1458017, was opened at 2006-03-24 21:17
Message generated for change (Comment added) made by splitscreen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1458017&group_id=5470

Please note that this 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: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: Log._log needs to be more forgiving...

Initial Comment:
The _log method of distutils' Log class executes

    print msg % args

where args might be an empty tuple (the methods that
call _log all
have varargs signatures).  If that's the case and msg
happens to
contain a % sign, it barfs.  It should be more
forgiving, for
instance:

    def _log(self, level, msg, args):
        if level >= self.threshold:
            try:
                print msg % args
            except TypeError:
                if not args:
                    print msg
                else:
                    raise
            sys.stdout.flush()

I just corrected this locally for our 2.3 and 2.4
installations.  The
above is a bit ugly, but it does allow the common case
(msg contains a
% but an empty args list) to pass while still catching
most programmer
errors.  Distutils is trying to log this message (wrapped):

  gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes
  -fPIC -I/opt/app/mysql-5.0.19/include
  -I/opt/app/mysql-5.0.19/include
-I/opt/lang/python/include/python2.3
  -c _mysql.c -o build/temp.solaris-2.8-i86pc-2.3/_mysql.o
  -I/opt/app/mysql-5.0.19/include -xO3 -mt -fsimple=1
-ftrap=%none
  -nofstore -xbuiltin=%all -xlibmil -xlibmopt
-xtarget=generic

I suppose it would be better if all the places in
distutils which log
compiler commands without extra args escaped their %
signs.  This
seems like an acceptable compromise though.

Skip


----------------------------------------------------------------------

Comment By: splitscreen (splitscreen)
Date: 2006-03-28 17:45

Message:
Logged In: YES 
user_id=1126061

Oh right, I understand now.

Yeah the fix seems fine to me.

Although, would it be more appropriate to check 

if not args:

is True?

So the _log() function would be something more like this:

def _log(self, level, msg, args):
    if level >= self.threshold:
        if not args:
            print msg
        else:
            print msg % args
         sys.stdout.flush()

Just thinking out-loud really.. not sure the check for the
raised exception is really necessary.

Thanks, Matt

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2006-03-28 03:58

Message:
Logged In: YES 
user_id=44345

It barfs if you pass an empty tuple and the msg argument contains a % escape.
For example, try:

    print "%s" % ()

In the particular case that tripped me up, it's trying to print a (bogus) gcc
command which contains % escapes while passing no args to map them.


----------------------------------------------------------------------

Comment By: splitscreen (splitscreen)
Date: 2006-03-27 21:27

Message:
Logged In: YES 
user_id=1126061

I can't reproduce on 2.4.2. Although maybe I misunderstood...

Are you saying that _log() barfs when you pass an empty tuple?

Passing an empty tuple to _log() works fine here..

I can understand it breaking when you pass some format
string to args and the msg contains an '%', that's the
developer's fault for not escaping the precentage sign.

Could you clarify? Or am I totally wrong?

Thanks

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1458017&group_id=5470

From noreply at sourceforge.net  Tue Mar 28 20:03:08 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 28 Mar 2006 10:03:08 -0800
Subject: [ python-Bugs-1458220 ] sys.maxint should be mentioned in explanation
	of int type
Message-ID: <E1FOIX5-0006mJ-GS@sc8-sf-web3.sourceforge.net>

Bugs item #1458220, was opened at 2006-03-25 10:42
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1458220&group_id=5470

Please note that this 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: 2
Submitted By: Christoph Zwerschke (cito)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.maxint should be mentioned in explanation of int type

Initial Comment:
The Lib Reference says in section 2.3.4 (Numeric Types
-- int, float, long, complex):

"Plain integers (also just called integers) are
implemented using long in C, which gives them at least
32 bits of precision."

I think it would be helpful to insert the following
sentence here: "The maximum value on your platform is
sys.maxint."

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-28 18:03

Message:
Logged In: YES 
user_id=849994

Added a clause in r43404.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1458220&group_id=5470

From noreply at sourceforge.net  Wed Mar 29 01:08:16 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 28 Mar 2006 15:08:16 -0800
Subject: [ python-Bugs-1442493 ] IDLE shell window gets very slow when
	displaying long lines
Message-ID: <E1FONIO-0005qY-Ep@sc8-sf-web5.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: 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: 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 Mar 29 01:17:31 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 28 Mar 2006 15:17:31 -0800
Subject: [ python-Bugs-1199282 ] subprocess _active.remove(self) self not in
	list _active
Message-ID: <E1FONRL-0001fA-1R@sc8-sf-web1.sourceforge.net>

Bugs item #1199282, was opened at 2005-05-10 20:24
Message generated for change (Comment added) made by tfaujour
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199282&group_id=5470

Please note that this message 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: cheops (atila-cheops)
Assigned to: Peter ?
strand (astrand)
Summary: subprocess _active.remove(self) self not in list _active

Initial Comment:
I start a subprocess in a seperate thread (25 concurrent 
threads)
in some of the threads the following error occurs
 
Exception in thread Thread-4:
Traceback (most recent call last):
  File "C:\Python24\lib\threading.py", line 442, in 
__bootstrap
    self.run()
  File "upgrade.py", line 45, in run
    returncode = p.wait()
  File "C:\Python24\lib\subprocess.py", line 765, in wait
    _active.remove(self)
ValueError: list.remove(x): x not in list
 
this is the code that starts the subprocess and where I 
wait for the result
 
p = subprocess.Popen('command', \
                             stdin=None, 
stdout=subprocess.PIPE, \
                             stderr=subprocess.STDOUT, 
universal_newlines=True)
returncode = p.wait()
errormessage = p.stdout.readlines()

----------------------------------------------------------------------

Comment By: Tristan Faujour (tfaujour)
Date: 2006-03-29 01:17

Message:
Logged In: YES 
user_id=1488657

I am running into the same problem on a Windows 2k/XP
plateform with a multi-threaded application. It occurs randomly.

It has never appened (yet) on a Linux plateform.

I think accesses to _active should be serialized in a
thread-safe way. _active could be a Queue (from the Queue
module) for example.


----------------------------------------------------------------------

Comment By: HVB bei TUP (hvb_tup)
Date: 2006-01-25 09:10

Message:
Logged In: YES 
user_id=1434251

Wouldn't it be best to completely remove any references 
to "_active" and "_cleanup"?

----------------------------------------------------------------------

Comment By: cheops (atila-cheops)
Date: 2006-01-25 08:08

Message:
Logged In: YES 
user_id=1276121

As suggested by astrand
adding a try ... except clause in the file subprocess.py did
the job
I had to add that try ... except clause in 2 places
if you look in the file there are 2 instances were
list.remove(x) occurs unprotected.

try:
 list.remove(x)
except:
 pass

I have worked with 2.4.0, 2.4.1 and 2.4.2 and all three
needed the patch.
Hope this helps.

----------------------------------------------------------------------

Comment By: HVB bei TUP (hvb_tup)
Date: 2006-01-23 17:34

Message:
Logged In: YES 
user_id=1434251

BTW: In my case, I call python.exe from a Windows service.

----------------------------------------------------------------------

Comment By: HVB bei TUP (hvb_tup)
Date: 2006-01-23 17:30

Message:
Logged In: YES 
user_id=1434251

I have a similar problem.
Python 2.4.1 under MS Windows 2003,
Multi-Threaded application (about concurrent 10 threads).

In my case the same error occurs during _cleanup called 
from __init__ :

  
File "E:\lisa_ins\ewu\coop\reporting\python\tup_lisa\util\t
hreadutil.py", line 582, in callSubProcess
    creationflags = creationflags
  File "C:\Python24\lib\subprocess.py", line 506, in 
__init__
    _cleanup()
  File "C:\Python24\lib\subprocess.py", line 414, in 
_cleanup
    inst.poll()
  File "C:\Python24\lib\subprocess.py", line 755, in poll
    _active.remove(self)
ValueError: list.remove(x): x not in list

Is there a work-around?


----------------------------------------------------------------------

Comment By: cheops (atila-cheops)
Date: 2005-09-19 11:29

Message:
Logged In: YES 
user_id=1276121

I noticed this bug under windows
to reproduce the bug, I attached the script I use, but this 
needs input, I tried with a simpler example (pinging a number 
of host concurrently) but that did not cause the bug.

----------------------------------------------------------------------

Comment By: Peter ?
strand (astrand)
Date: 2005-06-23 18:03

Message:
Logged In: YES 
user_id=344921

I believe it should be sufficient to add a try...except
clause around _active.remove(). Can you upload a complete
example that triggers the bug? Have you noticed this bug on
Windows, UNIX or both platforms?


----------------------------------------------------------------------

Comment By: cheops (atila-cheops)
Date: 2005-05-12 12:17

Message:
Logged In: YES 
user_id=1276121

this might be related to bug 1183780

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199282&group_id=5470

From noreply at sourceforge.net  Wed Mar 29 02:05:49 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 28 Mar 2006 16:05:49 -0800
Subject: [ python-Bugs-1460340 ] random.sample can raise KeyError
Message-ID: <E1FOOC5-0004gD-8q@sc8-sf-web1.sourceforge.net>

Bugs item #1460340, was opened at 2006-03-29 00: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=1460340&group_id=5470

Please note that this message 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: paul rubin (phr)
Assigned to: Nobody/Anonymous (nobody)
Summary: random.sample can raise KeyError

Initial Comment:
I have only tested this in 2.3 and the relevant code in
random.py has changed in the current svn branch, but
from inspection it looks to me like the bug may still
be there.

If you initialize a dictionary as follows:

 a={}.fromkeys(range(10)+range(10,100,2)+range(100,110))

then

 random.sample(a,3)

raises KeyError most times that you call it.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460340&group_id=5470

From noreply at sourceforge.net  Wed Mar 29 07:11:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 28 Mar 2006 21:11:25 -0800
Subject: [ python-Bugs-1199282 ] subprocess _active.remove(self) self not in
	list _active
Message-ID: <E1FOSxp-00079D-R9@sc8-sf-web1.sourceforge.net>

Bugs item #1199282, was opened at 2005-05-10 20:24
Message generated for change (Comment added) made by astrand
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199282&group_id=5470

Please note that this message 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: cheops (atila-cheops)
Assigned to: Peter ?
strand (astrand)
Summary: subprocess _active.remove(self) self not in list _active

Initial Comment:
I start a subprocess in a seperate thread (25 concurrent 
threads)
in some of the threads the following error occurs
 
Exception in thread Thread-4:
Traceback (most recent call last):
  File "C:\Python24\lib\threading.py", line 442, in 
__bootstrap
    self.run()
  File "upgrade.py", line 45, in run
    returncode = p.wait()
  File "C:\Python24\lib\subprocess.py", line 765, in wait
    _active.remove(self)
ValueError: list.remove(x): x not in list
 
this is the code that starts the subprocess and where I 
wait for the result
 
p = subprocess.Popen('command', \
                             stdin=None, 
stdout=subprocess.PIPE, \
                             stderr=subprocess.STDOUT, 
universal_newlines=True)
returncode = p.wait()
errormessage = p.stdout.readlines()

----------------------------------------------------------------------

>Comment By: Peter ?
strand (astrand)
Date: 2006-03-29 07:11

Message:
Logged In: YES 
user_id=344921

>I think accesses to _active should be serialized in a
>thread-safe way. _active could be a Queue (from the Queue
>module) for example

Simply list operations such as remove() and append() are
thread safe, so there should be no need for a Queue. Also, a
Queue cannot be used since the subprocess module needs to be
compatible with Python 2.2. 

----------------------------------------------------------------------

Comment By: Tristan Faujour (tfaujour)
Date: 2006-03-29 01:17

Message:
Logged In: YES 
user_id=1488657

I am running into the same problem on a Windows 2k/XP
plateform with a multi-threaded application. It occurs randomly.

It has never appened (yet) on a Linux plateform.

I think accesses to _active should be serialized in a
thread-safe way. _active could be a Queue (from the Queue
module) for example.


----------------------------------------------------------------------

Comment By: HVB bei TUP (hvb_tup)
Date: 2006-01-25 09:10

Message:
Logged In: YES 
user_id=1434251

Wouldn't it be best to completely remove any references 
to "_active" and "_cleanup"?

----------------------------------------------------------------------

Comment By: cheops (atila-cheops)
Date: 2006-01-25 08:08

Message:
Logged In: YES 
user_id=1276121

As suggested by astrand
adding a try ... except clause in the file subprocess.py did
the job
I had to add that try ... except clause in 2 places
if you look in the file there are 2 instances were
list.remove(x) occurs unprotected.

try:
 list.remove(x)
except:
 pass

I have worked with 2.4.0, 2.4.1 and 2.4.2 and all three
needed the patch.
Hope this helps.

----------------------------------------------------------------------

Comment By: HVB bei TUP (hvb_tup)
Date: 2006-01-23 17:34

Message:
Logged In: YES 
user_id=1434251

BTW: In my case, I call python.exe from a Windows service.

----------------------------------------------------------------------

Comment By: HVB bei TUP (hvb_tup)
Date: 2006-01-23 17:30

Message:
Logged In: YES 
user_id=1434251

I have a similar problem.
Python 2.4.1 under MS Windows 2003,
Multi-Threaded application (about concurrent 10 threads).

In my case the same error occurs during _cleanup called 
from __init__ :

  
File "E:\lisa_ins\ewu\coop\reporting\python\tup_lisa\util\t
hreadutil.py", line 582, in callSubProcess
    creationflags = creationflags
  File "C:\Python24\lib\subprocess.py", line 506, in 
__init__
    _cleanup()
  File "C:\Python24\lib\subprocess.py", line 414, in 
_cleanup
    inst.poll()
  File "C:\Python24\lib\subprocess.py", line 755, in poll
    _active.remove(self)
ValueError: list.remove(x): x not in list

Is there a work-around?


----------------------------------------------------------------------

Comment By: cheops (atila-cheops)
Date: 2005-09-19 11:29

Message:
Logged In: YES 
user_id=1276121

I noticed this bug under windows
to reproduce the bug, I attached the script I use, but this 
needs input, I tried with a simpler example (pinging a number 
of host concurrently) but that did not cause the bug.

----------------------------------------------------------------------

Comment By: Peter ?
strand (astrand)
Date: 2005-06-23 18:03

Message:
Logged In: YES 
user_id=344921

I believe it should be sufficient to add a try...except
clause around _active.remove(). Can you upload a complete
example that triggers the bug? Have you noticed this bug on
Windows, UNIX or both platforms?


----------------------------------------------------------------------

Comment By: cheops (atila-cheops)
Date: 2005-05-12 12:17

Message:
Logged In: YES 
user_id=1276121

this might be related to bug 1183780

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199282&group_id=5470

From noreply at sourceforge.net  Wed Mar 29 09:16:44 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 28 Mar 2006 23:16:44 -0800
Subject: [ python-Bugs-1460493 ] Why not drop the _active list?
Message-ID: <E1FOUv6-0004cj-I7@sc8-sf-web6.sourceforge.net>

Bugs item #1460493, was opened at 2006-03-29 07: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=1460493&group_id=5470

Please note that this 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: HVB bei TUP (hvb_tup)
Assigned to: Nobody/Anonymous (nobody)
Summary: Why not drop the _active list?

Initial Comment:
I am using a modified version of subprocess.py,

where I have removed the _active list and all 
references to it.

I have tested it (under Windows 2000) and there were 
no errors.

So what is the reason for managing the _active list 
at all? Why not drop it?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460493&group_id=5470

From noreply at sourceforge.net  Wed Mar 29 10:28:53 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 29 Mar 2006 00:28:53 -0800
Subject: [ python-Bugs-1460514 ] ctypes extension does not compile on Mac OS
	10.3.9
Message-ID: <E1FOW2v-0003mZ-8x@sc8-sf-web2.sourceforge.net>

Bugs item #1460514, was opened at 2006-03-29 01: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=1460514&group_id=5470

Please note that this 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: Open
Resolution: None
Priority: 5
Submitted By: Andrew Dalke (dalke)
Assigned to: Nobody/Anonymous (nobody)
Summary: ctypes extension does not compile on Mac OS 10.3.9

Initial Comment:
I compiled Python from CVS this morning.  It silently failed to compile 
ctypes.  Here is the text surrounding the failure

gcc [deleted] -c /Users/dalke/cvses/python-svn/Modules/_ctypes/
libffi/src/powerpc/darwin_closure.S -o build/temp.darwin-7.9.0-
Power_Macintosh-2.5/darwin_closure.o
darwin_closure.S:249:unknown section attribute: live_support
darwin_closure.S:249:Rest of line ignored. 1st junk character valued 69 
(E).
building 'itertools' extension
 ...

Python installed but when I tried to import ctypes I got

  File "/usr/local/lib/python2.5/ctypes/__init__.py", line 8, in 
<module>
    from _ctypes import Union, Structure, Array
ImportError: No module named _ctypes

I tracked it down to the '+live_support' attribute from the 
darwin_closure.S.  My compiler does not understand that.

Thomas Heller (in private email) pointed out the text from the ctypes 
README

        On OS X, the segment attribute live_support must be
	defined. If your compiler doesn't know about it, upgrade or
	set the environment variable CCASFLAGS="-Dno_live_support".

Upgrading is out of the option.  I set the environment variable but that 
did not fix things when I tried to recompile Python.  However, editing 
the file to remove the "+live_support" works.  All the self-tests passed, 
and my experimentation this afternoon was successful.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460514&group_id=5470

From noreply at sourceforge.net  Wed Mar 29 11:11:28 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 29 Mar 2006 01:11:28 -0800
Subject: [ python-Bugs-1460340 ] random.sample can raise KeyError
Message-ID: <E1FOWi8-0001sK-Sg@sc8-sf-web5.sourceforge.net>

Bugs item #1460340, was opened at 2006-03-29 00:05
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460340&group_id=5470

Please note that this message 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: Invalid
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Nobody/Anonymous (nobody)
Summary: random.sample can raise KeyError

Initial Comment:
I have only tested this in 2.3 and the relevant code in
random.py has changed in the current svn branch, but
from inspection it looks to me like the bug may still
be there.

If you initialize a dictionary as follows:

 a={}.fromkeys(range(10)+range(10,100,2)+range(100,110))

then

 random.sample(a,3)

raises KeyError most times that you call it.


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-29 09:11

Message:
Logged In: YES 
user_id=849994

random.sample is documented to take a sequence as its first
argument. A dict is not a sequence type.

I think you want
random.sample(a.keys(), 3)
or, for large dicts,
random.sample(a.iterkeys(), 3)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460340&group_id=5470

From noreply at sourceforge.net  Wed Mar 29 11:17:21 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 29 Mar 2006 01:17:21 -0800
Subject: [ python-Bugs-1460340 ] random.sample can raise KeyError
Message-ID: <E1FOWnp-0005oZ-0H@sc8-sf-web1.sourceforge.net>

Bugs item #1460340, was opened at 2006-03-28 19:05
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460340&group_id=5470

Please note that this message 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: 5
Submitted By: paul rubin (phr)
Assigned to: Nobody/Anonymous (nobody)
Summary: random.sample can raise KeyError

Initial Comment:
I have only tested this in 2.3 and the relevant code in
random.py has changed in the current svn branch, but
from inspection it looks to me like the bug may still
be there.

If you initialize a dictionary as follows:

 a={}.fromkeys(range(10)+range(10,100,2)+range(100,110))

then

 random.sample(a,3)

raises KeyError most times that you call it.


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2006-03-29 04:17

Message:
Logged In: YES 
user_id=80475

Checked-in a fix.
See revision 43420 and 43421.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-03-29 04:11

Message:
Logged In: YES 
user_id=849994

random.sample is documented to take a sequence as its first
argument. A dict is not a sequence type.

I think you want
random.sample(a.keys(), 3)
or, for large dicts,
random.sample(a.iterkeys(), 3)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460340&group_id=5470

From noreply at sourceforge.net  Wed Mar 29 11:27:21 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 29 Mar 2006 01:27:21 -0800
Subject: [ python-Bugs-1460514 ] ctypes extension does not compile on Mac OS
	10.3.9
Message-ID: <E1FOWxV-0004UX-Ru@sc8-sf-web6.sourceforge.net>

Bugs item #1460514, was opened at 2006-03-29 08:28
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460514&group_id=5470

Please note that this 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: Open
Resolution: None
>Priority: 7
Submitted By: Andrew Dalke (dalke)
>Assigned to: Thomas Heller (theller)
Summary: ctypes extension does not compile on Mac OS 10.3.9

Initial Comment:
I compiled Python from CVS this morning.  It silently failed to compile 
ctypes.  Here is the text surrounding the failure

gcc [deleted] -c /Users/dalke/cvses/python-svn/Modules/_ctypes/
libffi/src/powerpc/darwin_closure.S -o build/temp.darwin-7.9.0-
Power_Macintosh-2.5/darwin_closure.o
darwin_closure.S:249:unknown section attribute: live_support
darwin_closure.S:249:Rest of line ignored. 1st junk character valued 69 
(E).
building 'itertools' extension
 ...

Python installed but when I tried to import ctypes I got

  File "/usr/local/lib/python2.5/ctypes/__init__.py", line 8, in 
<module>
    from _ctypes import Union, Structure, Array
ImportError: No module named _ctypes

I tracked it down to the '+live_support' attribute from the 
darwin_closure.S.  My compiler does not understand that.

Thomas Heller (in private email) pointed out the text from the ctypes 
README

        On OS X, the segment attribute live_support must be
	defined. If your compiler doesn't know about it, upgrade or
	set the environment variable CCASFLAGS="-Dno_live_support".

Upgrading is out of the option.  I set the environment variable but that 
did not fix things when I tried to recompile Python.  However, editing 
the file to remove the "+live_support" works.  All the self-tests passed, 
and my experimentation this afternoon was successful.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460514&group_id=5470

From noreply at sourceforge.net  Wed Mar 29 11:41:19 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 29 Mar 2006 01:41:19 -0800
Subject: [ python-Bugs-1460564 ] Misleading documentation for socket.fromfd()
Message-ID: <E1FOXB1-0005NL-Ca@sc8-sf-web6.sourceforge.net>

Bugs item #1460564, was opened at 2006-03-29 11: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=1460564&group_id=5470

Please note that this message 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: Michael Smith (mlrsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: Misleading documentation for socket.fromfd()

Initial Comment:
The socket.fromfd() method does not correctly document
what it does, in a way that is likely to cause users to
leak file descriptors.

Proposed fix:

--- Modules/socketmodule.c      2005-09-14
20:15:03.000000000 +0200
+++
/home/msmith/src/Python-2.4.2/Modules/socketmodule.c  
     2006-03-29 11:28:35.000000000 +0200
@@ -3077,7 +3077,8 @@
 PyDoc_STRVAR(fromfd_doc,
 "fromfd(fd, family, type[, proto]) -> socket object\n\
 \n\
-Create a socket object from the given file descriptor.\n\
+Duplicate the given file descriptor, and create a
socket\n\
+object from the duplicate.\r\
 The remaining arguments are the same as for socket().");

 #endif /* NO_DUP */


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460564&group_id=5470

From noreply at sourceforge.net  Wed Mar 29 11:46:52 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 29 Mar 2006 01:46:52 -0800
Subject: [ python-Bugs-1460340 ] random.sample can raise KeyError
Message-ID: <E1FOXGO-0004lA-Ki@sc8-sf-web4-b.sourceforge.net>

Bugs item #1460340, was opened at 2006-03-29 00:05
Message generated for change (Comment added) made by phr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460340&group_id=5470

Please note that this message 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: 5
Submitted By: paul rubin (phr)
Assigned to: Nobody/Anonymous (nobody)
Summary: random.sample can raise KeyError

Initial Comment:
I have only tested this in 2.3 and the relevant code in
random.py has changed in the current svn branch, but
from inspection it looks to me like the bug may still
be there.

If you initialize a dictionary as follows:

 a={}.fromkeys(range(10)+range(10,100,2)+range(100,110))

then

 random.sample(a,3)

raises KeyError most times that you call it.


----------------------------------------------------------------------

>Comment By: paul rubin (phr)
Date: 2006-03-29 09:46

Message:
Logged In: YES 
user_id=72053

I don't think the fix at 43421 is quite right, but I can't
easily test it in my current setup.  Suppose

a = dict.fromkeys(range(99) + ['x'])
b = random.sample(a,1)

99% of the time, there's no KeyError and b gets set to [j]
where j is some random integer.

1% of the time, there's a KeyError, random.sample is called
recursively, and the recursive call returns [some integer j]
99% of the time, and returns ['x'] 1% of the time.

So in total, ['x'] gets returned .01% of the time instead of
1% of the time.

I think it's better to not set result[i]=population[j]
inside the loop.  Instead, just build up the selected set
until it has enough indices; then try to make a result list
using those indices, and if there's a KeyError, convert the
population to a list and use the same selection set to make
the results.

gbrandl also correctly points out that a dict is not a
sequence type, so maybe it's ok to just punt on dicts.  But
it's obvious from the code comments that somebody once
wanted dicts to work, and it's reasonable for people to want
sets to work.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-03-29 09:17

Message:
Logged In: YES 
user_id=80475

Checked-in a fix.
See revision 43420 and 43421.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-03-29 09:11

Message:
Logged In: YES 
user_id=849994

random.sample is documented to take a sequence as its first
argument. A dict is not a sequence type.

I think you want
random.sample(a.keys(), 3)
or, for large dicts,
random.sample(a.iterkeys(), 3)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460340&group_id=5470

From noreply at sourceforge.net  Wed Mar 29 12:07:45 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 29 Mar 2006 02:07:45 -0800
Subject: [ python-Bugs-1460340 ] random.sample can raise KeyError
Message-ID: <E1FOXab-0001bI-Dw@sc8-sf-web2.sourceforge.net>

Bugs item #1460340, was opened at 2006-03-29 00:05
Message generated for change (Comment added) made by phr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460340&group_id=5470

Please note that this message 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: 5
Submitted By: paul rubin (phr)
Assigned to: Nobody/Anonymous (nobody)
Summary: random.sample can raise KeyError

Initial Comment:
I have only tested this in 2.3 and the relevant code in
random.py has changed in the current svn branch, but
from inspection it looks to me like the bug may still
be there.

If you initialize a dictionary as follows:

 a={}.fromkeys(range(10)+range(10,100,2)+range(100,110))

then

 random.sample(a,3)

raises KeyError most times that you call it.


----------------------------------------------------------------------

>Comment By: paul rubin (phr)
Date: 2006-03-29 10:07

Message:
Logged In: YES 
user_id=72053

Actually the previous comment is wrong too; 99% of the time,
sample(a,1) will return None since that's the value
connected to every key in the dictionary, i.e. it's
population[j] for every j.  The other 1% of the time, the
dict gets converted to a list, and the sample returns a key
from the dict rather than a value, which is certainly wrong.
 And you can see how the probabilities are still messed up
if the values in the dict are distinct.

I think it's ok to give up on dicts, but some warning should
about it be added to the manual unless dict-like things
somehow get detected in the code.  It would be best to test
for the object really being a sequence, but I don't know if
such a test exists.  Maybe one should be added.

I'll leave it to you guys to reopen this bug if appropriate.

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2006-03-29 09:46

Message:
Logged In: YES 
user_id=72053

I don't think the fix at 43421 is quite right, but I can't
easily test it in my current setup.  Suppose

a = dict.fromkeys(range(99) + ['x'])
b = random.sample(a,1)

99% of the time, there's no KeyError and b gets set to [j]
where j is some random integer.

1% of the time, there's a KeyError, random.sample is called
recursively, and the recursive call returns [some integer j]
99% of the time, and returns ['x'] 1% of the time.

So in total, ['x'] gets returned .01% of the time instead of
1% of the time.

I think it's better to not set result[i]=population[j]
inside the loop.  Instead, just build up the selected set
until it has enough indices; then try to make a result list
using those indices, and if there's a KeyError, convert the
population to a list and use the same selection set to make
the results.

gbrandl also correctly points out that a dict is not a
sequence type, so maybe it's ok to just punt on dicts.  But
it's obvious from the code comments that somebody once
wanted dicts to work, and it's reasonable for people to want
sets to work.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-03-29 09:17

Message:
Logged In: YES 
user_id=80475

Checked-in a fix.
See revision 43420 and 43421.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-03-29 09:11

Message:
Logged In: YES 
user_id=849994

random.sample is documented to take a sequence as its first
argument. A dict is not a sequence type.

I think you want
random.sample(a.keys(), 3)
or, for large dicts,
random.sample(a.iterkeys(), 3)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460340&group_id=5470

From noreply at sourceforge.net  Wed Mar 29 13:22:41 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 29 Mar 2006 03:22:41 -0800
Subject: [ python-Bugs-1460605 ] Python 2.4.2 does not compile on SunOS 5.10
	using gcc 
Message-ID: <E1FOYl7-0006Ii-7Y@sc8-sf-web2.sourceforge.net>

Bugs item #1460605, was opened at 2006-03-29 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=1460605&group_id=5470

Please note that this 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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jakob Schi?tz (schiotz)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.4.2 does not compile on SunOS 5.10 using gcc 

Initial Comment:
Core Python does not compile on my university's Sun server.

$ ./configure --prefix=$HOME
$ gmake
   [ lots of output deleted ]
gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -I. -I./Include  -DPy_BUILD_CORE -o
Objects/cobject.o Objects/cobject.c
gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -I. -I./Include  -DPy_BUILD_CORE -o
Objects/complexobject.o Objects/complexobject.c
Objects/complexobject.c: In function `complex_pow':
Objects/complexobject.c:476: error: invalid operands to
binary ==
Objects/complexobject.c:476: error: wrong type argument
to unary minus
Objects/complexobject.c:476: error: invalid operands to
binary ==
Objects/complexobject.c:476: error: wrong type argument
to unary minus
gmake: *** [Objects/complexobject.o] Error 1

$ uname -a
SunOS hald 5.10 Generic_118822-18 sun4u sparc
SUNW,Sun-Fire-15000
~/src/Python-2.4.2

$ gcc --version
gcc (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying
conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460605&group_id=5470

From noreply at sourceforge.net  Wed Mar 29 15:02:18 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 29 Mar 2006 05:02:18 -0800
Subject: [ python-Bugs-1460340 ] random.sample can raise KeyError
Message-ID: <E1FOaJW-0001Kl-Ou@sc8-sf-web6.sourceforge.net>

Bugs item #1460340, was opened at 2006-03-28 19:05
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460340&group_id=5470

Please note that this message 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: paul rubin (phr)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: random.sample can raise KeyError

Initial Comment:
I have only tested this in 2.3 and the relevant code in
random.py has changed in the current svn branch, but
from inspection it looks to me like the bug may still
be there.

If you initialize a dictionary as follows:

 a={}.fromkeys(range(10)+range(10,100,2)+range(100,110))

then

 random.sample(a,3)

raises KeyError most times that you call it.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-03-29 08:02

Message:
Logged In: YES 
user_id=31435

Ya, this is flaky for dicts; re-opening.  For example,

>>> d = dict((i, complex(i, i)) for i in xrange(30))
>>> random.sample(d, 5)  # ask for 5 and it samples values
[(25+25j), (4+4j), (16+16j), (13+13j), (17+17j)]
>>> random.sample(d, 6)  # ask for 6 and it samples keys
[20, 11, 9, 4, 14, 1]

That one doesn't have to do with internal exceptions, it has
only to do with which of sample()'s internal algorithms gets
used.

Paul's point about potential bias is also a worry.  Here's a
full example:

"""
from random import sample
d = dict.fromkeys(range(24))
d['x'] = 'y'
count = hits = 0
while 1:
    count += 1
    hits += sample(d, 1) == ['x']
    if count % 10000 == 0:
        print count, "%.2f%%" % (100.0 * hits / count)
"""

Since len(d) == 25, I'd hope to see 'x' selected 1/25 = 4%
of the time.  Instead it gets selected 0.16% of the time
(1/25**2 -- and Paul's analysis of why is on target).


----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2006-03-29 05:07

Message:
Logged In: YES 
user_id=72053

Actually the previous comment is wrong too; 99% of the time,
sample(a,1) will return None since that's the value
connected to every key in the dictionary, i.e. it's
population[j] for every j.  The other 1% of the time, the
dict gets converted to a list, and the sample returns a key
from the dict rather than a value, which is certainly wrong.
 And you can see how the probabilities are still messed up
if the values in the dict are distinct.

I think it's ok to give up on dicts, but some warning should
about it be added to the manual unless dict-like things
somehow get detected in the code.  It would be best to test
for the object really being a sequence, but I don't know if
such a test exists.  Maybe one should be added.

I'll leave it to you guys to reopen this bug if appropriate.

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2006-03-29 04:46

Message:
Logged In: YES 
user_id=72053

I don't think the fix at 43421 is quite right, but I can't
easily test it in my current setup.  Suppose

a = dict.fromkeys(range(99) + ['x'])
b = random.sample(a,1)

99% of the time, there's no KeyError and b gets set to [j]
where j is some random integer.

1% of the time, there's a KeyError, random.sample is called
recursively, and the recursive call returns [some integer j]
99% of the time, and returns ['x'] 1% of the time.

So in total, ['x'] gets returned .01% of the time instead of
1% of the time.

I think it's better to not set result[i]=population[j]
inside the loop.  Instead, just build up the selected set
until it has enough indices; then try to make a result list
using those indices, and if there's a KeyError, convert the
population to a list and use the same selection set to make
the results.

gbrandl also correctly points out that a dict is not a
sequence type, so maybe it's ok to just punt on dicts.  But
it's obvious from the code comments that somebody once
wanted dicts to work, and it's reasonable for people to want
sets to work.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-03-29 04:17

Message:
Logged In: YES 
user_id=80475

Checked-in a fix.
See revision 43420 and 43421.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-03-29 04:11

Message:
Logged In: YES 
user_id=849994

random.sample is documented to take a sequence as its first
argument. A dict is not a sequence type.

I think you want
random.sample(a.keys(), 3)
or, for large dicts,
random.sample(a.iterkeys(), 3)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460340&group_id=5470

From noreply at sourceforge.net  Wed Mar 29 15:50:52 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 29 Mar 2006 05:50:52 -0800
Subject: [ python-Bugs-1199282 ] subprocess _active.remove(self) self not in
	list _active
Message-ID: <E1FOb4W-0002o9-1I@sc8-sf-web5.sourceforge.net>

Bugs item #1199282, was opened at 2005-05-10 20:24
Message generated for change (Comment added) made by tfaujour
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199282&group_id=5470

Please note that this message 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: cheops (atila-cheops)
Assigned to: Peter ?
strand (astrand)
Summary: subprocess _active.remove(self) self not in list _active

Initial Comment:
I start a subprocess in a seperate thread (25 concurrent 
threads)
in some of the threads the following error occurs
 
Exception in thread Thread-4:
Traceback (most recent call last):
  File "C:\Python24\lib\threading.py", line 442, in 
__bootstrap
    self.run()
  File "upgrade.py", line 45, in run
    returncode = p.wait()
  File "C:\Python24\lib\subprocess.py", line 765, in wait
    _active.remove(self)
ValueError: list.remove(x): x not in list
 
this is the code that starts the subprocess and where I 
wait for the result
 
p = subprocess.Popen('command', \
                             stdin=None, 
stdout=subprocess.PIPE, \
                             stderr=subprocess.STDOUT, 
universal_newlines=True)
returncode = p.wait()
errormessage = p.stdout.readlines()

----------------------------------------------------------------------

Comment By: Tristan Faujour (tfaujour)
Date: 2006-03-29 15:50

Message:
Logged In: YES 
user_id=1488657

> Simply list operations such as remove() and append() are
> thread safe,

OK, my apologies... I did not know.

I did some more tests. On Linux, I found lots of:

  File "./subprocess.py", line 428, in call
    return Popen(*args, **kwargs).wait()
  File "./subprocess.py", line 1023, in wait
    pid, sts = os.waitpid(self.pid, 0)
OSError: [Errno 10] No child processes

The try...except solution does not handle this (since we are
in the "posix" section).

In my opinion, the call to _cleanup() in Popen.__init__() is
useless (it just checks if older processes have stopped when
a new one is started. I cannot see why it could be
mandatory) and it is the root of this bug.

I commented it out (line 506) and retried my tests on Linux
& Windows plateforms: I had no exception at all.



----------------------------------------------------------------------

Comment By: Peter ?
strand (astrand)
Date: 2006-03-29 07:11

Message:
Logged In: YES 
user_id=344921

>I think accesses to _active should be serialized in a
>thread-safe way. _active could be a Queue (from the Queue
>module) for example

Simply list operations such as remove() and append() are
thread safe, so there should be no need for a Queue. Also, a
Queue cannot be used since the subprocess module needs to be
compatible with Python 2.2. 

----------------------------------------------------------------------

Comment By: Tristan Faujour (tfaujour)
Date: 2006-03-29 01:17

Message:
Logged In: YES 
user_id=1488657

I am running into the same problem on a Windows 2k/XP
plateform with a multi-threaded application. It occurs randomly.

It has never appened (yet) on a Linux plateform.

I think accesses to _active should be serialized in a
thread-safe way. _active could be a Queue (from the Queue
module) for example.


----------------------------------------------------------------------

Comment By: HVB bei TUP (hvb_tup)
Date: 2006-01-25 09:10

Message:
Logged In: YES 
user_id=1434251

Wouldn't it be best to completely remove any references 
to "_active" and "_cleanup"?

----------------------------------------------------------------------

Comment By: cheops (atila-cheops)
Date: 2006-01-25 08:08

Message:
Logged In: YES 
user_id=1276121

As suggested by astrand
adding a try ... except clause in the file subprocess.py did
the job
I had to add that try ... except clause in 2 places
if you look in the file there are 2 instances were
list.remove(x) occurs unprotected.

try:
 list.remove(x)
except:
 pass

I have worked with 2.4.0, 2.4.1 and 2.4.2 and all three
needed the patch.
Hope this helps.

----------------------------------------------------------------------

Comment By: HVB bei TUP (hvb_tup)
Date: 2006-01-23 17:34

Message:
Logged In: YES 
user_id=1434251

BTW: In my case, I call python.exe from a Windows service.

----------------------------------------------------------------------

Comment By: HVB bei TUP (hvb_tup)
Date: 2006-01-23 17:30

Message:
Logged In: YES 
user_id=1434251

I have a similar problem.
Python 2.4.1 under MS Windows 2003,
Multi-Threaded application (about concurrent 10 threads).

In my case the same error occurs during _cleanup called 
from __init__ :

  
File "E:\lisa_ins\ewu\coop\reporting\python\tup_lisa\util\t
hreadutil.py", line 582, in callSubProcess
    creationflags = creationflags
  File "C:\Python24\lib\subprocess.py", line 506, in 
__init__
    _cleanup()
  File "C:\Python24\lib\subprocess.py", line 414, in 
_cleanup
    inst.poll()
  File "C:\Python24\lib\subprocess.py", line 755, in poll
    _active.remove(self)
ValueError: list.remove(x): x not in list

Is there a work-around?


----------------------------------------------------------------------

Comment By: cheops (atila-cheops)
Date: 2005-09-19 11:29

Message:
Logged In: YES 
user_id=1276121

I noticed this bug under windows
to reproduce the bug, I attached the script I use, but this 
needs input, I tried with a simpler example (pinging a number 
of host concurrently) but that did not cause the bug.

----------------------------------------------------------------------

Comment By: Peter ?
strand (astrand)
Date: 2005-06-23 18:03

Message:
Logged In: YES 
user_id=344921

I believe it should be sufficient to add a try...except
clause around _active.remove(). Can you upload a complete
example that triggers the bug? Have you noticed this bug on
Windows, UNIX or both platforms?


----------------------------------------------------------------------

Comment By: cheops (atila-cheops)
Date: 2005-05-12 12:17

Message:
Logged In: YES 
user_id=1276121

this might be related to bug 1183780

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199282&group_id=5470

From noreply at sourceforge.net  Wed Mar 29 15:53:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 29 Mar 2006 05:53:23 -0800
Subject: [ python-Bugs-1081824 ] Rewrite of docs for compiler.visitor
Message-ID: <E1FOb6x-0002zw-Pq@sc8-sf-web5.sourceforge.net>

Bugs item #1081824, was opened at 2004-12-09 02:06
Message generated for change (Comment added) made by kjohnson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081824&group_id=5470

Please note that this 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: Kent Johnson (kjohnson)
Assigned to: Jeremy Hylton (jhylton)
Summary: Rewrite of docs for compiler.visitor

Initial Comment:
I was recently prompted to look at the docs for
compiler.visitor (Lib Ref 19.4 Using Visitors to Walk
ASTs). With all due respect it is not up to the
standards of most of the docs. I have attempted a
rewrite which is in the attachment.

I suggest also that the entry for walk() on the main
compiler doc page (19.1) should be updated to refer to
19.4 for details.

HTH
Kent

----------------------------------------------------------------------

>Comment By: Kent Johnson (kjohnson)
Date: 2006-03-29 13:53

Message:
Logged In: YES 
user_id=49695

Hmmph. A year later I see I didn't actually attach my
suggested rewrite. Trying again.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081824&group_id=5470

From noreply at sourceforge.net  Wed Mar 29 15:59:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 29 Mar 2006 05:59:05 -0800
Subject: [ python-Bugs-1460493 ] Why not drop the _active list?
Message-ID: <E1FObCT-00041V-VD@sc8-sf-web4-b.sourceforge.net>

Bugs item #1460493, was opened at 2006-03-29 09:16
Message generated for change (Comment added) made by tfaujour
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460493&group_id=5470

Please note that this 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: HVB bei TUP (hvb_tup)
Assigned to: Nobody/Anonymous (nobody)
Summary: Why not drop the _active list?

Initial Comment:
I am using a modified version of subprocess.py,

where I have removed the _active list and all 
references to it.

I have tested it (under Windows 2000) and there were 
no errors.

So what is the reason for managing the _active list 
at all? Why not drop it?

----------------------------------------------------------------------

Comment By: Tristan Faujour (tfaujour)
Date: 2006-03-29 15:59

Message:
Logged In: YES 
user_id=1488657

I agree.

The use of _active makes subprocess.py thread-UNsafe.

See also: Bug #1199282

In order to have a thread-safe subprocess.py, I commented
out the call to _cleanup() in Popen.__init__(). As a side
effect, _active becomes useless.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460493&group_id=5470

From noreply at sourceforge.net  Wed Mar 29 20:06:12 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 29 Mar 2006 10:06:12 -0800
Subject: [ python-Bugs-1457783 ] Malloc error on MacOSX/imaplib
Message-ID: <E1FOf3c-0005vB-9x@sc8-sf-web1.sourceforge.net>

Bugs item #1457783, was opened at 2006-03-24 10:10
Message generated for change (Settings changed) made by etrepum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457783&group_id=5470

Please note that this message 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: Duplicate
Priority: 5
Submitted By: Andreas Jung (ajung)
Assigned to: Nobody/Anonymous (nobody)
Summary: Malloc error on MacOSX/imaplib

Initial Comment:
I am using Python 2.4.2 on MacOSX (10.4.5). Fetching
mails with larger attachments (2MB or so) using IMAP
(with getmail) fails:

python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
    File "/opt/python-2.4.2/bin/getmail", line 558, in main
    go(configs)
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
    File "/opt/python-2.4.2/bin/getmail", line 112, in go
    msg = retriever.getmsg(msgid)
    File
"/opt/python-2.4.2/lib/python2.4/site-packages/getmailcore/_retrieverbases.py",
line 383, in getmsg
    return self._getmsgbyid(msgid)
    File
"/opt/python-2.4.2/lib/python2.4/site-packages/getmailcore/_retrieverbases.py",
line 750, in _getmsgbyid
    return self._getmsgpartbyid(msgid, '(RFC822)')
    File
"/opt/python-2.4.2/lib/python2.4/site-packages/getmailcore/_retrieverbases.py",
line 731, in _getmsgpartbyid
    response = self._parse_imapuidcmdresponse('FETCH',
uid, part)
    File
"/opt/python-2.4.2/lib/python2.4/site-packages/getmailcore/_retrieverbases.py",
line 621, in _parse_imapuidcmdresponse
    result, resplist = self.conn.uid(cmd, *args)
    File "/opt/python-2.4.2/lib/python2.4/imaplib.py",
line 725, in uid
    typ, dat = self._simple_command(name, command, *args)
    File "/opt/python-2.4.2/lib/python2.4/imaplib.py",
line 1028, in _simple_command
    return self._command_complete(name,
self._command(name, *args))
    File "/opt/python-2.4.2/lib/python2.4/imaplib.py",
line 858, in _command_complete
    typ, data = self._get_tagged_response(tag)
    File "/opt/python-2.4.2/lib/python2.4/imaplib.py",
line 959, in _get_tagged_response
    self._get_response()
    File "/opt/python-2.4.2/lib/python2.4/imaplib.py",
line 921, in _get_response
    data = self.read(size)
    File "/opt/python-2.4.2/lib/python2.4/imaplib.py",
line 1123, in read
    data = self.sslobj.read(size-read)
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
python2.4(5615) malloc: *** vm_allocate(size=262144)
failed (error code=3)
python2.4(5615) malloc: *** error: can't allocate region
python2.4(5615) malloc: *** set a breakpoint in
szone_error to debug
  MemoryError



----------------------------------------------------------------------

>Comment By: Bob Ippolito (etrepum)
Date: 2006-03-29 13:06

Message:
Logged In: YES 
user_id=139309

This is a duplicate of http://python.org/sf/1092502

The implementation of realloc on Darwin never frees memory, so when using a 
large buffer size on incomplete reads you end up with lots of small strings that 
actually take up a large allocation.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457783&group_id=5470

From noreply at sourceforge.net  Wed Mar 29 21:16:26 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 29 Mar 2006 11:16:26 -0800
Subject: [ python-Bugs-1460886 ] Broken __hash__ for Unicode objects
Message-ID: <E1FOg9a-0003LX-QC@sc8-sf-web2.sourceforge.net>

Bugs item #1460886, was opened at 2006-03-29 19: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=1460886&group_id=5470

Please note that this 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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Joe Wreschnig (piman)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Broken __hash__ for Unicode objects

Initial Comment:
http://docs.python.org/ref/customization.html says
equal objects should hash to the same value. But this
is not the case when the default Unicode encoding has
been changed (by e.g. importing PyGTK).

Using Python 2.4.2:

>>> import sys
>>> reload(sys)
<module 'sys' (built-in)>
>>> sys.setdefaultencoding('utf-8')
>>> hash(u"\u1234"), hash(str(u"\u1234"))
(-518661067, -1855038154)
>>> u"\u1234" == str(u"\u1234")
True

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460886&group_id=5470

From noreply at sourceforge.net  Wed Mar 29 21:54:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 29 Mar 2006 11:54:24 -0800
Subject: [ python-Bugs-1460886 ] Broken __hash__ for Unicode objects
Message-ID: <E1FOgkK-0002Wj-9R@sc8-sf-web6.sourceforge.net>

Bugs item #1460886, was opened at 2006-03-29 21:16
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460886&group_id=5470

Please note that this 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: None
Status: Open
>Resolution: Invalid
Priority: 5
Submitted By: Joe Wreschnig (piman)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Broken __hash__ for Unicode objects

Initial Comment:
http://docs.python.org/ref/customization.html says
equal objects should hash to the same value. But this
is not the case when the default Unicode encoding has
been changed (by e.g. importing PyGTK).

Using Python 2.4.2:

>>> import sys
>>> reload(sys)
<module 'sys' (built-in)>
>>> sys.setdefaultencoding('utf-8')
>>> hash(u"\u1234"), hash(str(u"\u1234"))
(-518661067, -1855038154)
>>> u"\u1234" == str(u"\u1234")
True

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2006-03-29 21:54

Message:
Logged In: YES 
user_id=38388

This is a known fact.

When changing the default encoding, you are basically on
your own, so there's nothing much we can about it.

BTW, the above hack that you're using to get at the
sys.setdefaultencoding() API already indicates that you're
leaving the path of standard Python. 

We deliberatly remove that API from the sys module in
site.py to make changing the default encoding an explicit task. 

If importing PyGTK has the side-effect of applying such a
hack, then PyGTK is seriously broken and you should report
this to their developers.

Closing as "Invalid".


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460886&group_id=5470

From noreply at sourceforge.net  Wed Mar 29 21:54:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 29 Mar 2006 11:54:42 -0800
Subject: [ python-Bugs-1460886 ] Broken __hash__ for Unicode objects
Message-ID: <E1FOgkc-0002Wo-CL@sc8-sf-web6.sourceforge.net>

Bugs item #1460886, was opened at 2006-03-29 21:16
Message generated for change (Settings changed) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460886&group_id=5470

Please note that this 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: None
>Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Joe Wreschnig (piman)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Broken __hash__ for Unicode objects

Initial Comment:
http://docs.python.org/ref/customization.html says
equal objects should hash to the same value. But this
is not the case when the default Unicode encoding has
been changed (by e.g. importing PyGTK).

Using Python 2.4.2:

>>> import sys
>>> reload(sys)
<module 'sys' (built-in)>
>>> sys.setdefaultencoding('utf-8')
>>> hash(u"\u1234"), hash(str(u"\u1234"))
(-518661067, -1855038154)
>>> u"\u1234" == str(u"\u1234")
True

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2006-03-29 21:54

Message:
Logged In: YES 
user_id=38388

This is a known fact.

When changing the default encoding, you are basically on
your own, so there's nothing much we can about it.

BTW, the above hack that you're using to get at the
sys.setdefaultencoding() API already indicates that you're
leaving the path of standard Python. 

We deliberatly remove that API from the sys module in
site.py to make changing the default encoding an explicit task. 

If importing PyGTK has the side-effect of applying such a
hack, then PyGTK is seriously broken and you should report
this to their developers.

Closing as "Invalid".


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460886&group_id=5470

From noreply at sourceforge.net  Wed Mar 29 22:19:03 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 29 Mar 2006 12:19:03 -0800
Subject: [ python-Bugs-1442493 ] IDLE shell window gets very slow when
	displaying long lines
Message-ID: <E1FOh8B-0006Mi-8I@sc8-sf-web3.sourceforge.net>

Bugs item #1442493, was opened at 2006-03-03 14:45
Message generated for change (Comment added) made by drhok
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: Heiko Selber (drhok)
Date: 2006-03-29 20: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 23: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 20: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 23: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 Mar 29 22:27:09 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 29 Mar 2006 12:27:09 -0800
Subject: [ python-Feature Requests-1453973 ] addheaders for urlopen / open /
	xxxx_open
Message-ID: <E1FOhG1-0007xl-GL@sc8-sf-web2.sourceforge.net>

Feature Requests item #1453973, was opened at 2006-03-19 10:55
Message generated for change (Comment added) made by josiahcarlson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1453973&group_id=5470

Please note that this message 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: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: addheaders for urlopen / open / xxxx_open

Initial Comment:
Adding a header also for each open call is a frequent
need for me (much more than e.g. proxies per call in
urllib1/urlopen). 

For example:

urlopen(url,data,addheaders=[('Referer':lasturl)])

So far one is forced to set the _complete_ re-rendered
bunch of opener.addheaders each time (and to maintain a
separate opener for each thread )

open/OpenerDirector.open maybe should distribute
*args,**kwargs

---

Note on disciplined use of protocol modules in urllib2
( see also #1046077 ):

urllib2 still draws in all kind of (future?) protocol
modules all in advance =>  slows down app startup / cgi
script's ...; ugly non-pythonic/non-modular; unused
prots cannot be excluded for cx_Freeze,setup ... 
Now the fat cookielib was also added in that manner.
Thus, when you use urllib2 for "ftp://xy", you load
also all kind of fun (down to things like
_MozillaCookieJar) into Python. 

The need for those imports is very local (search e.g.
"ftplib."). ==> local import in those few places.

I saw, this jam style already encouraged more
undisciplined dependencies like :
"origin_req_host = cookielib.request_host(self)"
(~urllib2-py2.4/line 191) in the general Request.__init__ 


Robert

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-03-29 12:27

Message:
Logged In: YES 
user_id=341410

Whether or not urllib2 imports generally unneeded modules is
a different matter than whether inserting headers should be
easier.  In the future, please separate feature requests
from random chatter about a module.

I'm personally for making it easier to include alternate
headers, though am ambiguous as to your suggested change.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1453973&group_id=5470

From noreply at sourceforge.net  Wed Mar 29 22:35:00 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 29 Mar 2006 12:35:00 -0800
Subject: [ python-Bugs-1442493 ] IDLE shell window gets very slow when
	displaying long lines
Message-ID: <E1FOhNc-0007Lx-7J@sc8-sf-web3.sourceforge.net>

Bugs item #1442493, was opened at 2006-03-03 06:45
Message generated for change (Comment added) made by josiahcarlson
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: Josiah Carlson (josiahcarlson)
Date: 2006-03-29 12: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 12: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 15: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 12: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 15: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 Mar 29 22:40:06 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 29 Mar 2006 12:40:06 -0800
Subject: [ python-Bugs-1460605 ] Python 2.4.2 does not compile on SunOS 5.10
	using gcc 
Message-ID: <E1FOhSY-0007PO-Og@sc8-sf-web1.sourceforge.net>

Bugs item #1460605, was opened at 2006-03-29 13:22
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460605&group_id=5470

Please note that this 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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jakob Schi?tz (schiotz)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.4.2 does not compile on SunOS 5.10 using gcc 

Initial Comment:
Core Python does not compile on my university's Sun server.

$ ./configure --prefix=$HOME
$ gmake
   [ lots of output deleted ]
gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -I. -I./Include  -DPy_BUILD_CORE -o
Objects/cobject.o Objects/cobject.c
gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -I. -I./Include  -DPy_BUILD_CORE -o
Objects/complexobject.o Objects/complexobject.c
Objects/complexobject.c: In function `complex_pow':
Objects/complexobject.c:476: error: invalid operands to
binary ==
Objects/complexobject.c:476: error: wrong type argument
to unary minus
Objects/complexobject.c:476: error: invalid operands to
binary ==
Objects/complexobject.c:476: error: wrong type argument
to unary minus
gmake: *** [Objects/complexobject.o] Error 1

$ uname -a
SunOS hald 5.10 Generic_118822-18 sun4u sparc
SUNW,Sun-Fire-15000
~/src/Python-2.4.2

$ gcc --version
gcc (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying
conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.



----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-03-29 22:40

Message:
Logged In: YES 
user_id=21627

Can you please try 2.4.3 instead?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460605&group_id=5470

From noreply at sourceforge.net  Wed Mar 29 22:41:22 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 29 Mar 2006 12:41:22 -0800
Subject: [ python-Bugs-1460493 ] Why not drop the _active list?
Message-ID: <E1FOhTm-0007UO-5a@sc8-sf-web1.sourceforge.net>

Bugs item #1460493, was opened at 2006-03-29 09:16
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460493&group_id=5470

Please note that this 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: HVB bei TUP (hvb_tup)
Assigned to: Nobody/Anonymous (nobody)
Summary: Why not drop the _active list?

Initial Comment:
I am using a modified version of subprocess.py,

where I have removed the _active list and all 
references to it.

I have tested it (under Windows 2000) and there were 
no errors.

So what is the reason for managing the _active list 
at all? Why not drop it?

----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-03-29 22:41

Message:
Logged In: YES 
user_id=21627

The purpose of the _active list is to wait(2) for open
processes. It needs to stay.

----------------------------------------------------------------------

Comment By: Tristan Faujour (tfaujour)
Date: 2006-03-29 15:59

Message:
Logged In: YES 
user_id=1488657

I agree.

The use of _active makes subprocess.py thread-UNsafe.

See also: Bug #1199282

In order to have a thread-safe subprocess.py, I commented
out the call to _cleanup() in Popen.__init__(). As a side
effect, _active becomes useless.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460493&group_id=5470

From noreply at sourceforge.net  Wed Mar 29 22:52:22 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 29 Mar 2006 12:52:22 -0800
Subject: [ python-Bugs-1442493 ] IDLE shell window gets very slow when
	displaying long lines
Message-ID: <E1FOheQ-0008V9-En@sc8-sf-web3.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: 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: 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  Thu Mar 30 00:03:11 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 29 Mar 2006 14:03:11 -0800
Subject: [ python-Bugs-1460886 ] Broken __hash__ for Unicode objects
Message-ID: <E1FOikx-0001XB-0Q@sc8-sf-web4-b.sourceforge.net>

Bugs item #1460886, was opened at 2006-03-29 19:16
Message generated for change (Comment added) made by piman
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460886&group_id=5470

Please note that this 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: None
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Joe Wreschnig (piman)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Broken __hash__ for Unicode objects

Initial Comment:
http://docs.python.org/ref/customization.html says
equal objects should hash to the same value. But this
is not the case when the default Unicode encoding has
been changed (by e.g. importing PyGTK).

Using Python 2.4.2:

>>> import sys
>>> reload(sys)
<module 'sys' (built-in)>
>>> sys.setdefaultencoding('utf-8')
>>> hash(u"\u1234"), hash(str(u"\u1234"))
(-518661067, -1855038154)
>>> u"\u1234" == str(u"\u1234")
True

----------------------------------------------------------------------

>Comment By: Joe Wreschnig (piman)
Date: 2006-03-29 22:03

Message:
Logged In: YES 
user_id=796

What's the point of having a default encoding if it breaks a
fundamental part of the language on anything but the default
value?

I mean, I can tweak site.py to set it to utf-8; does this
become a valid bug then? site.py even contains a check to
set the encoding to an alternate value if I want.

This may be a "known fact". Every reported bug is a known
fact. That doesn't mean it's not a bug.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2006-03-29 19:54

Message:
Logged In: YES 
user_id=38388

This is a known fact.

When changing the default encoding, you are basically on
your own, so there's nothing much we can about it.

BTW, the above hack that you're using to get at the
sys.setdefaultencoding() API already indicates that you're
leaving the path of standard Python. 

We deliberatly remove that API from the sys module in
site.py to make changing the default encoding an explicit task. 

If importing PyGTK has the side-effect of applying such a
hack, then PyGTK is seriously broken and you should report
this to their developers.

Closing as "Invalid".


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460886&group_id=5470

From noreply at sourceforge.net  Thu Mar 30 00:36:50 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 29 Mar 2006 14:36:50 -0800
Subject: [ python-Bugs-1460886 ] Broken __hash__ for Unicode objects
Message-ID: <E1FOjHW-0004R3-P5@sc8-sf-web6.sourceforge.net>

Bugs item #1460886, was opened at 2006-03-29 21:16
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460886&group_id=5470

Please note that this 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: None
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Joe Wreschnig (piman)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Broken __hash__ for Unicode objects

Initial Comment:
http://docs.python.org/ref/customization.html says
equal objects should hash to the same value. But this
is not the case when the default Unicode encoding has
been changed (by e.g. importing PyGTK).

Using Python 2.4.2:

>>> import sys
>>> reload(sys)
<module 'sys' (built-in)>
>>> sys.setdefaultencoding('utf-8')
>>> hash(u"\u1234"), hash(str(u"\u1234"))
(-518661067, -1855038154)
>>> u"\u1234" == str(u"\u1234")
True

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2006-03-30 00:36

Message:
Logged In: YES 
user_id=38388

You can tweak the default encoding setting in site.py, but
again, you're on your own when doing so.

I also wonder why you would expect str(u"\u1234") (==
'\xe1\x88\xb4' with your setting) to have the same hash
value as a single Unicode code point.

Note that hash values are cached inside the Unicode object.
If we were to let the hash value depend on the current
setting of the default encoding, it would be possible to
have two equal Unicode objects with two different hash values.

It's one of the few places that actually does hard code the
ASCII default encoding. Most others will work with other
encodings as well, but again: no guarantees. Note that
because of this, you don't get a differen hash value for
ASCII Unicode code points and ASCII-compatible default
encodings.

In future versions, the default encoding will go away, so
please don't start relying on it.


----------------------------------------------------------------------

Comment By: Joe Wreschnig (piman)
Date: 2006-03-30 00:03

Message:
Logged In: YES 
user_id=796

What's the point of having a default encoding if it breaks a
fundamental part of the language on anything but the default
value?

I mean, I can tweak site.py to set it to utf-8; does this
become a valid bug then? site.py even contains a check to
set the encoding to an alternate value if I want.

This may be a "known fact". Every reported bug is a known
fact. That doesn't mean it's not a bug.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2006-03-29 21:54

Message:
Logged In: YES 
user_id=38388

This is a known fact.

When changing the default encoding, you are basically on
your own, so there's nothing much we can about it.

BTW, the above hack that you're using to get at the
sys.setdefaultencoding() API already indicates that you're
leaving the path of standard Python. 

We deliberatly remove that API from the sys module in
site.py to make changing the default encoding an explicit task. 

If importing PyGTK has the side-effect of applying such a
hack, then PyGTK is seriously broken and you should report
this to their developers.

Closing as "Invalid".


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460886&group_id=5470

From noreply at sourceforge.net  Thu Mar 30 07:20:09 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 29 Mar 2006 21:20:09 -0800
Subject: [ python-Bugs-1461115 ] test_winsound fails in 2.4.3
Message-ID: <E1FOpZp-0006UQ-KC@sc8-sf-web1.sourceforge.net>

Bugs item #1461115, was opened at 2006-03-30 00:20
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1461115&group_id=5470

Please note that this 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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Martin v. L??wis (loewis)
Summary: test_winsound fails in 2.4.3

Initial Comment:
The released 2.4.3 Windows installer doesn't include
source file Lib/test/check_soundcard.vbs, which causes
test_winsound to report 7 bogus failures when run on a
box with a sound card.

I expect the 2.5 installer also needs to be fiddled to
include this file.

I confirmed that the problem went away after copying
check_soundcard.vbs from a 2.4 branch checkout into the
2.4.3 installation tree.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1461115&group_id=5470

From noreply at sourceforge.net  Thu Mar 30 09:43:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 29 Mar 2006 23:43:05 -0800
Subject: [ python-Bugs-1460493 ] Why not drop the _active list?
Message-ID: <E1FOro9-0007rc-Bw@sc8-sf-web3.sourceforge.net>

Bugs item #1460493, was opened at 2006-03-28 23:16
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460493&group_id=5470

Please note that this 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: HVB bei TUP (hvb_tup)
Assigned to: Nobody/Anonymous (nobody)
Summary: Why not drop the _active list?

Initial Comment:
I am using a modified version of subprocess.py,

where I have removed the _active list and all 
references to it.

I have tested it (under Windows 2000) and there were 
no errors.

So what is the reason for managing the _active list 
at all? Why not drop it?

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-29 23:43

Message:
Logged In: YES 
user_id=33168

If you always called wait() the _active list isn't
beneficial to you.  However, many people do not call wait
and the _active list provides a mechanism to cleanup zombied
children.  This is important for many users.

If you need thread safely, you can handle the locking
yourself before calling poll()/wait().

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-03-29 12:41

Message:
Logged In: YES 
user_id=21627

The purpose of the _active list is to wait(2) for open
processes. It needs to stay.

----------------------------------------------------------------------

Comment By: Tristan Faujour (tfaujour)
Date: 2006-03-29 05:59

Message:
Logged In: YES 
user_id=1488657

I agree.

The use of _active makes subprocess.py thread-UNsafe.

See also: Bug #1199282

In order to have a thread-safe subprocess.py, I commented
out the call to _cleanup() in Popen.__init__(). As a side
effect, _active becomes useless.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460493&group_id=5470

From noreply at sourceforge.net  Thu Mar 30 09:52:38 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 29 Mar 2006 23:52:38 -0800
Subject: [ python-Bugs-826756 ] email/Generator.py: Incorrect header output
Message-ID: <E1FOrxO-00010W-Dq@sc8-sf-web2.sourceforge.net>

Bugs item #826756, was opened at 2003-10-20 20:23
Message generated for change (Comment added) made by bbaetz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=826756&group_id=5470

Please note that this message 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: Invalid
Priority: 5
Submitted By: Matthias Pronk (mjepronk)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email/Generator.py: Incorrect header output

Initial Comment:
I've found a small bug when using the email/Parser.py
classes. When there is a long &quot;Subject&quot; header, it will
be wrapped to multiple lines, which are preceded by a
tab. This is undesired behaviour, because e-mail
clients show this tab in the subject. Especially,
Mozilla for Windows shows a strange square symbol. The
following code in email/Generator.py (line 180)
resolves the problem:

            else:
                # Header's got lots of smarts, so use it.
                if h.lower() == 'subject':
                    cont_ws = ' ' 
                else:
                    cont_ws = '\t'
                print &gt;&gt; self._fp, Header(
                    v, maxlinelen=self.__maxheaderlen,
                    header_name=h,
continuation_ws=cont_ws).encode()

For more information you can e-mail me: matthias -at-
rubberbiscuit.nl

----------------------------------------------------------------------

Comment By: Bradley Baetz (bbaetz)
Date: 2006-03-30 18:52

Message:
Logged In: YES 
user_id=495627

I disagree that this follows RFC2822. The RFC says:

   The process of moving from this folded multiple-line
representation
   of a header field to its single line representation is called
   "unfolding". Unfolding is accomplished by simply removing
any CRLF
   that is immediately followed by WSP.  Each header field
should be
   treated in its unfolded form for further syntactic and
semantic
   evaluation.

This means that if python takes a header:

Subject: This is a long string

and wraps it to:

Subject: This is a\r\n\tlong string

then when the MUA "simply remov[es] any CRLF" the
whitespace, and we end up with:

Subject: This is a\tlong string

with a tab rather than a space, which doesn't look too good.
Some MUAs condense any following WSP into a single space,
but thats technically breaking the RFC.

(This affects mailman -
http://mail.python.org/pipermail/mailman-developers/2005-December/018410.html)

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-11-22 05:38

Message:
Logged In: YES 
user_id=12800

RFC 2822 specifies when and how long headers are supposed to
be wrapped, and the default Generator behavior is to be
compliant with this standard.  I consider it a bug in your
mail reader that such long headers are displayed incorrectly
(other mail readers display long wrapped headers correctly).

Having said this, you have options.  You can disable
wrapping altogether by passing maxheaderlen=0 to the
Generator constructor, or you can create a Generator
subclass which overrides the _write_headers() method and
passes a different value for continuation_ws.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=826756&group_id=5470

From noreply at sourceforge.net  Thu Mar 30 10:04:19 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 30 Mar 2006 00:04:19 -0800
Subject: [ python-Bugs-1460493 ] Why not drop the _active list?
Message-ID: <E1FOs8h-0000Ag-VH@sc8-sf-web1.sourceforge.net>

Bugs item #1460493, was opened at 2006-03-29 07:16
Message generated for change (Comment added) made by atila-cheops
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460493&group_id=5470

Please note that this 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: HVB bei TUP (hvb_tup)
Assigned to: Nobody/Anonymous (nobody)
Summary: Why not drop the _active list?

Initial Comment:
I am using a modified version of subprocess.py,

where I have removed the _active list and all 
references to it.

I have tested it (under Windows 2000) and there were 
no errors.

So what is the reason for managing the _active list 
at all? Why not drop it?

----------------------------------------------------------------------

Comment By: cheops (atila-cheops)
Date: 2006-03-30 08:04

Message:
Logged In: YES 
user_id=1276121

what happens if you are doing a _cleanup (iterating over a
copy of _active) in multiple threads?
can it not happen then that you clean up a process 2 times?

thread 1 starts a _cleanup: makes a copy of _active[:] and
starts polling
thread 2 starts a _cleanup: makes a copy of _active[:] and
starts polling

thread 1 encounters a finished process and removes it from
_active[]
thread 2 does not know the process is removed, finds the
same process finished and tries to remove it from _active
but this fails, because thread 1 removed it already

so the action of cleaning up should maybe be serialized
if 1 thread is doing it, the other one should block

everyone who needs this can of course patch the
subprocess.py file, but shouldn't this be fixed in the library?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-30 07:43

Message:
Logged In: YES 
user_id=33168

If you always called wait() the _active list isn't
beneficial to you.  However, many people do not call wait
and the _active list provides a mechanism to cleanup zombied
children.  This is important for many users.

If you need thread safely, you can handle the locking
yourself before calling poll()/wait().

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-03-29 20:41

Message:
Logged In: YES 
user_id=21627

The purpose of the _active list is to wait(2) for open
processes. It needs to stay.

----------------------------------------------------------------------

Comment By: Tristan Faujour (tfaujour)
Date: 2006-03-29 13:59

Message:
Logged In: YES 
user_id=1488657

I agree.

The use of _active makes subprocess.py thread-UNsafe.

See also: Bug #1199282

In order to have a thread-safe subprocess.py, I commented
out the call to _cleanup() in Popen.__init__(). As a side
effect, _active becomes useless.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460493&group_id=5470

From noreply at sourceforge.net  Thu Mar 30 10:06:18 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 30 Mar 2006 00:06:18 -0800
Subject: [ python-Bugs-1460493 ] Why not drop the _active list?
Message-ID: <E1FOsAc-0006r6-EJ@sc8-sf-web6.sourceforge.net>

Bugs item #1460493, was opened at 2006-03-29 07:16
Message generated for change (Comment added) made by atila-cheops
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460493&group_id=5470

Please note that this 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: HVB bei TUP (hvb_tup)
Assigned to: Nobody/Anonymous (nobody)
Summary: Why not drop the _active list?

Initial Comment:
I am using a modified version of subprocess.py,

where I have removed the _active list and all 
references to it.

I have tested it (under Windows 2000) and there were 
no errors.

So what is the reason for managing the _active list 
at all? Why not drop it?

----------------------------------------------------------------------

Comment By: cheops (atila-cheops)
Date: 2006-03-30 08:06

Message:
Logged In: YES 
user_id=1276121

the same problem probably exists in popen2.py
there _active is also used
so if something is fixed in subprocess.py, it should
probably also be fixed in popen2.py

----------------------------------------------------------------------

Comment By: cheops (atila-cheops)
Date: 2006-03-30 08:04

Message:
Logged In: YES 
user_id=1276121

what happens if you are doing a _cleanup (iterating over a
copy of _active) in multiple threads?
can it not happen then that you clean up a process 2 times?

thread 1 starts a _cleanup: makes a copy of _active[:] and
starts polling
thread 2 starts a _cleanup: makes a copy of _active[:] and
starts polling

thread 1 encounters a finished process and removes it from
_active[]
thread 2 does not know the process is removed, finds the
same process finished and tries to remove it from _active
but this fails, because thread 1 removed it already

so the action of cleaning up should maybe be serialized
if 1 thread is doing it, the other one should block

everyone who needs this can of course patch the
subprocess.py file, but shouldn't this be fixed in the library?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-30 07:43

Message:
Logged In: YES 
user_id=33168

If you always called wait() the _active list isn't
beneficial to you.  However, many people do not call wait
and the _active list provides a mechanism to cleanup zombied
children.  This is important for many users.

If you need thread safely, you can handle the locking
yourself before calling poll()/wait().

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-03-29 20:41

Message:
Logged In: YES 
user_id=21627

The purpose of the _active list is to wait(2) for open
processes. It needs to stay.

----------------------------------------------------------------------

Comment By: Tristan Faujour (tfaujour)
Date: 2006-03-29 13:59

Message:
Logged In: YES 
user_id=1488657

I agree.

The use of _active makes subprocess.py thread-UNsafe.

See also: Bug #1199282

In order to have a thread-safe subprocess.py, I commented
out the call to _cleanup() in Popen.__init__(). As a side
effect, _active becomes useless.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460493&group_id=5470

From noreply at sourceforge.net  Thu Mar 30 10:17:38 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 30 Mar 2006 00:17:38 -0800
Subject: [ python-Bugs-1460493 ] Why not drop the _active list?
Message-ID: <E1FOsLa-000101-BR@sc8-sf-web1.sourceforge.net>

Bugs item #1460493, was opened at 2006-03-29 07:16
Message generated for change (Comment added) made by atila-cheops
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460493&group_id=5470

Please note that this 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: HVB bei TUP (hvb_tup)
Assigned to: Nobody/Anonymous (nobody)
Summary: Why not drop the _active list?

Initial Comment:
I am using a modified version of subprocess.py,

where I have removed the _active list and all 
references to it.

I have tested it (under Windows 2000) and there were 
no errors.

So what is the reason for managing the _active list 
at all? Why not drop it?

----------------------------------------------------------------------

Comment By: cheops (atila-cheops)
Date: 2006-03-30 08:17

Message:
Logged In: YES 
user_id=1276121

also #1214859 is interesting, has a patch

----------------------------------------------------------------------

Comment By: cheops (atila-cheops)
Date: 2006-03-30 08:06

Message:
Logged In: YES 
user_id=1276121

the same problem probably exists in popen2.py
there _active is also used
so if something is fixed in subprocess.py, it should
probably also be fixed in popen2.py

----------------------------------------------------------------------

Comment By: cheops (atila-cheops)
Date: 2006-03-30 08:04

Message:
Logged In: YES 
user_id=1276121

what happens if you are doing a _cleanup (iterating over a
copy of _active) in multiple threads?
can it not happen then that you clean up a process 2 times?

thread 1 starts a _cleanup: makes a copy of _active[:] and
starts polling
thread 2 starts a _cleanup: makes a copy of _active[:] and
starts polling

thread 1 encounters a finished process and removes it from
_active[]
thread 2 does not know the process is removed, finds the
same process finished and tries to remove it from _active
but this fails, because thread 1 removed it already

so the action of cleaning up should maybe be serialized
if 1 thread is doing it, the other one should block

everyone who needs this can of course patch the
subprocess.py file, but shouldn't this be fixed in the library?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-30 07:43

Message:
Logged In: YES 
user_id=33168

If you always called wait() the _active list isn't
beneficial to you.  However, many people do not call wait
and the _active list provides a mechanism to cleanup zombied
children.  This is important for many users.

If you need thread safely, you can handle the locking
yourself before calling poll()/wait().

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-03-29 20:41

Message:
Logged In: YES 
user_id=21627

The purpose of the _active list is to wait(2) for open
processes. It needs to stay.

----------------------------------------------------------------------

Comment By: Tristan Faujour (tfaujour)
Date: 2006-03-29 13:59

Message:
Logged In: YES 
user_id=1488657

I agree.

The use of _active makes subprocess.py thread-UNsafe.

See also: Bug #1199282

In order to have a thread-safe subprocess.py, I commented
out the call to _cleanup() in Popen.__init__(). As a side
effect, _active becomes useless.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460493&group_id=5470

From noreply at sourceforge.net  Thu Mar 30 12:18:45 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 30 Mar 2006 02:18:45 -0800
Subject: [ python-Bugs-1460340 ] random.sample can raise KeyError
Message-ID: <E1FOuEn-0005A3-Os@sc8-sf-web5.sourceforge.net>

Bugs item #1460340, was opened at 2006-03-28 19:05
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460340&group_id=5470

Please note that this message 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: paul rubin (phr)
>Assigned to: Nobody/Anonymous (nobody)
Summary: random.sample can raise KeyError

Initial Comment:
I have only tested this in 2.3 and the relevant code in
random.py has changed in the current svn branch, but
from inspection it looks to me like the bug may still
be there.

If you initialize a dictionary as follows:

 a={}.fromkeys(range(10)+range(10,100,2)+range(100,110))

then

 random.sample(a,3)

raises KeyError most times that you call it.


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2006-03-30 05:18

Message:
Logged In: YES 
user_id=80475

Bah.  I'm not overly concerned.  It is a Python fact of 
life that objects defining __getitem__ cannot aways be 
clearly categorized as being either a sequence or a 
mapping but not both.  You can add some additional checks 
like checking for a keys() method, but there is a limit to 
what you can do against these safe-cracking style efforts 
to trick the routine.  I hope this quest for theoretical 
perfection doesn't lead to throwing the baby out with the 
bathwater.  It would be ashamed to lose the automated 
choice of the best performing algorithm.  If that happens, 
somebody's real-world use cases are certain to suffer.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-03-29 08:02

Message:
Logged In: YES 
user_id=31435

Ya, this is flaky for dicts; re-opening.  For example,

>>> d = dict((i, complex(i, i)) for i in xrange(30))
>>> random.sample(d, 5)  # ask for 5 and it samples values
[(25+25j), (4+4j), (16+16j), (13+13j), (17+17j)]
>>> random.sample(d, 6)  # ask for 6 and it samples keys
[20, 11, 9, 4, 14, 1]

That one doesn't have to do with internal exceptions, it has
only to do with which of sample()'s internal algorithms gets
used.

Paul's point about potential bias is also a worry.  Here's a
full example:

"""
from random import sample
d = dict.fromkeys(range(24))
d['x'] = 'y'
count = hits = 0
while 1:
    count += 1
    hits += sample(d, 1) == ['x']
    if count % 10000 == 0:
        print count, "%.2f%%" % (100.0 * hits / count)
"""

Since len(d) == 25, I'd hope to see 'x' selected 1/25 = 4%
of the time.  Instead it gets selected 0.16% of the time
(1/25**2 -- and Paul's analysis of why is on target).


----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2006-03-29 05:07

Message:
Logged In: YES 
user_id=72053

Actually the previous comment is wrong too; 99% of the time,
sample(a,1) will return None since that's the value
connected to every key in the dictionary, i.e. it's
population[j] for every j.  The other 1% of the time, the
dict gets converted to a list, and the sample returns a key
from the dict rather than a value, which is certainly wrong.
 And you can see how the probabilities are still messed up
if the values in the dict are distinct.

I think it's ok to give up on dicts, but some warning should
about it be added to the manual unless dict-like things
somehow get detected in the code.  It would be best to test
for the object really being a sequence, but I don't know if
such a test exists.  Maybe one should be added.

I'll leave it to you guys to reopen this bug if appropriate.

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2006-03-29 04:46

Message:
Logged In: YES 
user_id=72053

I don't think the fix at 43421 is quite right, but I can't
easily test it in my current setup.  Suppose

a = dict.fromkeys(range(99) + ['x'])
b = random.sample(a,1)

99% of the time, there's no KeyError and b gets set to [j]
where j is some random integer.

1% of the time, there's a KeyError, random.sample is called
recursively, and the recursive call returns [some integer j]
99% of the time, and returns ['x'] 1% of the time.

So in total, ['x'] gets returned .01% of the time instead of
1% of the time.

I think it's better to not set result[i]=population[j]
inside the loop.  Instead, just build up the selected set
until it has enough indices; then try to make a result list
using those indices, and if there's a KeyError, convert the
population to a list and use the same selection set to make
the results.

gbrandl also correctly points out that a dict is not a
sequence type, so maybe it's ok to just punt on dicts.  But
it's obvious from the code comments that somebody once
wanted dicts to work, and it's reasonable for people to want
sets to work.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-03-29 04:17

Message:
Logged In: YES 
user_id=80475

Checked-in a fix.
See revision 43420 and 43421.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-03-29 04:11

Message:
Logged In: YES 
user_id=849994

random.sample is documented to take a sequence as its first
argument. A dict is not a sequence type.

I think you want
random.sample(a.keys(), 3)
or, for large dicts,
random.sample(a.iterkeys(), 3)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460340&group_id=5470

From noreply at sourceforge.net  Thu Mar 30 13:34:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 30 Mar 2006 03:34:05 -0800
Subject: [ python-Bugs-1460605 ] Python 2.4.2 does not compile on SunOS 5.10
	using gcc 
Message-ID: <E1FOvPh-000322-T1@sc8-sf-web6.sourceforge.net>

Bugs item #1460605, was opened at 2006-03-29 13:22
Message generated for change (Comment added) made by schiotz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460605&group_id=5470

Please note that this 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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jakob Schi?tz (schiotz)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.4.2 does not compile on SunOS 5.10 using gcc 

Initial Comment:
Core Python does not compile on my university's Sun server.

$ ./configure --prefix=$HOME
$ gmake
   [ lots of output deleted ]
gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -I. -I./Include  -DPy_BUILD_CORE -o
Objects/cobject.o Objects/cobject.c
gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -I. -I./Include  -DPy_BUILD_CORE -o
Objects/complexobject.o Objects/complexobject.c
Objects/complexobject.c: In function `complex_pow':
Objects/complexobject.c:476: error: invalid operands to
binary ==
Objects/complexobject.c:476: error: wrong type argument
to unary minus
Objects/complexobject.c:476: error: invalid operands to
binary ==
Objects/complexobject.c:476: error: wrong type argument
to unary minus
gmake: *** [Objects/complexobject.o] Error 1

$ uname -a
SunOS hald 5.10 Generic_118822-18 sun4u sparc
SUNW,Sun-Fire-15000
~/src/Python-2.4.2

$ gcc --version
gcc (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying
conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.



----------------------------------------------------------------------

>Comment By: Jakob Schi?tz (schiotz)
Date: 2006-03-30 13:34

Message:
Logged In: YES 
user_id=56465

Wow!  You have released a new version while I compiled the
old one.

The new version compiles just fine.

Thanks for your help!

Jakob


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-03-29 22:40

Message:
Logged In: YES 
user_id=21627

Can you please try 2.4.3 instead?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460605&group_id=5470

From noreply at sourceforge.net  Thu Mar 30 13:58:07 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 30 Mar 2006 03:58:07 -0800
Subject: [ python-Bugs-1460605 ] Python 2.4.2 does not compile on SunOS 5.10
	using gcc 
Message-ID: <E1FOvmx-0006U3-HS@sc8-sf-web1.sourceforge.net>

Bugs item #1460605, was opened at 2006-03-29 11:22
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460605&group_id=5470

Please note that this 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: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jakob Schi?tz (schiotz)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.4.2 does not compile on SunOS 5.10 using gcc 

Initial Comment:
Core Python does not compile on my university's Sun server.

$ ./configure --prefix=$HOME
$ gmake
   [ lots of output deleted ]
gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -I. -I./Include  -DPy_BUILD_CORE -o
Objects/cobject.o Objects/cobject.c
gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -I. -I./Include  -DPy_BUILD_CORE -o
Objects/complexobject.o Objects/complexobject.c
Objects/complexobject.c: In function `complex_pow':
Objects/complexobject.c:476: error: invalid operands to
binary ==
Objects/complexobject.c:476: error: wrong type argument
to unary minus
Objects/complexobject.c:476: error: invalid operands to
binary ==
Objects/complexobject.c:476: error: wrong type argument
to unary minus
gmake: *** [Objects/complexobject.o] Error 1

$ uname -a
SunOS hald 5.10 Generic_118822-18 sun4u sparc
SUNW,Sun-Fire-15000
~/src/Python-2.4.2

$ gcc --version
gcc (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying
conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.



----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-30 11:58

Message:
Logged In: YES 
user_id=849994

Closing as Fixed then.

----------------------------------------------------------------------

Comment By: Jakob Schi?tz (schiotz)
Date: 2006-03-30 11:34

Message:
Logged In: YES 
user_id=56465

Wow!  You have released a new version while I compiled the
old one.

The new version compiles just fine.

Thanks for your help!

Jakob


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-03-29 20:40

Message:
Logged In: YES 
user_id=21627

Can you please try 2.4.3 instead?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460605&group_id=5470

From noreply at sourceforge.net  Thu Mar 30 18:31:55 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 30 Mar 2006 08:31:55 -0800
Subject: [ python-Bugs-1460493 ] Why not drop the _active list?
Message-ID: <E1FP03v-0007hp-Ev@sc8-sf-web1.sourceforge.net>

Bugs item #1460493, was opened at 2006-03-29 09:16
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460493&group_id=5470

Please note that this 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: HVB bei TUP (hvb_tup)
Assigned to: Nobody/Anonymous (nobody)
Summary: Why not drop the _active list?

Initial Comment:
I am using a modified version of subprocess.py,

where I have removed the _active list and all 
references to it.

I have tested it (under Windows 2000) and there were 
no errors.

So what is the reason for managing the _active list 
at all? Why not drop it?

----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-03-30 18:31

Message:
Logged In: YES 
user_id=21627

attila-cheops, please read the 2.5 version of popen2.

popen2 now only adds processes to _active in __del__, not in
__init__, so the problem with the application still wanting
to wait/poll is solved.

Multiple threads simultaneously isn't a problem, since it is
(or should be) harmless to invoke poll on a process that has
already been waited for. For only one of the poll calls, the
wait will actually succeed, and that should be the one that
removes it from the _active list.

The same strategy should be applied to subprocess.

----------------------------------------------------------------------

Comment By: cheops (atila-cheops)
Date: 2006-03-30 10:17

Message:
Logged In: YES 
user_id=1276121

also #1214859 is interesting, has a patch

----------------------------------------------------------------------

Comment By: cheops (atila-cheops)
Date: 2006-03-30 10:06

Message:
Logged In: YES 
user_id=1276121

the same problem probably exists in popen2.py
there _active is also used
so if something is fixed in subprocess.py, it should
probably also be fixed in popen2.py

----------------------------------------------------------------------

Comment By: cheops (atila-cheops)
Date: 2006-03-30 10:04

Message:
Logged In: YES 
user_id=1276121

what happens if you are doing a _cleanup (iterating over a
copy of _active) in multiple threads?
can it not happen then that you clean up a process 2 times?

thread 1 starts a _cleanup: makes a copy of _active[:] and
starts polling
thread 2 starts a _cleanup: makes a copy of _active[:] and
starts polling

thread 1 encounters a finished process and removes it from
_active[]
thread 2 does not know the process is removed, finds the
same process finished and tries to remove it from _active
but this fails, because thread 1 removed it already

so the action of cleaning up should maybe be serialized
if 1 thread is doing it, the other one should block

everyone who needs this can of course patch the
subprocess.py file, but shouldn't this be fixed in the library?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-30 09:43

Message:
Logged In: YES 
user_id=33168

If you always called wait() the _active list isn't
beneficial to you.  However, many people do not call wait
and the _active list provides a mechanism to cleanup zombied
children.  This is important for many users.

If you need thread safely, you can handle the locking
yourself before calling poll()/wait().

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-03-29 22:41

Message:
Logged In: YES 
user_id=21627

The purpose of the _active list is to wait(2) for open
processes. It needs to stay.

----------------------------------------------------------------------

Comment By: Tristan Faujour (tfaujour)
Date: 2006-03-29 15:59

Message:
Logged In: YES 
user_id=1488657

I agree.

The use of _active makes subprocess.py thread-UNsafe.

See also: Bug #1199282

In order to have a thread-safe subprocess.py, I commented
out the call to _cleanup() in Popen.__init__(). As a side
effect, _active becomes useless.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460493&group_id=5470

From noreply at sourceforge.net  Thu Mar 30 21:52:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 30 Mar 2006 11:52:25 -0800
Subject: [ python-Bugs-1461610 ] xmlrpclib.binary doesn't exist
Message-ID: <E1FP3Bx-00040w-OR@sc8-sf-web3.sourceforge.net>

Bugs item #1461610, was opened at 2006-03-30 14: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=1461610&group_id=5470

Please note that this 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: Chris AtLee (catlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: xmlrpclib.binary doesn't exist

Initial Comment:
The current 2.4 and 2.5 docs mention that the xmlrpclib
has a function
called binary which converts any python value to a
Binary object.

However, this function does not exist in either 2.4.3
or 2.5.

The Binary constructor accepts a data parameter, so I
would say just
remove mention of the binary function from the docs and
leave the
implementation as-is.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1461610&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 02:50:48 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 30 Mar 2006 16:50:48 -0800
Subject: [ python-Bugs-1461783 ] Invalid modes crash open()
Message-ID: <E1FP7qi-0002nP-Ro@sc8-sf-web4-b.sourceforge.net>

Bugs item #1461783, was opened at 2006-03-31 00:50
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1461783&group_id=5470

Please note that this message 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: splitscreen (splitscreen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Invalid modes crash open()

Initial Comment:
The 2.5a0 interpreter can be crashed by opening a file
with an invalid mode, i.e

open("bogus", "bogus")

results in the Microsoft Visual C++ Debug Library
spewing an "assertion failed" message with the expression

("Invalid file open mode", 0) 

in the file _open.c, line 98.

Attached is a very rough patch that raises and IOError
if the open mode doesn't begin with an 'a', 'w' or 'r'
on the Windows platform. 

If this is something wrong at my end (and I feel it may
be) please let me know. I'd be happy to offer any more
information.

BTW, I'm using Microsoft Visual Studio 2005.

Thanks,
Matt

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1461783&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 05:55:15 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 30 Mar 2006 19:55:15 -0800
Subject: [ python-Bugs-1460340 ] random.sample can raise KeyError
Message-ID: <E1FPAjD-0005tw-Cg@sc8-sf-web4-b.sourceforge.net>

Bugs item #1460340, was opened at 2006-03-28 19:05
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460340&group_id=5470

Please note that this message 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: paul rubin (phr)
>Assigned to: Tim Peters (tim_one)
Summary: random.sample can raise KeyError

Initial Comment:
I have only tested this in 2.3 and the relevant code in
random.py has changed in the current svn branch, but
from inspection it looks to me like the bug may still
be there.

If you initialize a dictionary as follows:

 a={}.fromkeys(range(10)+range(10,100,2)+range(100,110))

then

 random.sample(a,3)

raises KeyError most times that you call it.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-03-30 22:55

Message:
Logged In: YES 
user_id=31435

Assigned to me.  The current situation is unacceptable,
because internal code comments and the test suite were left
implying that random.sample() "should work" for dicts -- but
it doesn't, and the failure modes are both subtle and silent.

Note that my first example was utterly vanilla, using a
small dict with a contiguous range of integer keys.  That's
not asking sample() to crack a safe, it's asking it to
borrow candy from a dead baby ;-)

I don't care a lot about the second example, but it would
would also work right if dicts were forced into sample()'s
first internal algorithm (and potential optimization be
damned in the case of a dict).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-03-30 05:18

Message:
Logged In: YES 
user_id=80475

Bah.  I'm not overly concerned.  It is a Python fact of 
life that objects defining __getitem__ cannot aways be 
clearly categorized as being either a sequence or a 
mapping but not both.  You can add some additional checks 
like checking for a keys() method, but there is a limit to 
what you can do against these safe-cracking style efforts 
to trick the routine.  I hope this quest for theoretical 
perfection doesn't lead to throwing the baby out with the 
bathwater.  It would be ashamed to lose the automated 
choice of the best performing algorithm.  If that happens, 
somebody's real-world use cases are certain to suffer.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-03-29 08:02

Message:
Logged In: YES 
user_id=31435

Ya, this is flaky for dicts; re-opening.  For example,

>>> d = dict((i, complex(i, i)) for i in xrange(30))
>>> random.sample(d, 5)  # ask for 5 and it samples values
[(25+25j), (4+4j), (16+16j), (13+13j), (17+17j)]
>>> random.sample(d, 6)  # ask for 6 and it samples keys
[20, 11, 9, 4, 14, 1]

That one doesn't have to do with internal exceptions, it has
only to do with which of sample()'s internal algorithms gets
used.

Paul's point about potential bias is also a worry.  Here's a
full example:

"""
from random import sample
d = dict.fromkeys(range(24))
d['x'] = 'y'
count = hits = 0
while 1:
    count += 1
    hits += sample(d, 1) == ['x']
    if count % 10000 == 0:
        print count, "%.2f%%" % (100.0 * hits / count)
"""

Since len(d) == 25, I'd hope to see 'x' selected 1/25 = 4%
of the time.  Instead it gets selected 0.16% of the time
(1/25**2 -- and Paul's analysis of why is on target).


----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2006-03-29 05:07

Message:
Logged In: YES 
user_id=72053

Actually the previous comment is wrong too; 99% of the time,
sample(a,1) will return None since that's the value
connected to every key in the dictionary, i.e. it's
population[j] for every j.  The other 1% of the time, the
dict gets converted to a list, and the sample returns a key
from the dict rather than a value, which is certainly wrong.
 And you can see how the probabilities are still messed up
if the values in the dict are distinct.

I think it's ok to give up on dicts, but some warning should
about it be added to the manual unless dict-like things
somehow get detected in the code.  It would be best to test
for the object really being a sequence, but I don't know if
such a test exists.  Maybe one should be added.

I'll leave it to you guys to reopen this bug if appropriate.

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2006-03-29 04:46

Message:
Logged In: YES 
user_id=72053

I don't think the fix at 43421 is quite right, but I can't
easily test it in my current setup.  Suppose

a = dict.fromkeys(range(99) + ['x'])
b = random.sample(a,1)

99% of the time, there's no KeyError and b gets set to [j]
where j is some random integer.

1% of the time, there's a KeyError, random.sample is called
recursively, and the recursive call returns [some integer j]
99% of the time, and returns ['x'] 1% of the time.

So in total, ['x'] gets returned .01% of the time instead of
1% of the time.

I think it's better to not set result[i]=population[j]
inside the loop.  Instead, just build up the selected set
until it has enough indices; then try to make a result list
using those indices, and if there's a KeyError, convert the
population to a list and use the same selection set to make
the results.

gbrandl also correctly points out that a dict is not a
sequence type, so maybe it's ok to just punt on dicts.  But
it's obvious from the code comments that somebody once
wanted dicts to work, and it's reasonable for people to want
sets to work.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-03-29 04:17

Message:
Logged In: YES 
user_id=80475

Checked-in a fix.
See revision 43420 and 43421.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-03-29 04:11

Message:
Logged In: YES 
user_id=849994

random.sample is documented to take a sequence as its first
argument. A dict is not a sequence type.

I think you want
random.sample(a.keys(), 3)
or, for large dicts,
random.sample(a.iterkeys(), 3)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460340&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 06:37:59 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 30 Mar 2006 20:37:59 -0800
Subject: [ python-Bugs-1461855 ] fdopen() not guaranteed to have Python
	semantics
Message-ID: <E1FPBOZ-0000kp-AG@sc8-sf-web6.sourceforge.net>

Bugs item #1461855, was opened at 2006-03-31 04: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=1461855&group_id=5470

Please note that this message 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: John Levon (movement)
Assigned to: Nobody/Anonymous (nobody)
Summary: fdopen() not guaranteed to have Python semantics

Initial Comment:
The specification for seek() says:

 seek(  	offset[, whence])
    Note that if the file is opened for appending (mode
'a' or 'a+'), any seek() operations will be undone at
the next write.

Consider operating on an fdopen()ed file. The Python
source simply calls into the OS-provided fdopen():

http://pxr.openlook.org/pxr/source/Modules/posixmodule.c#3530

However, the POSIX standard

http://www.opengroup.org/onlinepubs/009695399/functions/fdopen.html

says:

"Although not explicitly required by this volume of
IEEE Std 1003.1-2001, a good implementation of append
(a) mode would cause the O_APPEND flag to be set."

Thus, to ensure Python semantics, Python's fdopen()
must perform an fcntl() to ensure O_APPEND is set.

For example, on Solaris, this optional O_APPEND
behaviour is not applied:

http://cvs.opensolaris.org/source/xref/on/usr/src/lib/libc/port/stdio/fdopen.c?r=1.22#97

This has recently caused serious problems with the
Mercurial SCM.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1461855&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 11:54:17 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 01:54:17 -0800
Subject: [ python-Bugs-1460340 ] random.sample can raise KeyError
Message-ID: <E1FPGKf-0007Ub-PS@sc8-sf-web2.sourceforge.net>

Bugs item #1460340, was opened at 2006-03-28 19:05
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460340&group_id=5470

Please note that this message 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: paul rubin (phr)
Assigned to: Tim Peters (tim_one)
Summary: random.sample can raise KeyError

Initial Comment:
I have only tested this in 2.3 and the relevant code in
random.py has changed in the current svn branch, but
from inspection it looks to me like the bug may still
be there.

If you initialize a dictionary as follows:

 a={}.fromkeys(range(10)+range(10,100,2)+range(100,110))

then

 random.sample(a,3)

raises KeyError most times that you call it.


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2006-03-31 04:54

Message:
Logged In: YES 
user_id=80475

It probably should not support dicts at all and should 
make some effort to detect them and raise a TypeError.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-03-30 22:55

Message:
Logged In: YES 
user_id=31435

Assigned to me.  The current situation is unacceptable,
because internal code comments and the test suite were left
implying that random.sample() "should work" for dicts -- but
it doesn't, and the failure modes are both subtle and silent.

Note that my first example was utterly vanilla, using a
small dict with a contiguous range of integer keys.  That's
not asking sample() to crack a safe, it's asking it to
borrow candy from a dead baby ;-)

I don't care a lot about the second example, but it would
would also work right if dicts were forced into sample()'s
first internal algorithm (and potential optimization be
damned in the case of a dict).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-03-30 05:18

Message:
Logged In: YES 
user_id=80475

Bah.  I'm not overly concerned.  It is a Python fact of 
life that objects defining __getitem__ cannot aways be 
clearly categorized as being either a sequence or a 
mapping but not both.  You can add some additional checks 
like checking for a keys() method, but there is a limit to 
what you can do against these safe-cracking style efforts 
to trick the routine.  I hope this quest for theoretical 
perfection doesn't lead to throwing the baby out with the 
bathwater.  It would be ashamed to lose the automated 
choice of the best performing algorithm.  If that happens, 
somebody's real-world use cases are certain to suffer.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-03-29 08:02

Message:
Logged In: YES 
user_id=31435

Ya, this is flaky for dicts; re-opening.  For example,

>>> d = dict((i, complex(i, i)) for i in xrange(30))
>>> random.sample(d, 5)  # ask for 5 and it samples values
[(25+25j), (4+4j), (16+16j), (13+13j), (17+17j)]
>>> random.sample(d, 6)  # ask for 6 and it samples keys
[20, 11, 9, 4, 14, 1]

That one doesn't have to do with internal exceptions, it has
only to do with which of sample()'s internal algorithms gets
used.

Paul's point about potential bias is also a worry.  Here's a
full example:

"""
from random import sample
d = dict.fromkeys(range(24))
d['x'] = 'y'
count = hits = 0
while 1:
    count += 1
    hits += sample(d, 1) == ['x']
    if count % 10000 == 0:
        print count, "%.2f%%" % (100.0 * hits / count)
"""

Since len(d) == 25, I'd hope to see 'x' selected 1/25 = 4%
of the time.  Instead it gets selected 0.16% of the time
(1/25**2 -- and Paul's analysis of why is on target).


----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2006-03-29 05:07

Message:
Logged In: YES 
user_id=72053

Actually the previous comment is wrong too; 99% of the time,
sample(a,1) will return None since that's the value
connected to every key in the dictionary, i.e. it's
population[j] for every j.  The other 1% of the time, the
dict gets converted to a list, and the sample returns a key
from the dict rather than a value, which is certainly wrong.
 And you can see how the probabilities are still messed up
if the values in the dict are distinct.

I think it's ok to give up on dicts, but some warning should
about it be added to the manual unless dict-like things
somehow get detected in the code.  It would be best to test
for the object really being a sequence, but I don't know if
such a test exists.  Maybe one should be added.

I'll leave it to you guys to reopen this bug if appropriate.

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2006-03-29 04:46

Message:
Logged In: YES 
user_id=72053

I don't think the fix at 43421 is quite right, but I can't
easily test it in my current setup.  Suppose

a = dict.fromkeys(range(99) + ['x'])
b = random.sample(a,1)

99% of the time, there's no KeyError and b gets set to [j]
where j is some random integer.

1% of the time, there's a KeyError, random.sample is called
recursively, and the recursive call returns [some integer j]
99% of the time, and returns ['x'] 1% of the time.

So in total, ['x'] gets returned .01% of the time instead of
1% of the time.

I think it's better to not set result[i]=population[j]
inside the loop.  Instead, just build up the selected set
until it has enough indices; then try to make a result list
using those indices, and if there's a KeyError, convert the
population to a list and use the same selection set to make
the results.

gbrandl also correctly points out that a dict is not a
sequence type, so maybe it's ok to just punt on dicts.  But
it's obvious from the code comments that somebody once
wanted dicts to work, and it's reasonable for people to want
sets to work.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-03-29 04:17

Message:
Logged In: YES 
user_id=80475

Checked-in a fix.
See revision 43420 and 43421.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-03-29 04:11

Message:
Logged In: YES 
user_id=849994

random.sample is documented to take a sequence as its first
argument. A dict is not a sequence type.

I think you want
random.sample(a.keys(), 3)
or, for large dicts,
random.sample(a.iterkeys(), 3)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460340&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 12:30:10 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 02:30:10 -0800
Subject: [ python-Bugs-1460340 ] random.sample can raise KeyError
Message-ID: <E1FPGtO-0004SY-Nl@sc8-sf-web5.sourceforge.net>

Bugs item #1460340, was opened at 2006-03-29 00:05
Message generated for change (Comment added) made by phr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460340&group_id=5470

Please note that this message 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: paul rubin (phr)
Assigned to: Tim Peters (tim_one)
Summary: random.sample can raise KeyError

Initial Comment:
I have only tested this in 2.3 and the relevant code in
random.py has changed in the current svn branch, but
from inspection it looks to me like the bug may still
be there.

If you initialize a dictionary as follows:

 a={}.fromkeys(range(10)+range(10,100,2)+range(100,110))

then

 random.sample(a,3)

raises KeyError most times that you call it.


----------------------------------------------------------------------

>Comment By: paul rubin (phr)
Date: 2006-03-31 10:30

Message:
Logged In: YES 
user_id=72053

It can handle dicts easily enough by sampling from
population.values() instead of list(population), if it knows
it's dealing with a dict.  On clpy I suggested adding
s.values() for sets so that the values in dicts and sets
(and multisets if those get added) could be handled
uniformly, but  reception hasn't been good.  

I see there's an operator.isSequenceType function, that
presumably checks for built-in sequence types, not arbitrary
classes with __getattr__ methods that make them act like
sequences.  But maybe it's close enough to what we want,
that the docs can say that random.sample is limited to
sequences, sets, and (maybe) dicts.  If it were up to me, 
I'd check for a .values() operation on non-sequences and use
it if available, or raise TypeError otherwise.  Then I'd add
that operation to sets.

There is also a very cute algorithm for doing random
sampling from sequences of unknown length (iterators).  I'm
sure Tim and Ray know about it.  Maybe I'll try coding it. 
The k=1 case (basically random.choice) looks like:
  for n,x in enumerate(seq):
    if random()*(n+1) < 1: c=x
  return [c]


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-03-31 09:54

Message:
Logged In: YES 
user_id=80475

It probably should not support dicts at all and should 
make some effort to detect them and raise a TypeError.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-03-31 03:55

Message:
Logged In: YES 
user_id=31435

Assigned to me.  The current situation is unacceptable,
because internal code comments and the test suite were left
implying that random.sample() "should work" for dicts -- but
it doesn't, and the failure modes are both subtle and silent.

Note that my first example was utterly vanilla, using a
small dict with a contiguous range of integer keys.  That's
not asking sample() to crack a safe, it's asking it to
borrow candy from a dead baby ;-)

I don't care a lot about the second example, but it would
would also work right if dicts were forced into sample()'s
first internal algorithm (and potential optimization be
damned in the case of a dict).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-03-30 10:18

Message:
Logged In: YES 
user_id=80475

Bah.  I'm not overly concerned.  It is a Python fact of 
life that objects defining __getitem__ cannot aways be 
clearly categorized as being either a sequence or a 
mapping but not both.  You can add some additional checks 
like checking for a keys() method, but there is a limit to 
what you can do against these safe-cracking style efforts 
to trick the routine.  I hope this quest for theoretical 
perfection doesn't lead to throwing the baby out with the 
bathwater.  It would be ashamed to lose the automated 
choice of the best performing algorithm.  If that happens, 
somebody's real-world use cases are certain to suffer.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-03-29 13:02

Message:
Logged In: YES 
user_id=31435

Ya, this is flaky for dicts; re-opening.  For example,

>>> d = dict((i, complex(i, i)) for i in xrange(30))
>>> random.sample(d, 5)  # ask for 5 and it samples values
[(25+25j), (4+4j), (16+16j), (13+13j), (17+17j)]
>>> random.sample(d, 6)  # ask for 6 and it samples keys
[20, 11, 9, 4, 14, 1]

That one doesn't have to do with internal exceptions, it has
only to do with which of sample()'s internal algorithms gets
used.

Paul's point about potential bias is also a worry.  Here's a
full example:

"""
from random import sample
d = dict.fromkeys(range(24))
d['x'] = 'y'
count = hits = 0
while 1:
    count += 1
    hits += sample(d, 1) == ['x']
    if count % 10000 == 0:
        print count, "%.2f%%" % (100.0 * hits / count)
"""

Since len(d) == 25, I'd hope to see 'x' selected 1/25 = 4%
of the time.  Instead it gets selected 0.16% of the time
(1/25**2 -- and Paul's analysis of why is on target).


----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2006-03-29 10:07

Message:
Logged In: YES 
user_id=72053

Actually the previous comment is wrong too; 99% of the time,
sample(a,1) will return None since that's the value
connected to every key in the dictionary, i.e. it's
population[j] for every j.  The other 1% of the time, the
dict gets converted to a list, and the sample returns a key
from the dict rather than a value, which is certainly wrong.
 And you can see how the probabilities are still messed up
if the values in the dict are distinct.

I think it's ok to give up on dicts, but some warning should
about it be added to the manual unless dict-like things
somehow get detected in the code.  It would be best to test
for the object really being a sequence, but I don't know if
such a test exists.  Maybe one should be added.

I'll leave it to you guys to reopen this bug if appropriate.

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2006-03-29 09:46

Message:
Logged In: YES 
user_id=72053

I don't think the fix at 43421 is quite right, but I can't
easily test it in my current setup.  Suppose

a = dict.fromkeys(range(99) + ['x'])
b = random.sample(a,1)

99% of the time, there's no KeyError and b gets set to [j]
where j is some random integer.

1% of the time, there's a KeyError, random.sample is called
recursively, and the recursive call returns [some integer j]
99% of the time, and returns ['x'] 1% of the time.

So in total, ['x'] gets returned .01% of the time instead of
1% of the time.

I think it's better to not set result[i]=population[j]
inside the loop.  Instead, just build up the selected set
until it has enough indices; then try to make a result list
using those indices, and if there's a KeyError, convert the
population to a list and use the same selection set to make
the results.

gbrandl also correctly points out that a dict is not a
sequence type, so maybe it's ok to just punt on dicts.  But
it's obvious from the code comments that somebody once
wanted dicts to work, and it's reasonable for people to want
sets to work.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-03-29 09:17

Message:
Logged In: YES 
user_id=80475

Checked-in a fix.
See revision 43420 and 43421.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-03-29 09:11

Message:
Logged In: YES 
user_id=849994

random.sample is documented to take a sequence as its first
argument. A dict is not a sequence type.

I think you want
random.sample(a.keys(), 3)
or, for large dicts,
random.sample(a.iterkeys(), 3)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460340&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 13:35:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 03:35:05 -0800
Subject: [ python-Bugs-1257728 ] error message incorrectly claims Visual C++
	is required
Message-ID: <E1FPHuD-0008UF-62@sc8-sf-web5.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-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  Fri Mar 31 13:37:20 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 03:37:20 -0800
Subject: [ python-Bugs-1460340 ] random.sample can raise KeyError
Message-ID: <E1FPHwO-0004YE-AO@sc8-sf-web3.sourceforge.net>

Bugs item #1460340, was opened at 2006-03-28 19:05
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460340&group_id=5470

Please note that this message 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: paul rubin (phr)
Assigned to: Tim Peters (tim_one)
Summary: random.sample can raise KeyError

Initial Comment:
I have only tested this in 2.3 and the relevant code in
random.py has changed in the current svn branch, but
from inspection it looks to me like the bug may still
be there.

If you initialize a dictionary as follows:

 a={}.fromkeys(range(10)+range(10,100,2)+range(100,110))

then

 random.sample(a,3)

raises KeyError most times that you call it.


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2006-03-31 06:37

Message:
Logged In: YES 
user_id=80475

Sampling dict.values is screwy.  If they want to sample a 
dictionary, they can be explicit about what they want by 
using d.keys() or d.values().

I prefer to completely forgo dict support
and stick with sequences (as documented)
and sets (supported but not documented).



----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2006-03-31 05:30

Message:
Logged In: YES 
user_id=72053

It can handle dicts easily enough by sampling from
population.values() instead of list(population), if it knows
it's dealing with a dict.  On clpy I suggested adding
s.values() for sets so that the values in dicts and sets
(and multisets if those get added) could be handled
uniformly, but  reception hasn't been good.  

I see there's an operator.isSequenceType function, that
presumably checks for built-in sequence types, not arbitrary
classes with __getattr__ methods that make them act like
sequences.  But maybe it's close enough to what we want,
that the docs can say that random.sample is limited to
sequences, sets, and (maybe) dicts.  If it were up to me, 
I'd check for a .values() operation on non-sequences and use
it if available, or raise TypeError otherwise.  Then I'd add
that operation to sets.

There is also a very cute algorithm for doing random
sampling from sequences of unknown length (iterators).  I'm
sure Tim and Ray know about it.  Maybe I'll try coding it. 
The k=1 case (basically random.choice) looks like:
  for n,x in enumerate(seq):
    if random()*(n+1) < 1: c=x
  return [c]


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-03-31 04:54

Message:
Logged In: YES 
user_id=80475

It probably should not support dicts at all and should 
make some effort to detect them and raise a TypeError.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-03-30 22:55

Message:
Logged In: YES 
user_id=31435

Assigned to me.  The current situation is unacceptable,
because internal code comments and the test suite were left
implying that random.sample() "should work" for dicts -- but
it doesn't, and the failure modes are both subtle and silent.

Note that my first example was utterly vanilla, using a
small dict with a contiguous range of integer keys.  That's
not asking sample() to crack a safe, it's asking it to
borrow candy from a dead baby ;-)

I don't care a lot about the second example, but it would
would also work right if dicts were forced into sample()'s
first internal algorithm (and potential optimization be
damned in the case of a dict).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-03-30 05:18

Message:
Logged In: YES 
user_id=80475

Bah.  I'm not overly concerned.  It is a Python fact of 
life that objects defining __getitem__ cannot aways be 
clearly categorized as being either a sequence or a 
mapping but not both.  You can add some additional checks 
like checking for a keys() method, but there is a limit to 
what you can do against these safe-cracking style efforts 
to trick the routine.  I hope this quest for theoretical 
perfection doesn't lead to throwing the baby out with the 
bathwater.  It would be ashamed to lose the automated 
choice of the best performing algorithm.  If that happens, 
somebody's real-world use cases are certain to suffer.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-03-29 08:02

Message:
Logged In: YES 
user_id=31435

Ya, this is flaky for dicts; re-opening.  For example,

>>> d = dict((i, complex(i, i)) for i in xrange(30))
>>> random.sample(d, 5)  # ask for 5 and it samples values
[(25+25j), (4+4j), (16+16j), (13+13j), (17+17j)]
>>> random.sample(d, 6)  # ask for 6 and it samples keys
[20, 11, 9, 4, 14, 1]

That one doesn't have to do with internal exceptions, it has
only to do with which of sample()'s internal algorithms gets
used.

Paul's point about potential bias is also a worry.  Here's a
full example:

"""
from random import sample
d = dict.fromkeys(range(24))
d['x'] = 'y'
count = hits = 0
while 1:
    count += 1
    hits += sample(d, 1) == ['x']
    if count % 10000 == 0:
        print count, "%.2f%%" % (100.0 * hits / count)
"""

Since len(d) == 25, I'd hope to see 'x' selected 1/25 = 4%
of the time.  Instead it gets selected 0.16% of the time
(1/25**2 -- and Paul's analysis of why is on target).


----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2006-03-29 05:07

Message:
Logged In: YES 
user_id=72053

Actually the previous comment is wrong too; 99% of the time,
sample(a,1) will return None since that's the value
connected to every key in the dictionary, i.e. it's
population[j] for every j.  The other 1% of the time, the
dict gets converted to a list, and the sample returns a key
from the dict rather than a value, which is certainly wrong.
 And you can see how the probabilities are still messed up
if the values in the dict are distinct.

I think it's ok to give up on dicts, but some warning should
about it be added to the manual unless dict-like things
somehow get detected in the code.  It would be best to test
for the object really being a sequence, but I don't know if
such a test exists.  Maybe one should be added.

I'll leave it to you guys to reopen this bug if appropriate.

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2006-03-29 04:46

Message:
Logged In: YES 
user_id=72053

I don't think the fix at 43421 is quite right, but I can't
easily test it in my current setup.  Suppose

a = dict.fromkeys(range(99) + ['x'])
b = random.sample(a,1)

99% of the time, there's no KeyError and b gets set to [j]
where j is some random integer.

1% of the time, there's a KeyError, random.sample is called
recursively, and the recursive call returns [some integer j]
99% of the time, and returns ['x'] 1% of the time.

So in total, ['x'] gets returned .01% of the time instead of
1% of the time.

I think it's better to not set result[i]=population[j]
inside the loop.  Instead, just build up the selected set
until it has enough indices; then try to make a result list
using those indices, and if there's a KeyError, convert the
population to a list and use the same selection set to make
the results.

gbrandl also correctly points out that a dict is not a
sequence type, so maybe it's ok to just punt on dicts.  But
it's obvious from the code comments that somebody once
wanted dicts to work, and it's reasonable for people to want
sets to work.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-03-29 04:17

Message:
Logged In: YES 
user_id=80475

Checked-in a fix.
See revision 43420 and 43421.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-03-29 04:11

Message:
Logged In: YES 
user_id=849994

random.sample is documented to take a sequence as its first
argument. A dict is not a sequence type.

I think you want
random.sample(a.keys(), 3)
or, for large dicts,
random.sample(a.iterkeys(), 3)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460340&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 13:42:33 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 03:42:33 -0800
Subject: [ python-Bugs-1460340 ] random.sample can raise KeyError
Message-ID: <E1FPI1R-0004rn-Ve@sc8-sf-web3.sourceforge.net>

Bugs item #1460340, was opened at 2006-03-29 00:05
Message generated for change (Comment added) made by phr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460340&group_id=5470

Please note that this message 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: paul rubin (phr)
Assigned to: Tim Peters (tim_one)
Summary: random.sample can raise KeyError

Initial Comment:
I have only tested this in 2.3 and the relevant code in
random.py has changed in the current svn branch, but
from inspection it looks to me like the bug may still
be there.

If you initialize a dictionary as follows:

 a={}.fromkeys(range(10)+range(10,100,2)+range(100,110))

then

 random.sample(a,3)

raises KeyError most times that you call it.


----------------------------------------------------------------------

>Comment By: paul rubin (phr)
Date: 2006-03-31 11:42

Message:
Logged In: YES 
user_id=72053

This notion of supporting sets without documenting it also
seems screwy.  I defer to you guys whether sets or dicts
need to be supported, but if either is supported to the
extent that someone is going to bother maintaining the code
and test suite for it, IMO the support should be documented.  

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-03-31 11:37

Message:
Logged In: YES 
user_id=80475

Sampling dict.values is screwy.  If they want to sample a 
dictionary, they can be explicit about what they want by 
using d.keys() or d.values().

I prefer to completely forgo dict support
and stick with sequences (as documented)
and sets (supported but not documented).



----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2006-03-31 10:30

Message:
Logged In: YES 
user_id=72053

It can handle dicts easily enough by sampling from
population.values() instead of list(population), if it knows
it's dealing with a dict.  On clpy I suggested adding
s.values() for sets so that the values in dicts and sets
(and multisets if those get added) could be handled
uniformly, but  reception hasn't been good.  

I see there's an operator.isSequenceType function, that
presumably checks for built-in sequence types, not arbitrary
classes with __getattr__ methods that make them act like
sequences.  But maybe it's close enough to what we want,
that the docs can say that random.sample is limited to
sequences, sets, and (maybe) dicts.  If it were up to me, 
I'd check for a .values() operation on non-sequences and use
it if available, or raise TypeError otherwise.  Then I'd add
that operation to sets.

There is also a very cute algorithm for doing random
sampling from sequences of unknown length (iterators).  I'm
sure Tim and Ray know about it.  Maybe I'll try coding it. 
The k=1 case (basically random.choice) looks like:
  for n,x in enumerate(seq):
    if random()*(n+1) < 1: c=x
  return [c]


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-03-31 09:54

Message:
Logged In: YES 
user_id=80475

It probably should not support dicts at all and should 
make some effort to detect them and raise a TypeError.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-03-31 03:55

Message:
Logged In: YES 
user_id=31435

Assigned to me.  The current situation is unacceptable,
because internal code comments and the test suite were left
implying that random.sample() "should work" for dicts -- but
it doesn't, and the failure modes are both subtle and silent.

Note that my first example was utterly vanilla, using a
small dict with a contiguous range of integer keys.  That's
not asking sample() to crack a safe, it's asking it to
borrow candy from a dead baby ;-)

I don't care a lot about the second example, but it would
would also work right if dicts were forced into sample()'s
first internal algorithm (and potential optimization be
damned in the case of a dict).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-03-30 10:18

Message:
Logged In: YES 
user_id=80475

Bah.  I'm not overly concerned.  It is a Python fact of 
life that objects defining __getitem__ cannot aways be 
clearly categorized as being either a sequence or a 
mapping but not both.  You can add some additional checks 
like checking for a keys() method, but there is a limit to 
what you can do against these safe-cracking style efforts 
to trick the routine.  I hope this quest for theoretical 
perfection doesn't lead to throwing the baby out with the 
bathwater.  It would be ashamed to lose the automated 
choice of the best performing algorithm.  If that happens, 
somebody's real-world use cases are certain to suffer.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-03-29 13:02

Message:
Logged In: YES 
user_id=31435

Ya, this is flaky for dicts; re-opening.  For example,

>>> d = dict((i, complex(i, i)) for i in xrange(30))
>>> random.sample(d, 5)  # ask for 5 and it samples values
[(25+25j), (4+4j), (16+16j), (13+13j), (17+17j)]
>>> random.sample(d, 6)  # ask for 6 and it samples keys
[20, 11, 9, 4, 14, 1]

That one doesn't have to do with internal exceptions, it has
only to do with which of sample()'s internal algorithms gets
used.

Paul's point about potential bias is also a worry.  Here's a
full example:

"""
from random import sample
d = dict.fromkeys(range(24))
d['x'] = 'y'
count = hits = 0
while 1:
    count += 1
    hits += sample(d, 1) == ['x']
    if count % 10000 == 0:
        print count, "%.2f%%" % (100.0 * hits / count)
"""

Since len(d) == 25, I'd hope to see 'x' selected 1/25 = 4%
of the time.  Instead it gets selected 0.16% of the time
(1/25**2 -- and Paul's analysis of why is on target).


----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2006-03-29 10:07

Message:
Logged In: YES 
user_id=72053

Actually the previous comment is wrong too; 99% of the time,
sample(a,1) will return None since that's the value
connected to every key in the dictionary, i.e. it's
population[j] for every j.  The other 1% of the time, the
dict gets converted to a list, and the sample returns a key
from the dict rather than a value, which is certainly wrong.
 And you can see how the probabilities are still messed up
if the values in the dict are distinct.

I think it's ok to give up on dicts, but some warning should
about it be added to the manual unless dict-like things
somehow get detected in the code.  It would be best to test
for the object really being a sequence, but I don't know if
such a test exists.  Maybe one should be added.

I'll leave it to you guys to reopen this bug if appropriate.

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2006-03-29 09:46

Message:
Logged In: YES 
user_id=72053

I don't think the fix at 43421 is quite right, but I can't
easily test it in my current setup.  Suppose

a = dict.fromkeys(range(99) + ['x'])
b = random.sample(a,1)

99% of the time, there's no KeyError and b gets set to [j]
where j is some random integer.

1% of the time, there's a KeyError, random.sample is called
recursively, and the recursive call returns [some integer j]
99% of the time, and returns ['x'] 1% of the time.

So in total, ['x'] gets returned .01% of the time instead of
1% of the time.

I think it's better to not set result[i]=population[j]
inside the loop.  Instead, just build up the selected set
until it has enough indices; then try to make a result list
using those indices, and if there's a KeyError, convert the
population to a list and use the same selection set to make
the results.

gbrandl also correctly points out that a dict is not a
sequence type, so maybe it's ok to just punt on dicts.  But
it's obvious from the code comments that somebody once
wanted dicts to work, and it's reasonable for people to want
sets to work.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-03-29 09:17

Message:
Logged In: YES 
user_id=80475

Checked-in a fix.
See revision 43420 and 43421.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-03-29 09:11

Message:
Logged In: YES 
user_id=849994

random.sample is documented to take a sequence as its first
argument. A dict is not a sequence type.

I think you want
random.sample(a.keys(), 3)
or, for large dicts,
random.sample(a.iterkeys(), 3)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460340&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 14:29:51 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 04:29:51 -0800
Subject: [ python-Bugs-1460340 ] random.sample can raise KeyError
Message-ID: <E1FPIlD-0004bA-UW@sc8-sf-web4-b.sourceforge.net>

Bugs item #1460340, was opened at 2006-03-28 19:05
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460340&group_id=5470

Please note that this message 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: paul rubin (phr)
Assigned to: Tim Peters (tim_one)
Summary: random.sample can raise KeyError

Initial Comment:
I have only tested this in 2.3 and the relevant code in
random.py has changed in the current svn branch, but
from inspection it looks to me like the bug may still
be there.

If you initialize a dictionary as follows:

 a={}.fromkeys(range(10)+range(10,100,2)+range(100,110))

then

 random.sample(a,3)

raises KeyError most times that you call it.


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2006-03-31 07:29

Message:
Logged In: YES 
user_id=80475

It should be documented. Was noting that it (and dicts) 
currently are not.  That gives us the freedom to change it.

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2006-03-31 06:42

Message:
Logged In: YES 
user_id=72053

This notion of supporting sets without documenting it also
seems screwy.  I defer to you guys whether sets or dicts
need to be supported, but if either is supported to the
extent that someone is going to bother maintaining the code
and test suite for it, IMO the support should be documented.  

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-03-31 06:37

Message:
Logged In: YES 
user_id=80475

Sampling dict.values is screwy.  If they want to sample a 
dictionary, they can be explicit about what they want by 
using d.keys() or d.values().

I prefer to completely forgo dict support
and stick with sequences (as documented)
and sets (supported but not documented).



----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2006-03-31 05:30

Message:
Logged In: YES 
user_id=72053

It can handle dicts easily enough by sampling from
population.values() instead of list(population), if it knows
it's dealing with a dict.  On clpy I suggested adding
s.values() for sets so that the values in dicts and sets
(and multisets if those get added) could be handled
uniformly, but  reception hasn't been good.  

I see there's an operator.isSequenceType function, that
presumably checks for built-in sequence types, not arbitrary
classes with __getattr__ methods that make them act like
sequences.  But maybe it's close enough to what we want,
that the docs can say that random.sample is limited to
sequences, sets, and (maybe) dicts.  If it were up to me, 
I'd check for a .values() operation on non-sequences and use
it if available, or raise TypeError otherwise.  Then I'd add
that operation to sets.

There is also a very cute algorithm for doing random
sampling from sequences of unknown length (iterators).  I'm
sure Tim and Ray know about it.  Maybe I'll try coding it. 
The k=1 case (basically random.choice) looks like:
  for n,x in enumerate(seq):
    if random()*(n+1) < 1: c=x
  return [c]


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-03-31 04:54

Message:
Logged In: YES 
user_id=80475

It probably should not support dicts at all and should 
make some effort to detect them and raise a TypeError.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-03-30 22:55

Message:
Logged In: YES 
user_id=31435

Assigned to me.  The current situation is unacceptable,
because internal code comments and the test suite were left
implying that random.sample() "should work" for dicts -- but
it doesn't, and the failure modes are both subtle and silent.

Note that my first example was utterly vanilla, using a
small dict with a contiguous range of integer keys.  That's
not asking sample() to crack a safe, it's asking it to
borrow candy from a dead baby ;-)

I don't care a lot about the second example, but it would
would also work right if dicts were forced into sample()'s
first internal algorithm (and potential optimization be
damned in the case of a dict).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-03-30 05:18

Message:
Logged In: YES 
user_id=80475

Bah.  I'm not overly concerned.  It is a Python fact of 
life that objects defining __getitem__ cannot aways be 
clearly categorized as being either a sequence or a 
mapping but not both.  You can add some additional checks 
like checking for a keys() method, but there is a limit to 
what you can do against these safe-cracking style efforts 
to trick the routine.  I hope this quest for theoretical 
perfection doesn't lead to throwing the baby out with the 
bathwater.  It would be ashamed to lose the automated 
choice of the best performing algorithm.  If that happens, 
somebody's real-world use cases are certain to suffer.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-03-29 08:02

Message:
Logged In: YES 
user_id=31435

Ya, this is flaky for dicts; re-opening.  For example,

>>> d = dict((i, complex(i, i)) for i in xrange(30))
>>> random.sample(d, 5)  # ask for 5 and it samples values
[(25+25j), (4+4j), (16+16j), (13+13j), (17+17j)]
>>> random.sample(d, 6)  # ask for 6 and it samples keys
[20, 11, 9, 4, 14, 1]

That one doesn't have to do with internal exceptions, it has
only to do with which of sample()'s internal algorithms gets
used.

Paul's point about potential bias is also a worry.  Here's a
full example:

"""
from random import sample
d = dict.fromkeys(range(24))
d['x'] = 'y'
count = hits = 0
while 1:
    count += 1
    hits += sample(d, 1) == ['x']
    if count % 10000 == 0:
        print count, "%.2f%%" % (100.0 * hits / count)
"""

Since len(d) == 25, I'd hope to see 'x' selected 1/25 = 4%
of the time.  Instead it gets selected 0.16% of the time
(1/25**2 -- and Paul's analysis of why is on target).


----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2006-03-29 05:07

Message:
Logged In: YES 
user_id=72053

Actually the previous comment is wrong too; 99% of the time,
sample(a,1) will return None since that's the value
connected to every key in the dictionary, i.e. it's
population[j] for every j.  The other 1% of the time, the
dict gets converted to a list, and the sample returns a key
from the dict rather than a value, which is certainly wrong.
 And you can see how the probabilities are still messed up
if the values in the dict are distinct.

I think it's ok to give up on dicts, but some warning should
about it be added to the manual unless dict-like things
somehow get detected in the code.  It would be best to test
for the object really being a sequence, but I don't know if
such a test exists.  Maybe one should be added.

I'll leave it to you guys to reopen this bug if appropriate.

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2006-03-29 04:46

Message:
Logged In: YES 
user_id=72053

I don't think the fix at 43421 is quite right, but I can't
easily test it in my current setup.  Suppose

a = dict.fromkeys(range(99) + ['x'])
b = random.sample(a,1)

99% of the time, there's no KeyError and b gets set to [j]
where j is some random integer.

1% of the time, there's a KeyError, random.sample is called
recursively, and the recursive call returns [some integer j]
99% of the time, and returns ['x'] 1% of the time.

So in total, ['x'] gets returned .01% of the time instead of
1% of the time.

I think it's better to not set result[i]=population[j]
inside the loop.  Instead, just build up the selected set
until it has enough indices; then try to make a result list
using those indices, and if there's a KeyError, convert the
population to a list and use the same selection set to make
the results.

gbrandl also correctly points out that a dict is not a
sequence type, so maybe it's ok to just punt on dicts.  But
it's obvious from the code comments that somebody once
wanted dicts to work, and it's reasonable for people to want
sets to work.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-03-29 04:17

Message:
Logged In: YES 
user_id=80475

Checked-in a fix.
See revision 43420 and 43421.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-03-29 04:11

Message:
Logged In: YES 
user_id=849994

random.sample is documented to take a sequence as its first
argument. A dict is not a sequence type.

I think you want
random.sample(a.keys(), 3)
or, for large dicts,
random.sample(a.iterkeys(), 3)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460340&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 16:05:26 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 06:05:26 -0800
Subject: [ python-Bugs-891249 ] pickle dump argument description vague
Message-ID: <E1FPKFi-0002AQ-7n@sc8-sf-web4-b.sourceforge.net>

Bugs item #891249, was opened at 2004-02-05 20:08
Message generated for change (Comment added) made by zseil
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=891249&group_id=5470

Please note that this 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: Brad Clements (bkc)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: pickle dump argument description vague

Initial Comment:
The documentation for pickle.dump()

see http://www.python.org/doc/current/lib/node64.html

dump(  	object, file[, protocol[, bin]])

implies that up to four arguments can be specified.
That bin can be specified if protocol has been
specified. The implementation actually accepts only 3
arguments, the last one being either 'protocol' or a
'bin' flag.

The text notation for this function needs to be
clarified, and the visual presentation of the argument
functions changed.

Perhaps to:

dump(  	object, file[, protocol | bin])

or

dump(  	object, file[, protocol] | [, bin])

or

dump(  	object, file[, protocol_or_bin])




----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-03-31 16:05

Message:
Logged In: YES 
user_id=1326842

The bin parameter has been consistently removed from the
docs as well as from the pickle module in revision 37966.

Resolution should be changed to fixed.

----------------------------------------------------------------------

Comment By: Irmen de Jong (irmen)
Date: 2004-11-07 20:13

Message:
Logged In: YES 
user_id=129426

There is one other thing.
The cPickle dump/dumps functions don't like the 'bin'
argument at all:
TypeError: 'bin' is an invalid keyword argument for this
function
They only accept the 'protocol' argument.

So that's another thing that should probably be changed in
cPickle (also see bug 888594), or it should probably be
mentioned in the docs, or the 'bin' argument should be
removed totally ;-)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=891249&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 16:12:01 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 06:12:01 -0800
Subject: [ python-Bugs-1461783 ] Invalid modes crash open()
Message-ID: <E1FPKM5-0006n0-Qx@sc8-sf-web2.sourceforge.net>

Bugs item #1461783, was opened at 2006-03-31 00:50
Message generated for change (Settings changed) made by splitscreen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1461783&group_id=5470

Please note that this message 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: None
Priority: 5
Submitted By: splitscreen (splitscreen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Invalid modes crash open()

Initial Comment:
The 2.5a0 interpreter can be crashed by opening a file
with an invalid mode, i.e

open("bogus", "bogus")

results in the Microsoft Visual C++ Debug Library
spewing an "assertion failed" message with the expression

("Invalid file open mode", 0) 

in the file _open.c, line 98.

Attached is a very rough patch that raises and IOError
if the open mode doesn't begin with an 'a', 'w' or 'r'
on the Windows platform. 

If this is something wrong at my end (and I feel it may
be) please let me know. I'd be happy to offer any more
information.

BTW, I'm using Microsoft Visual Studio 2005.

Thanks,
Matt

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1461783&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 16:13:32 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 06:13:32 -0800
Subject: [ python-Bugs-891249 ] pickle dump argument description vague
Message-ID: <E1FPKNY-0006ui-1d@sc8-sf-web2.sourceforge.net>

Bugs item #891249, was opened at 2004-02-05 19:08
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=891249&group_id=5470

Please note that this 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: Brad Clements (bkc)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: pickle dump argument description vague

Initial Comment:
The documentation for pickle.dump()

see http://www.python.org/doc/current/lib/node64.html

dump(  	object, file[, protocol[, bin]])

implies that up to four arguments can be specified.
That bin can be specified if protocol has been
specified. The implementation actually accepts only 3
arguments, the last one being either 'protocol' or a
'bin' flag.

The text notation for this function needs to be
clarified, and the visual presentation of the argument
functions changed.

Perhaps to:

dump(  	object, file[, protocol | bin])

or

dump(  	object, file[, protocol] | [, bin])

or

dump(  	object, file[, protocol_or_bin])




----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-31 14:13

Message:
Logged In: YES 
user_id=849994

Python 2.5 docs don't include the "bin" parameter any more.

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-03-31 14:05

Message:
Logged In: YES 
user_id=1326842

The bin parameter has been consistently removed from the
docs as well as from the pickle module in revision 37966.

Resolution should be changed to fixed.

----------------------------------------------------------------------

Comment By: Irmen de Jong (irmen)
Date: 2004-11-07 19:13

Message:
Logged In: YES 
user_id=129426

There is one other thing.
The cPickle dump/dumps functions don't like the 'bin'
argument at all:
TypeError: 'bin' is an invalid keyword argument for this
function
They only accept the 'protocol' argument.

So that's another thing that should probably be changed in
cPickle (also see bug 888594), or it should probably be
mentioned in the docs, or the 'bin' argument should be
removed totally ;-)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=891249&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 16:22:41 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 06:22:41 -0800
Subject: [ python-Bugs-1391872 ] floating point literals don't work in non-US
	locale in 2.5
Message-ID: <E1FPKWP-0002Fv-Aw@sc8-sf-web5.sourceforge.net>

Bugs item #1391872, was opened at 2005-12-28 12:01
Message generated for change (Comment added) made by ivilata
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1391872&group_id=5470

Please note that this message 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: Fredrik Lundh (effbot)
Assigned to: Neal Norwitz (nnorwitz)
Summary: floating point literals don't work in non-US locale in 2.5

Initial Comment:
According to reports on comp.lang.python, the current 
SVN trunk fails to handle floating point literals if 
the locale is changed:

>>> import locale 
>>> locale.setlocale(locale.LC_ALL, '') 
'German_Germany.1252' 
>>> 3.141592 
3.0 

This works just fine in 2.4.2.

See the later portions of the thread "build 
curiosities of svn head (on WinXP)" for more details:

http://groups.google.com/group/comp.lang.python/browse_
frm/thread/226584dd47047bb6/e609cb1a0d47e98f

----------------------------------------------------------------------

Comment By: Ivan Vilata i Balaguer (ivilata)
Date: 2006-03-31 16:22

Message:
Logged In: YES 
user_id=1064183

I have tried this under r43476, with ca_ES.UTF-8 locale, and
it seems to work right::

  Python 2.5a0 (trunk:43476, Mar 31 2006, 15:46:07) 
  [GCC 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9)]
on linux2
  Type "help", "copyright", "credits" or "license" for more
information.
  >>> import locale
  >>> 3.141592
  3.1415920000000002
  >>> locale.setlocale(locale.LC_ALL, '')
  'ca_ES.UTF-8'
  >>> 3.141592
  3.1415920000000002
  >>> 


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-20 09:02

Message:
Logged In: YES 
user_id=33168

Keeping open as a reminder to fix the regression tests
running  on the PSF box every 12 hours.  Need to have a run
in a different locale.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-20 09:11

Message:
Logged In: YES 
user_id=1188172

Neal, you checked in a workaround in test__locale for eu_ES.
Can this be closed then?

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2006-01-19 08:12

Message:
Logged In: YES 
user_id=357491

This still fails on OS X 10.4.4:

AssertionError: using eval('3.14') failed for eu_ES

This is using rev. 42094.

----------------------------------------------------------------------

Comment By: Fredrik Lundh (effbot)
Date: 2005-12-29 21:37

Message:
Logged In: YES 
user_id=38376

Verified and fixed in SVN.  Assinging to Neal, in case
he wants to add an extra locale test pass to his build
robot.

----------------------------------------------------------------------

Comment By: Fredrik Lundh (effbot)
Date: 2005-12-29 19:52

Message:
Logged In: YES 
user_id=38376

Looks good to me.  I'll check this in shortly.

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2005-12-29 09:22

Message:
Logged In: YES 
user_id=55188

The new patch tests it along with other locale-dependent 
tests on test__locale. How about this?

----------------------------------------------------------------------

Comment By: Fredrik Lundh (effbot)
Date: 2005-12-28 20:00

Message:
Logged In: YES 
user_id=38376

I'm not sure you can make too many assumptions about
the locale in the test suite, but I'm pretty sure that
it would be a good idea to let your "build robot" run
the test suite twice; once with the standard C locale,
and once with a non-US locale (e.g. sv_SE.utf8 which
does include some odd characters, different date and
money formats, and a decimal comma).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-12-28 19:16

Message:
Logged In: YES 
user_id=33168

Wow, I thought for sure I broke it with my recent patch to remove support for 
hex floats.  But it looks like just an AST problem (which I can be blamed for 
too :-).  The patch looks fine, but could you add tests so this doesn't happen 
again.  Thanks!

I'll be back in a week and try to fix it then if no one gets back to it.

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2005-12-28 15:04

Message:
Logged In: YES 
user_id=55188

Okay. Here's a fix.

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2005-12-28 14:41

Message:
Logged In: YES 
user_id=55188

This looks like a bug introduced by AST import;
r39757 is okay but r39762 has such an error.

----------------------------------------------------------------------

Comment By: Fredrik Lundh (effbot)
Date: 2005-12-28 12:02

Message:
Logged In: YES 
user_id=38376

I just confirmed this on Unix:

$ export LANG=sv_SE.utf8
$ ./python
Python 2.5a0 (41806M, Dec 25 2005, 12:12:29)
[GCC 2.96 20000731 (Red Hat Linux 7.2 2.96-112.7.2)] on 
linux2
Type "help", "copyright", "credits" or "license" for more 
information.
>>> 3.14
3.1400000000000001
>>> import locale
>>> locale.setlocale(locale.LC_ALL, "")
'sv_SE.utf8'
>>> 3.14
3.0
>>>


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1391872&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 16:35:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 06:35:23 -0800
Subject: [ python-Bugs-1461610 ] xmlrpclib.binary doesn't exist
Message-ID: <E1FPKih-00036t-O4@sc8-sf-web5.sourceforge.net>

Bugs item #1461610, was opened at 2006-03-30 19:52
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1461610&group_id=5470

Please note that this 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: Chris AtLee (catlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: xmlrpclib.binary doesn't exist

Initial Comment:
The current 2.4 and 2.5 docs mention that the xmlrpclib
has a function
called binary which converts any python value to a
Binary object.

However, this function does not exist in either 2.4.3
or 2.5.

The Binary constructor accepts a data parameter, so I
would say just
remove mention of the binary function from the docs and
leave the
implementation as-is.


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-31 14:35

Message:
Logged In: YES 
user_id=849994

Removed from documentation.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1461610&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 16:50:09 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 06:50:09 -0800
Subject: [ python-Bugs-960340 ] Poor documentation of new-style classes
Message-ID: <E1FPKwz-00043K-5X@sc8-sf-web5.sourceforge.net>

Bugs item #960340, was opened at 2004-05-25 21:30
Message generated for change (Comment added) made by zseil
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=960340&group_id=5470

Please note that this 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: Hallvard B Furuseth (hfuru)
Assigned to: Nobody/Anonymous (nobody)
Summary: Poor documentation of new-style classes

Initial Comment:
The Python Reference Manual (info file python-ref)
talks a lot about new-style classes, but does
not say what they are, except in a brief note
buried in node 'Coercion rules'.  The library
reference does say that object() creates such
classes, that too lacks a way to look up
'new-style classes' and find object().

Also, since 'object' is a type, it seems strange
that the Library Reference has it in the
'Built-in Functions' node instead of a node
about (callable) types.  The same applies to
several other types.  If you want to keep them
there, at least add index entries for them in
the Class-Exception-Object Index.

This refers to the doc in info-2.3.3.tar.bz2
from <http://docs.python.org/download.html>.


----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-03-31 16:50

Message:
Logged In: YES 
user_id=1326842

This was fixed in revision 41814, when a section
titled New-style and classic classes was added
to the reference manual. See:
http://docs.python.org/dev/ref/node33.html
This bug should be closed and resolution changed to fixed.

----------------------------------------------------------------------

Comment By: Hallvard B Furuseth (hfuru)
Date: 2004-06-01 20:37

Message:
Logged In: YES 
user_id=726647

Index to the language reference, yes.  And I think the
types of classes should be lifted to the header of a
paragraph.  Maybe just something like this, before
the Programmer's note:

New-style vs. old-style/classic classes:
Subclasses of 'object' are called new-style classes, other
classes are called old-style or classic classes.  Note
that all standard types such as 'int' and 'dict' are
subclasses of 'object'.  [If that latest part is true.
It seems to be about right, anyway.]

Maybe you had better also explain here or in section 3.1
(Objects, values and types) that not all objects are
subclasses of 'object'.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-05-26 15:48

Message:
Logged In: YES 
user_id=764593

That's a start, but I do think "classic class", "old class", and 
"new-style class" should show up in the index to the language 
reference as well.

One obvious (but perhaps not sufficient?) place is the 
programmers note at the bottom of 7.6, class definitions.  
<URL: http://www.python.org/dev/doc/devel/ref/class.html >

Just change:

"For new-style classes, descriptors ..."

to:

"For new-style classes (those inheriting from object), 
descriptors ..."

The language lawyer reference also seems like the right place 
to list all the differences between classic and new classes, but 
I am less certain how to do that properly.  (And it starts to be 
an Enhancement request.)


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-05-26 06:45

Message:
Logged In: YES 
user_id=80475

The glossary in the tutorial was added to meet this need.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-05-26 00:13

Message:
Logged In: YES 
user_id=764593

object() doesn't create a new-style class; it creates an 
instance of class object.

Note that the definition of a new-style class is just a class 
inheriting from object, so object itself is a new-style class.

That said, the distributed documentation should probably have 
something more about "new-style" vs "old-style" classes, and 
should have a reference in the index.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=960340&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 16:56:38 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 06:56:38 -0800
Subject: [ python-Bugs-1018315 ] __new__ not defined?
Message-ID: <E1FPL3G-0000LU-9v@sc8-sf-web1.sourceforge.net>

Bugs item #1018315, was opened at 2004-08-28 22:59
Message generated for change (Comment added) made by zseil
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1018315&group_id=5470

Please note that this 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: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: __new__ not defined?

Initial Comment:
I can't find __new__ in the index for either the Language 
Reference Manual or Library Reference Manual.  Poking 
around I did find it mentioned in ext/newtypes.tex, but
without any details.  I'd submit something, but I don't
know at this point how to use it.


----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-03-31 16:56

Message:
Logged In: YES 
user_id=1326842

This is a duplicate of a bug 1156412, which was already
fixed.
This bug should be closed and resolution changed to closed.

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-09-22 04:49

Message:
Logged In: YES 
user_id=1038590

I had the same problem when trying to convert Decimal to use
__new__ instead of __init__.

The only info I could find was
http://www.python.org/2.2.3/descrintro.html.

Which actually does a very good job of explaining how
new-style classes work. The only problem is that it is on
the website, but NOT referenced in the docs.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1018315&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 17:01:28 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 07:01:28 -0800
Subject: [ python-Bugs-1018315 ] __new__ not defined?
Message-ID: <E1FPL7w-0004kG-4R@sc8-sf-web5.sourceforge.net>

Bugs item #1018315, was opened at 2004-08-28 22:59
Message generated for change (Comment added) made by zseil
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1018315&group_id=5470

Please note that this 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: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: __new__ not defined?

Initial Comment:
I can't find __new__ in the index for either the Language 
Reference Manual or Library Reference Manual.  Poking 
around I did find it mentioned in ext/newtypes.tex, but
without any details.  I'd submit something, but I don't
know at this point how to use it.


----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-03-31 17:01

Message:
Logged In: YES 
user_id=1326842

Some more details: __new__ is now documented in reference
manual, http://docs.python.org/dev/ref/customization.html.

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-03-31 16:56

Message:
Logged In: YES 
user_id=1326842

This is a duplicate of a bug 1156412, which was already
fixed.
This bug should be closed and resolution changed to closed.

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-09-22 04:49

Message:
Logged In: YES 
user_id=1038590

I had the same problem when trying to convert Decimal to use
__new__ instead of __init__.

The only info I could find was
http://www.python.org/2.2.3/descrintro.html.

Which actually does a very good job of explaining how
new-style classes work. The only problem is that it is on
the website, but NOT referenced in the docs.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1018315&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 17:02:22 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 07:02:22 -0800
Subject: [ python-Bugs-1462152 ] Python does not check for POSIX compliant
	open() modes
Message-ID: <E1FPL8o-0001fE-UO@sc8-sf-web2.sourceforge.net>

Bugs item #1462152, was opened at 2006-03-31 15: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=1462152&group_id=5470

Please note that this message 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: splitscreen (splitscreen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python does not check for POSIX compliant open() modes

Initial Comment:
Python does not check for POSIX-compliant modes when
passing them to open() and fopen().

According to the POSIX standard all modes should start
with either an 'a', 'r' or 'w'.

This patch implements this check in the
check_the_mode() function of fileobject.c and a test
has been modified in the test_file.py test.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462152&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 17:03:47 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 07:03:47 -0800
Subject: [ python-Bugs-1451503 ] os.startfile() still doesn't work with
	Unicode filenames
Message-ID: <E1FPLAB-0001PN-WF@sc8-sf-web3.sourceforge.net>

Bugs item #1451503, was opened at 2006-03-16 18:08
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451503&group_id=5470

Please note that this 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: roee88 (roee88)
>Assigned to: Martin v. L??wis (loewis)
Summary: os.startfile() still doesn't work with Unicode filenames

Initial Comment:
>From 2.4.2 changelog:
>>>Bug #1007046: os.startfile() did not accept 
unicode strings encoded in the file system encoding. 

If the filename is unicode type and the encoding 
isn't the default system encoding, all "unknown" (to 
system encoding) characters are replaced by "?".
This is causing the os.startfile() to fail with 
WindowsError: [Errno2] 
Because the filename doesn't really have the "?".

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-31 15:03

Message:
Logged In: YES 
user_id=849994

Attaching patch. Please check.

----------------------------------------------------------------------

Comment By: roee88 (roee88)
Date: 2006-03-22 12:00

Message:
Logged In: YES 
user_id=1111143

Sorry, but I can't work on a patch.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-03-19 10:49

Message:
Logged In: YES 
user_id=21627

Well, it does work on Unicode strings when all characters
from the string come from the system code page; this got
implemented in response to bug #1007046.

To fix this, the implementation should use ShellExecuteW
(except on Win9x). Would you like to work on a patch?

As a work-around, change your system code page so your file
names are supported.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451503&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 17:04:27 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 07:04:27 -0800
Subject: [ python-Bugs-1018315 ] __new__ not defined?
Message-ID: <E1FPLAp-0000rX-V0@sc8-sf-web1.sourceforge.net>

Bugs item #1018315, was opened at 2004-08-28 20:59
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1018315&group_id=5470

Please note that this 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: Duplicate
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: __new__ not defined?

Initial Comment:
I can't find __new__ in the index for either the Language 
Reference Manual or Library Reference Manual.  Poking 
around I did find it mentioned in ext/newtypes.tex, but
without any details.  I'd submit something, but I don't
know at this point how to use it.


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-31 15:04

Message:
Logged In: YES 
user_id=849994

Closing as a Duplicate. Thanks, zseil!

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-03-31 15:01

Message:
Logged In: YES 
user_id=1326842

Some more details: __new__ is now documented in reference
manual, http://docs.python.org/dev/ref/customization.html.

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-03-31 14:56

Message:
Logged In: YES 
user_id=1326842

This is a duplicate of a bug 1156412, which was already
fixed.
This bug should be closed and resolution changed to closed.

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-09-22 02:49

Message:
Logged In: YES 
user_id=1038590

I had the same problem when trying to convert Decimal to use
__new__ instead of __init__.

The only info I could find was
http://www.python.org/2.2.3/descrintro.html.

Which actually does a very good job of explaining how
new-style classes work. The only problem is that it is on
the website, but NOT referenced in the docs.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1018315&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 17:12:37 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 07:12:37 -0800
Subject: [ python-Bugs-960340 ] Poor documentation of new-style classes
Message-ID: <E1FPLIj-0001zN-8G@sc8-sf-web3.sourceforge.net>

Bugs item #960340, was opened at 2004-05-25 19:30
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=960340&group_id=5470

Please note that this 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: Hallvard B Furuseth (hfuru)
Assigned to: Nobody/Anonymous (nobody)
Summary: Poor documentation of new-style classes

Initial Comment:
The Python Reference Manual (info file python-ref)
talks a lot about new-style classes, but does
not say what they are, except in a brief note
buried in node 'Coercion rules'.  The library
reference does say that object() creates such
classes, that too lacks a way to look up
'new-style classes' and find object().

Also, since 'object' is a type, it seems strange
that the Library Reference has it in the
'Built-in Functions' node instead of a node
about (callable) types.  The same applies to
several other types.  If you want to keep them
there, at least add index entries for them in
the Class-Exception-Object Index.

This refers to the doc in info-2.3.3.tar.bz2
from <http://docs.python.org/download.html>.


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-31 15:12

Message:
Logged In: YES 
user_id=849994

Added index entries in 43480. All else seems to be explained
properly now.

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-03-31 14:50

Message:
Logged In: YES 
user_id=1326842

This was fixed in revision 41814, when a section
titled New-style and classic classes was added
to the reference manual. See:
http://docs.python.org/dev/ref/node33.html
This bug should be closed and resolution changed to fixed.

----------------------------------------------------------------------

Comment By: Hallvard B Furuseth (hfuru)
Date: 2004-06-01 18:37

Message:
Logged In: YES 
user_id=726647

Index to the language reference, yes.  And I think the
types of classes should be lifted to the header of a
paragraph.  Maybe just something like this, before
the Programmer's note:

New-style vs. old-style/classic classes:
Subclasses of 'object' are called new-style classes, other
classes are called old-style or classic classes.  Note
that all standard types such as 'int' and 'dict' are
subclasses of 'object'.  [If that latest part is true.
It seems to be about right, anyway.]

Maybe you had better also explain here or in section 3.1
(Objects, values and types) that not all objects are
subclasses of 'object'.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-05-26 13:48

Message:
Logged In: YES 
user_id=764593

That's a start, but I do think "classic class", "old class", and 
"new-style class" should show up in the index to the language 
reference as well.

One obvious (but perhaps not sufficient?) place is the 
programmers note at the bottom of 7.6, class definitions.  
<URL: http://www.python.org/dev/doc/devel/ref/class.html >

Just change:

"For new-style classes, descriptors ..."

to:

"For new-style classes (those inheriting from object), 
descriptors ..."

The language lawyer reference also seems like the right place 
to list all the differences between classic and new classes, but 
I am less certain how to do that properly.  (And it starts to be 
an Enhancement request.)


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-05-26 04:45

Message:
Logged In: YES 
user_id=80475

The glossary in the tutorial was added to meet this need.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-05-25 22:13

Message:
Logged In: YES 
user_id=764593

object() doesn't create a new-style class; it creates an 
instance of class object.

Note that the definition of a new-style class is just a class 
inheriting from object, so object itself is a new-style class.

That said, the distributed documentation should probably have 
something more about "new-style" vs "old-style" classes, and 
should have a reference in the index.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=960340&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 17:14:21 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 07:14:21 -0800
Subject: [ python-Bugs-947906 ] calendar.weekheader(n): n should mean chars
	not bytes
Message-ID: <E1FPLKP-0005aN-8R@sc8-sf-web5.sourceforge.net>

Bugs item #947906, was opened at 2004-05-04 20:38
Message generated for change (Comment added) made by doerwalter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=947906&group_id=5470

Please note that this message 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: Accepted
Priority: 7
Submitted By: Leonardo Rochael Almeida (rochael)
Assigned to: Nobody/Anonymous (nobody)
Summary: calendar.weekheader(n): n should mean chars not bytes

Initial Comment:
calendar.weekheader(n) is locale aware, which is good
in principle. The parameter n, however, is interpreted
as meaning bytes, not chars, which can generate broken
strings for, e.g. localized weekday names:

>>> calendar.weekheader(2)
'Mo Tu We Th Fr Sa Su'
>>> locale.setlocale(locale.LC_ALL, "pt_BR.UTF-8")
'pt_BR.UTF-8'
>>> calendar.weekheader(2)
'Se Te Qu Qu Se S\xc3 Do'

Notice how "S?bado" (Saturday) above is missing the
second utf-8 byte for the encoding of "?":

>>> u"S?".encode("utf-8")
'S\xc3\xa1'

The implementation of weekheader (and of all of
calendar.py, it seems) is based on localized 8 bit
strings. I suppose the correct fix for this bug will
involve a roundtrip thru unicode.


----------------------------------------------------------------------

>Comment By: Walter D?rwald (doerwalter)
Date: 2006-03-31 17:14

Message:
Logged In: YES 
user_id=89016

Here's a new version of the patch with documentation for the
Calendar classes and a new test. The script interface isn't
documented in the TeX file (python -mcalendar --help should
be enough).

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-07-21 21:17

Message:
Logged In: YES 
user_id=89016

The following patch doesn't fix the unicode problem, but it 
should enable us to have both 8bit and unicode calendars. It 
reimplements the calendar functionality as classes. This 
makes it possible to reuse the date calculation logic and 
extend or replace the string formatting logic. Implementing a 
unicode version would be done by subclassing TextCalendar 
and overwritting formatweekday() and formatmonthname().

The patch adds several other features:

A HTML version of a calendar can be output. (An example 
output can be found at 
http://styx.livinglogic.de/~walter/calendar/calendar.html).

The calendar module can be used as a script from the 
command line. Various options are available.

It's possible to specify the number of months per row (they 
were fixed at 3 in the old version).

If this patch is accepted I can provide documentation and 
tests.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2004-06-03 06:43

Message:
Logged In: YES 
user_id=21627

Adding an ucalendar module would be reasonable, IMO.
Introducing ustrftime is not necessary - we could just apply
the "unicode in/unicode out" procedure (i.e. if the format
is a Unicode string, return a Unicode result). The tricky
part of that is to convert the strftime result to Unicode.
We could try mbstowcs, but that would fail if the locale
doesn't use Unicode for wchar_t.

Once ucalendar is written, we could document that the
calendar module has known problems if the locale's encoding
is not Latin-1.

However, I'm not going to implement that any time soon, so
unassigning.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-06-02 21:08

Message:
Logged In: YES 
user_id=89016

Maybe we should have a second version of calendar (named 
ucalendar?) that works with unicode strings? Could those two 
modules be rewritten to use as much common functionality as 
possible? Or we could use a module global to configure 
whether str or unicode should be returned?

Most of the localization functionality in calendar seems to 
come from datetime.datetime.strftime(), so it probably would 
help to have a method datetime.datetime.ustrftime() that 
returns the formatted string as unicode (using the locale 
encoding).

Assigning to MvL as the locale/unicode expert.

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2004-05-08 01:57

Message:
Logged In: YES 
user_id=55188

I think calendar.weekheader should mean not chars nor bytes
but width.
Because the function is currectly used for fixed width
representations
of calendars.
Yes. They are same for western alphabets. But, for many of CJK
characters are in full width. So, they need only 1 character for
calendar.weekheader(2); and it's conventional in real life, too.

But, we don't have unicode.width() support to implement the
feature yet.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=947906&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 17:43:59 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 07:43:59 -0800
Subject: [ python-Bugs-1454227 ] makesetup fails to tolerate valid linker
	options
Message-ID: <E1FPLn5-000432-R8@sc8-sf-web3.sourceforge.net>

Bugs item #1454227, was opened at 2006-03-20 05:11
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1454227&group_id=5470

Please note that this 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: Works For Me
Priority: 5
Submitted By: Jeff Blaine (jblaine)
Assigned to: Nobody/Anonymous (nobody)
Summary: makesetup fails to tolerate valid linker options

Initial Comment:
Using something like the following (in Setup.local)
will generate 'bad word' when makesetup runs:

-L/whatever -Xlinker -rpath /whatever

The '/whatever' after -rpath is the bad word, yet it is
completely valid syntax.

I have to edit makesetup to get it to tolerate library
directories and add them to $libs.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-31 15:43

Message:
Logged In: YES 
user_id=849994

I don't get such a warning with the SVN trunk.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1454227&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 17:59:26 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 07:59:26 -0800
Subject: [ python-Bugs-1447885 ] traceback.format_exception_only() and
	SyntaxError
Message-ID: <E1FPM22-00054D-Ok@sc8-sf-web3.sourceforge.net>

Bugs item #1447885, was opened at 2006-03-11 13:46
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1447885&group_id=5470

Please note that this message 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: 5
Submitted By: Remy Blank (remyblank)
Assigned to: Nobody/Anonymous (nobody)
Summary: traceback.format_exception_only() and SyntaxError

Initial Comment:
There is a special case in
traceback.format_exception_only() for SyntaxError so
that the location of the syntax error is printed.
Unfortunately, the test is written so that it only
works with SyntaxError, but not for children of
SyntaxError, e.g. IndentationError.

OTOH, the interpreter prints the correct output if the
exception is allowed to terminate the program.

I have attached a test case that shows the difference
in output. With the current traceback.py module, the
output is different:

joe at pat py $ ./testSyntaxError.py
Traceback (most recent call last):
  File "./testSyntaxError.py", line 7, in ?
    import SyntaxErr
IndentationError: expected an indented block
(SyntaxErr.py, line 2)

joe at pat py $ ./testSyntaxError.py raise
Traceback (most recent call last):
  File "./testSyntaxError.py", line 7, in ?
    import SyntaxErr
  File "/home/joe/tmp/py/SyntaxErr.py", line 2
    class OtherClass:
        ^
IndentationError: expected an indented block

There's a second file that is needed for the test case,
I'll attach it as well.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-31 15:59

Message:
Logged In: YES 
user_id=849994

Fixed in rev. 43486. Thanks!

----------------------------------------------------------------------

Comment By: Remy Blank (remyblank)
Date: 2006-03-11 13:51

Message:
Logged In: YES 
user_id=568100

This patch makes both the output of the interpreter and the
output generated by format_exception_only() identical.

----------------------------------------------------------------------

Comment By: Remy Blank (remyblank)
Date: 2006-03-11 13:47

Message:
Logged In: YES 
user_id=568100

This file generates the IndentationError.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1447885&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 18:06:10 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 08:06:10 -0800
Subject: [ python-Bugs-960340 ] Poor documentation of new-style classes
Message-ID: <E1FPM8Y-0000Y4-9y@sc8-sf-web5.sourceforge.net>

Bugs item #960340, was opened at 2004-05-25 15:30
Message generated for change (Comment added) made by jimjjewett
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=960340&group_id=5470

Please note that this 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: Hallvard B Furuseth (hfuru)
Assigned to: Nobody/Anonymous (nobody)
Summary: Poor documentation of new-style classes

Initial Comment:
The Python Reference Manual (info file python-ref)
talks a lot about new-style classes, but does
not say what they are, except in a brief note
buried in node 'Coercion rules'.  The library
reference does say that object() creates such
classes, that too lacks a way to look up
'new-style classes' and find object().

Also, since 'object' is a type, it seems strange
that the Library Reference has it in the
'Built-in Functions' node instead of a node
about (callable) types.  The same applies to
several other types.  If you want to keep them
there, at least add index entries for them in
the Class-Exception-Object Index.

This refers to the doc in info-2.3.3.tar.bz2
from <http://docs.python.org/download.html>.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2006-03-31 11:06

Message:
Logged In: YES 
user_id=764593

Slight typo at http://docs.python.org/dev/ref/node33.html

manuel ==> manual

The spelling of "flavour" (rather than "flavor") also 
sticks out, but I can't say its wrong; I just hadn't seen 
British spelling on other words in the documents.


----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-03-31 10:12

Message:
Logged In: YES 
user_id=849994

Added index entries in 43480. All else seems to be explained
properly now.

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-03-31 09:50

Message:
Logged In: YES 
user_id=1326842

This was fixed in revision 41814, when a section
titled New-style and classic classes was added
to the reference manual. See:
http://docs.python.org/dev/ref/node33.html
This bug should be closed and resolution changed to fixed.

----------------------------------------------------------------------

Comment By: Hallvard B Furuseth (hfuru)
Date: 2004-06-01 14:37

Message:
Logged In: YES 
user_id=726647

Index to the language reference, yes.  And I think the
types of classes should be lifted to the header of a
paragraph.  Maybe just something like this, before
the Programmer's note:

New-style vs. old-style/classic classes:
Subclasses of 'object' are called new-style classes, other
classes are called old-style or classic classes.  Note
that all standard types such as 'int' and 'dict' are
subclasses of 'object'.  [If that latest part is true.
It seems to be about right, anyway.]

Maybe you had better also explain here or in section 3.1
(Objects, values and types) that not all objects are
subclasses of 'object'.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-05-26 09:48

Message:
Logged In: YES 
user_id=764593

That's a start, but I do think "classic class", "old class", and 
"new-style class" should show up in the index to the language 
reference as well.

One obvious (but perhaps not sufficient?) place is the 
programmers note at the bottom of 7.6, class definitions.  
<URL: http://www.python.org/dev/doc/devel/ref/class.html >

Just change:

"For new-style classes, descriptors ..."

to:

"For new-style classes (those inheriting from object), 
descriptors ..."

The language lawyer reference also seems like the right place 
to list all the differences between classic and new classes, but 
I am less certain how to do that properly.  (And it starts to be 
an Enhancement request.)


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-05-26 00:45

Message:
Logged In: YES 
user_id=80475

The glossary in the tutorial was added to meet this need.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-05-25 18:13

Message:
Logged In: YES 
user_id=764593

object() doesn't create a new-style class; it creates an 
instance of class object.

Note that the definition of a new-style class is just a class 
inheriting from object, so object itself is a new-style class.

That said, the distributed documentation should probably have 
something more about "new-style" vs "old-style" classes, and 
should have a reference in the index.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=960340&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 16:38:34 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 06:38:34 -0800
Subject: [ python-Bugs-1457312 ] AttributeError in upload_file on interrupted
	connection
Message-ID: <E1FPKlm-0008CW-0y@sc8-sf-web3.sourceforge.net>

Bugs item #1457312, was opened at 2006-03-23 21:33
Message generated for change (Settings changed) made by gbrandl
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: Open
Resolution: None
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.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457312&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 18:20:13 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 08:20:13 -0800
Subject: [ python-Bugs-1461855 ] fdopen() not guaranteed to have Python
	semantics
Message-ID: <E1FPMM9-0003If-3L@sc8-sf-web6.sourceforge.net>

Bugs item #1461855, was opened at 2006-03-31 06:37
Message generated for change (Comment added) made by titty
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1461855&group_id=5470

Please note that this message 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: John Levon (movement)
Assigned to: Nobody/Anonymous (nobody)
Summary: fdopen() not guaranteed to have Python semantics

Initial Comment:
The specification for seek() says:

 seek(  	offset[, whence])
    Note that if the file is opened for appending (mode
'a' or 'a+'), any seek() operations will be undone at
the next write.

Consider operating on an fdopen()ed file. The Python
source simply calls into the OS-provided fdopen():

http://pxr.openlook.org/pxr/source/Modules/posixmodule.c#3530

However, the POSIX standard

http://www.opengroup.org/onlinepubs/009695399/functions/fdopen.html

says:

"Although not explicitly required by this volume of
IEEE Std 1003.1-2001, a good implementation of append
(a) mode would cause the O_APPEND flag to be set."

Thus, to ensure Python semantics, Python's fdopen()
must perform an fcntl() to ensure O_APPEND is set.

For example, on Solaris, this optional O_APPEND
behaviour is not applied:

http://cvs.opensolaris.org/source/xref/on/usr/src/lib/libc/port/stdio/fdopen.c?r=1.22#97

This has recently caused serious problems with the
Mercurial SCM.

----------------------------------------------------------------------

Comment By: Ralf Schmitt (titty)
Date: 2006-03-31 18:20

Message:
Logged In: YES 
user_id=17929

freebsd 4.11 shows the same behaviour.

import fcntl
import os

def test_fdopen_append():
    
    def is_append(fd):
        return bool(fcntl.fcntl(fd, fcntl.F_GETFL) &
os.O_APPEND)


    fd = os.open("foo.txt", os.O_RDWR | os.O_CREAT)
    assert fd != -1
    
    print "is_append:", is_append(fd)
    
    f=os.fdopen(fd, 'a')
    print "after fdopen is_append:", is_append(fd)

    assert is_append(fd)

test_fdopen_append()


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1461855&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 18:42:47 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 08:42:47 -0800
Subject: [ python-Bugs-1250170 ] gethostbyname(gethostname()) fails on
	misconfigured system
Message-ID: <E1FPMhz-0004gP-KW@sc8-sf-web6.sourceforge.net>

Bugs item #1250170, was opened at 2005-08-02 12:17
Message generated for change (Comment added) made by jakamkon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1250170&group_id=5470

Please note that this message 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: Tadeusz Andrzej Kadlubowski (tkadlubo)
Assigned to: Nobody/Anonymous (nobody)
Summary: gethostbyname(gethostname()) fails on misconfigured system

Initial Comment:
Hello,

I downloaded python CVS tree, compiled it and ran tests. 

Two tests failed: urllib2 and mimetools. Both in the same fashion, 
when doing socket.gethostbyname(socket.gethostname())

(It is used in mimetools.py library in line 130 and in test_urllib2.py 
test unit in line 352.)

In the interpreter it fails in the following way:

>>> import socket
>>> socket.gethostbyname(socket.gethostname())
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
socket.gaierror: (-2, 'Name or service not known')

The reason is that my hostname is bogus, no single DNS knows 
about it, and I don't see any reason to set up a DNS server on my 
box. Of course editing /etc/hosts and adding my hostname as an 
alias for 127.0.0.1 solves the problem.

Anyway I don't see any particular reason why the library shouldn't 
handle such situation i.e. when there's no connection between 
hostname and IP address.

What do you think about it? I can make a SF patch item to solve 
this issue if you like. I am quite sure adding try/catch will make it 
in both cases.

----------------------------------------------------------------------

Comment By: Kuba Ko??czyk (jakamkon)
Date: 2006-03-31 16:42

Message:
Logged In: YES 
user_id=1491175

Patch #1462230 fix it

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-30 06:33

Message:
Logged In: YES 
user_id=33168

Please provide a patch and attach it to this report.  Thanks.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1250170&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 18:48:08 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 08:48:08 -0800
Subject: [ python-Bugs-1170065 ] HTTPResponse.getheaders() returns lowercased
	header names
Message-ID: <E1FPMnA-0007fD-80@sc8-sf-web1.sourceforge.net>

Bugs item #1170065, was opened at 2005-03-24 20:24
Message generated for change (Comment added) made by tzot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170065&group_id=5470

Please note that this message 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: 1
Submitted By: Alexey Dvoychenkov (yain)
Assigned to: Nobody/Anonymous (nobody)
Summary: HTTPResponse.getheaders() returns lowercased header names

Initial Comment:
I'm not sure, if this is a bug, or intentional
behaviour, because on one hand RFC states that field
names for HTTP headers are case-insensitive, on the
other hand, it's not what server really returns to client.

Example:

print response.getheaders()

Yields this (output formatted a bit for clarity):

[('content-length', '5998'), 
('accept-ranges', 'bytes'), 
('last-modified', 'Sun, 30 Jan 2005 14:36:09 GMT'), 
('connection', 'close'), 
('etag', '"26d79-176e-41fcf0d9"'), 
('date', 'Thu, 24 Mar 2005 18:14:07 GMT'), 
('content-type', 'text/html')]



----------------------------------------------------------------------

Comment By: Christos Georgiou (tzot)
Date: 2006-03-31 19:48

Message:
Logged In: YES 
user_id=539787

I believe that since HTTP Headers are not case sensitive,
this is not a bug.
Fixing the case to either lower-case or upper-case is
typical wherever data are case insensitive, and since Python
strings are case sensitive (in this case, the header name is
being used as a key to a dict), rfc822.py selects lower-case
('suitably canonicalized') to implement case insensitivity.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170065&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 18:52:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 08:52:46 -0800
Subject: [ python-Bugs-1460564 ] Misleading documentation for socket.fromfd()
Message-ID: <E1FPMre-0008SV-JS@sc8-sf-web3.sourceforge.net>

Bugs item #1460564, was opened at 2006-03-29 04:41
Message generated for change (Comment added) made by mikeh-id
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460564&group_id=5470

Please note that this message 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: Michael Smith (mlrsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: Misleading documentation for socket.fromfd()

Initial Comment:
The socket.fromfd() method does not correctly document
what it does, in a way that is likely to cause users to
leak file descriptors.

Proposed fix:

--- Modules/socketmodule.c      2005-09-14
20:15:03.000000000 +0200
+++
/home/msmith/src/Python-2.4.2/Modules/socketmodule.c  
     2006-03-29 11:28:35.000000000 +0200
@@ -3077,7 +3077,8 @@
 PyDoc_STRVAR(fromfd_doc,
 "fromfd(fd, family, type[, proto]) -> socket object\n\
 \n\
-Create a socket object from the given file descriptor.\n\
+Duplicate the given file descriptor, and create a
socket\n\
+object from the duplicate.\r\
 The remaining arguments are the same as for socket().");

 #endif /* NO_DUP */


----------------------------------------------------------------------

Comment By: Mike Howard (mikeh-id)
Date: 2006-03-31 11:52

Message:
Logged In: YES 
user_id=1195975

I don't believe the comment is incorrect, but I think the
code should be changed to reflect the comment.

socket.fromfd() is designed to be used when stdin/out/err
are inhereted from an invoking process - most probably
inetd.  In this case, we get a file descriptor for an entity
which is really a socket and we need a socket in order to
perform i/o properly.  Consequently, I think it is an error
to dup() the fd within 'fromfd'.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460564&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 19:00:20 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 09:00:20 -0800
Subject: [ python-Bugs-615772 ] Tkinter.Misc has no __contains__ method
Message-ID: <E1FPMyy-0000X4-Ki@sc8-sf-web3.sourceforge.net>

Bugs item #615772, was opened at 2002-09-28 07:27
Message generated for change (Comment added) made by tzot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=615772&group_id=5470

Please note that this 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: Samuel Bronson (sbronson)
Assigned to: Nobody/Anonymous (nobody)
Summary: Tkinter.Misc has no __contains__ method

Initial Comment:
This can lead to a lot of confusion.

If I do `&quot;spam&quot; in widget', I get a TypeError.

Case in point: (the code in question is probably
incorrect, so I am not including it)

 /usr/tmp/python-14024DA 
   45             self.pack()
   46 
   47 if __name__ == '__main__':
   48     widget = TkLife(None, height=20, width=20)
   49     widget.loop()
widget undefined
TkLife = &lt;class __main__.TkLife&gt;
None undefined
height undefined
width undefined

 /usr/tmp/python-14024DA in
__init__(self=&lt;__main__.TkLife instance&gt;, master=None,
**kw={'height': 20, 'width': 20})
   27         self['state'] = Tkinter.DISABLED
   28 
   29         if 'cells' not in self:
   30             assert 'width' in self and 'height'
in self
   31             self['cells'] =
randomcells(self['width'], self['height'])
self = &lt;__main__.TkLife instance&gt;

 /usr/local/lib/python2.2/lib-tk/Tkinter.py in
cget(self=&lt;__main__.TkLife instance&gt;, key=0)
 1088     def cget(self, key):
 1089         &quot;&quot;&quot;Return the resource value for a KEY
given as string.&quot;&quot;&quot;
 1090         return self.tk.call(self._w, 'cget', '-'
+ key)
 1091     __getitem__ = cget
 1092     def __setitem__(self, key, value):
self = &lt;__main__.TkLife instance&gt;
self.tk = &lt;tkapp object&gt;
self.tk.call = &lt;built-in method call of tkapp object&gt;
self._w = '.135644212'
key = 0
TypeError: cannot concatenate 'str' and 'int' objects
      __doc__ =
'Inappropriate argument type.'
      __getitem__ =
&lt;bound method TypeError.__getitem__ of
&lt;exceptions.TypeError instance at 0x83202cc&gt;&gt;
      __init__ =
&lt;bound method TypeError.__init__ of
&lt;exceptions.TypeError instance at 0x83202cc&gt;&gt;
      __module__ =
'exceptions'
      __str__ =
&lt;bound method TypeError.__str__ of
&lt;exceptions.TypeError instance at 0x83202cc&gt;&gt;
      args =
(&quot;cannot concatenate 'str' and 'int' objects&quot;,)

The above is a description of an error in a Python
program.  Here is
the original traceback:

Traceback (most recent call last):
  File &quot;&lt;stdin&gt;&quot;, line 1, in ?
  File &quot;/usr/tmp/python-14024DA&quot;, line 48, in ?
    widget = TkLife(None, height=20, width=20)
  File &quot;/usr/tmp/python-14024DA&quot;, line 29, in __init__
    if 'cells' not in self:
  File &quot;/usr/local/lib/python2.2/lib-tk/Tkinter.py&quot;,
line 1090, in cget
    return self.tk.call(self._w, 'cget', '-' + key)
TypeError: cannot concatenate 'str' and 'int' objects


----------------------------------------------------------------------

Comment By: Christos Georgiou (tzot)
Date: 2006-03-31 20:00

Message:
Logged In: YES 
user_id=539787

The __setitem__ and __getitem__ methods are there only as a
convenience, not to emulate dictionaries.  The TclError
returned ("unknown option...") is clear enough to be handled
in an except clause.

I vote -0 for inclusion of such functionality (`option in
widget`) for LBYL code.

----------------------------------------------------------------------

Comment By: Jeff Epler (jepler)
Date: 2002-09-29 16:52

Message:
Logged In: YES 
user_id=2772

This patch makes Tkinter widgets more &quot;dict-like&quot;.  I don't
know if this is really desirable, I've never configured
widgets through the __setitem__ interface.

* __getitem__ raises KeyError when cget() raises TclError
* __setitem__ raises KeyError when configure() raises TclError
* implemented has_key(), __contains__(), values(), items()

Uh, I'm obviously blind here, because I don't see the
&quot;attach file&quot; section of the tracker.  Sorry, but I'll have
to inline the patch.  I'll also place it at
http://unpythonic.net/~jepler/tkinter-dictlike.diff

--- Tkinter.py.ori      Sun Sep 29 08:30:58 2002
+++ Tkinter.py  Sun Sep 29 08:46:20 2002
@@ -1096,13 +1096,27 @@
     def cget(self, key):
         &quot;&quot;&quot;Return the resource value for a KEY given as
string.&quot;&quot;&quot;
         return self.tk.call(self._w, 'cget', '-' + key)
-    __getitem__ = cget
+    def __getitem__(self, key):
+        try:
+            return self.cget(key)
+        except TclError:
+            raise KeyError, key
     def __setitem__(self, key, value):
-        self.configure({key: value})
+        try:
+            self.configure({key: value})
+        except TclError:
+            raise KeyError, key
+    def has_key(self, key):
+        return key in self.keys()
+    __contains__ = has_key
     def keys(self):
         &quot;&quot;&quot;Return a list of all resource names of this
widget.&quot;&quot;&quot;
         return map(lambda x: x[0][1:],
                self.tk.split(self.tk.call(self._w,
'configure')))
+    def values(self):
+        return [self[k] for k in self.keys()]
+    def items(self):
+        return [(k, self[k]) for k in self.keys()]
     def __str__(self):
         &quot;&quot;&quot;Return the window path name of this widget.&quot;&quot;&quot;
         return self._w


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=615772&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 19:02:48 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 09:02:48 -0800
Subject: [ python-Bugs-1461855 ] fdopen() not guaranteed to have Python
	semantics
Message-ID: <E1FPN1M-0005yI-5P@sc8-sf-web6.sourceforge.net>

Bugs item #1461855, was opened at 2006-03-31 06:37
Message generated for change (Comment added) made by titty
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1461855&group_id=5470

Please note that this message 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: John Levon (movement)
Assigned to: Nobody/Anonymous (nobody)
Summary: fdopen() not guaranteed to have Python semantics

Initial Comment:
The specification for seek() says:

 seek(  	offset[, whence])
    Note that if the file is opened for appending (mode
'a' or 'a+'), any seek() operations will be undone at
the next write.

Consider operating on an fdopen()ed file. The Python
source simply calls into the OS-provided fdopen():

http://pxr.openlook.org/pxr/source/Modules/posixmodule.c#3530

However, the POSIX standard

http://www.opengroup.org/onlinepubs/009695399/functions/fdopen.html

says:

"Although not explicitly required by this volume of
IEEE Std 1003.1-2001, a good implementation of append
(a) mode would cause the O_APPEND flag to be set."

Thus, to ensure Python semantics, Python's fdopen()
must perform an fcntl() to ensure O_APPEND is set.

For example, on Solaris, this optional O_APPEND
behaviour is not applied:

http://cvs.opensolaris.org/source/xref/on/usr/src/lib/libc/port/stdio/fdopen.c?r=1.22#97

This has recently caused serious problems with the
Mercurial SCM.

----------------------------------------------------------------------

Comment By: Ralf Schmitt (titty)
Date: 2006-03-31 19:02

Message:
Logged In: YES 
user_id=17929

patch here:
http://sourceforge.net/tracker/index.php?func=detail&aid=1462227&group_id=5470&atid=305470

----------------------------------------------------------------------

Comment By: Ralf Schmitt (titty)
Date: 2006-03-31 18:20

Message:
Logged In: YES 
user_id=17929

freebsd 4.11 shows the same behaviour.

import fcntl
import os

def test_fdopen_append():
    
    def is_append(fd):
        return bool(fcntl.fcntl(fd, fcntl.F_GETFL) &
os.O_APPEND)


    fd = os.open("foo.txt", os.O_RDWR | os.O_CREAT)
    assert fd != -1
    
    print "is_append:", is_append(fd)
    
    f=os.fdopen(fd, 'a')
    print "after fdopen is_append:", is_append(fd)

    assert is_append(fd)

test_fdopen_append()


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1461855&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 19:11:16 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 09:11:16 -0800
Subject: [ python-Bugs-947906 ] calendar.weekheader(n): n should mean chars
	not bytes
Message-ID: <E1FPN9Y-0001Fv-Ht@sc8-sf-web3.sourceforge.net>

Bugs item #947906, was opened at 2004-05-04 20:38
Message generated for change (Comment added) made by doerwalter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=947906&group_id=5470

Please note that this message 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: Accepted
Priority: 7
Submitted By: Leonardo Rochael Almeida (rochael)
Assigned to: Nobody/Anonymous (nobody)
Summary: calendar.weekheader(n): n should mean chars not bytes

Initial Comment:
calendar.weekheader(n) is locale aware, which is good
in principle. The parameter n, however, is interpreted
as meaning bytes, not chars, which can generate broken
strings for, e.g. localized weekday names:

>>> calendar.weekheader(2)
'Mo Tu We Th Fr Sa Su'
>>> locale.setlocale(locale.LC_ALL, "pt_BR.UTF-8")
'pt_BR.UTF-8'
>>> calendar.weekheader(2)
'Se Te Qu Qu Se S\xc3 Do'

Notice how "S?bado" (Saturday) above is missing the
second utf-8 byte for the encoding of "?":

>>> u"S?".encode("utf-8")
'S\xc3\xa1'

The implementation of weekheader (and of all of
calendar.py, it seems) is based on localized 8 bit
strings. I suppose the correct fix for this bug will
involve a roundtrip thru unicode.


----------------------------------------------------------------------

>Comment By: Walter D?rwald (doerwalter)
Date: 2006-03-31 19:11

Message:
Logged In: YES 
user_id=89016

Checked in calendar.diff as r43483.


----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2006-03-31 17:14

Message:
Logged In: YES 
user_id=89016

Here's a new version of the patch with documentation for the
Calendar classes and a new test. The script interface isn't
documented in the TeX file (python -mcalendar --help should
be enough).

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-07-21 21:17

Message:
Logged In: YES 
user_id=89016

The following patch doesn't fix the unicode problem, but it 
should enable us to have both 8bit and unicode calendars. It 
reimplements the calendar functionality as classes. This 
makes it possible to reuse the date calculation logic and 
extend or replace the string formatting logic. Implementing a 
unicode version would be done by subclassing TextCalendar 
and overwritting formatweekday() and formatmonthname().

The patch adds several other features:

A HTML version of a calendar can be output. (An example 
output can be found at 
http://styx.livinglogic.de/~walter/calendar/calendar.html).

The calendar module can be used as a script from the 
command line. Various options are available.

It's possible to specify the number of months per row (they 
were fixed at 3 in the old version).

If this patch is accepted I can provide documentation and 
tests.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2004-06-03 06:43

Message:
Logged In: YES 
user_id=21627

Adding an ucalendar module would be reasonable, IMO.
Introducing ustrftime is not necessary - we could just apply
the "unicode in/unicode out" procedure (i.e. if the format
is a Unicode string, return a Unicode result). The tricky
part of that is to convert the strftime result to Unicode.
We could try mbstowcs, but that would fail if the locale
doesn't use Unicode for wchar_t.

Once ucalendar is written, we could document that the
calendar module has known problems if the locale's encoding
is not Latin-1.

However, I'm not going to implement that any time soon, so
unassigning.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-06-02 21:08

Message:
Logged In: YES 
user_id=89016

Maybe we should have a second version of calendar (named 
ucalendar?) that works with unicode strings? Could those two 
modules be rewritten to use as much common functionality as 
possible? Or we could use a module global to configure 
whether str or unicode should be returned?

Most of the localization functionality in calendar seems to 
come from datetime.datetime.strftime(), so it probably would 
help to have a method datetime.datetime.ustrftime() that 
returns the formatted string as unicode (using the locale 
encoding).

Assigning to MvL as the locale/unicode expert.

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2004-05-08 01:57

Message:
Logged In: YES 
user_id=55188

I think calendar.weekheader should mean not chars nor bytes
but width.
Because the function is currectly used for fixed width
representations
of calendars.
Yes. They are same for western alphabets. But, for many of CJK
characters are in full width. So, they need only 1 character for
calendar.weekheader(2); and it's conventional in real life, too.

But, we don't have unicode.width() support to implement the
feature yet.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=947906&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 19:12:56 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 09:12:56 -0800
Subject: [ python-Bugs-1460564 ] Misleading documentation for socket.fromfd()
Message-ID: <E1FPNBA-0001KC-Ea@sc8-sf-web3.sourceforge.net>

Bugs item #1460564, was opened at 2006-03-29 11:41
Message generated for change (Comment added) made by mlrsmith
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460564&group_id=5470

Please note that this message 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: Michael Smith (mlrsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: Misleading documentation for socket.fromfd()

Initial Comment:
The socket.fromfd() method does not correctly document
what it does, in a way that is likely to cause users to
leak file descriptors.

Proposed fix:

--- Modules/socketmodule.c      2005-09-14
20:15:03.000000000 +0200
+++
/home/msmith/src/Python-2.4.2/Modules/socketmodule.c  
     2006-03-29 11:28:35.000000000 +0200
@@ -3077,7 +3077,8 @@
 PyDoc_STRVAR(fromfd_doc,
 "fromfd(fd, family, type[, proto]) -> socket object\n\
 \n\
-Create a socket object from the given file descriptor.\n\
+Duplicate the given file descriptor, and create a
socket\n\
+object from the duplicate.\r\
 The remaining arguments are the same as for socket().");

 #endif /* NO_DUP */


----------------------------------------------------------------------

>Comment By: Michael Smith (mlrsmith)
Date: 2006-03-31 19:12

Message:
Logged In: YES 
user_id=1488997

It is not an error to dup() the fd here, but it IS behaviour
that the process calling socket.fromfd() must know about. 

Also, changing this behaviour will probably break most users
of this API, since I don't see any way to use it correctly
without knowing that it does, in fact, dup() the FD (my code
reviously leaked file descriptors because I didn't know
this). Breaking existing applications is bad, hence my
suggestion to augment the documentation.

FWIW: my app receives file descriptors - which are sockets -
over a unix socket using sendmsg/recvmsg, for which I have
an extension written in C. Using socket.fromfd() on this FD
works perfectly, but I need to then os.close(fd) the
original FD to avoid leaking it.



----------------------------------------------------------------------

Comment By: Mike Howard (mikeh-id)
Date: 2006-03-31 18:52

Message:
Logged In: YES 
user_id=1195975

I don't believe the comment is incorrect, but I think the
code should be changed to reflect the comment.

socket.fromfd() is designed to be used when stdin/out/err
are inhereted from an invoking process - most probably
inetd.  In this case, we get a file descriptor for an entity
which is really a socket and we need a socket in order to
perform i/o properly.  Consequently, I think it is an error
to dup() the fd within 'fromfd'.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460564&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 19:19:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 09:19:23 -0800
Subject: [ python-Bugs-1462278 ] Coercion rules incomplete in Reference Manual
Message-ID: <E1FPNHP-0001HK-9k@sc8-sf-web1.sourceforge.net>

Bugs item #1462278, was opened at 2006-03-31 19:19
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462278&group_id=5470

Please note that this 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: ?iga Seilnacht (zseil)
Assigned to: Nobody/Anonymous (nobody)
Summary: Coercion rules incomplete in Reference Manual

Initial Comment:
The eighth item in that list says:

Exception to the previous item: 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. This is done so that a subclass can
completely override binary operators. Otherwise, the
left operand's __op__ method would always accept the
right operand: when an instance of a given class is
expected, an instance of a subclass of that class is
always acceptable.

This is not correct; subclass's __rop__() method is
called only if it has overloaded the base class's
method; example::

class A(object):
    def __add__(self, other):
        return self.__class__.__name__
    __radd__ = __add__

class B(A):pass

a = A()
b = B()
print b + a # prints B
print a + b # prints A

According to the docs B should be printed in both
cases. The change in behaviour was introduced in
revision 30639.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462278&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 19:36:40 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 09:36:40 -0800
Subject: [ python-Bugs-947906 ] calendar.weekheader(n): n should mean chars
	not bytes
Message-ID: <E1FPNY8-0007MJ-5R@sc8-sf-web4-b.sourceforge.net>

Bugs item #947906, was opened at 2004-05-04 20:38
Message generated for change (Comment added) made by doerwalter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=947906&group_id=5470

Please note that this message 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: Accepted
Priority: 7
Submitted By: Leonardo Rochael Almeida (rochael)
Assigned to: Nobody/Anonymous (nobody)
Summary: calendar.weekheader(n): n should mean chars not bytes

Initial Comment:
calendar.weekheader(n) is locale aware, which is good
in principle. The parameter n, however, is interpreted
as meaning bytes, not chars, which can generate broken
strings for, e.g. localized weekday names:

>>> calendar.weekheader(2)
'Mo Tu We Th Fr Sa Su'
>>> locale.setlocale(locale.LC_ALL, "pt_BR.UTF-8")
'pt_BR.UTF-8'
>>> calendar.weekheader(2)
'Se Te Qu Qu Se S\xc3 Do'

Notice how "S?bado" (Saturday) above is missing the
second utf-8 byte for the encoding of "?":

>>> u"S?".encode("utf-8")
'S\xc3\xa1'

The implementation of weekheader (and of all of
calendar.py, it seems) is based on localized 8 bit
strings. I suppose the correct fix for this bug will
involve a roundtrip thru unicode.


----------------------------------------------------------------------

>Comment By: Walter D?rwald (doerwalter)
Date: 2006-03-31 19:36

Message:
Logged In: YES 
user_id=89016

This second patch (calendar2.diff) adds new subclasses
LocaleTextCalendar and LocaleHTMLCalendar that output
localized month and weekday names and can cope with encodings.


----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2006-03-31 19:11

Message:
Logged In: YES 
user_id=89016

Checked in calendar.diff as r43483.


----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2006-03-31 17:14

Message:
Logged In: YES 
user_id=89016

Here's a new version of the patch with documentation for the
Calendar classes and a new test. The script interface isn't
documented in the TeX file (python -mcalendar --help should
be enough).

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-07-21 21:17

Message:
Logged In: YES 
user_id=89016

The following patch doesn't fix the unicode problem, but it 
should enable us to have both 8bit and unicode calendars. It 
reimplements the calendar functionality as classes. This 
makes it possible to reuse the date calculation logic and 
extend or replace the string formatting logic. Implementing a 
unicode version would be done by subclassing TextCalendar 
and overwritting formatweekday() and formatmonthname().

The patch adds several other features:

A HTML version of a calendar can be output. (An example 
output can be found at 
http://styx.livinglogic.de/~walter/calendar/calendar.html).

The calendar module can be used as a script from the 
command line. Various options are available.

It's possible to specify the number of months per row (they 
were fixed at 3 in the old version).

If this patch is accepted I can provide documentation and 
tests.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2004-06-03 06:43

Message:
Logged In: YES 
user_id=21627

Adding an ucalendar module would be reasonable, IMO.
Introducing ustrftime is not necessary - we could just apply
the "unicode in/unicode out" procedure (i.e. if the format
is a Unicode string, return a Unicode result). The tricky
part of that is to convert the strftime result to Unicode.
We could try mbstowcs, but that would fail if the locale
doesn't use Unicode for wchar_t.

Once ucalendar is written, we could document that the
calendar module has known problems if the locale's encoding
is not Latin-1.

However, I'm not going to implement that any time soon, so
unassigning.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-06-02 21:08

Message:
Logged In: YES 
user_id=89016

Maybe we should have a second version of calendar (named 
ucalendar?) that works with unicode strings? Could those two 
modules be rewritten to use as much common functionality as 
possible? Or we could use a module global to configure 
whether str or unicode should be returned?

Most of the localization functionality in calendar seems to 
come from datetime.datetime.strftime(), so it probably would 
help to have a method datetime.datetime.ustrftime() that 
returns the formatted string as unicode (using the locale 
encoding).

Assigning to MvL as the locale/unicode expert.

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2004-05-08 01:57

Message:
Logged In: YES 
user_id=55188

I think calendar.weekheader should mean not chars nor bytes
but width.
Because the function is currectly used for fixed width
representations
of calendars.
Yes. They are same for western alphabets. But, for many of CJK
characters are in full width. So, they need only 1 character for
calendar.weekheader(2); and it's conventional in real life, too.

But, we don't have unicode.width() support to implement the
feature yet.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=947906&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 19:41:06 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 09:41:06 -0800
Subject: [ python-Bugs-1250170 ] gethostbyname(gethostname()) fails on
	misconfigured system
Message-ID: <E1FPNcQ-0007em-7K@sc8-sf-web4-b.sourceforge.net>

Bugs item #1250170, was opened at 2005-08-02 12:17
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1250170&group_id=5470

Please note that this message 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: 5
Submitted By: Tadeusz Andrzej Kadlubowski (tkadlubo)
Assigned to: Nobody/Anonymous (nobody)
Summary: gethostbyname(gethostname()) fails on misconfigured system

Initial Comment:
Hello,

I downloaded python CVS tree, compiled it and ran tests. 

Two tests failed: urllib2 and mimetools. Both in the same fashion, 
when doing socket.gethostbyname(socket.gethostname())

(It is used in mimetools.py library in line 130 and in test_urllib2.py 
test unit in line 352.)

In the interpreter it fails in the following way:

>>> import socket
>>> socket.gethostbyname(socket.gethostname())
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
socket.gaierror: (-2, 'Name or service not known')

The reason is that my hostname is bogus, no single DNS knows 
about it, and I don't see any reason to set up a DNS server on my 
box. Of course editing /etc/hosts and adding my hostname as an 
alias for 127.0.0.1 solves the problem.

Anyway I don't see any particular reason why the library shouldn't 
handle such situation i.e. when there's no connection between 
hostname and IP address.

What do you think about it? I can make a SF patch item to solve 
this issue if you like. I am quite sure adding try/catch will make it 
in both cases.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-31 17:41

Message:
Logged In: YES 
user_id=849994

Applied patch in rev. 43490.

----------------------------------------------------------------------

Comment By: Kuba Ko??czyk (jakamkon)
Date: 2006-03-31 16:42

Message:
Logged In: YES 
user_id=1491175

Patch #1462230 fix it

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-30 06:33

Message:
Logged In: YES 
user_id=33168

Please provide a patch and attach it to this report.  Thanks.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1250170&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 19:43:21 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 09:43:21 -0800
Subject: [ python-Bugs-1445068 ] getpass.getpass queries on STDOUT not STERR
	(*nix)
Message-ID: <E1FPNeb-0007nS-Am@sc8-sf-web4-b.sourceforge.net>

Bugs item #1445068, was opened at 2006-03-07 19:48
Message generated for change (Comment added) made by splitscreen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1445068&group_id=5470

Please note that this message 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: Jon Lasser (jonlasser)
Assigned to: Nobody/Anonymous (nobody)
Summary: getpass.getpass queries on STDOUT not STERR (*nix)

Initial Comment:
Expected behavior of a *nix system would be to get the
password query on STDERR, so that (for non-interactive
applications) one can send the output of the command to
somewhere else, and not be hanging on a password
request that was never seen by the user at the
terminal. (And also so that output isn't polluted by
the password request, when parsing it via a pipeline.)

----------------------------------------------------------------------

Comment By: splitscreen (splitscreen)
Date: 2006-03-31 17:43

Message:
Logged In: YES 
user_id=1126061

Patch #1462298 fixes this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1445068&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 19:45:09 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 09:45:09 -0800
Subject: [ python-Bugs-947906 ] calendar.weekheader(n): n should mean chars
	not bytes
Message-ID: <E1FPNgL-0007v5-4t@sc8-sf-web4-b.sourceforge.net>

Bugs item #947906, was opened at 2004-05-04 20:38
Message generated for change (Comment added) made by doerwalter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=947906&group_id=5470

Please note that this message 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: Accepted
Priority: 7
Submitted By: Leonardo Rochael Almeida (rochael)
Assigned to: Nobody/Anonymous (nobody)
Summary: calendar.weekheader(n): n should mean chars not bytes

Initial Comment:
calendar.weekheader(n) is locale aware, which is good
in principle. The parameter n, however, is interpreted
as meaning bytes, not chars, which can generate broken
strings for, e.g. localized weekday names:

>>> calendar.weekheader(2)
'Mo Tu We Th Fr Sa Su'
>>> locale.setlocale(locale.LC_ALL, "pt_BR.UTF-8")
'pt_BR.UTF-8'
>>> calendar.weekheader(2)
'Se Te Qu Qu Se S\xc3 Do'

Notice how "S?bado" (Saturday) above is missing the
second utf-8 byte for the encoding of "?":

>>> u"S?".encode("utf-8")
'S\xc3\xa1'

The implementation of weekheader (and of all of
calendar.py, it seems) is based on localized 8 bit
strings. I suppose the correct fix for this bug will
involve a roundtrip thru unicode.


----------------------------------------------------------------------

>Comment By: Walter D?rwald (doerwalter)
Date: 2006-03-31 19:45

Message:
Logged In: YES 
user_id=89016

This third patch (calendar3.diff) is a variant of of the
second patch, that uses xmlcharrefreplace error handling in
the HTML calendar.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2006-03-31 19:36

Message:
Logged In: YES 
user_id=89016

This second patch (calendar2.diff) adds new subclasses
LocaleTextCalendar and LocaleHTMLCalendar that output
localized month and weekday names and can cope with encodings.


----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2006-03-31 19:11

Message:
Logged In: YES 
user_id=89016

Checked in calendar.diff as r43483.


----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2006-03-31 17:14

Message:
Logged In: YES 
user_id=89016

Here's a new version of the patch with documentation for the
Calendar classes and a new test. The script interface isn't
documented in the TeX file (python -mcalendar --help should
be enough).

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-07-21 21:17

Message:
Logged In: YES 
user_id=89016

The following patch doesn't fix the unicode problem, but it 
should enable us to have both 8bit and unicode calendars. It 
reimplements the calendar functionality as classes. This 
makes it possible to reuse the date calculation logic and 
extend or replace the string formatting logic. Implementing a 
unicode version would be done by subclassing TextCalendar 
and overwritting formatweekday() and formatmonthname().

The patch adds several other features:

A HTML version of a calendar can be output. (An example 
output can be found at 
http://styx.livinglogic.de/~walter/calendar/calendar.html).

The calendar module can be used as a script from the 
command line. Various options are available.

It's possible to specify the number of months per row (they 
were fixed at 3 in the old version).

If this patch is accepted I can provide documentation and 
tests.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2004-06-03 06:43

Message:
Logged In: YES 
user_id=21627

Adding an ucalendar module would be reasonable, IMO.
Introducing ustrftime is not necessary - we could just apply
the "unicode in/unicode out" procedure (i.e. if the format
is a Unicode string, return a Unicode result). The tricky
part of that is to convert the strftime result to Unicode.
We could try mbstowcs, but that would fail if the locale
doesn't use Unicode for wchar_t.

Once ucalendar is written, we could document that the
calendar module has known problems if the locale's encoding
is not Latin-1.

However, I'm not going to implement that any time soon, so
unassigning.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-06-02 21:08

Message:
Logged In: YES 
user_id=89016

Maybe we should have a second version of calendar (named 
ucalendar?) that works with unicode strings? Could those two 
modules be rewritten to use as much common functionality as 
possible? Or we could use a module global to configure 
whether str or unicode should be returned?

Most of the localization functionality in calendar seems to 
come from datetime.datetime.strftime(), so it probably would 
help to have a method datetime.datetime.ustrftime() that 
returns the formatted string as unicode (using the locale 
encoding).

Assigning to MvL as the locale/unicode expert.

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2004-05-08 01:57

Message:
Logged In: YES 
user_id=55188

I think calendar.weekheader should mean not chars nor bytes
but width.
Because the function is currectly used for fixed width
representations
of calendars.
Yes. They are same for western alphabets. But, for many of CJK
characters are in full width. So, they need only 1 character for
calendar.weekheader(2); and it's conventional in real life, too.

But, we don't have unicode.width() support to implement the
feature yet.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=947906&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 19:46:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 09:46:46 -0800
Subject: [ python-Bugs-1332869 ] Fatal Python error: Interpreter not
	initialized 
Message-ID: <E1FPNhu-0000Mb-3N@sc8-sf-web6.sourceforge.net>

Bugs item #1332869, was opened at 2005-10-20 01:22
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1332869&group_id=5470

Please note that this message 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: Andrew Mitchell (ajmitch)
>Assigned to: Neal Norwitz (nnorwitz)
Summary:  Fatal Python error: Interpreter not initialized 

Initial Comment:
When running 'bzr status' on Ubuntu 5.10 with python
2.4.2, I came across the error:
Fatal Python error: Interpreter not initialized
(version mismatch?)
Aborted

The bzr code in question has a __del__ method which
when invoked (eventually) imports socket (which imports
_socket), causing everything to fall over in a heap.

A backtrace is available at http://pastebin.com/399461


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-03-31 12:46

Message:
Logged In: YES 
user_id=31435

Sorry for the delay!  I didn't realize this was assigned to
me.  Note that the possiblity for problems here was already
noted in Py_Finalize():

	/* Collect garbage.  This may call finalizers; it's nice to
call these
	 * before all modules are destroyed.
	 * XXX If a __del__ or weakref callback is triggered here,
and tries to
	 * XXX import a module, bad things can happen, because
Python no
	 * XXX longer believes it's initialized.
	 * XXX     Fatal Python error: Interpreter not initialized
(version mismatch?)
	 * XXX is easy to provoke that way.  I've also seen, e.g.,
	 * XXX     Exception exceptions.ImportError: 'No module
named sha'
	 * XXX         in <function callback at 0x008F5718> ignored
	 * XXX but I'm unclear on exactly how that one happens.  In
any case,
	 * XXX I haven't seen a real-life report of either of these.
	 */
	PyGC_Collect();

I don't think it would do much harm to move "initialized =
0" down, although it's impossible to get truly concerned
about code doing imports in __del__ when the interpreter is
tearing itself down.  Note that sys exit funcs have already
been called, and signals have been disabled, by this time,
so there would still be ways for dubious __del__ code to fail.

Anyway, if you want to do this, the XXX comments reproduced
above should be changed too (e.g., deleted).

Assigning to Neal, so that he can get practice following his
new "no changes without a test case" guideline :-)

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-21 02:15

Message:
Logged In: YES 
user_id=33168

Well, what I really hope is that Tim can *make* some time to
*look* at this patch.  Feel free to long over it if you
wish. :-)

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-21 01:55

Message:
Logged In: YES 
user_id=33168

Hey Tim, I'm hoping you can take some time to long at this
patch (you too Michael and anyone else listening).

Attached is a patch which seems to fix this problem.  At
least it fixes it from Tim's example in the mail from Nov (I
think).  It moves initialized down after the GC collect.

Is this patch a good or bad thing?

Andrew, it would be interesting if you could test this patch
(you will need to rebuild python) for bzr.  I couldn't
trigger the problem from my version.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-10-20 06:09

Message:
Logged In: YES 
user_id=6656

Are you using daemon threads?

Why is a __del__ method importing things?

----------------------------------------------------------------------

Comment By: Andrew Mitchell (ajmitch)
Date: 2005-10-20 04:51

Message:
Logged In: YES 
user_id=19159

Also,  gdb did not report other modules loaded

----------------------------------------------------------------------

Comment By: Andrew Mitchell (ajmitch)
Date: 2005-10-20 04:04

Message:
Logged In: YES 
user_id=19159

Feedback in #bzr indicated that I was triggering this code:
http://pastebin.com/399491 and also something similar to
http://mail.python.org/pipermail/python-dev/2003-September/038151.html
Another example that triggers it is
http://mail.python.org/pipermail/python-dev/2003-November/040188.html
It's all a stock breezy system, no external modules, and bzr
is retrieved from running:
 rsync -av bazaar-ng.org::bazaar-ng/bzr/bzr.dev .
I was using the latest revision at the time this happened.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-20 01:39

Message:
Logged In: YES 
user_id=33168

Also, where is the bzr code and what version are you running?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-20 01:37

Message:
Logged In: YES 
user_id=33168

Are there any other extension modules in the system that are
not provided with python?  When you went into gdb did it
print a long list of dynamic modules loaded?  Can you
provide that info too?

I'm guessing this is a memory overwrite which can happen
with poorly behaved C extension modules.  You could try
running python under valgrind and see what it reports.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1332869&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 19:49:52 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 09:49:52 -0800
Subject: [ python-Bugs-1460564 ] Misleading documentation for socket.fromfd()
Message-ID: <E1FPNku-0000YW-2G@sc8-sf-web6.sourceforge.net>

Bugs item #1460564, was opened at 2006-03-29 04:41
Message generated for change (Comment added) made by mikeh-id
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460564&group_id=5470

Please note that this message 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: Michael Smith (mlrsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: Misleading documentation for socket.fromfd()

Initial Comment:
The socket.fromfd() method does not correctly document
what it does, in a way that is likely to cause users to
leak file descriptors.

Proposed fix:

--- Modules/socketmodule.c      2005-09-14
20:15:03.000000000 +0200
+++
/home/msmith/src/Python-2.4.2/Modules/socketmodule.c  
     2006-03-29 11:28:35.000000000 +0200
@@ -3077,7 +3077,8 @@
 PyDoc_STRVAR(fromfd_doc,
 "fromfd(fd, family, type[, proto]) -> socket object\n\
 \n\
-Create a socket object from the given file descriptor.\n\
+Duplicate the given file descriptor, and create a
socket\n\
+object from the duplicate.\r\
 The remaining arguments are the same as for socket().");

 #endif /* NO_DUP */


----------------------------------------------------------------------

Comment By: Mike Howard (mikeh-id)
Date: 2006-03-31 12:49

Message:
Logged In: YES 
user_id=1195975

I don't believe the comment is incorrect, but I think the
code should be changed to reflect the comment.

socket.fromfd() is designed to be used when stdin/out/err
are inhereted from an invoking process - most probably
inetd.  In this case, we get a file descriptor for an entity
which is really a socket and we need a socket in order to
perform i/o properly.  Consequently, I think it is an error
to dup() the fd within 'fromfd'.



----------------------------------------------------------------------

Comment By: Michael Smith (mlrsmith)
Date: 2006-03-31 12:12

Message:
Logged In: YES 
user_id=1488997

It is not an error to dup() the fd here, but it IS behaviour
that the process calling socket.fromfd() must know about. 

Also, changing this behaviour will probably break most users
of this API, since I don't see any way to use it correctly
without knowing that it does, in fact, dup() the FD (my code
reviously leaked file descriptors because I didn't know
this). Breaking existing applications is bad, hence my
suggestion to augment the documentation.

FWIW: my app receives file descriptors - which are sockets -
over a unix socket using sendmsg/recvmsg, for which I have
an extension written in C. Using socket.fromfd() on this FD
works perfectly, but I need to then os.close(fd) the
original FD to avoid leaking it.



----------------------------------------------------------------------

Comment By: Mike Howard (mikeh-id)
Date: 2006-03-31 11:52

Message:
Logged In: YES 
user_id=1195975

I don't believe the comment is incorrect, but I think the
code should be changed to reflect the comment.

socket.fromfd() is designed to be used when stdin/out/err
are inhereted from an invoking process - most probably
inetd.  In this case, we get a file descriptor for an entity
which is really a socket and we need a socket in order to
perform i/o properly.  Consequently, I think it is an error
to dup() the fd within 'fromfd'.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460564&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 20:00:40 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 10:00:40 -0800
Subject: [ python-Bugs-1460564 ] Misleading documentation for socket.fromfd()
Message-ID: <E1FPNvM-0004nR-A0@sc8-sf-web2.sourceforge.net>

Bugs item #1460564, was opened at 2006-03-29 04:41
Message generated for change (Comment added) made by mikeh-id
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460564&group_id=5470

Please note that this message 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: Michael Smith (mlrsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: Misleading documentation for socket.fromfd()

Initial Comment:
The socket.fromfd() method does not correctly document
what it does, in a way that is likely to cause users to
leak file descriptors.

Proposed fix:

--- Modules/socketmodule.c      2005-09-14
20:15:03.000000000 +0200
+++
/home/msmith/src/Python-2.4.2/Modules/socketmodule.c  
     2006-03-29 11:28:35.000000000 +0200
@@ -3077,7 +3077,8 @@
 PyDoc_STRVAR(fromfd_doc,
 "fromfd(fd, family, type[, proto]) -> socket object\n\
 \n\
-Create a socket object from the given file descriptor.\n\
+Duplicate the given file descriptor, and create a
socket\n\
+object from the duplicate.\r\
 The remaining arguments are the same as for socket().");

 #endif /* NO_DUP */


----------------------------------------------------------------------

Comment By: Mike Howard (mikeh-id)
Date: 2006-03-31 13:00

Message:
Logged In: YES 
user_id=1195975

I still believe that fromfd() is in error in dup'ing the
supplied file descriptor.  This is because fromfd() is
designed only for limited use and because duplication can be
handled in other ways.  It is unlikely anyone would
intentitionally close both the file descriptor and the socket.

The Library Documentation for includes the comment "This
function is rarely needed, but can be used to get or set
socket options on a socket passed to a program as standard
input or output (such as a server started by the Unix inet
daemon). The socket is assumed to be in blocking mode.
Availability: Unix."

I can't conceive of any case where it would be necessary for
this function to dup() the file descriptor which couldn't be
handled using the socket object dup() method.  Using the
socket object method would be more transparent than hiding
the dup() within fromfd() and makes the documentation
consistent.

Regarding breaking existing code:
 - I just tested multiple calls of sys.stdin/stdout.close()
and they run w/o error, so closing the socket derived from
either will not cause problems if someone closes the
underlying file descriptor.


----------------------------------------------------------------------

Comment By: Mike Howard (mikeh-id)
Date: 2006-03-31 12:49

Message:
Logged In: YES 
user_id=1195975

I don't believe the comment is incorrect, but I think the
code should be changed to reflect the comment.

socket.fromfd() is designed to be used when stdin/out/err
are inhereted from an invoking process - most probably
inetd.  In this case, we get a file descriptor for an entity
which is really a socket and we need a socket in order to
perform i/o properly.  Consequently, I think it is an error
to dup() the fd within 'fromfd'.



----------------------------------------------------------------------

Comment By: Michael Smith (mlrsmith)
Date: 2006-03-31 12:12

Message:
Logged In: YES 
user_id=1488997

It is not an error to dup() the fd here, but it IS behaviour
that the process calling socket.fromfd() must know about. 

Also, changing this behaviour will probably break most users
of this API, since I don't see any way to use it correctly
without knowing that it does, in fact, dup() the FD (my code
reviously leaked file descriptors because I didn't know
this). Breaking existing applications is bad, hence my
suggestion to augment the documentation.

FWIW: my app receives file descriptors - which are sockets -
over a unix socket using sendmsg/recvmsg, for which I have
an extension written in C. Using socket.fromfd() on this FD
works perfectly, but I need to then os.close(fd) the
original FD to avoid leaking it.



----------------------------------------------------------------------

Comment By: Mike Howard (mikeh-id)
Date: 2006-03-31 11:52

Message:
Logged In: YES 
user_id=1195975

I don't believe the comment is incorrect, but I think the
code should be changed to reflect the comment.

socket.fromfd() is designed to be used when stdin/out/err
are inhereted from an invoking process - most probably
inetd.  In this case, we get a file descriptor for an entity
which is really a socket and we need a socket in order to
perform i/o properly.  Consequently, I think it is an error
to dup() the fd within 'fromfd'.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460564&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 20:02:40 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 10:02:40 -0800
Subject: [ python-Bugs-1353269 ] poplib.POP3_SSL() class incompatible with
	socket.timeout
Message-ID: <E1FPNxI-0007zp-Jr@sc8-sf-web5.sourceforge.net>

Bugs item #1353269, was opened at 2005-11-10 16:34
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353269&group_id=5470

Please note that this message 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: Charles (melicertes)
Assigned to: Nobody/Anonymous (nobody)
Summary: poplib.POP3_SSL() class incompatible with socket.timeout

Initial Comment:
If you call socket.setdefaulttimeout() to enable
timeout mode, then create a POP3-over-SSL connection by
instantiating a poplib.POP3_SSL() object, the resulting
connection can hang because the underlying socket.ssl()
object doesn't work when timeouts are enabled.

If, after creating the POP3_SSL object, you call
object.conn.sock.setblocking(1), the hangs will not happen.

This is exactly the same bug as happened with IMAP SSL
connections, as I reported in bug #977680.

The Python documentation still does not mention that
socket SSL support is not compatible with socket
timeout support.


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-31 18:02

Message:
Logged In: YES 
user_id=849994

Fixed with said patch.

----------------------------------------------------------------------

Comment By: Arkadiusz Miskiewicz (arekm)
Date: 2005-12-14 23:31

Message:
Logged In: YES 
user_id=139606

btw. please test this patch: https://sourceforge.net/tracker
/index.php?func=detail&aid=1380952&group_id=5470&atid=305470



----------------------------------------------------------------------

Comment By: Arkadiusz Miskiewicz (arekm)
Date: 2005-12-14 22:59

Message:
Logged In: YES 
user_id=139606

It's just broken in _ssl.c.

In PySSL_SSLread() there is:

sockstate = check_socket_and_wait_for_timeout(self->Socket, 
0);

It hangs here because that function waits for new data on 
the socket but SSL layer could already read that data.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353269&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 20:03:02 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 10:03:02 -0800
Subject: [ python-Bugs-1462152 ] Python does not check for POSIX compliant
	open() modes
Message-ID: <E1FPNxe-0001PD-4w@sc8-sf-web6.sourceforge.net>

Bugs item #1462152, was opened at 2006-03-31 10: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=1462152&group_id=5470

Please note that this message 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: splitscreen (splitscreen)
>Assigned to: Georg Brandl (birkenfeld)
Summary: Python does not check for POSIX compliant open() modes

Initial Comment:
Python does not check for POSIX-compliant modes when
passing them to open() and fopen().

According to the POSIX standard all modes should start
with either an 'a', 'r' or 'w'.

This patch implements this check in the
check_the_mode() function of fileobject.c and a test
has been modified in the test_file.py test.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-03-31 13:03

Message:
Logged In: YES 
user_id=31435

There's a small danger of backward-incompatibility here,
since platforms are free to support any goofy mode
characters they like, and Python just passes on whatever the
user typed.  I understand that some MS compilers in debug
mode raise internal exceptions, but that's an MS bug and the
workaround is dead easy ("don't do that").

All that said, I'm in favor of this patch ;-).  However, if
it goes in two things are needed:

1. The error message should be more informative, like

   PyErr_Format(PyExc_ValueError, "mode argument must "
     "begin with 'w', 'r', or 'a', not '%.200s'", mode);

2. The Python docs should change to match (i.e., the
   manual should document this new restriction on mode
   strings).

WRT the test case, it's more natural to write, e.g.,

    TESTFN in s

than

    s.find(TESTFN) != -1

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462152&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 20:03:29 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 10:03:29 -0800
Subject: [ python-Bugs-1098618 ] socket.setdefaulttimeout() breaks
	smtplib.starttls()
Message-ID: <E1FPNy5-0001SA-4i@sc8-sf-web6.sourceforge.net>

Bugs item #1098618, was opened at 2005-01-08 20:24
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098618&group_id=5470

Please note that this message 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: Matthew Cowles (mdcowles)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket.setdefaulttimeout() breaks smtplib.starttls()

Initial Comment:
If you use socket.setdefaulttimeout() to set a socket 
timeout, and then do smtplib.starttls(), no data is read after 
TLS is started.

Here's a session that's as you'd expect:

>>> import smtplib
>>> s=smtplib.SMTP("smtp.example.com")
>>> s.set_debuglevel(1)
>>> s.helo()
send: 'helo mint-julep.mondoinfo.com\r\n'
reply: '250 smtpout-1.example.net\r\n'
reply: retcode (250); Msg: smtpout-1.example.net
(250, 'smtpout-1.example.net')
>>> s.starttls()
send: 'STARTTLS\r\n'
reply: '220 Ready to start TLS\r\n'
reply: retcode (220); Msg: Ready to start TLS
(220, 'Ready to start TLS')
>>> s.ehlo()
send: 'ehlo mint-julep.mondoinfo.com\r\n'
reply: '250-smtpout-1.example.net\r\n'
reply: '250-PIPELINING\r\n'
reply: '250-SIZE 32768000\r\n'
reply: '250-VRFY\r\n'
reply: '250-ETRN\r\n'
reply: '250-AUTH LOGIN PLAIN DIGEST-MD5\r\n'
reply: '250-AUTH=LOGIN PLAIN DIGEST-MD5\r\n'
reply: '250 8BITMIME\r\n'
reply: retcode (250); Msg: smtpout-1.example.net
PIPELINING
SIZE 32768000
VRFY
ETRN
AUTH LOGIN PLAIN DIGEST-MD5
AUTH=LOGIN PLAIN DIGEST-MD5
8BITMIME
(250,
 'smtpout-1.example.net\nPIPELINING\nSIZE 
32768000\nVRFY\nETRN\nAUTH LOGIN PLAIN DIGEST-
MD5\nAUTH=LOGIN PLAIN DIGEST-MD5\n8BITMIME')
>>> s.quit()
send: 'quit\r\n'
reply: '221 Bye\r\n'
reply: retcode (221); Msg: Bye

But if I set a socket timeout, I get this:

>>> import socket
>>> socket.setdefaulttimeout(30)
>>> s=smtplib.SMTP("smtp.example.com")
>>> s.set_debuglevel(1)
>>> s.helo()
send: 'helo mint-julep.mondoinfo.com\r\n'
reply: '250 smtpout-1.example.net\r\n'
reply: retcode (250); Msg: smtpout-1.example.net
(250, 'smtpout-1.example.net')
>>> s.starttls()
send: 'STARTTLS\r\n'
reply: '220 Ready to start TLS\r\n'
reply: retcode (220); Msg: Ready to start TLS
(220, 'Ready to start TLS')
>>> s.ehlo()
send: 'ehlo mint-julep.mondoinfo.com\r\n'
^CTraceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/Library/Frameworks/Python.framework/Versions/2.4/
lib/python2.4/smtplib.py", line 391, in ehlo
    (code,msg)=self.getreply()
  File "/Library/Frameworks/Python.framework/Versions/2.4/
lib/python2.4/smtplib.py", line 345, in getreply
    line = self.file.readline()
  File "/Library/Frameworks/Python.framework/Versions/2.4/
lib/python2.4/smtplib.py", line 160, in readline
    chr = self.sslobj.read(1)
KeyboardInterrupt

(I waited ten or fifteen seconds before typing the control-c.)

If I set the socket timeout back to None, it works correctly:

>>> socket.setdefaulttimeout(None)
>>> s=smtplib.SMTP("smtp.example.com")
>>> s.helo()
(250, 'smtpout-2.example.net')
>>> s.starttls()
(220, 'Ready to start TLS')
>>> s.ehlo()
(250,
 'smtpout-2.example.net\nPIPELINING\nSIZE 
32768000\nVRFY\nETRN\nAUTH LOGIN PLAIN DIGEST-
MD5\nAUTH=LOGIN PLAIN DIGEST-MD5\n8BITMIME')
>>> s.quit()


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-31 18:03

Message:
Logged In: YES 
user_id=849994

Fixed with the commit of patch #1380952.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098618&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 20:04:14 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 10:04:14 -0800
Subject: [ python-Bugs-1166206 ] SSL_pending is not used
Message-ID: <E1FPNyo-0004BN-R2@sc8-sf-web1.sourceforge.net>

Bugs item #1166206, was opened at 2005-03-18 20:18
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166206&group_id=5470

Please note that this message 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: 5
Submitted By: yawl (yawl)
Assigned to: Nobody/Anonymous (nobody)
Summary: SSL_pending is not used

Initial Comment:
I am not a Python user but use openssl a lot.
Recently I am checking implementations of non-blocking 
usage of SSL and find _ssl.c in Python.
It does a good job but I find there is an error in the code.
The problem is SSL_pending() should be called to check 
if there is data in openssl's internal buffer, otherwise a 
timeout may occur while it shouldn't.

This link explains SSL_Pending in detail:
http://www.linuxjournal.com/article/5487

And you check also check out SSL_Pending man page.


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-31 18:04

Message:
Logged In: YES 
user_id=849994

Fixed with the commit of patch #1380952.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166206&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 20:27:44 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 10:27:44 -0800
Subject: [ python-Bugs-1443328 ] Pickle protocol 2 fails on private slots.
Message-ID: <E1FPOLY-0002y4-J6@sc8-sf-web6.sourceforge.net>

Bugs item #1443328, was opened at 2006-03-05 04:18
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1443328&group_id=5470

Please note that this message 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: Daniele Varrazzo (dvarrazzo)
Assigned to: Tim Peters (tim_one)
Summary: Pickle protocol 2 fails on private slots.

Initial Comment:
The pickling protocol 2 can manage new style objects
defining __slots__ and without __dict__. Anyway it
fails when one of the slots is "private".

>>> class C1(object):
	__slots__ = ["__priv"]
	def __init__(self):
		self.__priv = 42
	def get_priv(self):
		return self.__priv

>>> C1().get_priv()
42
>>> import pickle
>>> pickle.loads(pickle.dumps(C1(), 2)).get_priv()

Traceback (most recent call last):
  File "<pyshell#258>", line 1, in -toplevel-
    pickle.loads(pickle.dumps(C1(), 2)).get_priv()
  File "<pyshell#255>", line 6, in get_priv
    return self.__priv
AttributeError: _C1__priv

of course redefining __getstate__ and __setstate__
bypasses the problem.

the cPickle module shows the same issue.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-31 18:27

Message:
Logged In: YES 
user_id=849994

Fixed with commit of patch #1462313.

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-03-27 05:50

Message:
Logged In: YES 
user_id=1326842

The bug is in the copy_reg module.
object.__reduce_ex__ calls function 
_slotnames in that module.
There is another bug when __slots__
is a single string. Examples below.

>>> import copy_reg
>>> class A(object):
...     __slots__ = ('__spam',)
...
>>> class B(object):
...     __slots__ = 'spam'
...
>>> copy_reg._slotnames(A) # should be ['_A__spam']
['__spam']
>>> copy_reg._slotnames(B) # should be ['spam']
['s', 'p', 'a', 'm']

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-03-09 08:21

Message:
Logged In: YES 
user_id=849994

Confirmed with pickle and cPickle here.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1443328&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 20:43:37 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 10:43:37 -0800
Subject: [ python-Bugs-1445068 ] getpass.getpass queries on STDOUT not STERR
	(*nix)
Message-ID: <E1FPOav-00039s-0s@sc8-sf-web4-b.sourceforge.net>

Bugs item #1445068, was opened at 2006-03-07 19:48
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1445068&group_id=5470

Please note that this message 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: 5
Submitted By: Jon Lasser (jonlasser)
Assigned to: Nobody/Anonymous (nobody)
Summary: getpass.getpass queries on STDOUT not STERR (*nix)

Initial Comment:
Expected behavior of a *nix system would be to get the
password query on STDERR, so that (for non-interactive
applications) one can send the output of the command to
somewhere else, and not be hanging on a password
request that was never seen by the user at the
terminal. (And also so that output isn't polluted by
the password request, when parsing it via a pipeline.)

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-31 18:43

Message:
Logged In: YES 
user_id=849994

Added a "stream" argument in rev. 43495.

----------------------------------------------------------------------

Comment By: splitscreen (splitscreen)
Date: 2006-03-31 17:43

Message:
Logged In: YES 
user_id=1126061

Patch #1462298 fixes this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1445068&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 20:58:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 10:58:25 -0800
Subject: [ python-Bugs-1334662 ] int(string, base) wrong answers
Message-ID: <E1FPOpF-0007f0-II@sc8-sf-web1.sourceforge.net>

Bugs item #1334662, was opened at 2005-10-22 06:13
Message generated for change (Comment added) made by ivilata
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1334662&group_id=5470

Please note that this message 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: Tim Peters (tim_one)
Assigned to: Nobody/Anonymous (nobody)
Summary: int(string, base) wrong answers

Initial Comment:
This affects all Python releases to date.  See

<http://mail.python.org/pipermail/python-dev/2005-
October/057510.html>

for discussion.  The overflow check in PyOS_strtoul() is 
too clever, and causes these wrong results on a 32-bit 
box (on a box with sizeof(long) == 8, other examples 
would fail):

int('102002022201221111211', 3) = 0
int('32244002423141', 5) = 0
int('1550104015504', 6) = 0
int('211301422354', 7) = 0
int('12068657454', 9) = 0
int('1904440554', 11) = 0
int('9ba461594', 12) = 0
int('535a79889', 13) = 0
int('2ca5b7464', 14) = 0
int('1a20dcd81', 15) = 0
int('a7ffda91', 17) = 0
int('704he7g4', 18) = 0
int('4f5aff66', 19) = 0
int('3723ai4g', 20) = 0
int('281d55i4', 21) = 0
int('1fj8b184', 22) = 0
int('1606k7ic', 23) = 0
int('mb994ag', 24) = 0
int('hek2mgl', 25) = 0
int('dnchbnm', 26) = 0
int('b28jpdm', 27) = 0
int('8pfgih4', 28) = 0
int('76beigg', 29) = 0
int('5qmcpqg', 30) = 0
int('4q0jto4', 31) = 0
int('3aokq94', 33) = 0
int('2qhxjli', 34) = 0
int('2br45qb', 35) = 0
int('1z141z4', 36) = 0


----------------------------------------------------------------------

Comment By: Ivan Vilata i Balaguer (ivilata)
Date: 2006-03-31 20:58

Message:
Logged In: YES 
user_id=1064183

There is a special case (added by Guido back in 1997, r9327)
for detecting overflows only for base 10, so that
'4294967296' does not get interpreted as 0.  It seems that
the special case is no longer needed since the adoption on
Python long integers in case of overflow.  Using the case
for base 10 for all bases (look at the attached
1334662-mystrtoul.c.diff) does the trick.  Given this script::

  print 2, int('100000000000000000000000000000000', 2)
  print 3, int('102002022201221111211', 3)
  print 4, int('10000000000000000', 4)
  print 5, int('32244002423141', 5)
  print 6, int('1550104015504', 6)
  print 7, int('211301422354', 7)
  print 8, int('40000000000', 8)
  print 9, int('12068657454', 9)
  print 10, int('4294967296', 10)
  print 11, int('1904440554', 11)
  print 12, int('9ba461594', 12)
  print 13, int('535a79889', 13)
  print 14, int('2ca5b7464', 14)
  print 15, int('1a20dcd81', 15)
  print 16, int('100000000', 16)
  print 17, int('a7ffda91', 17)
  print 18, int('704he7g4', 18)
  print 19, int('4f5aff66', 19)
  print 20, int('3723ai4g', 20)
  print 21, int('281d55i4', 21)
  print 22, int('1fj8b184', 22)
  print 23, int('1606k7ic', 23)
  print 24, int('mb994ag', 24)
  print 25, int('hek2mgl', 25)
  print 26, int('dnchbnm', 26)
  print 27, int('b28jpdm', 27)
  print 28, int('8pfgih4', 28)
  print 29, int('76beigg', 29)
  print 30, int('5qmcpqg', 30)
  print 31, int('4q0jto4', 31)
  print 32, int('4000000', 32)
  print 33, int('3aokq94', 33)
  print 34, int('2qhxjli', 34)
  print 35, int('2br45qb', 35)
  print 36, int('1z141z4', 36)

The old output is::

  2 4294967296
  3 0
  4 4294967296
  5 0
  6 0
  7 0
  8 4294967296
  9 0
  10 4294967296
  11 0
  12 0
  13 0
  14 0
  15 0
  16 4294967296
  17 0
  18 0
  19 0
  20 0
  21 0
  22 0
  23 0
  24 0
  25 0
  26 0
  27 0
  28 0
  29 0
  30 0
  31 0
  32 4294967296
  33 0
  34 0
  35 0
  36 0

And the new one::

  2 4294967296
  3 4294967296
  4 4294967296
  5 4294967296
  6 4294967296
  ...
  32 4294967296
  33 4294967296
  34 4294967296
  35 4294967296
  36 4294967296

The old bugs should be tested for in ``test_builtin.py``,
but I don't know the Python test infrastructure too well.  I
will give it a try, nonetheless.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1334662&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 21:11:55 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 11:11:55 -0800
Subject: [ python-Bugs-1462352 ] socket.ssl won't work together with
	socket.settimeout on Win
Message-ID: <E1FPP2J-0008Tj-CY@sc8-sf-web1.sourceforge.net>

Bugs item #1462352, was opened at 2006-03-31 19: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=1462352&group_id=5470

Please note that this 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: 6
Submitted By: Georg Brandl (gbrandl)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket.ssl won't work together with socket.settimeout on Win

Initial Comment:
Symptoms:

>>> import socket
>>> s = socket.socket()
>>> s.settimeout(30.0)
>>> s.connect(("gmail.org", 995))
>>> ss = socket.ssl(s)
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "C:\python24\lib\socket.py", line 74, in ssl
     return _realssl(sock, keyfile, certfile)
 socket.sslerror: (2, 'The operation did not complete
(read)')

This does not occur on Unix, where
test_socket_ssl.test_timeout runs smoothly.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462352&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 21:20:38 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 11:20:38 -0800
Subject: [ python-Bugs-1444104 ] os.open() Documentation
Message-ID: <E1FPPAk-00012z-Cb@sc8-sf-web3.sourceforge.net>

Bugs item #1444104, was opened at 2006-03-06 13:04
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1444104&group_id=5470

Please note that this 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: Feature Request
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Thomas Guettler (guettli)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.open() Documentation

Initial Comment:
Hi,

I think the note in the docu could be improved:

"""To read a ``file object'' returned by the built-in
function open() or by popen() or fdopen(), or
sys.stdin, use its read() or readline() methods."""

(I think) a better note:

"""To read a ``file object'' returned by the built-in
function open(), popen(), fdopen() or sys.stdin, use
its read() or readline() methods. You can convert the
file descriptor returned by os.open() to a file object
with [LINK os.fdopen()]"""

The same note is used for os.write().

At os.open() there should be a link to os.fdopen(), too.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-31 19:20

Message:
Logged In: YES 
user_id=849994

Added a note in rev. 43498.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1444104&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 21:23:59 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 11:23:59 -0800
Subject: [ python-Bugs-1334662 ] int(string, base) wrong answers
Message-ID: <E1FPPDz-0006WH-V1@sc8-sf-web6.sourceforge.net>

Bugs item #1334662, was opened at 2005-10-22 06:13
Message generated for change (Comment added) made by ivilata
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1334662&group_id=5470

Please note that this message 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: Tim Peters (tim_one)
Assigned to: Nobody/Anonymous (nobody)
Summary: int(string, base) wrong answers

Initial Comment:
This affects all Python releases to date.  See

<http://mail.python.org/pipermail/python-dev/2005-
October/057510.html>

for discussion.  The overflow check in PyOS_strtoul() is 
too clever, and causes these wrong results on a 32-bit 
box (on a box with sizeof(long) == 8, other examples 
would fail):

int('102002022201221111211', 3) = 0
int('32244002423141', 5) = 0
int('1550104015504', 6) = 0
int('211301422354', 7) = 0
int('12068657454', 9) = 0
int('1904440554', 11) = 0
int('9ba461594', 12) = 0
int('535a79889', 13) = 0
int('2ca5b7464', 14) = 0
int('1a20dcd81', 15) = 0
int('a7ffda91', 17) = 0
int('704he7g4', 18) = 0
int('4f5aff66', 19) = 0
int('3723ai4g', 20) = 0
int('281d55i4', 21) = 0
int('1fj8b184', 22) = 0
int('1606k7ic', 23) = 0
int('mb994ag', 24) = 0
int('hek2mgl', 25) = 0
int('dnchbnm', 26) = 0
int('b28jpdm', 27) = 0
int('8pfgih4', 28) = 0
int('76beigg', 29) = 0
int('5qmcpqg', 30) = 0
int('4q0jto4', 31) = 0
int('3aokq94', 33) = 0
int('2qhxjli', 34) = 0
int('2br45qb', 35) = 0
int('1z141z4', 36) = 0


----------------------------------------------------------------------

Comment By: Ivan Vilata i Balaguer (ivilata)
Date: 2006-03-31 21:23

Message:
Logged In: YES 
user_id=1064183

The patch I talked about is under request ID #1462361.

----------------------------------------------------------------------

Comment By: Ivan Vilata i Balaguer (ivilata)
Date: 2006-03-31 20:58

Message:
Logged In: YES 
user_id=1064183

There is a special case (added by Guido back in 1997, r9327)
for detecting overflows only for base 10, so that
'4294967296' does not get interpreted as 0.  It seems that
the special case is no longer needed since the adoption on
Python long integers in case of overflow.  Using the case
for base 10 for all bases (look at the attached
1334662-mystrtoul.c.diff) does the trick.  Given this script::

  print 2, int('100000000000000000000000000000000', 2)
  print 3, int('102002022201221111211', 3)
  print 4, int('10000000000000000', 4)
  print 5, int('32244002423141', 5)
  print 6, int('1550104015504', 6)
  print 7, int('211301422354', 7)
  print 8, int('40000000000', 8)
  print 9, int('12068657454', 9)
  print 10, int('4294967296', 10)
  print 11, int('1904440554', 11)
  print 12, int('9ba461594', 12)
  print 13, int('535a79889', 13)
  print 14, int('2ca5b7464', 14)
  print 15, int('1a20dcd81', 15)
  print 16, int('100000000', 16)
  print 17, int('a7ffda91', 17)
  print 18, int('704he7g4', 18)
  print 19, int('4f5aff66', 19)
  print 20, int('3723ai4g', 20)
  print 21, int('281d55i4', 21)
  print 22, int('1fj8b184', 22)
  print 23, int('1606k7ic', 23)
  print 24, int('mb994ag', 24)
  print 25, int('hek2mgl', 25)
  print 26, int('dnchbnm', 26)
  print 27, int('b28jpdm', 27)
  print 28, int('8pfgih4', 28)
  print 29, int('76beigg', 29)
  print 30, int('5qmcpqg', 30)
  print 31, int('4q0jto4', 31)
  print 32, int('4000000', 32)
  print 33, int('3aokq94', 33)
  print 34, int('2qhxjli', 34)
  print 35, int('2br45qb', 35)
  print 36, int('1z141z4', 36)

The old output is::

  2 4294967296
  3 0
  4 4294967296
  5 0
  6 0
  7 0
  8 4294967296
  9 0
  10 4294967296
  11 0
  12 0
  13 0
  14 0
  15 0
  16 4294967296
  17 0
  18 0
  19 0
  20 0
  21 0
  22 0
  23 0
  24 0
  25 0
  26 0
  27 0
  28 0
  29 0
  30 0
  31 0
  32 4294967296
  33 0
  34 0
  35 0
  36 0

And the new one::

  2 4294967296
  3 4294967296
  4 4294967296
  5 4294967296
  6 4294967296
  ...
  32 4294967296
  33 4294967296
  34 4294967296
  35 4294967296
  36 4294967296

The old bugs should be tested for in ``test_builtin.py``,
but I don't know the Python test infrastructure too well.  I
will give it a try, nonetheless.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1334662&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 21:53:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 11:53:25 -0800
Subject: [ python-Bugs-1177964 ] Iterator on Fileobject gives no MemoryError
Message-ID: <E1FPPgT-00039z-DM@sc8-sf-web3.sourceforge.net>

Bugs item #1177964, was opened at 2005-04-06 13:55
Message generated for change (Comment added) made by catlee
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1177964&group_id=5470

Please note that this message 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: 7
Submitted By: Folke Lemaitre (zypher)
Assigned to: Nobody/Anonymous (nobody)
Summary: Iterator on Fileobject gives no MemoryError

Initial Comment:
The following problem has only been tested on linux.
Suppose at a certain time that your machine can
allocate a maximum of X megabytes of memory. Allocating
more than X should result in python MemoryErrors. Also
suppose you have a file containing one big line taking
more than X bytes (Large binary file for example).
In this case, if you read lines from a file through the
file objects iterator, you do NOT get the expected
MemoryError as result, but an empty list.

To reproduce, create a file twice as big as your
machines memory and disable the swap.

If you run the following code:
#    import os.path
#
#    def test(input):
#        print "Testing %s (%sMB)"%(repr(input),
os.path.getsize(input)/(1024.0*1024.0))
#        count = 0
#        for line in open(input):
#            count = count + 1
#       print "  >> Total Number of Lines: %s"%count
#
#    if __name__ == "__main__":
#        test('test.small')
#        test('test.big')

you'll get something like:
# folke at wladimir devel $ python2.4 bug.py
# Testing 'test.small' (20.0MB)
#   >> Total Number of Lines: 1
# Testing 'test.big' (2000.0MB)
#   >> Total Number of Lines: 0



----------------------------------------------------------------------

Comment By: Chris AtLee (catlee)
Date: 2006-03-31 14:53

Message:
Logged In: YES 
user_id=186532

This can be fixed by having the readahead method (used by
readahead_get_line_skip, used by file_iternext) raising a
MemoryError if it can't allocate enough room for the line.

Index: Objects/fileobject.c
===================================================================
--- Objects/fileobject.c        (revision 43486)
+++ Objects/fileobject.c        (working copy)
@@ -1797,7 +1797,8 @@

 /* Make sure that file has a readahead buffer with at least
one byte
    (unless at EOF) and no more than bufsize.  Returns
negative value on
-   error */
+   error.  Will raise a MemoryError if bufsize bytes cannot be
+   allocated. */
 static int
 readahead(PyFileObject *f, int bufsize)
 {
@@ -1810,6 +1811,7 @@
                        drop_readahead(f);
        }
        if ((f->f_buf = PyMem_Malloc(bufsize)) == NULL) {
+                PyErr_NoMemory();
                return -1;
        }
        Py_BEGIN_ALLOW_THREADS


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1177964&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 22:00:44 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 12:00:44 -0800
Subject: [ python-Bugs-1461855 ] fdopen() not guaranteed to have Python
	semantics
Message-ID: <E1FPPnY-000748-WE@sc8-sf-web5.sourceforge.net>

Bugs item #1461855, was opened at 2006-03-31 04:37
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1461855&group_id=5470

Please note that this message 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: John Levon (movement)
Assigned to: Nobody/Anonymous (nobody)
Summary: fdopen() not guaranteed to have Python semantics

Initial Comment:
The specification for seek() says:

 seek(  	offset[, whence])
    Note that if the file is opened for appending (mode
'a' or 'a+'), any seek() operations will be undone at
the next write.

Consider operating on an fdopen()ed file. The Python
source simply calls into the OS-provided fdopen():

http://pxr.openlook.org/pxr/source/Modules/posixmodule.c#3530

However, the POSIX standard

http://www.opengroup.org/onlinepubs/009695399/functions/fdopen.html

says:

"Although not explicitly required by this volume of
IEEE Std 1003.1-2001, a good implementation of append
(a) mode would cause the O_APPEND flag to be set."

Thus, to ensure Python semantics, Python's fdopen()
must perform an fcntl() to ensure O_APPEND is set.

For example, on Solaris, this optional O_APPEND
behaviour is not applied:

http://cvs.opensolaris.org/source/xref/on/usr/src/lib/libc/port/stdio/fdopen.c?r=1.22#97

This has recently caused serious problems with the
Mercurial SCM.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-31 20:00

Message:
Logged In: YES 
user_id=849994

Applied patch in rev. 43501, 43502.

----------------------------------------------------------------------

Comment By: Ralf Schmitt (titty)
Date: 2006-03-31 17:02

Message:
Logged In: YES 
user_id=17929

patch here:
http://sourceforge.net/tracker/index.php?func=detail&aid=1462227&group_id=5470&atid=305470

----------------------------------------------------------------------

Comment By: Ralf Schmitt (titty)
Date: 2006-03-31 16:20

Message:
Logged In: YES 
user_id=17929

freebsd 4.11 shows the same behaviour.

import fcntl
import os

def test_fdopen_append():
    
    def is_append(fd):
        return bool(fcntl.fcntl(fd, fcntl.F_GETFL) &
os.O_APPEND)


    fd = os.open("foo.txt", os.O_RDWR | os.O_CREAT)
    assert fd != -1
    
    print "is_append:", is_append(fd)
    
    f=os.fdopen(fd, 'a')
    print "after fdopen is_append:", is_append(fd)

    assert is_append(fd)

test_fdopen_append()


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1461855&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 22:03:28 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 12:03:28 -0800
Subject: [ python-Bugs-1350498 ] CVS migration not in www.python.org docs
Message-ID: <E1FPPqC-0007GU-3S@sc8-sf-web5.sourceforge.net>

Bugs item #1350498, was opened at 2005-11-07 08:52
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1350498&group_id=5470

Please note that this 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: Jim Jewett (jimjjewett)
Assigned to: Brett Cannon (bcannon)
Summary: CVS migration not in www.python.org docs

Initial Comment:
The development head has recently moved from 
CVS on sourceforge to subversion on python.org.

The www.python.org documentation still sends 
people to the sourceforge cvs via

(1)  The left hand navigation link (main page) under 
Documenation section, python project, cvs.  (The 
similar link on http://www.python.org/dev/ has been 
updated.)

(2)  The text of http://www.python.org/dev/ still says 
that deveopment takes place on sourceforge and 
sends people to the sourceforge cvs browser

It also includes a link to (sourceforge) CVS 
instructions, but no mention of subversion.

(3)  The tools link then points to http://www.python.
org/dev/tools.html, which still refers to CVS and CVS 
instructions.

(4)  The developer FAQ (http://www.python.org/dev/
devfaq.html) contains sections 1.2 and 1.4 for 
subversion (combine them?) and 1.3 for CVS -- 
section 1.3 seems to imply that the CVS tree is still 
active.


----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2006-03-31 12:03

Message:
Logged In: YES 
user_id=357491

All of the mentioned issues have been cleaned up.  Closing
as fixed.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2005-11-11 12:24

Message:
Logged In: YES 
user_id=357491

Fixed.  Thanks, Reinhold.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-11-11 00:52

Message:
Logged In: YES 
user_id=1188172

www.python.org/patches says:

We appreciate it if you send patches relative to the
`current svn tree
System Message: WARNING/2 (./index.ht, line 33); backlink
Inline interpreted text or phrase reference start-string
without end-string.

<http://www.python.org/dev/devfaq.html#subversion-svn>`_.
These are our latest sources. Even a patch relative to the
latest alpha or beta release may be way out of date.


----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2005-11-10 13:49

Message:
Logged In: YES 
user_id=357491

Everything but tools.html has been fixed.  That doc really
just needs to be replaced (see python-dev and the thread on
the dev FAQ update for any discussion on the topic) and so
fixing it is not on my list of things to do.  =)

I will leave this bug open, though, until the doc is deleted.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-11-09 21:48

Message:
Logged In: YES 
user_id=33168

Brett, did you finish updating all these docs?  Is this bug
dead now?

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-11-07 15:19

Message:
Logged In: YES 
user_id=21627

I fixed the first two. The latter will be modified later
this year, or next year.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1350498&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 22:15:19 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 12:15:19 -0800
Subject: [ python-Bugs-1461855 ] fdopen() not guaranteed to have Python
	semantics
Message-ID: <E1FPQ1f-00082y-Nq@sc8-sf-web5.sourceforge.net>

Bugs item #1461855, was opened at 2006-03-31 04:37
Message generated for change (Comment added) made by movement
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1461855&group_id=5470

Please note that this message 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: John Levon (movement)
Assigned to: Nobody/Anonymous (nobody)
Summary: fdopen() not guaranteed to have Python semantics

Initial Comment:
The specification for seek() says:

 seek(  	offset[, whence])
    Note that if the file is opened for appending (mode
'a' or 'a+'), any seek() operations will be undone at
the next write.

Consider operating on an fdopen()ed file. The Python
source simply calls into the OS-provided fdopen():

http://pxr.openlook.org/pxr/source/Modules/posixmodule.c#3530

However, the POSIX standard

http://www.opengroup.org/onlinepubs/009695399/functions/fdopen.html

says:

"Although not explicitly required by this volume of
IEEE Std 1003.1-2001, a good implementation of append
(a) mode would cause the O_APPEND flag to be set."

Thus, to ensure Python semantics, Python's fdopen()
must perform an fcntl() to ensure O_APPEND is set.

For example, on Solaris, this optional O_APPEND
behaviour is not applied:

http://cvs.opensolaris.org/source/xref/on/usr/src/lib/libc/port/stdio/fdopen.c?r=1.22#97

This has recently caused serious problems with the
Mercurial SCM.

----------------------------------------------------------------------

>Comment By: John Levon (movement)
Date: 2006-03-31 20:15

Message:
Logged In: YES 
user_id=53034

Shouldn't the documentation now state this change in
behaviour? i.e. if fdopen() fails, O_APPEND may still have
become set.

This behaviour seems a little odd to me in fact. Can't we set
fcntl after a successful fdopen()[1]? Also wouldn't it be
useful to point to the standards sentence I quote above?

[1] not sure what the ALLOW_THREAD thing does?

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-03-31 20:00

Message:
Logged In: YES 
user_id=849994

Applied patch in rev. 43501, 43502.

----------------------------------------------------------------------

Comment By: Ralf Schmitt (titty)
Date: 2006-03-31 17:02

Message:
Logged In: YES 
user_id=17929

patch here:
http://sourceforge.net/tracker/index.php?func=detail&aid=1462227&group_id=5470&atid=305470

----------------------------------------------------------------------

Comment By: Ralf Schmitt (titty)
Date: 2006-03-31 16:20

Message:
Logged In: YES 
user_id=17929

freebsd 4.11 shows the same behaviour.

import fcntl
import os

def test_fdopen_append():
    
    def is_append(fd):
        return bool(fcntl.fcntl(fd, fcntl.F_GETFL) &
os.O_APPEND)


    fd = os.open("foo.txt", os.O_RDWR | os.O_CREAT)
    assert fd != -1
    
    print "is_append:", is_append(fd)
    
    f=os.fdopen(fd, 'a')
    print "after fdopen is_append:", is_append(fd)

    assert is_append(fd)

test_fdopen_append()


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1461855&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 22:19:06 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 12:19:06 -0800
Subject: [ python-Bugs-1334662 ] int(string, base) wrong answers
Message-ID: <E1FPQ5K-0008IE-Gt@sc8-sf-web5.sourceforge.net>

Bugs item #1334662, was opened at 2005-10-22 06:13
Message generated for change (Comment added) made by ivilata
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1334662&group_id=5470

Please note that this message 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: Tim Peters (tim_one)
Assigned to: Nobody/Anonymous (nobody)
Summary: int(string, base) wrong answers

Initial Comment:
This affects all Python releases to date.  See

<http://mail.python.org/pipermail/python-dev/2005-
October/057510.html>

for discussion.  The overflow check in PyOS_strtoul() is 
too clever, and causes these wrong results on a 32-bit 
box (on a box with sizeof(long) == 8, other examples 
would fail):

int('102002022201221111211', 3) = 0
int('32244002423141', 5) = 0
int('1550104015504', 6) = 0
int('211301422354', 7) = 0
int('12068657454', 9) = 0
int('1904440554', 11) = 0
int('9ba461594', 12) = 0
int('535a79889', 13) = 0
int('2ca5b7464', 14) = 0
int('1a20dcd81', 15) = 0
int('a7ffda91', 17) = 0
int('704he7g4', 18) = 0
int('4f5aff66', 19) = 0
int('3723ai4g', 20) = 0
int('281d55i4', 21) = 0
int('1fj8b184', 22) = 0
int('1606k7ic', 23) = 0
int('mb994ag', 24) = 0
int('hek2mgl', 25) = 0
int('dnchbnm', 26) = 0
int('b28jpdm', 27) = 0
int('8pfgih4', 28) = 0
int('76beigg', 29) = 0
int('5qmcpqg', 30) = 0
int('4q0jto4', 31) = 0
int('3aokq94', 33) = 0
int('2qhxjli', 34) = 0
int('2br45qb', 35) = 0
int('1z141z4', 36) = 0


----------------------------------------------------------------------

Comment By: Ivan Vilata i Balaguer (ivilata)
Date: 2006-03-31 22:19

Message:
Logged In: YES 
user_id=1064183

Request #1462361 also contains a patch for adding some tests
to ``test_builtin.py``.  Someone with a 64-bit platform out
there?

----------------------------------------------------------------------

Comment By: Ivan Vilata i Balaguer (ivilata)
Date: 2006-03-31 21:23

Message:
Logged In: YES 
user_id=1064183

The patch I talked about is under request ID #1462361.

----------------------------------------------------------------------

Comment By: Ivan Vilata i Balaguer (ivilata)
Date: 2006-03-31 20:58

Message:
Logged In: YES 
user_id=1064183

There is a special case (added by Guido back in 1997, r9327)
for detecting overflows only for base 10, so that
'4294967296' does not get interpreted as 0.  It seems that
the special case is no longer needed since the adoption on
Python long integers in case of overflow.  Using the case
for base 10 for all bases (look at the attached
1334662-mystrtoul.c.diff) does the trick.  Given this script::

  print 2, int('100000000000000000000000000000000', 2)
  print 3, int('102002022201221111211', 3)
  print 4, int('10000000000000000', 4)
  print 5, int('32244002423141', 5)
  print 6, int('1550104015504', 6)
  print 7, int('211301422354', 7)
  print 8, int('40000000000', 8)
  print 9, int('12068657454', 9)
  print 10, int('4294967296', 10)
  print 11, int('1904440554', 11)
  print 12, int('9ba461594', 12)
  print 13, int('535a79889', 13)
  print 14, int('2ca5b7464', 14)
  print 15, int('1a20dcd81', 15)
  print 16, int('100000000', 16)
  print 17, int('a7ffda91', 17)
  print 18, int('704he7g4', 18)
  print 19, int('4f5aff66', 19)
  print 20, int('3723ai4g', 20)
  print 21, int('281d55i4', 21)
  print 22, int('1fj8b184', 22)
  print 23, int('1606k7ic', 23)
  print 24, int('mb994ag', 24)
  print 25, int('hek2mgl', 25)
  print 26, int('dnchbnm', 26)
  print 27, int('b28jpdm', 27)
  print 28, int('8pfgih4', 28)
  print 29, int('76beigg', 29)
  print 30, int('5qmcpqg', 30)
  print 31, int('4q0jto4', 31)
  print 32, int('4000000', 32)
  print 33, int('3aokq94', 33)
  print 34, int('2qhxjli', 34)
  print 35, int('2br45qb', 35)
  print 36, int('1z141z4', 36)

The old output is::

  2 4294967296
  3 0
  4 4294967296
  5 0
  6 0
  7 0
  8 4294967296
  9 0
  10 4294967296
  11 0
  12 0
  13 0
  14 0
  15 0
  16 4294967296
  17 0
  18 0
  19 0
  20 0
  21 0
  22 0
  23 0
  24 0
  25 0
  26 0
  27 0
  28 0
  29 0
  30 0
  31 0
  32 4294967296
  33 0
  34 0
  35 0
  36 0

And the new one::

  2 4294967296
  3 4294967296
  4 4294967296
  5 4294967296
  6 4294967296
  ...
  32 4294967296
  33 4294967296
  34 4294967296
  35 4294967296
  36 4294967296

The old bugs should be tested for in ``test_builtin.py``,
but I don't know the Python test infrastructure too well.  I
will give it a try, nonetheless.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1334662&group_id=5470

From noreply at sourceforge.net  Fri Mar 31 22:31:31 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 12:31:31 -0800
Subject: [ python-Bugs-1177964 ] Iterator on Fileobject gives no MemoryError
Message-ID: <E1FPQHL-00055u-VS@sc8-sf-web1.sourceforge.net>

Bugs item #1177964, was opened at 2005-04-06 17:55
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1177964&group_id=5470

Please note that this message 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: Folke Lemaitre (zypher)
Assigned to: Nobody/Anonymous (nobody)
Summary: Iterator on Fileobject gives no MemoryError

Initial Comment:
The following problem has only been tested on linux.
Suppose at a certain time that your machine can
allocate a maximum of X megabytes of memory. Allocating
more than X should result in python MemoryErrors. Also
suppose you have a file containing one big line taking
more than X bytes (Large binary file for example).
In this case, if you read lines from a file through the
file objects iterator, you do NOT get the expected
MemoryError as result, but an empty list.

To reproduce, create a file twice as big as your
machines memory and disable the swap.

If you run the following code:
#    import os.path
#
#    def test(input):
#        print "Testing %s (%sMB)"%(repr(input),
os.path.getsize(input)/(1024.0*1024.0))
#        count = 0
#        for line in open(input):
#            count = count + 1
#       print "  >> Total Number of Lines: %s"%count
#
#    if __name__ == "__main__":
#        test('test.small')
#        test('test.big')

you'll get something like:
# folke at wladimir devel $ python2.4 bug.py
# Testing 'test.small' (20.0MB)
#   >> Total Number of Lines: 1
# Testing 'test.big' (2000.0MB)
#   >> Total Number of Lines: 0



----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-31 20:31

Message:
Logged In: YES 
user_id=849994

Applied your patch in revs 43506, 43507.

----------------------------------------------------------------------

Comment By: Chris AtLee (catlee)
Date: 2006-03-31 19:53

Message:
Logged In: YES 
user_id=186532

This can be fixed by having the readahead method (used by
readahead_get_line_skip, used by file_iternext) raising a
MemoryError if it can't allocate enough room for the line.

Index: Objects/fileobject.c
===================================================================
--- Objects/fileobject.c        (revision 43486)
+++ Objects/fileobject.c        (working copy)
@@ -1797,7 +1797,8 @@

 /* Make sure that file has a readahead buffer with at least
one byte
    (unless at EOF) and no more than bufsize.  Returns
negative value on
-   error */
+   error.  Will raise a MemoryError if bufsize bytes cannot be
+   allocated. */
 static int
 readahead(PyFileObject *f, int bufsize)
 {
@@ -1810,6 +1811,7 @@
                        drop_readahead(f);
        }
        if ((f->f_buf = PyMem_Malloc(bufsize)) == NULL) {
+                PyErr_NoMemory();
                return -1;
        }
        Py_BEGIN_ALLOW_THREADS


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1177964&group_id=5470