From noreply at sourceforge.net  Tue May  1 08:04:49 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 30 Apr 2007 23:04:49 -0700
Subject: [ python-Bugs-1710295 ] Tutorial - Section 8.3 - <type 'instance'>
Message-ID: <E1HilTl-00040z-1R@sc8-sf-web22.sourceforge.net>

Bugs item #1710295, was opened at 2007-04-30 21:52
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1710295&group_id=5470

Please note that this 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
Private: No
Submitted By: elrond79 (elrond79)
Assigned to: Nobody/Anonymous (nobody)
Summary: Tutorial - Section 8.3 - <type 'instance'>

Initial Comment:
In section 8.3 of the Tutorial, after a paragraph saying "But use of .args is discouraged" is a code sample; in this sample, I believe the line

<type 'instance'>

should be changed to 

<type 'exceptions.Exception'>

At least, that's what I get when I input the sample... and it certainly makes more sense.

Python version: 2.5.1
OS: Microsoft Windows XP
    Professional x64 Edition
    Version 2003
    Service Pack 1
(taken from the System Properties / General page...)


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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-01 06:04

Message:
Logged In: YES 
user_id=849994
Originator: NO

Thanks for the report, this is now fixed in rev. 55036, 55037 (2.5).

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

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

From noreply at sourceforge.net  Tue May  1 15:48:12 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 01 May 2007 06:48:12 -0700
Subject: [ python-Bugs-1708326 ] find_module doc ambiguity
Message-ID: <E1HisiC-0001nH-9M@sc8-sf-web22.sourceforge.net>

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

Please note that this 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
Private: No
Submitted By: Andrew McNabb (amcnabb)
Assigned to: Nobody/Anonymous (nobody)
Summary: find_module doc ambiguity

Initial Comment:
The doc string for find_module doesn't make it clear that you can do:

stats_path = imp.find_module('scipy/stats')

It makes it sound like you would have to do:

scipy_path = imp.find_module('scipy')[1]
stats_path = imp.find_module('scipy', stats_path)[1]

However, the shorter snippet seems to work just fine.

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

Comment By: Jim Jewett (jimjjewett)
Date: 2007-05-01 09:48

Message:
Logged In: YES 
user_id=764593
Originator: NO

Are you sure it works the same?  I would expect that 

(1)  The longer form first finds a module (or package) named scipy, then
finds the (sub-)module stats within it.  The shortcut form might not
provide enough of the scipy context.  (Whether this actually matters
probably depends on what stats does, how much it depends on the rest of
scipy, and what you need it for.)

(2)  The longer form would work using python abstractions, while the short
form would depend on how files happened to be stored on your machine.  Your
storage format is fairly common, but not guaranteed.  For example, would
the short form work on windows, where directory slashes (sometimes) need to
go the other direction?  Would it work if scipy were in a zipfile egg?

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

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

From noreply at sourceforge.net  Tue May  1 17:02:53 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 01 May 2007 08:02:53 -0700
Subject: [ python-Bugs-1693753 ] Portability issue: os.rename behaves
	differently on win32
Message-ID: <E1HitsT-000352-OP@sc8-sf-web22.sourceforge.net>

Bugs item #1693753, was opened at 2007-04-03 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=1693753&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Platform-specific
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: cs_ (cs_)
Assigned to: Nobody/Anonymous (nobody)
Summary: Portability issue: os.rename behaves differently on win32

Initial Comment:
os.rename(src, dst) fails on Windows if dst already exist and regular file. On Unixes, it does not fail, and silently overwrites dst. It's better to use MoveFileEx(src, dst, MOVEFILE_REPLACE_EXISTING) when moving regular files under Win32 to make it behave consistent way.

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

>Comment By: Martin v. L?wis (loewis)
Date: 2007-05-01 17:02

Message:
Logged In: YES 
user_id=21627
Originator: NO

This change would be an incompatible change; see the discussion of the
proposed patch. Closing this report as "won't fix".

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-04-23 00:48

Message:
Logged In: YES 
user_id=984087
Originator: NO


I submitted a patch for this (1704547)

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-04-12 18:35

Message:
Logged In: YES 
user_id=984087
Originator: NO


>From MSDN document and googling, it does look like
MOVEFILE_REPLACE_EXISTING guarantees atomicity for rename operation. I will
see if I can come up with a patch (I will first need to learn building
python on windows).

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

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

From noreply at sourceforge.net  Tue May  1 17:04:05 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 01 May 2007 08:04:05 -0700
Subject: [ python-Bugs-1709284 ] test_1686475 fails because pagefile.sys does
	not exist
Message-ID: <E1Hittd-0001uq-6M@sc8-sf-web23.sourceforge.net>

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

Please note that this 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: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Calvin Spealman (ironfroggy)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_1686475 fails because pagefile.sys does not exist

Initial Comment:
The file pagefile.sys is used as a test on stat'ing an open file, because previously we could rely on windows using it. It does not exist in newer versions, so the test fails. The attached patch uses a temporary file instead.

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

>Comment By: Martin v. L?wis (loewis)
Date: 2007-05-01 17:04

Message:
Logged In: YES 
user_id=21627
Originator: NO

As discussed on python-dev: this patch is incorrect.

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

Comment By: Calvin Spealman (ironfroggy)
Date: 2007-04-28 20:32

Message:
Logged In: YES 
user_id=112166
Originator: YES

File Added: os_open_stat.patch

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

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

From noreply at sourceforge.net  Tue May  1 17:42:19 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 01 May 2007 08:42:19 -0700
Subject: [ python-Feature Requests-1708652 ] Exact matching
Message-ID: <E1HiuUd-0001T0-5W@sc8-sf-web22.sourceforge.net>

Feature Requests item #1708652, was opened at 2007-04-27 13:35
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1708652&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Regular Expressions
>Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Tom Lynn (tlynn)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: Exact matching

Initial Comment:
I'd like to see a regexp.exact() method on regexp objects, equivalent to regexp.search(r'\A%s\Z' % pattern, ...), for parsing binary formats.

It's probably not worth disturbing the current library interface for, but maybe in Py3k?


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

>Comment By: Martin v. L?wis (loewis)
Date: 2007-05-01 17:42

Message:
Logged In: YES 
user_id=21627
Originator: NO

Moving to the feature requests tracker.

Notice that in Py3k, the string type will be a Unicode type, so it's not
clear to me that regular expressions on binary data will still be
supported.

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

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

From noreply at sourceforge.net  Tue May  1 18:43:50 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 01 May 2007 09:43:50 -0700
Subject: [ python-Bugs-1710703 ] zipfile.ZipFile behavior inconsistent.
Message-ID: <E1HivSA-0008BM-5j@sc8-sf-web22.sourceforge.net>

Bugs item #1710703, was opened at 2007-05-01 11: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=1710703&group_id=5470

Please note that this message will contain a full 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
Private: No
Submitted By: Mark Flacy (markaflacy)
Assigned to: Nobody/Anonymous (nobody)
Summary: zipfile.ZipFile behavior inconsistent.

Initial Comment:
In short, ZipFile() will not write the Central Directory entry unless you have added a file to it.  That makes it impossible to create a valid empty zip archive.

In one of my applications, I have the need to extract a partial set of information from one zip file and insert it into another.  There are valid use cases where the source zip archive will not have any of the files which I am looking for.  In Python 2.4, I would end up with an empty file which was considered to be a valid empty zip archive.  In Python 2.5, an empty file is not considered a valid zip archive.  

One would reasonably expect that creating a new ZipFile(mode="r") and successfully closing it without writing any entries would result in a valid zip archive that could be re-opened later without throwing an exception.



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

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

From noreply at sourceforge.net  Tue May  1 19:26:11 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 01 May 2007 10:26:11 -0700
Subject: [ python-Bugs-1710718 ] Ctrl+Shift block marking by words
Message-ID: <E1Hiw79-0003qW-L6@sc8-sf-web21.sourceforge.net>

Bugs item #1710718, was opened at 2007-05-01 17: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=1710718&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: zorkin (zorkin)
Assigned to: Nobody/Anonymous (nobody)
Summary: Ctrl+Shift block marking by words

Initial Comment:
When I mark a block with ctrl+shift pressed, pressing the right arrow with cursor before the last word on the line marks this word plus whitespace till the first word on next line.

I think this behaviour is wrong - it should stop at the end of line.

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

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

From noreply at sourceforge.net  Tue May  1 19:39:24 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 01 May 2007 10:39:24 -0700
Subject: [ python-Bugs-1710718 ] Ctrl+Shift block marking by words
Message-ID: <E1HiwJw-00055k-A7@sc8-sf-web23.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: zorkin (zorkin)
Assigned to: Nobody/Anonymous (nobody)
Summary: Ctrl+Shift block marking by words

Initial Comment:
When I mark a block with ctrl+shift pressed, pressing the right arrow with cursor before the last word on the line marks this word plus whitespace till the first word on next line.

I think this behaviour is wrong - it should stop at the end of line.

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

>Comment By: zorkin (zorkin)
Date: 2007-05-01 17:39

Message:
Logged In: YES 
user_id=1741501
Originator: YES

And another thing: if the cursor is at the start of line and I press ctrl
+ right, it moves to the start of the second word, not the first one, like
it should.

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

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

From noreply at sourceforge.net  Tue May  1 20:05:38 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 01 May 2007 11:05:38 -0700
Subject: [ python-Bugs-1707768 ] os.path.normpath changes path (chops of
	trailing slash)
Message-ID: <E1HiwjK-0002h5-8U@sc8-sf-web21.sourceforge.net>

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

Please note that this message will contain a full 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
Private: No
Submitted By: Robert Siemer (siemer)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.normpath changes path (chops of trailing slash)

Initial Comment:
Hello everybody!

>>> os.path.normpath('/etc/passwd')
'/etc/passwd'


I don't know any environment at all where

a) '/etc/passwd/'
b) '/etc/passwd'

are treated the same. It clearly does not apply for the path part of http urls (this is left as an exercise for the reader).

But it also does not apply for (e.g.) Linux either:
an open() on path a) return ENOTDIR while it succeeds with b).

(assuming /etc/passwd is a file)

This is definitively not a documentation bug, as "normpath" should normalize a path and not fuck it up.


Robert

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

Comment By: Istvan Szegedi (iszegedi)
Date: 2007-05-01 20:05

Message:
Logged In: YES 
user_id=1772412
Originator: NO

I must admit that josm's comments make sense: in fact, I quickly tried out
how mkdir command from a bash shell would behave and it does the same:

# mkdir hello
# rmdir hello/. 
Invalid argument

whereas
# rmdir hello/

works fine. I also wrote a small C program using mkdir() and rmdir()
functions and they behave exactly the same as mkdir/rmdir from bash (well,
no real suprise).

My suggestion to get the original issue fixed was based on POSIX standard
and apparently the Linux commands are not fully POSIX compliant, either...
Or do I misunderstand the quotes from the standard?  Anyway, it is pretty
easy to modify my fix to be inline with Linux commands and C functions -
everything could be the same, apart from the last line where I added "/." 
-- this should be only "/".  So the entire function could look like this:

-- clip --


def normpath(path):
    """Normalize path, eliminating double slashes, etc."""
    if path == '':
        return '.'
    initial_slashes = path.startswith('/')
    # The next two lines were added by iszegedi
    path = path.rstrip()
    trailing_slash = path.endswith('/')
    # POSIX allows one or two initial slashes, but treats three or more
    # as single slash.
    if (initial_slashes and
        path.startswith('//') and not path.startswith('///')):
        initial_slashes = 2
    comps = path.split('/')
    new_comps = []
    for comp in comps:
        if comp in ('', '.'):
            continue
        if (comp != '..' or (not initial_slashes and not new_comps) or
             (new_comps and new_comps[-1] == '..')):
            new_comps.append(comp)
        elif new_comps:
            new_comps.pop()
    comps = new_comps
    path = '/'.join(comps)
    if initial_slashes:
        path = '/'*initial_slashes + path
    # The next two lines were added by iszegedi
    if trailing_slash:
        path = path + '/'
    return path or '.'


-- clip --

Nevertheless, I would really appreciate to receive some comments from
POSIX gurus, how they see this problem.


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

Comment By: jos (josm)
Date: 2007-04-30 08:48

Message:
Logged In: YES 
user_id=1776568
Originator: NO

I think we should be careful enough to tackle on this.
iszegedi's patch seems to work correctly,
but XBD's spec itself has some defect.
http://www.opengroup.org/austin/mailarchives/ag-review/msg01722.html

What do you think of the follow behavior?
>>> os.mkdir('dir/')
>>> os.mkdir('dir2/')
>>> os.rmdir(os.path.normpath('dir'))
>>> os.rmdir(os.path.normpath('dir2/'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 22] Invalid argument: 'dir2/.'




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

Comment By: Istvan Szegedi (iszegedi)
Date: 2007-04-28 22:27

Message:
Logged In: YES 
user_id=1772412
Originator: NO


Here is what Posix standard says about pathnames:

"Base Definitions volume of IEEE Std 1003.1-2001, Section 3.266,
Pathname.

A character string that is used to identify a file. In the context of IEEE
Std 1003.1-2001, a pathname consists of, at most, {PATH_MAX} bytes,
including the terminating null byte. It has an optional beginning slash,
followed by zero or more filenames separated by slashes. A pathname may
optionally contain one or more trailing slashes. Multiple successive
slashes are considered to be the same as one slash."

And in the details:

"A pathname that contains at least one non-slash character and that ends
with one or more trailing slashes shall be resolved as if a single dot
character ( '.' ) were appended to the pathname."

So if I am not mistaken, according to the POSIX standard the example that
you gave - '/etc/passwd/' - should be normalized to '/etc/passwd/.' That
does not happen, indeed.

The reason for that is that in posixpath.py file the normpath() function
is using a split('/') function to split up the path into smaller chunks,
skips everything which is empty or '.' and at the end of the normpath()
function it adds slash(es) only to the beginning of the string. 

As a test, I modified the normpath() function in the posixpath.py as
follows:

--- clip ---

def normpath(path):
    """Normalize path, eliminating double slashes, etc."""
    if path == '':
        return '.'
    initial_slashes = path.startswith('/')
    # The next two lines were added by iszegedi
    path = path.rstrip()
    trailing_slash = path.endswith('/')
    # POSIX allows one or two initial slashes, but treats three or more
    # as single slash.
    if (initial_slashes and
        path.startswith('//') and not path.startswith('///')):
        initial_slashes = 2
    comps = path.split('/')
    new_comps = []
    for comp in comps:
        if comp in ('', '.'):
            continue
        if (comp != '..' or (not initial_slashes and not new_comps) or
             (new_comps and new_comps[-1] == '..')):
            new_comps.append(comp)
        elif new_comps:
            new_comps.pop()
    comps = new_comps
    path = '/'.join(comps)
    if initial_slashes:
        path = '/'*initial_slashes + path
    # The next two lines were added by iszegedi
    if trailing_slash:
        path = path + '/.'
    return path or '.'
  
-- clip --

So I added two lines (marked as "added by iszegedi" ) in the beginning to
remove any trailing whitespaces and check whether the path ends with slash.
Then at the end of the function I added another two lines to append '/.' to
the end of the return value if the input path variable ended by slash

This works now fine.

What makes it a bit tricky is that python os module imports different
xxxpath.py module depending on the host operating system. So it imports
different modules for nt, for mac, for os2, for posix, etc.  The solution
above works for posix, but the other modules need to be checked, to.


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

Comment By: Robert Siemer (siemer)
Date: 2007-04-26 01:47

Message:
Logged In: YES 
user_id=150699
Originator: YES

A bugreport bug:

The example should read os.path.normpath('/etc/passwd/')...

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

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

From noreply at sourceforge.net  Tue May  1 20:23:24 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 01 May 2007 11:23:24 -0700
Subject: [ python-Bugs-1708326 ] imp.find_module doc ambiguity
Message-ID: <E1Hix0W-0005S3-VK@sc8-sf-web22.sourceforge.net>

Bugs item #1708326, was opened at 2007-04-26 12:18
Message generated for change (Settings changed) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1708326&group_id=5470

Please note that this 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
Private: No
Submitted By: Andrew McNabb (amcnabb)
Assigned to: Nobody/Anonymous (nobody)
>Summary: imp.find_module doc ambiguity

Initial Comment:
The doc string for find_module doesn't make it clear that you can do:

stats_path = imp.find_module('scipy/stats')

It makes it sound like you would have to do:

scipy_path = imp.find_module('scipy')[1]
stats_path = imp.find_module('scipy', stats_path)[1]

However, the shorter snippet seems to work just fine.

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

Comment By: Jim Jewett (jimjjewett)
Date: 2007-05-01 06:48

Message:
Logged In: YES 
user_id=764593
Originator: NO

Are you sure it works the same?  I would expect that 

(1)  The longer form first finds a module (or package) named scipy, then
finds the (sub-)module stats within it.  The shortcut form might not
provide enough of the scipy context.  (Whether this actually matters
probably depends on what stats does, how much it depends on the rest of
scipy, and what you need it for.)

(2)  The longer form would work using python abstractions, while the short
form would depend on how files happened to be stored on your machine.  Your
storage format is fairly common, but not guaranteed.  For example, would
the short form work on windows, where directory slashes (sometimes) need to
go the other direction?  Would it work if scipy were in a zipfile egg?

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

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

From noreply at sourceforge.net  Tue May  1 20:57:06 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 01 May 2007 11:57:06 -0700
Subject: [ python-Bugs-1708326 ] imp.find_module doc ambiguity
Message-ID: <E1HixX8-0006He-Do@sc8-sf-web24.sourceforge.net>

Bugs item #1708326, was opened at 2007-04-26 13:18
Message generated for change (Comment added) made by amcnabb
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1708326&group_id=5470

Please note that this 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
Private: No
Submitted By: Andrew McNabb (amcnabb)
Assigned to: Nobody/Anonymous (nobody)
Summary: imp.find_module doc ambiguity

Initial Comment:
The doc string for find_module doesn't make it clear that you can do:

stats_path = imp.find_module('scipy/stats')

It makes it sound like you would have to do:

scipy_path = imp.find_module('scipy')[1]
stats_path = imp.find_module('scipy', stats_path)[1]

However, the shorter snippet seems to work just fine.

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

>Comment By: Andrew McNabb (amcnabb)
Date: 2007-05-01 12:57

Message:
Logged In: YES 
user_id=1234027
Originator: YES

Given the issues you brought up, I guess I'm surprised that the shortcut
form is accepted, since it seems that it would often do the wrong thing.

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

Comment By: Jim Jewett (jimjjewett)
Date: 2007-05-01 07:48

Message:
Logged In: YES 
user_id=764593
Originator: NO

Are you sure it works the same?  I would expect that 

(1)  The longer form first finds a module (or package) named scipy, then
finds the (sub-)module stats within it.  The shortcut form might not
provide enough of the scipy context.  (Whether this actually matters
probably depends on what stats does, how much it depends on the rest of
scipy, and what you need it for.)

(2)  The longer form would work using python abstractions, while the short
form would depend on how files happened to be stored on your machine.  Your
storage format is fairly common, but not guaranteed.  For example, would
the short form work on windows, where directory slashes (sometimes) need to
go the other direction?  Would it work if scipy were in a zipfile egg?

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

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

From noreply at sourceforge.net  Tue May  1 22:46:25 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 01 May 2007 13:46:25 -0700
Subject: [ python-Bugs-1710802 ] subprocess must escape redirection characters
	under win32
Message-ID: <E1HizEv-0003Cn-30@sc8-sf-web24.sourceforge.net>

Bugs item #1710802, was opened at 2007-05-01 22: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=1710802&group_id=5470

Please note that this 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
Private: No
Submitted By: Patrick M?zard (pmezard)
Assigned to: Nobody/Anonymous (nobody)
Summary: subprocess must escape redirection characters under win32

Initial Comment:
Hello,
For some reason, subprocess.Popen arguments are not processed correctly when one of them contains a redirection character ("<>&|") when calling a batch file.

Unittest and patch are attached below. Here are the steps to reproduce it:

callee.py
"""
import sys
print sys.argv
"""

callee.bat
"""
python callee.py %*
"""

caller.py
"""
import subprocess

args = [
    'a<b',
    'a>b',
    'a|b',
    'a&b',
]

for arg in args:
    subprocess.check_call(['callee.bat', arg])
"""

Then:
"""
>python caller.py
The system cannot find the file specified.
Traceback (most recent call last):
  File "caller.py", line 22, in <module>
    subprocess.check_call(['callee.bat', arg])
  File "C:\Python251\lib\subprocess.py", line 461, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['callee.bat', 'a<b']' returned non-zero
 exit status 1
"""

With:
"""
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>>
"""


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

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

From noreply at sourceforge.net  Tue May  1 22:47:00 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 01 May 2007 13:47:00 -0700
Subject: [ python-Bugs-1710802 ] subprocess must escape redirection characters
	under win32
Message-ID: <E1HizFU-00022S-53@sc8-sf-web22.sourceforge.net>

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

Please note that this 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
Private: No
Submitted By: Patrick M?zard (pmezard)
Assigned to: Nobody/Anonymous (nobody)
Summary: subprocess must escape redirection characters under win32

Initial Comment:
Hello,
For some reason, subprocess.Popen arguments are not processed correctly when one of them contains a redirection character ("<>&|") when calling a batch file.

Unittest and patch are attached below. Here are the steps to reproduce it:

callee.py
"""
import sys
print sys.argv
"""

callee.bat
"""
python callee.py %*
"""

caller.py
"""
import subprocess

args = [
    'a<b',
    'a>b',
    'a|b',
    'a&b',
]

for arg in args:
    subprocess.check_call(['callee.bat', arg])
"""

Then:
"""
>python caller.py
The system cannot find the file specified.
Traceback (most recent call last):
  File "caller.py", line 22, in <module>
    subprocess.check_call(['callee.bat', arg])
  File "C:\Python251\lib\subprocess.py", line 461, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['callee.bat', 'a<b']' returned non-zero
 exit status 1
"""

With:
"""
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>>
"""


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

>Comment By: Patrick M?zard (pmezard)
Date: 2007-05-01 22:47

Message:
Logged In: YES 
user_id=1660346
Originator: YES

File Added: fix_subp

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

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

From noreply at sourceforge.net  Wed May  2 08:06:59 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 01 May 2007 23:06:59 -0700
Subject: [ python-Bugs-1710703 ] zipfile.ZipFile behavior inconsistent.
Message-ID: <E1Hj7zP-00035C-ET@sc8-sf-web24.sourceforge.net>

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

Please note that this message will contain a full 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
Private: No
Submitted By: Mark Flacy (markaflacy)
Assigned to: Nobody/Anonymous (nobody)
Summary: zipfile.ZipFile behavior inconsistent.

Initial Comment:
In short, ZipFile() will not write the Central Directory entry unless you have added a file to it.  That makes it impossible to create a valid empty zip archive.

In one of my applications, I have the need to extract a partial set of information from one zip file and insert it into another.  There are valid use cases where the source zip archive will not have any of the files which I am looking for.  In Python 2.4, I would end up with an empty file which was considered to be a valid empty zip archive.  In Python 2.5, an empty file is not considered a valid zip archive.  

One would reasonably expect that creating a new ZipFile(mode="r") and successfully closing it without writing any entries would result in a valid zip archive that could be re-opened later without throwing an exception.



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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-01 23:06

Message:
Logged In: YES 
user_id=33168
Originator: NO

Mark, can you create a patch for zipfile to make it do what you want?  Do
the docs mention anything about this either way?  Perhaps the docs also
need updating?

I don't know about what happened here, but I'm guessing there was some bug
fix.  This change could have been intentional or not.  I patch will help us
figure out what went wrong and how to proceed.  

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

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

From noreply at sourceforge.net  Wed May  2 08:07:53 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 01 May 2007 23:07:53 -0700
Subject: [ python-Bugs-1710718 ] Ctrl+Shift block marking by words
Message-ID: <E1Hj80H-0003Bc-Cp@sc8-sf-web24.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: zorkin (zorkin)
>Assigned to: Kurt B. Kaiser (kbk)
Summary: Ctrl+Shift block marking by words

Initial Comment:
When I mark a block with ctrl+shift pressed, pressing the right arrow with cursor before the last word on the line marks this word plus whitespace till the first word on next line.

I think this behaviour is wrong - it should stop at the end of line.

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

Comment By: zorkin (zorkin)
Date: 2007-05-01 10:39

Message:
Logged In: YES 
user_id=1741501
Originator: YES

And another thing: if the cursor is at the start of line and I press ctrl
+ right, it moves to the start of the second word, not the first one, like
it should.

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

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

From noreply at sourceforge.net  Wed May  2 08:38:53 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 01 May 2007 23:38:53 -0700
Subject: [ python-Bugs-1710802 ] subprocess must escape redirection characters
	under win32
Message-ID: <E1Hj8UH-0006TW-JF@sc8-sf-web24.sourceforge.net>

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

Please note that this message will contain 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
Private: No
Submitted By: Patrick M?zard (pmezard)
>Assigned to: Peter ?strand (astrand)
Summary: subprocess must escape redirection characters under win32

Initial Comment:
Hello,
For some reason, subprocess.Popen arguments are not processed correctly when one of them contains a redirection character ("<>&|") when calling a batch file.

Unittest and patch are attached below. Here are the steps to reproduce it:

callee.py
"""
import sys
print sys.argv
"""

callee.bat
"""
python callee.py %*
"""

caller.py
"""
import subprocess

args = [
    'a<b',
    'a>b',
    'a|b',
    'a&b',
]

for arg in args:
    subprocess.check_call(['callee.bat', arg])
"""

Then:
"""
>python caller.py
The system cannot find the file specified.
Traceback (most recent call last):
  File "caller.py", line 22, in <module>
    subprocess.check_call(['callee.bat', arg])
  File "C:\Python251\lib\subprocess.py", line 461, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['callee.bat', 'a<b']' returned non-zero
 exit status 1
"""

With:
"""
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>>
"""


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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-01 23:38

Message:
Logged In: YES 
user_id=33168
Originator: NO

Peter, can you take a look at this?

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

Comment By: Patrick M?zard (pmezard)
Date: 2007-05-01 13:47

Message:
Logged In: YES 
user_id=1660346
Originator: YES

File Added: fix_subp

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

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

From noreply at sourceforge.net  Wed May  2 13:10:22 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 02 May 2007 04:10:22 -0700
Subject: [ python-Bugs-1709284 ] test_1686475 fails because pagefile.sys does
	not exist
Message-ID: <E1HjCj0-0005aK-Bm@sc8-sf-web22.sourceforge.net>

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

Please note that this 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: Pending
Resolution: None
Priority: 5
Private: No
Submitted By: Calvin Spealman (ironfroggy)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_1686475 fails because pagefile.sys does not exist

Initial Comment:
The file pagefile.sys is used as a test on stat'ing an open file, because previously we could rely on windows using it. It does not exist in newer versions, so the test fails. The attached patch uses a temporary file instead.

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

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

Message:
Logged In: YES 
user_id=21627
Originator: NO

As discussed on python-dev: this patch is incorrect.

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

Comment By: Calvin Spealman (ironfroggy)
Date: 2007-04-28 18:32

Message:
Logged In: YES 
user_id=112166
Originator: YES

File Added: os_open_stat.patch

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

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

From noreply at sourceforge.net  Wed May  2 14:03:45 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 02 May 2007 05:03:45 -0700
Subject: [ python-Bugs-1699853 ] locale.getlocale() output fails as
	setlocale() input 
Message-ID: <E1HjDYf-0007Ct-59@sc8-sf-web21.sourceforge.net>

Bugs item #1699853, was opened at 2007-04-13 12:26
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1699853&group_id=5470

Please note that this message will contain a full 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
Private: No
Submitted By: Bernhard Reiter (ber)
Assigned to: Nobody/Anonymous (nobody)
Summary: locale.getlocale() output fails as setlocale() input 

Initial Comment:
This problem report about the locale module
consists of three closely related parts 
(this is why I have decided to put it in one report).
a) the example in the docs is wrong / missleading
b) under some locale settings python as a defect
c) a test case for the locale module, showing b)
   but useful as general start for a test module.

Details:
        a)
        Section example:
                The line
                >>> loc = locale.getlocale(locale.LC_ALL) # get current locale
                contradicts that getlocale should not be called with
                        LC_ALL, as stated in the description of getlocale.
                Suggestion is to change the example to be more useful
                as getting the locale as first action is not really useful.
                It should be "C" anyway which will lead to (None, None)
                so the value is already known. It would make more sense to

                first set the default locale to the user preferences:
import locale
locale.setlocale(locale.LC_ALL,'')
loc = locale.getlocale(locale.LC_NUMERIC)
locale.setlocale(locale.LC_NUMERIC,"C")
# convert a string here
locale.setlocale(locale.LC_NUMERIC, loc)

                _but_ this does not work, see problem b).
                What does work is:

import
locale.setlocale(locale.LC_ALL,'')
loc = locale.setlocale(locale.LC_NUMERIC)
locale.setlocale(locale.LC_NUMERIC,"C")
# convert a string here
locale.setlocale(locale.LC_NUMERIC, loc)

Note that all_loc = locale.setlocale(locale.LC_ALL) might contain
several categories (see attached test_locale.py where I needed to decode
this).
'LC_CTYPE=de_DE.UTF-8;LC_NUMERIC=en_GB.utf8;LC_TIME=de_DE.UTF-8;LC_COLLATE=de_DE.UTF-8;LC_MONETARY=de_DE.UTF-8;LC_MESSAGES=de_DE.UTF-8;LC_PAPER=de_DE.UTF-8;LC_NAME=de_DE.UTF-8;LC_ADDRESS=de_DE.UTF-8;LC_TELEPHONE=de_DE.UTF-8;LC_MEASUREMENT=de_DE.UTF-8;LC_IDENTIFICATION=de_DE.UTF-8'


        b)
                The output of getlocale cannot be used as input to
                setlocale sometimes.
                Works with
                * python2.5 und python2.4 on
                  Debian GNU/Linux Etch ppc, de_DE.utf8.

                I had failures with
                * python2.3, python2.4, python2.5
                  on Debian GNU/Linux Sarge ppc, de_DE at euro
                * Windows XP SP2
                        python-2.4.4.msi    German, see:

                >>> import locale
                >>> result = locale.setlocale(locale.LC_NUMERIC,"")
                >>> print result
                German_Germany.1252
                >>> got = locale.getlocale(locale.LC_NUMERIC)
                >>> print got
                ('de_DE', '1252')
                >>> # works
                ... locale.setlocale(locale.LC_NUMERIC, result)
                'German_Germany.1252'
                >>> # fails
                ... locale.setlocale(locale.LC_NUMERIC, got)
                Traceback (most recent call last):
                  File "<stdin>", line 2, in ?
                  File "C:\Python24\lib\locale.py", line 381, in setlocale
                    return _setlocale(category, locale)
                locale.Error: unsupported locale setting
                >>>



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

>Comment By: M.-A. Lemburg (lemburg)
Date: 2007-05-02 14:03

Message:
Logged In: YES 
user_id=38388
Originator: NO

I wrote that code, so let me comment on it:

The setlocale() function returns the setting that was previously active
(see the setlocale (3) man-page). 

Unfortunately, there's no clear standard on the way locales are named. The
man-page says:

"""
A locale name is typically of the form
language[_territory][.codeset][@modifier], where language is an ISO 639
language code, territory is an ISO 3166 country code, and codeset is a
character  set
       or encoding identifier like ISO-8859-1 or UTF-8.  For a list of all
supported locales, try "locale -a", cf. locale(1).
"""

"Germany_Germany" is clearly not a locale name that fits the above
scheme.

If I do "locale -a" on my box, the "Germany_Germany" is not mentioned in
the resulting list, so there's no surprise that  the function call
generates an error.

Note that you can set the locale without using setlocale(): all that is
needed is an environment variable and that is, of course, not subject to
any checks by setlocal().

I'd suggest to close this bug report as invalid.

Thanks.

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

Comment By: Bernhard Reiter (ber)
Date: 2007-04-19 12:23

Message:
Logged In: YES 
user_id=113859
Originator: YES

Feel free to drop them an email, this is a good idea.
Maybe "svn blame" or history inspection produces more names that actually
wrote
the code and the documentation.

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

Comment By: Istvan Szegedi (iszegedi)
Date: 2007-04-19 12:18

Message:
Logged In: YES 
user_id=1772412
Originator: NO

Hi Bernhard,

I absolutely agree with you and I cannot  really judge my correction,
either. It was just a quick and dirty solution to see if it would fix the
problem. In fact, there are other ways to do it as well, like  to modify
the 
encoding_alias table not to translate utf-8 string into utf (and thus to
prevent it to produce an invalid locale setting for _setlocale )

In the locale.py file I found two names mentioned:

Author:  Mark-Andre Lemburg (mal at lemburg.com) 
and Fredrick Lund  (fredrick at pythonware.com) as a modifyier

so it might be a good idea to drop them a mail and ask for their comments.
Do you want to do it or shall I? If you are willing to do it, please, keep
me in the loop.

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

Comment By: Bernhard Reiter (ber)
Date: 2007-04-19 10:55

Message:
Logged In: YES 
user_id=113859
Originator: YES

Istvan,
thanks for looking into this and adding information.
I do not feel competent to judge what the solution would be,
as I do not know the design goals of getlocale().
Given the documentation the function call would only make sense
if setlocale(getlocale(LC_XYZ)) would work in all cases, especially
after the locale has been set to the user preferances with
setlocale(LC_ALL,"")
There is no simple test case that can make sure this is the case.

The workaround for current code for me is to use setlocale(LC_XYZ) only
to ask for the currently set locale and then decipher the string if the
categories have different settings. This workaround can be seen in my
proposed test_case.py. 

I believe next steps could be to get a full overview and check design and
implementation, add some testcases so that more is covered and then fix 
the implementation. We could try to find out who invented getlocale
and ask.

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

Comment By: Istvan Szegedi (iszegedi)
Date: 2007-04-19 10:24

Message:
Logged In: YES 
user_id=1772412
Originator: NO

I could reproduce the problem on Fedora Core 5 with Python 2.4.3.

After tracing down the issue, I found the following:

The problem is in locate.py. There is a function called normalize defined
in the locate.py file. This function is invoked by setlocale function if
the incoming locale argument is not a string. (in your example this
condition is true because locale.getlocale function returns a tuple so got
variable is a tuple.) The normalize function is using an encoding_alias
table which results to translate the full locale into an incorrect version.
What happens in my environment is that there is an incoming value
en_us.utf-8  which is converted to en_us.utf and that is the return value
from normalize function. Then _setlocale low level function invoked in
setlocale function throws an exception when it receives en_us.utf  argument
and it is an unsupported locale setting.


This is the original code snippet in locale.py where it is converted in a
wrong way in normalize function:


    # Second try: langname (without encoding)
    code = locale_alias.get(langname, None)
    if code is not None:
        if '.' in code:
            langname, defenc = code.split('.')
        else:
            langname = code
            defenc = ''
        if encoding:
            encoding = encoding_alias.get(encoding, encoding)
        else:
            encoding = defenc
        if encoding:
            return langname + '.' + encoding
        else:
            return langname

    else:
        return localename


To get it fixed, I modified the code in locate.py as follows:


    # Second try: langname (without encoding)
    code = locale_alias.get(langname, None)
    if code is not None:
        if '.' in code:
            langname, defenc = code.split('.')
        else:
            langname = code
            defenc = ''
#        if encoding:
#            encoding = encoding_alias.get(encoding, encoding)
#        else:
#            encoding = defenc
	if encoding is None:
	     encoding = defenc
        if encoding:
            return langname + '.' + encoding
        else:
            return langname

    else:
        return localename


So the effect of encoding_table is skipped. Then your test_locale.py
returns OK.

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

Comment By: Istvan Szegedi (iszegedi)
Date: 2007-04-18 12:05

Message:
Logged In: YES 
user_id=1772412
Originator: NO

I could reproduce the problem on Fedora Core 5 with Python 2.4.3.

After tracing down the issue, I found the following:

The problem is in locate.py. There is a function called normalize defined
in the locate.py file. This function is invoked by setlocale function if
the incoming locale argument is not a string. (in your example this
condition is true because locale.getlocale function returns a tuple so got
variable is a tuple.) The normalize function is using an encoding_alias
table which results to translate the full locale into an incorrect version.
What happens in my environment is that there is an incoming value
en_us.utf-8  which is converted to en_us.utf and that is the return value
from normalize function. Then _setlocale low level function invoked in
setlocale function throws an exception when it receives en_us.utf  argument
and it is an unsupported locale setting.


This is the original code snippet in locale.py where it is converted in a
wrong way in normalize function:


    # Second try: langname (without encoding)
    code = locale_alias.get(langname, None)
    if code is not None:
        if '.' in code:
            langname, defenc = code.split('.')
        else:
            langname = code
            defenc = ''
        if encoding:
            encoding = encoding_alias.get(encoding, encoding)
        else:
            encoding = defenc
        if encoding:
            return langname + '.' + encoding
        else:
            return langname

    else:
        return localename


To get it fixed, I modified the code in locate.py as follows:


    # Second try: langname (without encoding)
    code = locale_alias.get(langname, None)
    if code is not None:
        if '.' in code:
            langname, defenc = code.split('.')
        else:
            langname = code
            defenc = ''
#        if encoding:
#            encoding = encoding_alias.get(encoding, encoding)
#        else:
#            encoding = defenc
	if encoding is None:
	     encoding = defenc
        if encoding:
            return langname + '.' + encoding
        else:
            return langname

    else:
        return localename


So the effect of encoding_table is skipped. Then your test_locale.py
returns OK.

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

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

From noreply at sourceforge.net  Wed May  2 15:25:09 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 02 May 2007 06:25:09 -0700
Subject: [ python-Bugs-1699853 ] locale.getlocale() output fails as
	setlocale() input 
Message-ID: <E1HjEpR-0001sp-4n@sc8-sf-web22.sourceforge.net>

Bugs item #1699853, was opened at 2007-04-13 12:26
Message generated for change (Comment added) made by ber
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1699853&group_id=5470

Please note that this message will contain a full 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
Private: No
Submitted By: Bernhard Reiter (ber)
Assigned to: Nobody/Anonymous (nobody)
Summary: locale.getlocale() output fails as setlocale() input 

Initial Comment:
This problem report about the locale module
consists of three closely related parts 
(this is why I have decided to put it in one report).
a) the example in the docs is wrong / missleading
b) under some locale settings python as a defect
c) a test case for the locale module, showing b)
   but useful as general start for a test module.

Details:
        a)
        Section example:
                The line
                >>> loc = locale.getlocale(locale.LC_ALL) # get current locale
                contradicts that getlocale should not be called with
                        LC_ALL, as stated in the description of getlocale.
                Suggestion is to change the example to be more useful
                as getting the locale as first action is not really useful.
                It should be "C" anyway which will lead to (None, None)
                so the value is already known. It would make more sense to

                first set the default locale to the user preferences:
import locale
locale.setlocale(locale.LC_ALL,'')
loc = locale.getlocale(locale.LC_NUMERIC)
locale.setlocale(locale.LC_NUMERIC,"C")
# convert a string here
locale.setlocale(locale.LC_NUMERIC, loc)

                _but_ this does not work, see problem b).
                What does work is:

import
locale.setlocale(locale.LC_ALL,'')
loc = locale.setlocale(locale.LC_NUMERIC)
locale.setlocale(locale.LC_NUMERIC,"C")
# convert a string here
locale.setlocale(locale.LC_NUMERIC, loc)

Note that all_loc = locale.setlocale(locale.LC_ALL) might contain
several categories (see attached test_locale.py where I needed to decode
this).
'LC_CTYPE=de_DE.UTF-8;LC_NUMERIC=en_GB.utf8;LC_TIME=de_DE.UTF-8;LC_COLLATE=de_DE.UTF-8;LC_MONETARY=de_DE.UTF-8;LC_MESSAGES=de_DE.UTF-8;LC_PAPER=de_DE.UTF-8;LC_NAME=de_DE.UTF-8;LC_ADDRESS=de_DE.UTF-8;LC_TELEPHONE=de_DE.UTF-8;LC_MEASUREMENT=de_DE.UTF-8;LC_IDENTIFICATION=de_DE.UTF-8'


        b)
                The output of getlocale cannot be used as input to
                setlocale sometimes.
                Works with
                * python2.5 und python2.4 on
                  Debian GNU/Linux Etch ppc, de_DE.utf8.

                I had failures with
                * python2.3, python2.4, python2.5
                  on Debian GNU/Linux Sarge ppc, de_DE at euro
                * Windows XP SP2
                        python-2.4.4.msi    German, see:

                >>> import locale
                >>> result = locale.setlocale(locale.LC_NUMERIC,"")
                >>> print result
                German_Germany.1252
                >>> got = locale.getlocale(locale.LC_NUMERIC)
                >>> print got
                ('de_DE', '1252')
                >>> # works
                ... locale.setlocale(locale.LC_NUMERIC, result)
                'German_Germany.1252'
                >>> # fails
                ... locale.setlocale(locale.LC_NUMERIC, got)
                Traceback (most recent call last):
                  File "<stdin>", line 2, in ?
                  File "C:\Python24\lib\locale.py", line 381, in setlocale
                    return _setlocale(category, locale)
                locale.Error: unsupported locale setting
                >>>



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

>Comment By: Bernhard Reiter (ber)
Date: 2007-05-02 15:25

Message:
Logged In: YES 
user_id=113859
Originator: YES

Marc-Andre,

thanks for your comment!

Note that setlocale() can also be used to query the current locale,
according to my manpage on a Debian GNU/Linux system and also
according to IEEE Std 1003.1, 2004 (POSIX).

This problem report is not invalid in both point.
You cannot deny a), the inconsistency having code that is not allowed a
few sections before in the description is appared.
b) also is a problem that occurss on a freshly installed Python
on a freshly installed German Windows version.
Same on Debian Sarge, depending on the default locale.
So if I use the functions according to the documentation,
this will just break in the real world which is not robust.

I know that it is probably hard to make this more robust,
but it is possible depeding on how the interface of this module
should look like. 

Note that in your remark you believe that Germany_Germany 
call fails,
but this is the one that succeeds because it is the locale
this Python version on windows has set and which setlocale
has returned. It is getlocale() that returns a value which
cannot be used for setlocale() again, despite the documentation.
This makes getlocale() useless for the purpose of getting a locale
setting that could later be reused as input for setlocale.
As setlocale() can do this as well, getlocale() seems to be superfluous.

Best Regards,
Bernhard

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2007-05-02 14:03

Message:
Logged In: YES 
user_id=38388
Originator: NO

I wrote that code, so let me comment on it:

The setlocale() function returns the setting that was previously active
(see the setlocale (3) man-page). 

Unfortunately, there's no clear standard on the way locales are named. The
man-page says:

"""
A locale name is typically of the form
language[_territory][.codeset][@modifier], where language is an ISO 639
language code, territory is an ISO 3166 country code, and codeset is a
character  set
       or encoding identifier like ISO-8859-1 or UTF-8.  For a list of all
supported locales, try "locale -a", cf. locale(1).
"""

"Germany_Germany" is clearly not a locale name that fits the above
scheme.

If I do "locale -a" on my box, the "Germany_Germany" is not mentioned in
the resulting list, so there's no surprise that  the function call
generates an error.

Note that you can set the locale without using setlocale(): all that is
needed is an environment variable and that is, of course, not subject to
any checks by setlocal().

I'd suggest to close this bug report as invalid.

Thanks.

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

Comment By: Bernhard Reiter (ber)
Date: 2007-04-19 12:23

Message:
Logged In: YES 
user_id=113859
Originator: YES

Feel free to drop them an email, this is a good idea.
Maybe "svn blame" or history inspection produces more names that actually
wrote
the code and the documentation.

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

Comment By: Istvan Szegedi (iszegedi)
Date: 2007-04-19 12:18

Message:
Logged In: YES 
user_id=1772412
Originator: NO

Hi Bernhard,

I absolutely agree with you and I cannot  really judge my correction,
either. It was just a quick and dirty solution to see if it would fix the
problem. In fact, there are other ways to do it as well, like  to modify
the 
encoding_alias table not to translate utf-8 string into utf (and thus to
prevent it to produce an invalid locale setting for _setlocale )

In the locale.py file I found two names mentioned:

Author:  Mark-Andre Lemburg (mal at lemburg.com) 
and Fredrick Lund  (fredrick at pythonware.com) as a modifyier

so it might be a good idea to drop them a mail and ask for their comments.
Do you want to do it or shall I? If you are willing to do it, please, keep
me in the loop.

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

Comment By: Bernhard Reiter (ber)
Date: 2007-04-19 10:55

Message:
Logged In: YES 
user_id=113859
Originator: YES

Istvan,
thanks for looking into this and adding information.
I do not feel competent to judge what the solution would be,
as I do not know the design goals of getlocale().
Given the documentation the function call would only make sense
if setlocale(getlocale(LC_XYZ)) would work in all cases, especially
after the locale has been set to the user preferances with
setlocale(LC_ALL,"")
There is no simple test case that can make sure this is the case.

The workaround for current code for me is to use setlocale(LC_XYZ) only
to ask for the currently set locale and then decipher the string if the
categories have different settings. This workaround can be seen in my
proposed test_case.py. 

I believe next steps could be to get a full overview and check design and
implementation, add some testcases so that more is covered and then fix 
the implementation. We could try to find out who invented getlocale
and ask.

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

Comment By: Istvan Szegedi (iszegedi)
Date: 2007-04-19 10:24

Message:
Logged In: YES 
user_id=1772412
Originator: NO

I could reproduce the problem on Fedora Core 5 with Python 2.4.3.

After tracing down the issue, I found the following:

The problem is in locate.py. There is a function called normalize defined
in the locate.py file. This function is invoked by setlocale function if
the incoming locale argument is not a string. (in your example this
condition is true because locale.getlocale function returns a tuple so got
variable is a tuple.) The normalize function is using an encoding_alias
table which results to translate the full locale into an incorrect version.
What happens in my environment is that there is an incoming value
en_us.utf-8  which is converted to en_us.utf and that is the return value
from normalize function. Then _setlocale low level function invoked in
setlocale function throws an exception when it receives en_us.utf  argument
and it is an unsupported locale setting.


This is the original code snippet in locale.py where it is converted in a
wrong way in normalize function:


    # Second try: langname (without encoding)
    code = locale_alias.get(langname, None)
    if code is not None:
        if '.' in code:
            langname, defenc = code.split('.')
        else:
            langname = code
            defenc = ''
        if encoding:
            encoding = encoding_alias.get(encoding, encoding)
        else:
            encoding = defenc
        if encoding:
            return langname + '.' + encoding
        else:
            return langname

    else:
        return localename


To get it fixed, I modified the code in locate.py as follows:


    # Second try: langname (without encoding)
    code = locale_alias.get(langname, None)
    if code is not None:
        if '.' in code:
            langname, defenc = code.split('.')
        else:
            langname = code
            defenc = ''
#        if encoding:
#            encoding = encoding_alias.get(encoding, encoding)
#        else:
#            encoding = defenc
	if encoding is None:
	     encoding = defenc
        if encoding:
            return langname + '.' + encoding
        else:
            return langname

    else:
        return localename


So the effect of encoding_table is skipped. Then your test_locale.py
returns OK.

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

Comment By: Istvan Szegedi (iszegedi)
Date: 2007-04-18 12:05

Message:
Logged In: YES 
user_id=1772412
Originator: NO

I could reproduce the problem on Fedora Core 5 with Python 2.4.3.

After tracing down the issue, I found the following:

The problem is in locate.py. There is a function called normalize defined
in the locate.py file. This function is invoked by setlocale function if
the incoming locale argument is not a string. (in your example this
condition is true because locale.getlocale function returns a tuple so got
variable is a tuple.) The normalize function is using an encoding_alias
table which results to translate the full locale into an incorrect version.
What happens in my environment is that there is an incoming value
en_us.utf-8  which is converted to en_us.utf and that is the return value
from normalize function. Then _setlocale low level function invoked in
setlocale function throws an exception when it receives en_us.utf  argument
and it is an unsupported locale setting.


This is the original code snippet in locale.py where it is converted in a
wrong way in normalize function:


    # Second try: langname (without encoding)
    code = locale_alias.get(langname, None)
    if code is not None:
        if '.' in code:
            langname, defenc = code.split('.')
        else:
            langname = code
            defenc = ''
        if encoding:
            encoding = encoding_alias.get(encoding, encoding)
        else:
            encoding = defenc
        if encoding:
            return langname + '.' + encoding
        else:
            return langname

    else:
        return localename


To get it fixed, I modified the code in locate.py as follows:


    # Second try: langname (without encoding)
    code = locale_alias.get(langname, None)
    if code is not None:
        if '.' in code:
            langname, defenc = code.split('.')
        else:
            langname = code
            defenc = ''
#        if encoding:
#            encoding = encoding_alias.get(encoding, encoding)
#        else:
#            encoding = defenc
	if encoding is None:
	     encoding = defenc
        if encoding:
            return langname + '.' + encoding
        else:
            return langname

    else:
        return localename


So the effect of encoding_table is skipped. Then your test_locale.py
returns OK.

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

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

From noreply at sourceforge.net  Wed May  2 21:23:56 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 02 May 2007 12:23:56 -0700
Subject: [ python-Bugs-1303614 ] Bypassing __dict__ readonlyness
Message-ID: <E1HjKQe-0001PC-RR@sc8-sf-web22.sourceforge.net>

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

Please note that this message 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
Private: No
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bypassing __dict__ readonlyness

Initial Comment:
The __dict__ attribute of some objects is read-only,
e.g. for type objects.  However, there is a generic
way to still access and modify it (without hacking with
gc.get_referrents(), that is).  This can lead to
obscure crashes.  Attached is an example that shows
a potential "problem" involving putting strange keys
in the __dict__ of a type.

This is probably very minor anyway.  If we wanted to
fix this, we would need a __dict__ descriptor that
looks more cleverly at the object to which it is
applied.

BTW the first person who understand why the attached
program crashes gets a free coffee.

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

>Comment By: Armin Rigo (arigo)
Date: 2007-05-02 19:23

Message:
Logged In: YES 
user_id=4771
Originator: YES

Thanks zseil for the patch, which looks really good to me.
For reference, it also contains the fix for #1174712.

Checked in as r55080.

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

Comment By: Ziga Seilnacht (zseil)
Date: 2007-04-19 16:40

Message:
Logged In: YES 
user_id=1326842
Originator: NO

Here is the updated patch.  I also added a few more
tests, and removed the news entry for revision 53997.


File Added: modify_dict_bug2.diff

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

Comment By: Armin Rigo (arigo)
Date: 2007-04-19 14:46

Message:
Logged In: YES 
user_id=4771
Originator: YES

Reverted r53997 in revision 54875.

zseil, could you update your patch for the new
svn head?  Thanks!  It should mostly be a matter
of simplifying it.

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

Comment By: Armin Rigo (arigo)
Date: 2007-04-18 09:22

Message:
Logged In: YES 
user_id=4771
Originator: YES

I'm skeptical about the whole revision 53997
which introduced not only the unneeded metaclass
condition, but also the strange check when
assigning to __bases__.  I don't think that this
check about __bases__ is correct or relevant or
really fixes any crash.  The link between the
bases and the metaclass of a class is tenuous
anyway: the bases are just used to compute the
metaclass if none is specified explicitly.

As I said on python-dev (with no answer) I am
thinking about reverting r53997 completely.
I'm going to check what I said above a bit more
in-depth first.

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

Comment By: Ziga Seilnacht (zseil)
Date: 2007-04-17 00:42

Message:
Logged In: YES 
user_id=1326842
Originator: NO

Here is a patch that shold fix the deldict bug.  It also
removes the new condition for metaclasses, because it
isn't needed anymore, and fixes bug #1174712.  These two
changes were needed so that the patch could be properly
tested.

The patch does what Armin suggested; the __dict__ descriptor
looks for a builtin base with tp_dictoffset != 0, and if one
is found, it delegates to that base's __dict__ descriptor.

File Added: modify_dict_bug.diff

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

Comment By: Armin Rigo (arigo)
Date: 2007-02-26 08:23

Message:
Logged In: YES 
user_id=4771
Originator: YES

456?  Now that's interesting.  Not 579?

I'm not sure if I ever thought about what the
expected answer should be, but I'd say that
you are correct: 'x.__dict__' should be empty
in the end.  Actually I don't really see how
it manages *not* to be empty in IronPython;
looks like either a very minor detail or a
deeper bug...

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

Comment By: Jeremy Hylton (jhylton)
Date: 2007-02-25 22:36

Message:
Logged In: YES 
user_id=31392
Originator: NO

I tried test67.py in IronPython.  It reports that x.hello has the value
456.  Is that the correct behavior?  It seems incorrect to me.  If the
__eq__ method is called, then the object should no longer have either the
Strange() or hello attributes.  They are cleared by reseting __dict__.  Is
that right?

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

Comment By: Jeremy Hylton (jhylton)
Date: 2007-02-25 22:23

Message:
Logged In: YES 
user_id=31392
Originator: NO

I tried test67.py in IronPython.  It reports that x.hello has the value
456.  Is that the correct behavior?  It seems incorrect to me.  If the
__eq__ method is called, then the object should no longer have either the
Strange() or hello attributes.  They are cleared by reseting __dict__.  Is
that right?

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

Comment By: Armin Rigo (arigo)
Date: 2006-06-30 07:05

Message:
Logged In: YES 
user_id=4771

Well, try making an "empty" class Foo(object): pass, and see
what magically shows up in Foo.__dict__.keys().  Here is the
__dict__ descriptor used for instances of Foo.  This
descriptor is connected to subtype_dict() and
subtype_setdict() in typeobject.c.

INCREF/DECREFs are in theory missing around every use of the
dictionary returned by _PyObject_GetDictPtr(), because more
or less any such use could remove the dict from the object
from which _PyObject_GetDictPtr() returned from, and so
decref the dict - while it's used.  This might require some
timing, to check the performance impact.

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

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

Message:
Logged In: YES 
user_id=357491

OK, then I am going to need a little guidance to dive into
this more since this is going into some murky waters for me.  =)

For the normal, non-evil case of an empty Python class
(``class Foo(object): pass``), I would think that accessing
__dict__ would fall through to the tp_getset for object, and
then fall to the same slot for type.  Now that is obviously
not happening since you get a straight dict back for that
attribute access and not a dict proxy as would be suggested
based on my logic listed above.

So, my question is, where is the code that handles fetching
Foo().__dict__?  And if you have an inkling of where I
should be looking in terms of possible refcounting additions
that would be great as well.

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

Comment By: Armin Rigo (arigo)
Date: 2006-06-29 21:19

Message:
Logged In: YES 
user_id=4771

Brett: I think you're approaching the problem from the wrong
angle.  The problem is being allowed to freely tamper with
the dict stored in objects.  Getting NULL errors here and
there is only a symptom.  As I explain, the '__dict__'
descriptor object needs to do some more checks, and to be
fully safe some Py_INCREF/Py_DECREF are needed in some
critical places.

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

Comment By: Brett Cannon (bcannon)
Date: 2006-06-29 17:45

Message:
Logged In: YES 
user_id=357491

For the deldict.py crasher, if you look at the traceback
there is no good place to do a check that tp_dict is sane
except in type_module() or PyDict_GetItem().  Now adding the
NULL check in type_module() will fix this specific problem,
but that seems like an ad-hoc patch.

Why don't we check for NULL in PyDict_GetItem() and return
NULL just like the PyDict_Check() test?  I am sure the
answer is "performance", but this is not PyDict_GETITEM()and
thus already is not the performance-critical version anyway.
 So why shouldn't we check for NULL there and possibly catch
other errors?

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

Comment By: Brett Cannon (bcannon)
Date: 2006-06-29 17:41

Message:
Logged In: YES 
user_id=357491

Simple patch for the loosing_dict_ref.py crasher is
attached.  Just checked for possible NULL values in what is
needed by _Py_ForgetReference().  Let me know what you
think, Armin.

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

Comment By: Michael Hudson (mwh)
Date: 2005-12-14 15:36

Message:
Logged In: YES 
user_id=6656

Yikes!

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

Comment By: Armin Rigo (arigo)
Date: 2005-12-14 15:32

Message:
Logged In: YES 
user_id=4771

A proposed fix for the later crash: the __dict__ descriptor of
user-defined classes should verify if there is another __dict__ descriptor
along the solid path of the type (i.e. following "tp_base" pointers).  If
so, it should delegate to it.

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

Comment By: Armin Rigo (arigo)
Date: 2005-12-14 14:49

Message:
Logged In: YES 
user_id=4771

Uh oh.  There is a much simpler crash.  The technique outlined in
deldict.py can be used to rebind or even delete the __dict__ attribute of
instances where it should normally not be allowed.

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

Comment By: Armin Rigo (arigo)
Date: 2005-09-25 08:55

Message:
Logged In: YES 
user_id=4771

The bug is related to code like PyObject_GenericGetAttribute and
_PyType_Lookup which are not careful about the reference counters of the
objects they operate on.  This allows a much simpler crash (test67.py): the
__dict__ of an object can be decrefed away while lookdict() is looking at
it.  This has a simple fix -- drop some amount of Py_INCREF/Py_DECREF in
core routines like PyObject_GenericGetAttr.  We probably need to measure if
it has a performance impact, though.

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

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

From noreply at sourceforge.net  Wed May  2 21:25:30 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 02 May 2007 12:25:30 -0700
Subject: [ python-Bugs-1174712 ] subclassing ModuleType and another built-in
	type
Message-ID: <E1HjKSA-0001ch-BJ@sc8-sf-web22.sourceforge.net>

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

Please note that this message 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
Private: No
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: subclassing ModuleType and another built-in type

Initial Comment:
class X(types.ModuleType, str): pass
X('name')
-> segfault

This buggy subclassing goes through typeobject.c's checks because PyModuleObject looks exactly like a user-defined subclass of 'object': it has a PyObject_HEAD followed only by the dict, as specified by tp_dictoffset.

A fix would be to forbid any subclassing to move the tp_dictoffset of a non-heap type.

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

>Comment By: Armin Rigo (arigo)
Date: 2007-05-02 19:25

Message:
Logged In: YES 
user_id=4771
Originator: YES

Fixed by zseil's patch for #1303614, r55080.

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

Comment By: Armin Rigo (arigo)
Date: 2005-12-14 14:57

Message:
Logged In: YES 
user_id=4771

The objection to the proposed fix is not valid in light
of the bug #1303614, which gives a general way to abuse
subclassing to allow the __dict__ of an instance to be
assigned to and deleted, even when it should not be allowed.  So I
wouldn't worry too much about the case I pointed up, because it should be
fixed together with #1303614 (though I don't really know how).  For now I
would be happy with just checking that subclassing a non-heap type doesn't
move the dict within the structure.

The same remark probably applies to the weakref field.  Both cases could
be fixed by being more careful in typeobject.c:extra_ivars(): PyModule_Type
should be considered to have extra_ivars() when compared to
PyBaseObject_Type.  This could be achieved by skipping the "t_size -= ..."
part if "type" is not a heap type.  Indeed, for non-heap types we should
not try to consider that an extra dict or weakref slot is not important,
because the C code probably accesses this extra slot directly, as in the
case of moduleobject.c.

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

Comment By: Michael Hudson (mwh)
Date: 2005-04-03 13:39

Message:
Logged In: YES 
user_id=6656

> This might point to the need for cleaning up typeobject.c's
> darker corners...

No kidding.  Maybe Samuele, you and I can gang up on Guido at 
EuroPython (is he sprinting?  Perhaps we should ask).

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

Comment By: Armin Rigo (arigo)
Date: 2005-04-02 12:27

Message:
Logged In: YES 
user_id=4771

The proposed fix is not good enough.  If another built-in C type similar
to PyModuleObject is defined (say by a C extension module), then it would
become possible to subclass both this new type and ModuleType.  This might
lead to unwanted behavior if e.g. one parent class allows rebinding
__dict__ and the other not (and crashes if __dict__ is rebound).

This might point to the need for cleaning up typeobject.c's darker
corners...

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

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

From noreply at sourceforge.net  Wed May  2 21:42:34 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 02 May 2007 12:42:34 -0700
Subject: [ python-Bugs-1180193 ] broken pyc files
Message-ID: <E1HjKig-0000Zx-PO@sc8-sf-web23.sourceforge.net>

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

Please note that this message 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
Private: No
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: broken pyc files

Initial Comment:
In a number of situations, the .pyc files can become "corrupted" in a subtle way: the co_filename attribute of the code objects it contains become wrong.  This can occur if we move or rename directories, or if we access the same set of files from two different locations (e.g. over NFS).

This corruption doesn't prevent the .pyc files from working, but the interpreter looses the reference to the source file.  It causes trouble in tracebacks, in the inspect module, etc.

A simple fix would be to use the following logic when importing a .py file: if there is a corresponding .pyc file, in addition to checking the timestamp, check the co_filename attribute of the loaded object.  If it doesn't point to the original .py file, discard the code object and ignore the .pyc file.

Alternatively, we could force all co_filenames to point to the .py file when loading the .pyc file.

I'll write a patch for whichever alternative seems better.

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

>Comment By: Armin Rigo (arigo)
Date: 2007-05-02 19:42

Message:
Logged In: YES 
user_id=4771
Originator: YES

It's an obscure detail, but I think that the
.pyc file should not be rewritten again after we
fix the co_filenames.  Fixing the co_filenames
is a very very cheap operation, and I can imagine
cases where the same .py files are accessed from
what appears to be two different paths, e.g. over
NFS - this would cause .pyc files to be rewritten
all the time, which is particularly bad if we
have the example of NFS in mind.  Not to mention
that two python processes trying to write
*different* data to the same .pyc file at the
same time are going to create a mess, ending in
a segfault the next time the broken .pyc is
loaded.

It's overall a mess, so let's play it safe.

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

Comment By: Ziga Seilnacht (zseil)
Date: 2007-04-24 10:01

Message:
Logged In: YES 
user_id=1326842
Originator: NO

Here is a patch that implements arigo's last suggestion.

File Added: update_co_filename.diff

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

Comment By: Ziga Seilnacht (zseil)
Date: 2007-04-03 13:46

Message:
Logged In: YES 
user_id=1326842
Originator: NO

Wouldn't your first solution be simpler? Changing all
co_filenames would require either changing various
marhal.c functions, or traversing the code object
returned by import.c/read_compiled_module().

Discarding the compiled code when the file names don't
match would be simpler and only require minor changes
in import.c/load_source_module().


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

Comment By: Armin Rigo (arigo)
Date: 2007-04-03 11:31

Message:
Logged In: YES 
user_id=4771
Originator: YES

If you ask me, I think that when the importing
system finds both a .py and a .pyc for a module,
then it should ignore all co_filename and replace
them with the real path of the .py file.  I can't
see any point of not doing so.

There are many other quirks caused by .pyc files
accidentally remaining around, but we cannot fix them
all as long as the .pyc files are at the same time
a cache for performance reason and a redistributable
program format (e.g. if "rm x.py" or "svn up" deletes
a .py file, then the module is still importable via
the .pyc left behind, a great way to oversee the fact
that imports elsewhere in the project need to be
updated).

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

Comment By: Ziga Seilnacht (zseil)
Date: 2007-04-03 07:16

Message:
Logged In: YES 
user_id=1326842
Originator: NO

This problem is reported quite often in the tracker,
although it shows up in different places:

http://www.python.org/sf/1666807
http://www.python.org/sf/1051638

I closed those bugs as duplicates of this one.

The logging package is also affected:

http://www.python.org/sf/1669498
http://www.python.org/sf/1633605
http://www.python.org/sf/1616422


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

Comment By: Armin Rigo (arigo)
Date: 2007-03-28 13:40

Message:
Logged In: YES 
user_id=4771
Originator: YES

What I called "corruption" is the situation
where both the .py and the .pyc files are
present, but the filename stored in the .pyc
co_filenames is no longer the valid absolute
path of the corresponding .py file, for any
reason (renaming, NFS views, etc.).

This situation causes the tracebacks and the
inspect module to fail to locate the .py file,
which I consider a bug.

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

Comment By: Martin v. L?wis (loewis)
Date: 2007-03-28 12:01

Message:
Logged In: YES 
user_id=21627
Originator: NO

I fail to see the corruption. It is quite desirable and normal to only
ship pyc files - that the file name they refer to is actually present is
not a requirement at all.

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

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

From noreply at sourceforge.net  Thu May  3 02:28:38 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 02 May 2007 17:28:38 -0700
Subject: [ python-Bugs-1711605 ] CGIHttpServer leaves traces of previous
	requests in env
Message-ID: <E1HjPBW-0001QV-14@sc8-sf-web23.sourceforge.net>

Bugs item #1711605, was opened at 2007-05-03 10: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=1711605&group_id=5470

Please note that this 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
Private: No
Submitted By: Steve Cassidy (stevecassidy)
Assigned to: Nobody/Anonymous (nobody)
Summary: CGIHttpServer leaves traces of previous requests in env

Initial Comment:
CGIHttpserver tries to reset the environment between calls to CGI scripts by setting various variables to '' if they are not needed in the current request. In some cases this is not the correct behaviour since the presence of a null value can be interpreted by a CGI script as being significant. 

For example, if HTTP_COOKIE has a null value then a script doing the standard test:

if os.environ.has_key('HTTP_COOKIE'):
   # get the cookie

will have trouble

The problem is that CGIHTTPserver.py resets the entries in the env array which is then passed to os.environ.update(), this can only overwrite the env variables, not remove them.

An alternative is to call 

if os.environ.has_key(k):
    del os.environ[k]

inside the loop that updates the empty keys, then these variables will not be passed on to the CGI script.

Steve


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

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

From noreply at sourceforge.net  Thu May  3 02:34:08 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 02 May 2007 17:34:08 -0700
Subject: [ python-Bugs-1711608 ] CGIHttpServer fails if python exe has spaces
Message-ID: <E1HjPGq-00069z-2c@sc8-sf-web21.sourceforge.net>

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

Please note that this 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
Private: No
Submitted By: Steve Cassidy (stevecassidy)
Assigned to: Nobody/Anonymous (nobody)
Summary: CGIHttpServer fails if python exe has spaces

Initial Comment:
In addition to the problem noted in #1436206 with spaces in the file names of scripts being executed, if Python has been installed in a directory with spaces (C:\Program Files\Python) the server will fail to execute the script because the name of the executable is not quoted properly.

My attempts to fix this have failed since just putting quotes around the exe name "C:\\Program Files\..." doesn't work, however we have found that just quoting the part of the path with spaces 'C:\\"Program Files"\\...' will work.  

It seems a bit odd that this bug has persisted for so long. A fix would be nice since this module is really good to give to my students (doing python web development for the first time) so they don't have to worry about server installation issues. 

Steve



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

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

From noreply at sourceforge.net  Thu May  3 12:24:47 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 03 May 2007 03:24:47 -0700
Subject: [ python-Bugs-1711800 ] SequenceMatcher bug with insert/delete block
	after "replace"
Message-ID: <E1HjYUR-0003RP-W0@sc8-sf-web24.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Christian Hammond (chipx86)
Assigned to: Nobody/Anonymous (nobody)
Summary: SequenceMatcher bug with insert/delete block after "replace"

Initial Comment:
difflib.SequenceMatcher fails to distinguish between a "replace" block and an "insert" or "delete" block when the "insert/delete" immediately follows a "replace". It will lump both changes together as one big "replace" block.

This happens due to how get_opcodes() works. get_opcodes() loops through the matching blocks, grouping them into tags and ranges. However, if a block of text is changed and then new text is immediately added, it can't see this. All it knows is that the next matching block is after the added text.

As an example, consider these strings:

"ABC"

"ABCD
EFG."

Any diffing program will show that the first line was replaced and the second was inserted. SequenceMatcher, however, just shows that there was one replace, and includes both lines in the range.

I've attached a testcase that reproduces this for both replace>insert and replace>delete blocks.

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

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

From noreply at sourceforge.net  Thu May  3 16:08:01 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 03 May 2007 07:08:01 -0700
Subject: [ python-Bugs-1701389 ] utf-16 codec problems with multiple file
	append
Message-ID: <E1HjbyT-0004II-AV@sc8-sf-web23.sourceforge.net>

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

Please note that this 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.5
Status: Closed
Resolution: Remind
Priority: 5
Private: No
Submitted By: Iceberg Luo (iceberg4ever)
Assigned to: M.-A. Lemburg (lemburg)
Summary: utf-16 codec problems with multiple file append

Initial Comment:
This bug is similar but not exactly the same as bug215974.  (http://sourceforge.net/tracker/?group_id=5470&atid=105470&aid=215974&func=detail)

In my test, even multiple write() within an open()~close() lifespan will not cause the multi BOM phenomena mentioned in bug215974. Maybe it is because bug 215974 was somehow fixed during the past 7 years, although Lemburg classified it as WontFix. 

However, if a file is appended for more than once, by an "codecs.open('file.txt', 'a', 'utf16')", the multi BOM appears.

At the same time, the saying of "(Extra unnecessary) BOM marks are removed from the input stream by the Python UTF-16 codec" in bug215974 is not true even in today, on Python2.4.4 and Python2.5.1c1 on Windows XP.

Iceberg
------------------

PS: Did not find the "File Upload" checkbox mentioned in this web page, so I think I'd better paste the code right here...

import codecs, os

filename = "test.utf-16"
if os.path.exists(filename): os.unlink(filename)  # reset

def myOpen():
  return codecs.open(filename, "a", 'UTF-16')
def readThemBack():
  return list( codecs.open(filename, "r", 'UTF-16') )
def clumsyPatch(raw): # you can read it after your first run of this program
  for line in raw:
    if line[0] in (u'\ufffe', u'\ufeff'): # get rid of the BOMs
      yield line[1:]
    else:
      yield line

fout = myOpen()
fout.write(u"ab\n") # to simplify the problem, I only use ASCII chars here
fout.write(u"cd\n")
fout.close()
print readThemBack()
assert readThemBack() == [ u'ab\n', u'cd\n' ]
assert os.stat(filename).st_size == 14  # Only one BOM in the file

fout = myOpen()
fout.write(u"ef\n")
fout.write(u"gh\n")
fout.close()
print readThemBack()
#print list( clumsyPatch( readThemBack() ) )  # later you can enable this fix
assert readThemBack() == [ u'ab\n', u'cd\n', u'ef\n', u'gh\n' ] # fails here
assert os.stat(filename).st_size == 26  # not to mention here: multi BOM appears


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

>Comment By: Iceberg Luo (iceberg4ever)
Date: 2007-05-03 22:08

Message:
Logged In: YES 
user_id=1770538
Originator: YES

The longtime arguable ZWNBSP is deprecated nowadays ( the
http://www.unicode.org/unicode/faq/utf_bom.html#24 suggests a "U+2060 WORD
JOINER" instead of ZWNBSP ). However I can understand that "backwards
compatibility" is always a good concern, and that's why SteamReader seems
reluctant to change.

In practice, a ZWNBSP inside a file is rarely intended (please also refer
to the topic "Q: What should I do with U+FEFF in the middle of a file?" in
same URL above). IMHO, it is very likely caused by the multi-append file
operation or etc. Well, at least, the unsymmetric "what you write is NOT
what you get/read" effect between "codecs.open(filename, 'a', 'UTF-16')"
and "codecs.open(filename, 'r', 'UTF-16')" is not elegant enough.

Aiming at the unsymmetry, finally I come up with a wrapper function for
the codecs.open(), which solve (or you may say "bypass") the problem well
in my case. I'll post the code as attachment.

BTW, even the official document of Python2.4, chapter "7.3.2.1 Built-in
Codecs", mentions that the:
   PyObject* PyUnicode_DecodeUTF16( const char *s, int size, const char
*errors, int *byteorder)
can "switches according to all byte order marks (BOM) it finds in the
input data. BOMs are not copied into the resulting Unicode string".  I
don't know whether it is the BOM-less decoder we talked for long time.
//shrug

Hope the information above can be some kind of recipe for those who
encounter same problem.  That's it. Thanks for your patience.

Best regards,
                            Iceberg
File Added: _codecs.py

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

Comment By: Walter D?rwald (doerwalter)
Date: 2007-04-23 18:56

Message:
Logged In: YES 
user_id=89016
Originator: NO

But BOMs *may* appear in normal content: Then their meaning is that of
ZERO WIDTH NO-BREAK SPACE (see
http://docs.python.org/lib/encodings-overview.html for more info).


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

Comment By: Iceberg Luo (iceberg4ever)
Date: 2007-04-20 11:39

Message:
Logged In: YES 
user_id=1770538
Originator: YES

If such a bug would be fixed, either StreamWriter or StreamReader should
do something.

I can understand Doerwalter that it is somewhat not comfortable for a
StreamWriter to detect whether these is already a BOM at current file
header, especially when operating in append mode. But, IMHO, the
StreamReader should be able to detect multi BOM during its life span and
automatically ignore the non-first one, providing that a BOM is never
supposed to occur in normal content.  Not to mention that such a Reader
seems exist for a while, according to the "(extra unnecessary) BOM marks
are removed
from the input stream by the Python UTF-16 codec" in bug215974
(http://sourceforge.net/tracker/?group_id=5470&atid=105470&aid=215974&func=
detail).

Therefore I don't think a WontFix will be the proper FINAL solution for
this case.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2007-04-19 19:30

Message:
Logged In: YES 
user_id=89016
Originator: NO

Closing as "won't fix"

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2007-04-19 18:35

Message:
Logged In: YES 
user_id=38388
Originator: NO

I suggest you close this as wont fix.


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

Comment By: Walter D?rwald (doerwalter)
Date: 2007-04-19 18:30

Message:
Logged In: YES 
user_id=89016
Originator: NO

append mode is simply not supported for codecs. How would the codec find
out the codec state that was active after the last characters where written
to the file?

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

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

From noreply at sourceforge.net  Thu May  3 17:03:57 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 03 May 2007 08:03:57 -0700
Subject: [ python-Bugs-1701389 ] utf-16 codec problems with multiple file
	append
Message-ID: <E1Hjcqb-0005lb-FN@sc8-sf-web21.sourceforge.net>

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

Please note that this 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.5
Status: Closed
Resolution: Remind
Priority: 5
Private: No
Submitted By: Iceberg Luo (iceberg4ever)
Assigned to: M.-A. Lemburg (lemburg)
Summary: utf-16 codec problems with multiple file append

Initial Comment:
This bug is similar but not exactly the same as bug215974.  (http://sourceforge.net/tracker/?group_id=5470&atid=105470&aid=215974&func=detail)

In my test, even multiple write() within an open()~close() lifespan will not cause the multi BOM phenomena mentioned in bug215974. Maybe it is because bug 215974 was somehow fixed during the past 7 years, although Lemburg classified it as WontFix. 

However, if a file is appended for more than once, by an "codecs.open('file.txt', 'a', 'utf16')", the multi BOM appears.

At the same time, the saying of "(Extra unnecessary) BOM marks are removed from the input stream by the Python UTF-16 codec" in bug215974 is not true even in today, on Python2.4.4 and Python2.5.1c1 on Windows XP.

Iceberg
------------------

PS: Did not find the "File Upload" checkbox mentioned in this web page, so I think I'd better paste the code right here...

import codecs, os

filename = "test.utf-16"
if os.path.exists(filename): os.unlink(filename)  # reset

def myOpen():
  return codecs.open(filename, "a", 'UTF-16')
def readThemBack():
  return list( codecs.open(filename, "r", 'UTF-16') )
def clumsyPatch(raw): # you can read it after your first run of this program
  for line in raw:
    if line[0] in (u'\ufffe', u'\ufeff'): # get rid of the BOMs
      yield line[1:]
    else:
      yield line

fout = myOpen()
fout.write(u"ab\n") # to simplify the problem, I only use ASCII chars here
fout.write(u"cd\n")
fout.close()
print readThemBack()
assert readThemBack() == [ u'ab\n', u'cd\n' ]
assert os.stat(filename).st_size == 14  # Only one BOM in the file

fout = myOpen()
fout.write(u"ef\n")
fout.write(u"gh\n")
fout.close()
print readThemBack()
#print list( clumsyPatch( readThemBack() ) )  # later you can enable this fix
assert readThemBack() == [ u'ab\n', u'cd\n', u'ef\n', u'gh\n' ] # fails here
assert os.stat(filename).st_size == 26  # not to mention here: multi BOM appears


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

>Comment By: Walter D?rwald (doerwalter)
Date: 2007-05-03 17:03

Message:
Logged In: YES 
user_id=89016
Originator: NO

>BTW, even the official document of Python2.4, chapter "7.3.2.1 Built-in
> Codecs", mentions that the:
>   PyObject* PyUnicode_DecodeUTF16( const char *s, int size, const char
> *errors, int *byteorder)
> can "switches according to all byte order marks (BOM) it finds in the
> input data. BOMs are not copied into the resulting Unicode string".  I
> don't know whether it is the BOM-less decoder we talked for long time.

This seems to be wrong. Looking at the source code
(Objects/unicodeobjects.c) reveals that only the first BOM is skipped.


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

Comment By: Iceberg Luo (iceberg4ever)
Date: 2007-05-03 16:08

Message:
Logged In: YES 
user_id=1770538
Originator: YES

The longtime arguable ZWNBSP is deprecated nowadays ( the
http://www.unicode.org/unicode/faq/utf_bom.html#24 suggests a "U+2060 WORD
JOINER" instead of ZWNBSP ). However I can understand that "backwards
compatibility" is always a good concern, and that's why SteamReader seems
reluctant to change.

In practice, a ZWNBSP inside a file is rarely intended (please also refer
to the topic "Q: What should I do with U+FEFF in the middle of a file?" in
same URL above). IMHO, it is very likely caused by the multi-append file
operation or etc. Well, at least, the unsymmetric "what you write is NOT
what you get/read" effect between "codecs.open(filename, 'a', 'UTF-16')"
and "codecs.open(filename, 'r', 'UTF-16')" is not elegant enough.

Aiming at the unsymmetry, finally I come up with a wrapper function for
the codecs.open(), which solve (or you may say "bypass") the problem well
in my case. I'll post the code as attachment.

BTW, even the official document of Python2.4, chapter "7.3.2.1 Built-in
Codecs", mentions that the:
   PyObject* PyUnicode_DecodeUTF16( const char *s, int size, const char
*errors, int *byteorder)
can "switches according to all byte order marks (BOM) it finds in the
input data. BOMs are not copied into the resulting Unicode string".  I
don't know whether it is the BOM-less decoder we talked for long time.
//shrug

Hope the information above can be some kind of recipe for those who
encounter same problem.  That's it. Thanks for your patience.

Best regards,
                            Iceberg
File Added: _codecs.py

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

Comment By: Walter D?rwald (doerwalter)
Date: 2007-04-23 12:56

Message:
Logged In: YES 
user_id=89016
Originator: NO

But BOMs *may* appear in normal content: Then their meaning is that of
ZERO WIDTH NO-BREAK SPACE (see
http://docs.python.org/lib/encodings-overview.html for more info).


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

Comment By: Iceberg Luo (iceberg4ever)
Date: 2007-04-20 05:39

Message:
Logged In: YES 
user_id=1770538
Originator: YES

If such a bug would be fixed, either StreamWriter or StreamReader should
do something.

I can understand Doerwalter that it is somewhat not comfortable for a
StreamWriter to detect whether these is already a BOM at current file
header, especially when operating in append mode. But, IMHO, the
StreamReader should be able to detect multi BOM during its life span and
automatically ignore the non-first one, providing that a BOM is never
supposed to occur in normal content.  Not to mention that such a Reader
seems exist for a while, according to the "(extra unnecessary) BOM marks
are removed
from the input stream by the Python UTF-16 codec" in bug215974
(http://sourceforge.net/tracker/?group_id=5470&atid=105470&aid=215974&func=
detail).

Therefore I don't think a WontFix will be the proper FINAL solution for
this case.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2007-04-19 13:30

Message:
Logged In: YES 
user_id=89016
Originator: NO

Closing as "won't fix"

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2007-04-19 12:35

Message:
Logged In: YES 
user_id=38388
Originator: NO

I suggest you close this as wont fix.


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

Comment By: Walter D?rwald (doerwalter)
Date: 2007-04-19 12:30

Message:
Logged In: YES 
user_id=89016
Originator: NO

append mode is simply not supported for codecs. How would the codec find
out the codec state that was active after the last characters where written
to the file?

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

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

From noreply at sourceforge.net  Thu May  3 19:12:48 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 03 May 2007 10:12:48 -0700
Subject: [ python-Bugs-1701389 ] utf-16 codec problems with multiple file
	append
Message-ID: <E1HjerI-0008RP-MT@sc8-sf-web23.sourceforge.net>

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

Please note that this 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.5
Status: Closed
Resolution: Remind
Priority: 5
Private: No
Submitted By: Iceberg Luo (iceberg4ever)
Assigned to: M.-A. Lemburg (lemburg)
Summary: utf-16 codec problems with multiple file append

Initial Comment:
This bug is similar but not exactly the same as bug215974.  (http://sourceforge.net/tracker/?group_id=5470&atid=105470&aid=215974&func=detail)

In my test, even multiple write() within an open()~close() lifespan will not cause the multi BOM phenomena mentioned in bug215974. Maybe it is because bug 215974 was somehow fixed during the past 7 years, although Lemburg classified it as WontFix. 

However, if a file is appended for more than once, by an "codecs.open('file.txt', 'a', 'utf16')", the multi BOM appears.

At the same time, the saying of "(Extra unnecessary) BOM marks are removed from the input stream by the Python UTF-16 codec" in bug215974 is not true even in today, on Python2.4.4 and Python2.5.1c1 on Windows XP.

Iceberg
------------------

PS: Did not find the "File Upload" checkbox mentioned in this web page, so I think I'd better paste the code right here...

import codecs, os

filename = "test.utf-16"
if os.path.exists(filename): os.unlink(filename)  # reset

def myOpen():
  return codecs.open(filename, "a", 'UTF-16')
def readThemBack():
  return list( codecs.open(filename, "r", 'UTF-16') )
def clumsyPatch(raw): # you can read it after your first run of this program
  for line in raw:
    if line[0] in (u'\ufffe', u'\ufeff'): # get rid of the BOMs
      yield line[1:]
    else:
      yield line

fout = myOpen()
fout.write(u"ab\n") # to simplify the problem, I only use ASCII chars here
fout.write(u"cd\n")
fout.close()
print readThemBack()
assert readThemBack() == [ u'ab\n', u'cd\n' ]
assert os.stat(filename).st_size == 14  # Only one BOM in the file

fout = myOpen()
fout.write(u"ef\n")
fout.write(u"gh\n")
fout.close()
print readThemBack()
#print list( clumsyPatch( readThemBack() ) )  # later you can enable this fix
assert readThemBack() == [ u'ab\n', u'cd\n', u'ef\n', u'gh\n' ] # fails here
assert os.stat(filename).st_size == 26  # not to mention here: multi BOM appears


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

>Comment By: Walter D?rwald (doerwalter)
Date: 2007-05-03 19:12

Message:
Logged In: YES 
user_id=89016
Originator: NO

OK, I've updated the documentation (r55094, r55095)

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

Comment By: Walter D?rwald (doerwalter)
Date: 2007-05-03 17:03

Message:
Logged In: YES 
user_id=89016
Originator: NO

>BTW, even the official document of Python2.4, chapter "7.3.2.1 Built-in
> Codecs", mentions that the:
>   PyObject* PyUnicode_DecodeUTF16( const char *s, int size, const char
> *errors, int *byteorder)
> can "switches according to all byte order marks (BOM) it finds in the
> input data. BOMs are not copied into the resulting Unicode string".  I
> don't know whether it is the BOM-less decoder we talked for long time.

This seems to be wrong. Looking at the source code
(Objects/unicodeobjects.c) reveals that only the first BOM is skipped.


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

Comment By: Iceberg Luo (iceberg4ever)
Date: 2007-05-03 16:08

Message:
Logged In: YES 
user_id=1770538
Originator: YES

The longtime arguable ZWNBSP is deprecated nowadays ( the
http://www.unicode.org/unicode/faq/utf_bom.html#24 suggests a "U+2060 WORD
JOINER" instead of ZWNBSP ). However I can understand that "backwards
compatibility" is always a good concern, and that's why SteamReader seems
reluctant to change.

In practice, a ZWNBSP inside a file is rarely intended (please also refer
to the topic "Q: What should I do with U+FEFF in the middle of a file?" in
same URL above). IMHO, it is very likely caused by the multi-append file
operation or etc. Well, at least, the unsymmetric "what you write is NOT
what you get/read" effect between "codecs.open(filename, 'a', 'UTF-16')"
and "codecs.open(filename, 'r', 'UTF-16')" is not elegant enough.

Aiming at the unsymmetry, finally I come up with a wrapper function for
the codecs.open(), which solve (or you may say "bypass") the problem well
in my case. I'll post the code as attachment.

BTW, even the official document of Python2.4, chapter "7.3.2.1 Built-in
Codecs", mentions that the:
   PyObject* PyUnicode_DecodeUTF16( const char *s, int size, const char
*errors, int *byteorder)
can "switches according to all byte order marks (BOM) it finds in the
input data. BOMs are not copied into the resulting Unicode string".  I
don't know whether it is the BOM-less decoder we talked for long time.
//shrug

Hope the information above can be some kind of recipe for those who
encounter same problem.  That's it. Thanks for your patience.

Best regards,
                            Iceberg
File Added: _codecs.py

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

Comment By: Walter D?rwald (doerwalter)
Date: 2007-04-23 12:56

Message:
Logged In: YES 
user_id=89016
Originator: NO

But BOMs *may* appear in normal content: Then their meaning is that of
ZERO WIDTH NO-BREAK SPACE (see
http://docs.python.org/lib/encodings-overview.html for more info).


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

Comment By: Iceberg Luo (iceberg4ever)
Date: 2007-04-20 05:39

Message:
Logged In: YES 
user_id=1770538
Originator: YES

If such a bug would be fixed, either StreamWriter or StreamReader should
do something.

I can understand Doerwalter that it is somewhat not comfortable for a
StreamWriter to detect whether these is already a BOM at current file
header, especially when operating in append mode. But, IMHO, the
StreamReader should be able to detect multi BOM during its life span and
automatically ignore the non-first one, providing that a BOM is never
supposed to occur in normal content.  Not to mention that such a Reader
seems exist for a while, according to the "(extra unnecessary) BOM marks
are removed
from the input stream by the Python UTF-16 codec" in bug215974
(http://sourceforge.net/tracker/?group_id=5470&atid=105470&aid=215974&func=
detail).

Therefore I don't think a WontFix will be the proper FINAL solution for
this case.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2007-04-19 13:30

Message:
Logged In: YES 
user_id=89016
Originator: NO

Closing as "won't fix"

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2007-04-19 12:35

Message:
Logged In: YES 
user_id=38388
Originator: NO

I suggest you close this as wont fix.


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

Comment By: Walter D?rwald (doerwalter)
Date: 2007-04-19 12:30

Message:
Logged In: YES 
user_id=89016
Originator: NO

append mode is simply not supported for codecs. How would the codec find
out the codec state that was active after the last characters where written
to the file?

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

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

From noreply at sourceforge.net  Thu May  3 20:20:45 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 03 May 2007 11:20:45 -0700
Subject: [ python-Bugs-1712236 ] __getslice__ changes integer arguments
Message-ID: <E1Hjfv3-0004Hy-O3@sc8-sf-web21.sourceforge.net>

Bugs item #1712236, was opened at 2007-05-03 21: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=1712236&group_id=5470

Please note that this message 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
Private: No
Submitted By: Imri Goldberg (lorgandon)
Assigned to: Nobody/Anonymous (nobody)
Summary: __getslice__ changes integer arguments

Initial Comment:
When using slicing for a sequence object, with a user defined __getslice__ function, the arguments to __getslice__ are changed.
This does not happen when __getslice__is called directly.
Attached is some code that demonstrates the problem.

I checked it on various versions, including my
"Python 2.5.1 (r251:54863, May  2 2007, 16:56:35)", on my Ubuntu machine.

Although __getslice__ is deprecated, there is still usage of the function, and a fix would be useful.

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

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

From noreply at sourceforge.net  Thu May  3 20:23:00 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 03 May 2007 11:23:00 -0700
Subject: [ python-Bugs-1712236 ] __getslice__ changes integer arguments
Message-ID: <E1HjfxE-0005SF-3H@sc8-sf-web22.sourceforge.net>

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

Please note that this message 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
Private: No
Submitted By: Imri Goldberg (lorgandon)
Assigned to: Nobody/Anonymous (nobody)
Summary: __getslice__ changes integer arguments

Initial Comment:
When using slicing for a sequence object, with a user defined __getslice__ function, the arguments to __getslice__ are changed.
This does not happen when __getslice__is called directly.
Attached is some code that demonstrates the problem.

I checked it on various versions, including my
"Python 2.5.1 (r251:54863, May  2 2007, 16:56:35)", on my Ubuntu machine.

Although __getslice__ is deprecated, there is still usage of the function, and a fix would be useful.

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

>Comment By: Imri Goldberg (lorgandon)
Date: 2007-05-03 21:23

Message:
Logged In: YES 
user_id=1715564
Originator: YES

This also seems to be the cause of bug "[ 908441 ] default index for
__getslice__ is not sys.maxint"

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

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

From noreply at sourceforge.net  Fri May  4 00:49:23 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 03 May 2007 15:49:23 -0700
Subject: [ python-Bugs-1712419 ] Cannot use dict with unicode keys as keyword
	arguments
Message-ID: <E1Hjk71-0004vi-6q@sc8-sf-web21.sourceforge.net>

Bugs item #1712419, was opened at 2007-05-04 00: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=1712419&group_id=5470

Please note that this 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.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Viktor Ferenczi (complex)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Cannot use dict with unicode keys as keyword arguments

Initial Comment:
Unicode strings cannot be used as keys in dictionaries passed as keyword argument to a function. For example:

Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> def fn(**kw):
...     print repr(kw)
...
>>> fn(**{u'x':1})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: fn() keywords must be strings
>>>

Unicode strings should be converted to str automatically using the site specific default encoding or something similar solution.

This bug caused problems when decoding dictionaries from data formats such as XML or JSON. Usually unicode strings are returned from such modules, such as simplejson. Manual encoding from unicode to str causes performance loss if this cannot be done by Python automatically.

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

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

From noreply at sourceforge.net  Fri May  4 06:10:06 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 03 May 2007 21:10:06 -0700
Subject: [ python-Feature Requests-1712419 ] Cannot use dict with unicode keys
	as keyword arguments
Message-ID: <E1Hjp7O-0000G5-7a@sc8-sf-web23.sourceforge.net>

Feature Requests item #1712419, was opened at 2007-05-03 22:49
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1712419&group_id=5470

Please note that this 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
Private: No
Submitted By: Viktor Ferenczi (complex)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Cannot use dict with unicode keys as keyword arguments

Initial Comment:
Unicode strings cannot be used as keys in dictionaries passed as keyword argument to a function. For example:

Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> def fn(**kw):
...     print repr(kw)
...
>>> fn(**{u'x':1})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: fn() keywords must be strings
>>>

Unicode strings should be converted to str automatically using the site specific default encoding or something similar solution.

This bug caused problems when decoding dictionaries from data formats such as XML or JSON. Usually unicode strings are returned from such modules, such as simplejson. Manual encoding from unicode to str causes performance loss if this cannot be done by Python automatically.

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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-04 04:10

Message:
Logged In: YES 
user_id=849994
Originator: NO

In any case, this is a feature request.

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

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

From noreply at sourceforge.net  Fri May  4 08:11:55 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 03 May 2007 23:11:55 -0700
Subject: [ python-Bugs-1712522 ] urllib.quote throws exception on Unicode URL
Message-ID: <E1Hjr1H-0007Ls-F3@sc8-sf-web21.sourceforge.net>

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

Please note that this message will contain 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
Private: No
Submitted By: John Nagle (nagle)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib.quote throws exception on Unicode URL

Initial Comment:
The code in urllib.quote fails on Unicode input, when
called by robotparser with a Unicode URL.

Traceback (most recent call last):
File "./sitetruth/InfoSitePage.py", line 415, in run
pagetree = self.httpfetch() # fetch page
File "./sitetruth/InfoSitePage.py", line 368, in httpfetch
if not self.owner().checkrobotaccess(self.requestedurl) : # if access disallowed by robots.txt file
File "./sitetruth/InfoSiteContent.py", line 446, in checkrobotaccess
return(self.robotcheck.can_fetch(config.kuseragent, url)) # return can fetch
File "/usr/local/lib/python2.5/robotparser.py", line 159, in can_fetch
url = urllib.quote(urlparse.urlparse(urllib.unquote(url))[2]) or "/"
File "/usr/local/lib/python2.5/urllib.py", line 1197, in quote
res = map(safe_map.__getitem__, s)
KeyError: u'\xe2'

   That bit of code needs some attention.  
- It still assumes ASCII goes up to 255, which hasn't been true in Python for a while now.
- The initialization may not be thread-safe; a table is being initialized on first use.

"robotparser" was trying to check if a URL with a Unicode character in it was allowed.  Note the "KeyError: u'\xe2'" 

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

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

From noreply at sourceforge.net  Fri May  4 09:26:00 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 04 May 2007 00:26:00 -0700
Subject: [ python-Bugs-1710703 ] zipfile.ZipFile behavior inconsistent.
Message-ID: <E1HjsAy-0007VW-4J@sc8-sf-web24.sourceforge.net>

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

Please note that this message will contain a full 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
Private: No
Submitted By: Mark Flacy (markaflacy)
Assigned to: Nobody/Anonymous (nobody)
Summary: zipfile.ZipFile behavior inconsistent.

Initial Comment:
In short, ZipFile() will not write the Central Directory entry unless you have added a file to it.  That makes it impossible to create a valid empty zip archive.

In one of my applications, I have the need to extract a partial set of information from one zip file and insert it into another.  There are valid use cases where the source zip archive will not have any of the files which I am looking for.  In Python 2.4, I would end up with an empty file which was considered to be a valid empty zip archive.  In Python 2.5, an empty file is not considered a valid zip archive.  

One would reasonably expect that creating a new ZipFile(mode="r") and successfully closing it without writing any entries would result in a valid zip archive that could be re-opened later without throwing an exception.



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

>Comment By: Mark Flacy (markaflacy)
Date: 2007-05-04 02:26

Message:
Logged In: YES 
user_id=1344993
Originator: YES

No wonder you're confused.  My description of how 2.4 worked was flat-out
wrong; empty files opened as zip files will throw IOExceptions and have
done so since 2.4 at least (I didn't look further back than that). 
However, it *is* the case that 2.4 would correctly write the Central
Directory entry on zipfile close for "w" and "a" modes, even for zip files
that never had any entries written into them.

In 2.4, the ZipFile.close() method contains the line...

        if self.mode in ("w", "a"):             # write ending records

...while in 2.5, the test was changed to...

        if self.mode in ("w", "a") and self._didModify: # write ending
records

That change was added in revision 46967 as part of the ZIP64 support and
that change breaks backwards compatibility (as well as not making a lot of
sense for the "w" case).

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-02 01:06

Message:
Logged In: YES 
user_id=33168
Originator: NO

Mark, can you create a patch for zipfile to make it do what you want?  Do
the docs mention anything about this either way?  Perhaps the docs also
need updating?

I don't know about what happened here, but I'm guessing there was some bug
fix.  This change could have been intentional or not.  I patch will help us
figure out what went wrong and how to proceed.  

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

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

From noreply at sourceforge.net  Fri May  4 12:27:52 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 04 May 2007 03:27:52 -0700
Subject: [ python-Feature Requests-1712419 ] Cannot use dict with unicode keys
	as keyword arguments
Message-ID: <E1Hjv0y-0006wm-Ls@sc8-sf-web24.sourceforge.net>

Feature Requests item #1712419, was opened at 2007-05-04 00:49
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1712419&group_id=5470

Please note that this 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
Private: No
Submitted By: Viktor Ferenczi (complex)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Cannot use dict with unicode keys as keyword arguments

Initial Comment:
Unicode strings cannot be used as keys in dictionaries passed as keyword argument to a function. For example:

Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> def fn(**kw):
...     print repr(kw)
...
>>> fn(**{u'x':1})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: fn() keywords must be strings
>>>

Unicode strings should be converted to str automatically using the site specific default encoding or something similar solution.

This bug caused problems when decoding dictionaries from data formats such as XML or JSON. Usually unicode strings are returned from such modules, such as simplejson. Manual encoding from unicode to str causes performance loss if this cannot be done by Python automatically.

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

>Comment By: M.-A. Lemburg (lemburg)
Date: 2007-05-04 12:27

Message:
Logged In: YES 
user_id=38388
Originator: NO

Python (currently) does not allow non-ASCII identifiers, so it's not
surprising that Unicode parameter names don't work.

It's also a really bad idea to pass data from an AJAX XML or JSON request
directly to a function without doing at least some post-processing of the
data in order to prevent DOS attacks, code injection, etc.

dict((str(key), value) for key, value in kw.iteritems()) is all that's
needed for the above. 

BTW, I don't think those few micro-seconds really matter in the face of
XML or JSON decoding, network latency, etc. ;-)


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

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-04 06:10

Message:
Logged In: YES 
user_id=849994
Originator: NO

In any case, this is a feature request.

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

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

From noreply at sourceforge.net  Fri May  4 15:47:32 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 04 May 2007 06:47:32 -0700
Subject: [ python-Bugs-1712742 ] pprint handles depth argument incorrectly
Message-ID: <E1Hjy8C-00041C-DD@sc8-sf-web23.sourceforge.net>

Bugs item #1712742, was opened at 2007-05-04 16: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=1712742&group_id=5470

Please note that this 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
Private: No
Submitted By: Dmitrii Tisnek (dimaq)
Assigned to: Nobody/Anonymous (nobody)
Summary: pprint handles depth argument incorrectly

Initial Comment:
pprint.pprint( [[[[[ ]]]]], depth=0)
AssertionError: depth must be > 0

pprint.pprint( [[[[[ ]]]]], depth=0.5)
[[...]]

pprint.pprint( [[[[[ ]]]]], depth=1)
[[[...]]]

I would like to see the root (that is [...]) with depth=0 (or depth=1 if you insist), either way, [[[...]]] for depth=1 is incorrect.


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

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

From noreply at sourceforge.net  Fri May  4 16:04:15 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 04 May 2007 07:04:15 -0700
Subject: [ python-Bugs-1581906 ] test_sqlite fails on OSX G5 arch if
	test_ctypes is run
Message-ID: <E1HjyON-0004vf-DZ@sc8-sf-web21.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Skip Montanaro (montanaro)
Assigned to: Skip Montanaro (montanaro)
Summary: test_sqlite fails on OSX G5 arch if test_ctypes is run

Initial Comment:
I noticed a test_sqlite test failure on my Mac G5 the other day while trying 
to set up a buildbot for sqlalchemy.  Everything runs fine on my G4 
powerbook.  Both machines run Mac OSX 10.4.8 with Apple's gcc 4.0.0, 
build 5026.

I whittled the problem down to just having test_ctypes and test_sqlite 
enabled, then further whittled it down to just having Lib/ctypes/test/
test_find.py available (all other ctypes tests eliminated).  More detailed 
problem descriptions are in these two postings to python-dev:

    http://article.gmane.org/gmane.comp.python.devel/84478
    http://article.gmane.org/gmane.comp.python.devel/84481

Skip


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

>Comment By: Thomas Heller (theller)
Date: 2007-05-04 16:04

Message:
Logged In: YES 
user_id=11105
Originator: NO

FYI, this PyOpenGL bug may be related:

https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1712741&group_id=5988

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

Comment By: Thomas Heller (theller)
Date: 2007-03-22 21:18

Message:
Logged In: YES 
user_id=11105
Originator: NO

Skip,

I do not have a G5 machine available, only a G4 and the problem doesn't
appear there.
For someone with a G5 it should not be too difficult to reproduce (or
investigate),
I think that running './python Lib/test/regrtest.py test_ctypes
test_sqlite' should suffice.

However, if loading the GLUT library changes the cwd, and sqlite fails
with a changed working dir,
I'm not sure where the problem really is and how it should be fixed.  It
could be said that test_ctypes
should restore the cwd after the tests (but maybe this should be done by
the test framework?),
or it could be said that test_sqlite should set the cwd in case the test
relies on it.

I'll assign back to you because I have no way to test it on a machine
where the problem appears.

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

Comment By: Skip Montanaro (montanaro)
Date: 2007-03-18 18:20

Message:
Logged In: YES 
user_id=44345
Originator: YES

Thomas, I assigned this to you simply so you can cast your eye on the
problem and see if you think there might be anything ctypes-related in the
problem I've reported.  I've ignored it up 'til now, but I bumped up
against it again trying to get the Pybots SQLAlchemy test suite running on
my Mac.  During my previous encounter with this problem Ronald Oussouren
reported on a possible connection with GLUT:

    http://mail.python.org/pipermail/python-dev/2006-October/069523.html

Assuming there is no obvious ctypes connection you can determine  (it's
not clear to me that there is any current directory funny business going
on) just assign it back to me and I'll try to find a pysqlite expert to
take a look.

Thx,

Skip


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

Comment By: Skip Montanaro (montanaro)
Date: 2006-10-21 20:04

Message:
Logged In: YES 
user_id=44345

Another article here:

    http://article.gmane.org/gmane.comp.python.devel/84487


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

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

From noreply at sourceforge.net  Fri May  4 20:30:06 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 04 May 2007 11:30:06 -0700
Subject: [ python-Bugs-1607951 ] mailbox.Maildir re-reads directory too often
Message-ID: <E1Hk2Xe-0003xC-Fb@sc8-sf-web22.sourceforge.net>

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

Please note that this message will contain a full 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
Private: No
Submitted By: Matthias Klose (doko)
Assigned to: A.M. Kuchling (akuchling)
Summary: mailbox.Maildir re-reads directory too often

Initial Comment:
[forwarded from http://bugs.debian.org/401395]

Various functions in mailbox.Maildir call self._refresh, which always re-reads the cur and new directories with os.listdir.  _refresh should stat each of the two directories first to see if they changed.  This cuts processing time of a series of lookups down by a factor of the number of messages in the folder, a potentially large number.


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

Comment By: Josh Triplett (joshtriplett)
Date: 2007-05-04 11:30

Message:
Logged In: YES 
user_id=1785566
Originator: NO

akuchling wrote:
> By stat()'ing the directories, do you mean checking the mtime?  I think
> this isn't safe because of the limited resolution of mtime on
filesystems;
> ext3 seems to have a 1-second resolution for mtime, for example.

Regardless of the resolution on any particular filesystem, stat and
stat64
return file timestamps as time_t, which has one-second resolution.

> This means that _refresh() might read a directory, and if some other
process
> adds or deletes a message in the same second, _refresh() couldn't detect
the
> change.

True.  mailbox.Maildir's behavior of always representing the current
contents
of the maildir without requiring the caller to explicitly refresh will
not
work with an implementation that checks for an mtime increase.

The two solutions below (inotify and your suggested mtime-1 approach)
would
allow the automatic updates to work efficiently.

> Is there some other property of directories that could be used for
> a more reliable check?

On Linux, you could use inotify to get a notice when anything changes in
the
directory.  You then wouldn't even incur the overhead of a repeated
directory
stat, and wouldn't need to re-read the entire directory to find the new
mail.

> The attached patch implements checking of mtime, but I don't recommend
> applying it; it causes the test suite in test_mailbox.py to break all
over
> the place, because the process modifies mailboxes so quickly that the
mtime
> check doesn't notice the process's own changes.

Fair enough.

> I'll wait a bit for any alternative suggestion, and then close this bug
as
> "won't fix".

Please don't.  The performance hit of repeatedly re-reading the directory
makes mailbox.Maildir unusably slow on even moderately large maildirs (a
few
thousand messages).  For the application we originally wanted
mailbox.Maildir
for, we had to rewrite the code to manually operate on the maildir
instead,
and we achieved an improvement of several orders of magnitude.

akuchling:
> Stray thought: would it help if the patch stored the (mtime - 1sec)
instead
> of the mtime?  Successive calls in the same second would then always
re-read
> the directories, but once the clock ticks to the next second, re-reads
would
> only occur if the directories have actually changed.  The check would be
'if
> new_mtime > self._new_mtime' instead of '=='.

Good idea.  That would work fine as well, and I believe it would have
addressed our performance problem.  This would work as a good solution on
platforms that lack inotify, or if you don't want to use inotify.

Compared to inotify, this would have somewhat more overhead (but still
far
less than the current approach), and would still perform poorly if you
insert
messages as you go (sometimes avoidable).  However, compared to the
current
approach, this has a massive improvement, so please consider implementing
it.

> Is this sort of mtime-based checking reliable on remote filesystems such
as
> NFS?

This particular sort of checking, yes, I think so.  The times do not
necessarily match the system clock (because they come from a remote
system
that does not necessarily have a synchronized clock), but the times
should
remain consistent with *each other*.

Thank you for looking at this problem,
Josh Triplett


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

Comment By: A.M. Kuchling (akuchling)
Date: 2006-12-14 11:09

Message:
Logged In: YES 
user_id=11375
Originator: NO

Stray thought: would it help if the patch stored the (mtime - 1sec)
instead of the mtime?  Successive calls in the same second would then
always re-read the directories, but once the clock ticks to the next
second, re-reads would only occur if the directories have actually changed.
 The check would be 'if new_mtime > self._new_mtime' instead of '=='.

Is this sort of mtime-based checking reliable on remote filesystems such
as NFS?

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

Comment By: A.M. Kuchling (akuchling)
Date: 2006-12-13 05:38

Message:
Logged In: YES 
user_id=11375
Originator: NO

By stat()'ing the directories, do you mean checking the mtime?  I think
this isn't safe because of the limited resolution of mtime on filesystems;
ext3 seems to have a 1-second resolution for mtime, for example.  This
means that _refresh() might read a directory, and if some other process
adds or deletes a message in the same second, _refresh() couldn't detect
the change.  Is there some other property of directories that could be used
for a more reliable check?

The attached patch implements checking of mtime, but I don't recommend
applying it; it causes the test suite in test_mailbox.py to break all over
the place, because the process modifies mailboxes so quickly that the mtime
check doesn't notice the process's own changes.

I'll wait a bit for any alternative suggestion, and then close this bug as
"won't fix".


File Added: mailbox-mtime.patch

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

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

From noreply at sourceforge.net  Fri May  4 21:17:28 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 04 May 2007 12:17:28 -0700
Subject: [ python-Bugs-1712742 ] pprint handles depth argument incorrectly
Message-ID: <E1Hk3HU-0004zO-NK@sc8-sf-web24.sourceforge.net>

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

Please note that this 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
Private: No
Submitted By: Dmitrii Tisnek (dimaq)
Assigned to: Nobody/Anonymous (nobody)
Summary: pprint handles depth argument incorrectly

Initial Comment:
pprint.pprint( [[[[[ ]]]]], depth=0)
AssertionError: depth must be > 0

pprint.pprint( [[[[[ ]]]]], depth=0.5)
[[...]]

pprint.pprint( [[[[[ ]]]]], depth=1)
[[[...]]]

I would like to see the root (that is [...]) with depth=0 (or depth=1 if you insist), either way, [[[...]]] for depth=1 is incorrect.


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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-04 15:17

Message:
Logged In: YES 
user_id=984087
Originator: NO


I created patch 1712742 to fix this. BTW, I think that a depth of 1 should
mean the top level object. 

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

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

From noreply at sourceforge.net  Fri May  4 23:13:14 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 04 May 2007 14:13:14 -0700
Subject: [ python-Bugs-1710802 ] subprocess must escape redirection characters
	under win32
Message-ID: <E1Hk55W-0000SP-6w@sc8-sf-web23.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: Patrick M?zard (pmezard)
Assigned to: Peter ?strand (astrand)
Summary: subprocess must escape redirection characters under win32

Initial Comment:
Hello,
For some reason, subprocess.Popen arguments are not processed correctly when one of them contains a redirection character ("<>&|") when calling a batch file.

Unittest and patch are attached below. Here are the steps to reproduce it:

callee.py
"""
import sys
print sys.argv
"""

callee.bat
"""
python callee.py %*
"""

caller.py
"""
import subprocess

args = [
    'a<b',
    'a>b',
    'a|b',
    'a&b',
]

for arg in args:
    subprocess.check_call(['callee.bat', arg])
"""

Then:
"""
>python caller.py
The system cannot find the file specified.
Traceback (most recent call last):
  File "caller.py", line 22, in <module>
    subprocess.check_call(['callee.bat', arg])
  File "C:\Python251\lib\subprocess.py", line 461, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['callee.bat', 'a<b']' returned non-zero
 exit status 1
"""

With:
"""
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>>
"""


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

>Comment By: Peter ?strand (astrand)
Date: 2007-05-04 23:13

Message:
Logged In: YES 
user_id=344921
Originator: NO

I'm testing with a simpler pair of files:

callee.bat:
echo arg1 %1
echo arg2 %2
echo arg3 %3

caller.py:
import subprocess
subprocess.call(['callee.bat', 'a<b'])

This fails. What happens is that CreateProcess is called with:
lpApplicationName=None
lpCommandLine="callee.bat a<b"

As far as I know, this is correct: I can't find anything in the
documentation of CreateProcess that indicates that "<" is a magical meta
character in this context. I find it very surprising that CreateProcess
behaves like this. 

After some further investigations, I've found out that it's the fact that
we are calling a batch file that's the problem. CreateProcess does not fail
on a command line such as "view.exe a<b". Indeed, the documentation as well
as a community comment on
http://msdn2.microsoft.com/en-us/library/ms682425.aspx indicates that batch
files are handled in a special (broken?) way. 

I'm reluctant to accept the attached patch. It might for this particular
situation, but as far as I can tell, we are following the documented API.
You should be able to work around this problem by quoting in your
application. 


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-02 08:38

Message:
Logged In: YES 
user_id=33168
Originator: NO

Peter, can you take a look at this?

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

Comment By: Patrick M?zard (pmezard)
Date: 2007-05-01 22:47

Message:
Logged In: YES 
user_id=1660346
Originator: YES

File Added: fix_subp

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

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

From noreply at sourceforge.net  Sat May  5 07:16:29 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 04 May 2007 22:16:29 -0700
Subject: [ python-Bugs-1713252 ] character set in Japanese on Ubuntu
	distribution
Message-ID: <E1HkCdB-0001WK-57@sc8-sf-web23.sourceforge.net>

Bugs item #1713252, was opened at 2007-05-04 22: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=1713252&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Christopher Grell (cgrell)
Assigned to: Nobody/Anonymous (nobody)
Summary: character set in Japanese on Ubuntu distribution

Initial Comment:
I tried to use IDLE on new Ubuntu 7.04 and the window opens with Japanese character set

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

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

From noreply at sourceforge.net  Sat May  5 09:08:04 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 05 May 2007 00:08:04 -0700
Subject: [ python-Bugs-1713252 ] character set in Japanese on Ubuntu
	distribution
Message-ID: <E1HkENA-0004zy-A7@sc8-sf-web23.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.5
>Status: Pending
Resolution: None
Priority: 5
Private: No
Submitted By: Christopher Grell (cgrell)
Assigned to: Nobody/Anonymous (nobody)
Summary: character set in Japanese on Ubuntu distribution

Initial Comment:
I tried to use IDLE on new Ubuntu 7.04 and the window opens with Japanese character set

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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-05 07:08

Message:
Logged In: YES 
user_id=849994
Originator: NO

As this is certainly not the case in other distributions, this is
something you should file with the Ubuntu bug tracker.

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

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

From noreply at sourceforge.net  Sat May  5 20:01:58 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 05 May 2007 11:01:58 -0700
Subject: [ python-Bugs-1713535 ] Error inside logging module's documentation
Message-ID: <E1HkOZy-0004r4-VM@sc8-sf-web23.sourceforge.net>

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

Please note that this 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
Private: No
Submitted By: billiejoex (billiejoex)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error inside logging module's documentation

Initial Comment:
http://docs.python.org/lib/module-logging.html

Inside the explanation of logging.debug an example code is showed:

 FORMAT = "%(asctime)-15s %(clientip)s %(user)-8s %(message)s"
 logging.basicConfig(format=FORMAT)
 dict = { 'clientip' : '192.168.0.1', 'user' : 'fbloggs' }
 logging.warning("Protocol problem: %s", "connection reset", extra=d)


In the code "dict" is created but never used. 
When logging.warning is called the author use the argument 'd' instead of 'dict' and no reference to 'd' exists:

 logging.warning("Protocol problem: %s", "connection reset", extra=d)

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

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

From noreply at sourceforge.net  Sat May  5 20:10:31 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 05 May 2007 11:10:31 -0700
Subject: [ python-Bugs-1713535 ] Error inside logging module documentation
Message-ID: <E1HkOiF-0000y3-Qg@sc8-sf-web24.sourceforge.net>

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

Please note that this 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: 1
Private: No
Submitted By: billiejoex (billiejoex)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Error inside logging module documentation

Initial Comment:
http://docs.python.org/lib/module-logging.html

Inside the explanation of logging.debug an example code is showed:

 FORMAT = "%(asctime)-15s %(clientip)s %(user)-8s %(message)s"
 logging.basicConfig(format=FORMAT)
 dict = { 'clientip' : '192.168.0.1', 'user' : 'fbloggs' }
 logging.warning("Protocol problem: %s", "connection reset", extra=d)


In the code "dict" is created but never used. 
When logging.warning is called the author use the argument 'd' instead of 'dict' and no reference to 'd' exists:

 logging.warning("Protocol problem: %s", "connection reset", extra=d)

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

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

From noreply at sourceforge.net  Sat May  5 20:11:13 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 05 May 2007 11:11:13 -0700
Subject: [ python-Bugs-1713535 ] Error inside logging module documentation
Message-ID: <E1HkOiv-00014s-Qj@sc8-sf-web24.sourceforge.net>

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

Please note that this 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
Private: No
Submitted By: billiejoex (billiejoex)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error inside logging module documentation

Initial Comment:
http://docs.python.org/lib/module-logging.html

Inside the explanation of logging.debug an example code is showed:

 FORMAT = "%(asctime)-15s %(clientip)s %(user)-8s %(message)s"
 logging.basicConfig(format=FORMAT)
 dict = { 'clientip' : '192.168.0.1', 'user' : 'fbloggs' }
 logging.warning("Protocol problem: %s", "connection reset", extra=d)


In the code "dict" is created but never used. 
When logging.warning is called the author use the argument 'd' instead of 'dict' and no reference to 'd' exists:

 logging.warning("Protocol problem: %s", "connection reset", extra=d)

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

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

From noreply at sourceforge.net  Sat May  5 20:57:17 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 05 May 2007 11:57:17 -0700
Subject: [ python-Bugs-1713535 ] Error inside logging module documentation
Message-ID: <E1HkPRV-0004JZ-03@sc8-sf-web22.sourceforge.net>

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

Please note that this 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
Private: No
Submitted By: billiejoex (billiejoex)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error inside logging module documentation

Initial Comment:
http://docs.python.org/lib/module-logging.html

Inside the explanation of logging.debug an example code is showed:

 FORMAT = "%(asctime)-15s %(clientip)s %(user)-8s %(message)s"
 logging.basicConfig(format=FORMAT)
 dict = { 'clientip' : '192.168.0.1', 'user' : 'fbloggs' }
 logging.warning("Protocol problem: %s", "connection reset", extra=d)


In the code "dict" is created but never used. 
When logging.warning is called the author use the argument 'd' instead of 'dict' and no reference to 'd' exists:

 logging.warning("Protocol problem: %s", "connection reset", extra=d)

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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-05 18:57

Message:
Logged In: YES 
user_id=849994
Originator: NO

Thanks for the report, fixed in rev. 55154, 55155.

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

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

From noreply at sourceforge.net  Sun May  6 04:11:23 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 05 May 2007 19:11:23 -0700
Subject: [ python-Feature Requests-1713624 ] commands module
Message-ID: <E1HkWDb-0002fN-0O@sc8-sf-web21.sourceforge.net>

Feature Requests item #1713624, was opened at 2007-05-05 22:11
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=1713624&group_id=5470

Please note that this 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.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Joseph Armbruster (joearmbruster)
Assigned to: Nobody/Anonymous (nobody)
Summary: commands module

Initial Comment:
In reference to the commands module, and it's simple self   :-)

Current comments in the module state the following:

# Module 'commands'
#
# Various tools for executing commands and looking at their output and status.
#
# NB This only works (and is only relevant) for UNIX.

Ultimately, I would like to see the following:

1) This comment removed:
# NB This only works (and is only relevant) for UNIX.

1) A change to getstatusoutput along these lines:
    if os.name == 'nt':
        pipe = os.popen(cmd + ' 2>&1','r')
    else:
        pipe = os.popen('{ ' + cmd + '; } 2>&1', 'r')

* I was going to suggest having a more pythonic getstatus method, that would act reasonably similar across platforms (maybe using some combination of os.listdir and os.stat or something), however, it is being deprecated, so onward!

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

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

From noreply at sourceforge.net  Sun May  6 05:41:30 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 05 May 2007 20:41:30 -0700
Subject: [ python-Bugs-1566331 ] Bad behaviour in <ossaudio audio device>.obuf*
Message-ID: <E1HkXco-0004KE-5C@sc8-sf-web21.sourceforge.net>

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

Please note that this 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
Private: No
Submitted By: Sam Dennis (samdennis)
Assigned to: Greg Ward (gward)
Summary: Bad behaviour in <ossaudio audio device>.obuf*

Initial Comment:
The _ssize() function in ossaudiodev.c (2.4.3, but it's
the same in svn) calls SNDCTL_SET_CHANNELS with
channels=0 as part of an attempt to determine the total
number of samples per second for the current
configuration of the audio device, but as far as I can
tell this is not guaranteed to act as a query and at
least two implementations treat it as a request for a
monaural format (the ALSA pcm-oss module and the
alsa-oss library).

What this can safely be replaced with I don't know;
both Linux's OSS drivers and ALSA support
SOUND_PCM_READ_CHANNELS but this is not standard to the
best of my knowledge.  Storing the value returned when
the program calls .setfmt or .setparameters may be an
option.

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

Comment By: Bob Luse (rluse)
Date: 2007-05-06 03:41

Message:
Logged In: YES 
user_id=1688601
Originator: NO

I just wanted to confirm that this is  problem for me as well when I run
this.  I am writing an application where I need to get buffer information
when I am running with 2 channels.  This is a quite normal situation these
days.  I assume that the change is made to mono because in OSS mono is the
default, so that it will work with what is now quite ancient hardware. 
But, requesting the buffer size should not cause such a dramatic error.  I
don't understand why this is such a problem.  Could there be a parameter
for number of channels since you cannot request the buffer size unless you
have already setup the hardware giving the number of channels?  So even if
the System cannot figure out the number of channels, your application knows
it and can tell it.  Granted, it is a kluge, but it is a kluge that can
work whereas currently whenever you request buffer information the speed of
your sound is cut in half making the obuf commands unusable.  Possibly
another solution would be to remove these commands until they work.  I did
notice that the program does reference SOUND_PCM_WRITE_CHANNELS.  Is
SOUND_PCM_WRITE_CHANNELS standard and SOUND_PCM_READ_CHANNELS not standard?
 I don't know that that is not true, but it does seem strange.  

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

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

From noreply at sourceforge.net  Sun May  6 06:15:45 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 05 May 2007 21:15:45 -0700
Subject: [ python-Bugs-1707768 ] os.path.normpath changes path (chops of
	trailing slash)
Message-ID: <E1HkY9x-0003g7-R2@sc8-sf-web22.sourceforge.net>

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

Please note that this message will contain a full 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
Private: No
Submitted By: Robert Siemer (siemer)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.normpath changes path (chops of trailing slash)

Initial Comment:
Hello everybody!

>>> os.path.normpath('/etc/passwd')
'/etc/passwd'


I don't know any environment at all where

a) '/etc/passwd/'
b) '/etc/passwd'

are treated the same. It clearly does not apply for the path part of http urls (this is left as an exercise for the reader).

But it also does not apply for (e.g.) Linux either:
an open() on path a) return ENOTDIR while it succeeds with b).

(assuming /etc/passwd is a file)

This is definitively not a documentation bug, as "normpath" should normalize a path and not fuck it up.


Robert

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

>Comment By: Robert Siemer (siemer)
Date: 2007-05-06 06:15

Message:
Logged In: YES 
user_id=150699
Originator: YES

1) I (submitter) didn't specify what I expected to see:

os.path.normpath('/etc/passwd/') --> '/etc/passwd/'

So, I agree with the latest consensus, but definitely not with the
"/etc/passwd/." version...


2) I can't draw any explicit normalization rules from the excerpts of the
POSIX standard posted by iszegedi. Saying that "dir/" should be treated as
"dir/." doesn't mean that it is the normalized version of the first one. -
I actually read implicitly that the first one is the habitual one that
needs interpretation.

And I think everybody agrees that - beeing the same or not - "dir/." is
unusual.

3) I don't know what this is good for in the proposal:
path = path.rstrip()

It removes significant whitespace from the path, what must be avoided.

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

Comment By: Istvan Szegedi (iszegedi)
Date: 2007-05-01 20:05

Message:
Logged In: YES 
user_id=1772412
Originator: NO

I must admit that josm's comments make sense: in fact, I quickly tried out
how mkdir command from a bash shell would behave and it does the same:

# mkdir hello
# rmdir hello/. 
Invalid argument

whereas
# rmdir hello/

works fine. I also wrote a small C program using mkdir() and rmdir()
functions and they behave exactly the same as mkdir/rmdir from bash (well,
no real suprise).

My suggestion to get the original issue fixed was based on POSIX standard
and apparently the Linux commands are not fully POSIX compliant, either...
Or do I misunderstand the quotes from the standard?  Anyway, it is pretty
easy to modify my fix to be inline with Linux commands and C functions -
everything could be the same, apart from the last line where I added "/." 
-- this should be only "/".  So the entire function could look like this:

-- clip --


def normpath(path):
    """Normalize path, eliminating double slashes, etc."""
    if path == '':
        return '.'
    initial_slashes = path.startswith('/')
    # The next two lines were added by iszegedi
    path = path.rstrip()
    trailing_slash = path.endswith('/')
    # POSIX allows one or two initial slashes, but treats three or more
    # as single slash.
    if (initial_slashes and
        path.startswith('//') and not path.startswith('///')):
        initial_slashes = 2
    comps = path.split('/')
    new_comps = []
    for comp in comps:
        if comp in ('', '.'):
            continue
        if (comp != '..' or (not initial_slashes and not new_comps) or
             (new_comps and new_comps[-1] == '..')):
            new_comps.append(comp)
        elif new_comps:
            new_comps.pop()
    comps = new_comps
    path = '/'.join(comps)
    if initial_slashes:
        path = '/'*initial_slashes + path
    # The next two lines were added by iszegedi
    if trailing_slash:
        path = path + '/'
    return path or '.'


-- clip --

Nevertheless, I would really appreciate to receive some comments from
POSIX gurus, how they see this problem.


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

Comment By: jos (josm)
Date: 2007-04-30 08:48

Message:
Logged In: YES 
user_id=1776568
Originator: NO

I think we should be careful enough to tackle on this.
iszegedi's patch seems to work correctly,
but XBD's spec itself has some defect.
http://www.opengroup.org/austin/mailarchives/ag-review/msg01722.html

What do you think of the follow behavior?
>>> os.mkdir('dir/')
>>> os.mkdir('dir2/')
>>> os.rmdir(os.path.normpath('dir'))
>>> os.rmdir(os.path.normpath('dir2/'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 22] Invalid argument: 'dir2/.'




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

Comment By: Istvan Szegedi (iszegedi)
Date: 2007-04-28 22:27

Message:
Logged In: YES 
user_id=1772412
Originator: NO


Here is what Posix standard says about pathnames:

"Base Definitions volume of IEEE Std 1003.1-2001, Section 3.266,
Pathname.

A character string that is used to identify a file. In the context of IEEE
Std 1003.1-2001, a pathname consists of, at most, {PATH_MAX} bytes,
including the terminating null byte. It has an optional beginning slash,
followed by zero or more filenames separated by slashes. A pathname may
optionally contain one or more trailing slashes. Multiple successive
slashes are considered to be the same as one slash."

And in the details:

"A pathname that contains at least one non-slash character and that ends
with one or more trailing slashes shall be resolved as if a single dot
character ( '.' ) were appended to the pathname."

So if I am not mistaken, according to the POSIX standard the example that
you gave - '/etc/passwd/' - should be normalized to '/etc/passwd/.' That
does not happen, indeed.

The reason for that is that in posixpath.py file the normpath() function
is using a split('/') function to split up the path into smaller chunks,
skips everything which is empty or '.' and at the end of the normpath()
function it adds slash(es) only to the beginning of the string. 

As a test, I modified the normpath() function in the posixpath.py as
follows:

--- clip ---

def normpath(path):
    """Normalize path, eliminating double slashes, etc."""
    if path == '':
        return '.'
    initial_slashes = path.startswith('/')
    # The next two lines were added by iszegedi
    path = path.rstrip()
    trailing_slash = path.endswith('/')
    # POSIX allows one or two initial slashes, but treats three or more
    # as single slash.
    if (initial_slashes and
        path.startswith('//') and not path.startswith('///')):
        initial_slashes = 2
    comps = path.split('/')
    new_comps = []
    for comp in comps:
        if comp in ('', '.'):
            continue
        if (comp != '..' or (not initial_slashes and not new_comps) or
             (new_comps and new_comps[-1] == '..')):
            new_comps.append(comp)
        elif new_comps:
            new_comps.pop()
    comps = new_comps
    path = '/'.join(comps)
    if initial_slashes:
        path = '/'*initial_slashes + path
    # The next two lines were added by iszegedi
    if trailing_slash:
        path = path + '/.'
    return path or '.'
  
-- clip --

So I added two lines (marked as "added by iszegedi" ) in the beginning to
remove any trailing whitespaces and check whether the path ends with slash.
Then at the end of the function I added another two lines to append '/.' to
the end of the return value if the input path variable ended by slash

This works now fine.

What makes it a bit tricky is that python os module imports different
xxxpath.py module depending on the host operating system. So it imports
different modules for nt, for mac, for os2, for posix, etc.  The solution
above works for posix, but the other modules need to be checked, to.


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

Comment By: Robert Siemer (siemer)
Date: 2007-04-26 01:47

Message:
Logged In: YES 
user_id=150699
Originator: YES

A bugreport bug:

The example should read os.path.normpath('/etc/passwd/')...

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

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

From noreply at sourceforge.net  Sun May  6 08:46:25 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 05 May 2007 23:46:25 -0700
Subject: [ python-Feature Requests-1713624 ] commands module
Message-ID: <E1HkaVl-0003qn-Gh@sc8-sf-web24.sourceforge.net>

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

Please note that this 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.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Joseph Armbruster (joearmbruster)
Assigned to: Nobody/Anonymous (nobody)
Summary: commands module

Initial Comment:
In reference to the commands module, and it's simple self   :-)

Current comments in the module state the following:

# Module 'commands'
#
# Various tools for executing commands and looking at their output and status.
#
# NB This only works (and is only relevant) for UNIX.

Ultimately, I would like to see the following:

1) This comment removed:
# NB This only works (and is only relevant) for UNIX.

1) A change to getstatusoutput along these lines:
    if os.name == 'nt':
        pipe = os.popen(cmd + ' 2>&1','r')
    else:
        pipe = os.popen('{ ' + cmd + '; } 2>&1', 'r')

* I was going to suggest having a more pythonic getstatus method, that would act reasonably similar across platforms (maybe using some combination of os.listdir and os.stat or something), however, it is being deprecated, so onward!

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

Comment By: Josiah Carlson (josiahcarlson)
Date: 2007-05-05 23:46

Message:
Logged In: YES 
user_id=341410
Originator: NO

Recent discussions in one of the python development lists has basically
stated that the commands module will be deprecated in favor of being
replaced by equivalent platform independent versions based on subprocess,
which will be placed in the subprocess module.  As such, it is doubtful
that your request will be fulfilled.  Suggested close as 'wont fix'.

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

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

From noreply at sourceforge.net  Sun May  6 11:31:43 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 06 May 2007 02:31:43 -0700
Subject: [ python-Bugs-1707768 ] os.path.normpath changes path (chops of
	trailing slash)
Message-ID: <E1Hkd5j-0001y6-KC@sc8-sf-web23.sourceforge.net>

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

Please note that this message will contain a full 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
Private: No
Submitted By: Robert Siemer (siemer)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.normpath changes path (chops of trailing slash)

Initial Comment:
Hello everybody!

>>> os.path.normpath('/etc/passwd')
'/etc/passwd'


I don't know any environment at all where

a) '/etc/passwd/'
b) '/etc/passwd'

are treated the same. It clearly does not apply for the path part of http urls (this is left as an exercise for the reader).

But it also does not apply for (e.g.) Linux either:
an open() on path a) return ENOTDIR while it succeeds with b).

(assuming /etc/passwd is a file)

This is definitively not a documentation bug, as "normpath" should normalize a path and not fuck it up.


Robert

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

Comment By: jos (josm)
Date: 2007-05-06 09:31

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Like all other python libraries, posixpath.normpath has its test cases,
which specify what normpath is supposed to work.
See test_normpath() in Lib/test/test_posixpath.py.

siemer, would you add some test cases for this problem to
test_posixpath.py?
I think it needs not just adding but also need to update existent cases.
That means it would break backwards-compatibility.

According to http://www.python.org/dev/intro/,
changing existing functionality "requires python- dev as a whole to agree
to the change."

So the TODO list would be

1. Write test cases for this problem and post it to the patch manager
2. Discuss the changes on python-dev at python.org and get agreement
3. Write patch and post it to the patch manager
4. Get some reviews
5. Commit

Correct Me If I'm Wrong.

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

Comment By: Robert Siemer (siemer)
Date: 2007-05-06 04:15

Message:
Logged In: YES 
user_id=150699
Originator: YES

1) I (submitter) didn't specify what I expected to see:

os.path.normpath('/etc/passwd/') --> '/etc/passwd/'

So, I agree with the latest consensus, but definitely not with the
"/etc/passwd/." version...


2) I can't draw any explicit normalization rules from the excerpts of the
POSIX standard posted by iszegedi. Saying that "dir/" should be treated as
"dir/." doesn't mean that it is the normalized version of the first one. -
I actually read implicitly that the first one is the habitual one that
needs interpretation.

And I think everybody agrees that - beeing the same or not - "dir/." is
unusual.

3) I don't know what this is good for in the proposal:
path = path.rstrip()

It removes significant whitespace from the path, what must be avoided.

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

Comment By: Istvan Szegedi (iszegedi)
Date: 2007-05-01 18:05

Message:
Logged In: YES 
user_id=1772412
Originator: NO

I must admit that josm's comments make sense: in fact, I quickly tried out
how mkdir command from a bash shell would behave and it does the same:

# mkdir hello
# rmdir hello/. 
Invalid argument

whereas
# rmdir hello/

works fine. I also wrote a small C program using mkdir() and rmdir()
functions and they behave exactly the same as mkdir/rmdir from bash (well,
no real suprise).

My suggestion to get the original issue fixed was based on POSIX standard
and apparently the Linux commands are not fully POSIX compliant, either...
Or do I misunderstand the quotes from the standard?  Anyway, it is pretty
easy to modify my fix to be inline with Linux commands and C functions -
everything could be the same, apart from the last line where I added "/." 
-- this should be only "/".  So the entire function could look like this:

-- clip --


def normpath(path):
    """Normalize path, eliminating double slashes, etc."""
    if path == '':
        return '.'
    initial_slashes = path.startswith('/')
    # The next two lines were added by iszegedi
    path = path.rstrip()
    trailing_slash = path.endswith('/')
    # POSIX allows one or two initial slashes, but treats three or more
    # as single slash.
    if (initial_slashes and
        path.startswith('//') and not path.startswith('///')):
        initial_slashes = 2
    comps = path.split('/')
    new_comps = []
    for comp in comps:
        if comp in ('', '.'):
            continue
        if (comp != '..' or (not initial_slashes and not new_comps) or
             (new_comps and new_comps[-1] == '..')):
            new_comps.append(comp)
        elif new_comps:
            new_comps.pop()
    comps = new_comps
    path = '/'.join(comps)
    if initial_slashes:
        path = '/'*initial_slashes + path
    # The next two lines were added by iszegedi
    if trailing_slash:
        path = path + '/'
    return path or '.'


-- clip --

Nevertheless, I would really appreciate to receive some comments from
POSIX gurus, how they see this problem.


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

Comment By: jos (josm)
Date: 2007-04-30 06:48

Message:
Logged In: YES 
user_id=1776568
Originator: NO

I think we should be careful enough to tackle on this.
iszegedi's patch seems to work correctly,
but XBD's spec itself has some defect.
http://www.opengroup.org/austin/mailarchives/ag-review/msg01722.html

What do you think of the follow behavior?
>>> os.mkdir('dir/')
>>> os.mkdir('dir2/')
>>> os.rmdir(os.path.normpath('dir'))
>>> os.rmdir(os.path.normpath('dir2/'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 22] Invalid argument: 'dir2/.'




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

Comment By: Istvan Szegedi (iszegedi)
Date: 2007-04-28 20:27

Message:
Logged In: YES 
user_id=1772412
Originator: NO


Here is what Posix standard says about pathnames:

"Base Definitions volume of IEEE Std 1003.1-2001, Section 3.266,
Pathname.

A character string that is used to identify a file. In the context of IEEE
Std 1003.1-2001, a pathname consists of, at most, {PATH_MAX} bytes,
including the terminating null byte. It has an optional beginning slash,
followed by zero or more filenames separated by slashes. A pathname may
optionally contain one or more trailing slashes. Multiple successive
slashes are considered to be the same as one slash."

And in the details:

"A pathname that contains at least one non-slash character and that ends
with one or more trailing slashes shall be resolved as if a single dot
character ( '.' ) were appended to the pathname."

So if I am not mistaken, according to the POSIX standard the example that
you gave - '/etc/passwd/' - should be normalized to '/etc/passwd/.' That
does not happen, indeed.

The reason for that is that in posixpath.py file the normpath() function
is using a split('/') function to split up the path into smaller chunks,
skips everything which is empty or '.' and at the end of the normpath()
function it adds slash(es) only to the beginning of the string. 

As a test, I modified the normpath() function in the posixpath.py as
follows:

--- clip ---

def normpath(path):
    """Normalize path, eliminating double slashes, etc."""
    if path == '':
        return '.'
    initial_slashes = path.startswith('/')
    # The next two lines were added by iszegedi
    path = path.rstrip()
    trailing_slash = path.endswith('/')
    # POSIX allows one or two initial slashes, but treats three or more
    # as single slash.
    if (initial_slashes and
        path.startswith('//') and not path.startswith('///')):
        initial_slashes = 2
    comps = path.split('/')
    new_comps = []
    for comp in comps:
        if comp in ('', '.'):
            continue
        if (comp != '..' or (not initial_slashes and not new_comps) or
             (new_comps and new_comps[-1] == '..')):
            new_comps.append(comp)
        elif new_comps:
            new_comps.pop()
    comps = new_comps
    path = '/'.join(comps)
    if initial_slashes:
        path = '/'*initial_slashes + path
    # The next two lines were added by iszegedi
    if trailing_slash:
        path = path + '/.'
    return path or '.'
  
-- clip --

So I added two lines (marked as "added by iszegedi" ) in the beginning to
remove any trailing whitespaces and check whether the path ends with slash.
Then at the end of the function I added another two lines to append '/.' to
the end of the return value if the input path variable ended by slash

This works now fine.

What makes it a bit tricky is that python os module imports different
xxxpath.py module depending on the host operating system. So it imports
different modules for nt, for mac, for os2, for posix, etc.  The solution
above works for posix, but the other modules need to be checked, to.


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

Comment By: Robert Siemer (siemer)
Date: 2007-04-25 23:47

Message:
Logged In: YES 
user_id=150699
Originator: YES

A bugreport bug:

The example should read os.path.normpath('/etc/passwd/')...

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

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

From noreply at sourceforge.net  Sun May  6 20:07:07 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 06 May 2007 11:07:07 -0700
Subject: [ python-Feature Requests-1713877 ] Expose callback API in readline
	module
Message-ID: <E1Hkl8V-0002VB-1v@sc8-sf-web21.sourceforge.net>

Feature Requests item #1713877, was opened at 2007-05-06 20:07
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=1713877&group_id=5470

Please note that this message will contain 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
Private: No
Submitted By: strank (strank)
Assigned to: Nobody/Anonymous (nobody)
Summary: Expose callback API in readline module

Initial Comment:
This is a request to expose the `callback API`_ of GNU readline in the readline module in the Python library.

.. _callback API: http://cnswww.cns.cwru.edu/php/chet/readline/readline.html#SEC41

This interface is suitable for asynchronous use, such as with twisted.

It is possible to expose the functions on Unix with ctypes::

  import readline
  import ctypes

  rl_lib = ctypes.cdll.LoadLibrary("libreadline.so.5")

  readline.callback_handler_remove = rl_lib.rl_callback_handler_remove
  readline.callback_read_char = rl_lib.rl_callback_read_char
  # the callback needs special treatment:
  rlcallbackfunctype = ctypes.CFUNCTYPE(ctypes.c_void_p, ctypes.c_char_p)
  def setcallbackfunc(prompt, thefunc):
      rl_lib.rl_callback_handler_install(prompt, rlcallbackfunctype(thefunc))
  readline.callback_handler_install = setcallbackfunc

but it would be much better to expose them "officially".


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

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

From noreply at sourceforge.net  Mon May  7 03:40:25 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 06 May 2007 18:40:25 -0700
Subject: [ python-Bugs-1713993 ] smtplib starttls() didn't do TLS Close Notify
	when quit()
Message-ID: <E1HksDB-0000YY-W9@sc8-sf-web23.sourceforge.net>

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

Please note that this 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
Private: No
Submitted By: AndCycle (andcycle)
Assigned to: Nobody/Anonymous (nobody)
Summary: smtplib starttls() didn't do TLS Close Notify when quit()

Initial Comment:
[code]
server = smtplib.SMTP('smtp.gmail.com')
server.set_debuglevel(1)
server.ehlo('x')
server.starttls()
server.ehlo('x')
server.noop()
server.rset()
server.quit()
[/code]
will always result in "sslerror: (8, 'EOF occurred in violation of protocol')",
although this won't really effect data transmission but this is really annoying,

relative discussion can be found
http://www.dbforums.com/archive/index.php/t-1401931.html


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

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

From noreply at sourceforge.net  Mon May  7 03:41:12 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 06 May 2007 18:41:12 -0700
Subject: [ python-Bugs-1713993 ] smtplib starttls() didn't do TLS Close Notify
	when quit()
Message-ID: <E1HksDw-0006iT-3f@sc8-sf-web22.sourceforge.net>

Bugs item #1713993, was opened at 2007-05-07 09:40
Message generated for change (Settings changed) made by andcycle
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1713993&group_id=5470

Please note that this 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: 1
Private: No
Submitted By: AndCycle (andcycle)
Assigned to: Nobody/Anonymous (nobody)
Summary: smtplib starttls() didn't do TLS Close Notify when quit()

Initial Comment:
[code]
server = smtplib.SMTP('smtp.gmail.com')
server.set_debuglevel(1)
server.ehlo('x')
server.starttls()
server.ehlo('x')
server.noop()
server.rset()
server.quit()
[/code]
will always result in "sslerror: (8, 'EOF occurred in violation of protocol')",
although this won't really effect data transmission but this is really annoying,

relative discussion can be found
http://www.dbforums.com/archive/index.php/t-1401931.html


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

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

From noreply at sourceforge.net  Mon May  7 03:46:24 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 06 May 2007 18:46:24 -0700
Subject: [ python-Bugs-1713993 ] smtplib starttls() didn't do TLS Close Notify
	when quit()
Message-ID: <E1HksIy-00027c-RQ@sc8-sf-web24.sourceforge.net>

Bugs item #1713993, was opened at 2007-05-07 09:40
Message generated for change (Settings changed) made by andcycle
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1713993&group_id=5470

Please note that this 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: Deleted
Resolution: None
Priority: 1
Private: No
Submitted By: AndCycle (andcycle)
Assigned to: Nobody/Anonymous (nobody)
Summary: smtplib starttls() didn't do TLS Close Notify when quit()

Initial Comment:
[code]
server = smtplib.SMTP('smtp.gmail.com')
server.set_debuglevel(1)
server.ehlo('x')
server.starttls()
server.ehlo('x')
server.noop()
server.rset()
server.quit()
[/code]
will always result in "sslerror: (8, 'EOF occurred in violation of protocol')",
although this won't really effect data transmission but this is really annoying,

relative discussion can be found
http://www.dbforums.com/archive/index.php/t-1401931.html


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

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

From noreply at sourceforge.net  Mon May  7 04:05:29 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 06 May 2007 19:05:29 -0700
Subject: [ python-Bugs-1713999 ] Multiple re.compile flags cause error
Message-ID: <E1HksbR-0000ZH-4q@sc8-sf-web21.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Regular Expressions
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Saul Spatz (saulspatz)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: Multiple re.compile flags cause error

Initial Comment:
The documentation for re.compile() shows that multiple flags are allowed, but 

re.compile(r'.*', re.VERBOSE, re.DOTALL)

results in an error message that only two arguments are allowed and three were given.

I'm using python 2.5 with Windows XP Home edition.

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

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

From noreply at sourceforge.net  Mon May  7 04:42:42 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 06 May 2007 19:42:42 -0700
Subject: [ python-Bugs-1713252 ] character set in Japanese on Ubuntu
	distribution
Message-ID: <E1HktBS-0007CP-2m@sc8-sf-web23.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.5
>Status: Open
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Christopher Grell (cgrell)
Assigned to: Nobody/Anonymous (nobody)
Summary: character set in Japanese on Ubuntu distribution

Initial Comment:
I tried to use IDLE on new Ubuntu 7.04 and the window opens with Japanese character set

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

>Comment By: Christopher Grell (cgrell)
Date: 2007-05-06 19:42

Message:
Logged In: YES 
user_id=1785859
Originator: YES

Changing default character size to 20 removes the issue

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

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

Message:
Logged In: YES 
user_id=849994
Originator: NO

As this is certainly not the case in other distributions, this is
something you should file with the Ubuntu bug tracker.

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

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

From noreply at sourceforge.net  Mon May  7 07:10:01 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 06 May 2007 22:10:01 -0700
Subject: [ python-Bugs-1713999 ] Multiple re.compile flags cause error
Message-ID: <E1HkvU1-0003E3-0o@sc8-sf-web21.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Regular Expressions
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Saul Spatz (saulspatz)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: Multiple re.compile flags cause error

Initial Comment:
The documentation for re.compile() shows that multiple flags are allowed, but 

re.compile(r'.*', re.VERBOSE, re.DOTALL)

results in an error message that only two arguments are allowed and three were given.

I'm using python 2.5 with Windows XP Home edition.

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

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-07 02:10

Message:
Logged In: YES 
user_id=479790
Originator: NO

Multiple flags must be ORed together: re.compile(r'.*', re.VERBOSE |
re.DOTALL)
>From the re module documentation at
http://docs.python.org/lib/node46.html: "Values can be any of the following
variables, combined using bitwise OR (the | operator)." 



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

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

From noreply at sourceforge.net  Mon May  7 07:40:06 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 06 May 2007 22:40:06 -0700
Subject: [ python-Bugs-1711800 ] SequenceMatcher bug with insert/delete block
	after "replace"
Message-ID: <E1Hkvx8-0006ZV-Fw@sc8-sf-web21.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Christian Hammond (chipx86)
Assigned to: Nobody/Anonymous (nobody)
Summary: SequenceMatcher bug with insert/delete block after "replace"

Initial Comment:
difflib.SequenceMatcher fails to distinguish between a "replace" block and an "insert" or "delete" block when the "insert/delete" immediately follows a "replace". It will lump both changes together as one big "replace" block.

This happens due to how get_opcodes() works. get_opcodes() loops through the matching blocks, grouping them into tags and ranges. However, if a block of text is changed and then new text is immediately added, it can't see this. All it knows is that the next matching block is after the added text.

As an example, consider these strings:

"ABC"

"ABCD
EFG."

Any diffing program will show that the first line was replaced and the second was inserted. SequenceMatcher, however, just shows that there was one replace, and includes both lines in the range.

I've attached a testcase that reproduces this for both replace>insert and replace>delete blocks.

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

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-07 02:40

Message:
Logged In: YES 
user_id=479790
Originator: NO

Maybe you are more interested on a Differ object. These are the results
from your example using '\n'.join(difflib.Differ().compare(a,b))

- This is my old file, containing only one line.
+ This is my new file.
+ It contains multiple lines.
+ SequenceMatcher should see two blocks as a result.

and 

+ This is my new file, containing only one line.
- This is my old file.
- It contains multiple lines.
- SequenceMatcher should see two blocks as a result.


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

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

From noreply at sourceforge.net  Mon May  7 10:35:38 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 07 May 2007 01:35:38 -0700
Subject: [ python-Bugs-1713999 ] Multiple re.compile flags cause error
Message-ID: <E1Hkyh0-0007Un-0q@sc8-sf-web24.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Regular Expressions
Group: Python 2.5
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Saul Spatz (saulspatz)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: Multiple re.compile flags cause error

Initial Comment:
The documentation for re.compile() shows that multiple flags are allowed, but 

re.compile(r'.*', re.VERBOSE, re.DOTALL)

results in an error message that only two arguments are allowed and three were given.

I'm using python 2.5 with Windows XP Home edition.

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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-07 08:35

Message:
Logged In: YES 
user_id=849994
Originator: NO

Closing as invalid.

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

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-07 05:10

Message:
Logged In: YES 
user_id=479790
Originator: NO

Multiple flags must be ORed together: re.compile(r'.*', re.VERBOSE |
re.DOTALL)
>From the re module documentation at
http://docs.python.org/lib/node46.html: "Values can be any of the following
variables, combined using bitwise OR (the | operator)." 



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

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

From noreply at sourceforge.net  Mon May  7 16:50:39 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 07 May 2007 07:50:39 -0700
Subject: [ python-Bugs-1714381 ] Universal line ending mode duplicates all
	line endings
Message-ID: <E1Hl4Xv-000856-II@sc8-sf-web24.sourceforge.net>

Bugs item #1714381, was opened at 2007-05-07 16: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=1714381&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Geoffrey Bache (gjb1002)
Assigned to: Nobody/Anonymous (nobody)
Summary: Universal line ending mode duplicates all line endings

Initial Comment:
On Windows XP, reading a file produced by Windows XP with universal line endings produces twice as many lines!

Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> open("winlineend").read()
'Hello\r\n'
>>> open("winlineend", "rU").read()
'Hello\n\n'


I would expect the last to give "Hello\n". 

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

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

From noreply at sourceforge.net  Mon May  7 19:09:08 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 07 May 2007 10:09:08 -0700
Subject: [ python-Feature Requests-1714448 ] if something as x:
Message-ID: <E1Hl6hw-0000Oq-7f@sc8-sf-web21.sourceforge.net>

Feature Requests item #1714448, was opened at 2007-05-07 21:09
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=1714448&group_id=5470

Please note that this 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
Private: No
Submitted By: k0wax (k0wax)
Assigned to: Nobody/Anonymous (nobody)
Summary: if something as x:

Initial Comment:
---

if map[x][y].overlay:
   map[x][y].overlay.blit(x,y)

---

... and ...

---

if map[x][y].overpay as ob:
   ob.blit(x, y)

---

the second one looks much more fun I think.

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

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

From noreply at sourceforge.net  Mon May  7 19:10:37 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 07 May 2007 10:10:37 -0700
Subject: [ python-Feature Requests-1714448 ] if something as x:
Message-ID: <E1Hl6jN-0002W0-O4@sc8-sf-web24.sourceforge.net>

Feature Requests item #1714448, was opened at 2007-05-07 21:09
Message generated for change (Settings changed) made by k0wax
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1714448&group_id=5470

Please note that this 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: 1
Private: No
Submitted By: k0wax (k0wax)
Assigned to: Nobody/Anonymous (nobody)
Summary: if something as x:

Initial Comment:
---

if map[x][y].overlay:
   map[x][y].overlay.blit(x,y)

---

... and ...

---

if map[x][y].overpay as ob:
   ob.blit(x, y)

---

the second one looks much more fun I think.

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

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

From noreply at sourceforge.net  Mon May  7 19:13:43 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 07 May 2007 10:13:43 -0700
Subject: [ python-Bugs-1714451 ] subprocess.py problems errors when calling
	cmd.exe
Message-ID: <E1Hl6mN-0000tT-Jn@sc8-sf-web21.sourceforge.net>

Bugs item #1714451, was opened at 2007-05-07 17: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=1714451&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: tzellman (tzellman)
Assigned to: Nobody/Anonymous (nobody)
Summary: subprocess.py problems errors when calling cmd.exe

Initial Comment:
An example:

>>> import subprocess
>>> proc = subprocess.Popen('"c:\Windows\system\ping.exe" "localhost"', shell=1, stdout=subprocess.PIPE, stderr=subprocess.PIPE)

'c:\Windows\system32\ping.exe" "localhost' is not recognized as an internal or external command, operable program or batch file.

This normally works from the cmd.exe prompt, so the command line is being passed incorrectly in the subprocess module.

My ACTUAL use case arises when I want to call the Microsoft compiler (CL.exe), and add include directories that have spaces in the name. For example:

"C:\Program Files\Microsoft Visual Studio 8\VC\BIN\CL.exe" /TC /O2 /DNDEBUG /W3
/nologo /c /EHsc /errorReport:prompt /Idefault\ /I.. /I. /Idefault /I"C:\Program Files\GnuWin32" /DWIN32 ..\pcreposix.c /Fodefault\pcreposix.obj

The fix for this problem is to modify line 765 in subprocess.py, replacing it with:


args = comspec + " /s /c \"%s\"" % args.replace('""', '"')


The /s tells cmd.exe not to re-format the command line. We then encase the entire command line in double quotes. I also replace occurrences of "" with " in the arg string, in case the user already encased the command in double quotes.

With this fix, the commands execute correctly.

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

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

From noreply at sourceforge.net  Mon May  7 19:20:46 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 07 May 2007 10:20:46 -0700
Subject: [ python-Bugs-1714451 ] subprocess.py problems errors when calling
	cmd.exe
Message-ID: <E1Hl6tC-0004I0-Np@sc8-sf-web23.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: tzellman (tzellman)
Assigned to: Nobody/Anonymous (nobody)
Summary: subprocess.py problems errors when calling cmd.exe

Initial Comment:
An example:

>>> import subprocess
>>> proc = subprocess.Popen('"c:\Windows\system\ping.exe" "localhost"', shell=1, stdout=subprocess.PIPE, stderr=subprocess.PIPE)

'c:\Windows\system32\ping.exe" "localhost' is not recognized as an internal or external command, operable program or batch file.

This normally works from the cmd.exe prompt, so the command line is being passed incorrectly in the subprocess module.

My ACTUAL use case arises when I want to call the Microsoft compiler (CL.exe), and add include directories that have spaces in the name. For example:

"C:\Program Files\Microsoft Visual Studio 8\VC\BIN\CL.exe" /TC /O2 /DNDEBUG /W3
/nologo /c /EHsc /errorReport:prompt /Idefault\ /I.. /I. /Idefault /I"C:\Program Files\GnuWin32" /DWIN32 ..\pcreposix.c /Fodefault\pcreposix.obj

The fix for this problem is to modify line 765 in subprocess.py, replacing it with:


args = comspec + " /s /c \"%s\"" % args.replace('""', '"')


The /s tells cmd.exe not to re-format the command line. We then encase the entire command line in double quotes. I also replace occurrences of "" with " in the arg string, in case the user already encased the command in double quotes.

With this fix, the commands execute correctly.

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

>Comment By: tzellman (tzellman)
Date: 2007-05-07 17:20

Message:
Logged In: YES 
user_id=1090960
Originator: YES

This could likely be rejected.

I realize a solution to this w/o modifying the Python source is to encase
the expression yourself in double quotes. So, the example given would look
like:
>>> import subprocess
>>> proc = subprocess.Popen('""c:\Windows\system\ping.exe" "localhost""',
shell=1, stdout=subprocess.PIPE, stderr=subprocess.PIPE)

And that will work.

Sorry for any confusion.


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

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

From noreply at sourceforge.net  Mon May  7 19:39:01 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 07 May 2007 10:39:01 -0700
Subject: [ python-Bugs-1714381 ] Universal line ending mode duplicates all
	line endings
Message-ID: <E1Hl7Ar-0006VB-NL@sc8-sf-web22.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Geoffrey Bache (gjb1002)
Assigned to: Nobody/Anonymous (nobody)
Summary: Universal line ending mode duplicates all line endings

Initial Comment:
On Windows XP, reading a file produced by Windows XP with universal line endings produces twice as many lines!

Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> open("winlineend").read()
'Hello\r\n'
>>> open("winlineend", "rU").read()
'Hello\n\n'


I would expect the last to give "Hello\n". 

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-07 13:39

Message:
Logged In: YES 
user_id=984087
Originator: NO


I created a file "test.txt" with notepad whose contents are "hello\r\n".
Both open().read() and open("rU").read() returned 'hello\n'. I tested with
both 2.5 and 2.5.1 (installed using installers from python.org) and the
result is same on both. Can you elaborate your test case more? How is this
file "winlineend" created?

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

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

From noreply at sourceforge.net  Mon May  7 22:27:47 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 07 May 2007 13:27:47 -0700
Subject: [ python-Bugs-1714381 ] Universal line ending mode duplicates all
	line endings
Message-ID: <E1Hl9oB-0004az-LY@sc8-sf-web22.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Geoffrey Bache (gjb1002)
Assigned to: Nobody/Anonymous (nobody)
Summary: Universal line ending mode duplicates all line endings

Initial Comment:
On Windows XP, reading a file produced by Windows XP with universal line endings produces twice as many lines!

Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> open("winlineend").read()
'Hello\r\n'
>>> open("winlineend", "rU").read()
'Hello\n\n'


I would expect the last to give "Hello\n". 

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

>Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-07 22:27

Message:
Logged In: YES 
user_id=769182
Originator: YES

I create the file as follows: 

>>> import os
>>> file = open("test.txt", "w")
>>> file.write("Hello" + os.linesep)
>>> file.close()
>>> open("test.txt").read()
'Hello\r\n'
>>> open("test.txt", "rU").read()
'Hello\n\n'


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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-07 19:39

Message:
Logged In: YES 
user_id=984087
Originator: NO


I created a file "test.txt" with notepad whose contents are "hello\r\n".
Both open().read() and open("rU").read() returned 'hello\n'. I tested with
both 2.5 and 2.5.1 (installed using installers from python.org) and the
result is same on both. Can you elaborate your test case more? How is this
file "winlineend" created?

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

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

From noreply at sourceforge.net  Mon May  7 23:06:02 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 07 May 2007 14:06:02 -0700
Subject: [ python-Bugs-1714451 ] subprocess.py problems errors when calling
	cmd.exe
Message-ID: <E1HlAPC-0000K8-Qm@sc8-sf-web22.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: tzellman (tzellman)
Assigned to: Nobody/Anonymous (nobody)
Summary: subprocess.py problems errors when calling cmd.exe

Initial Comment:
An example:

>>> import subprocess
>>> proc = subprocess.Popen('"c:\Windows\system\ping.exe" "localhost"', shell=1, stdout=subprocess.PIPE, stderr=subprocess.PIPE)

'c:\Windows\system32\ping.exe" "localhost' is not recognized as an internal or external command, operable program or batch file.

This normally works from the cmd.exe prompt, so the command line is being passed incorrectly in the subprocess module.

My ACTUAL use case arises when I want to call the Microsoft compiler (CL.exe), and add include directories that have spaces in the name. For example:

"C:\Program Files\Microsoft Visual Studio 8\VC\BIN\CL.exe" /TC /O2 /DNDEBUG /W3
/nologo /c /EHsc /errorReport:prompt /Idefault\ /I.. /I. /Idefault /I"C:\Program Files\GnuWin32" /DWIN32 ..\pcreposix.c /Fodefault\pcreposix.obj

The fix for this problem is to modify line 765 in subprocess.py, replacing it with:


args = comspec + " /s /c \"%s\"" % args.replace('""', '"')


The /s tells cmd.exe not to re-format the command line. We then encase the entire command line in double quotes. I also replace occurrences of "" with " in the arg string, in case the user already encased the command in double quotes.

With this fix, the commands execute correctly.

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

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-07 18:06

Message:
Logged In: YES 
user_id=479790
Originator: NO

Use a list of arguments instead, and please remember to use raw strings or
double backslashes:

proc = subprocess.Popen([r"c:\Windows\system\ping.exe","localhost"],
shell=1, stdout=subprocess.PIPE, stderr=subprocess.PIPE)


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

Comment By: tzellman (tzellman)
Date: 2007-05-07 14:20

Message:
Logged In: YES 
user_id=1090960
Originator: YES

This could likely be rejected.

I realize a solution to this w/o modifying the Python source is to encase
the expression yourself in double quotes. So, the example given would look
like:
>>> import subprocess
>>> proc = subprocess.Popen('""c:\Windows\system\ping.exe" "localhost""',
shell=1, stdout=subprocess.PIPE, stderr=subprocess.PIPE)

And that will work.

Sorry for any confusion.


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

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

From noreply at sourceforge.net  Mon May  7 23:15:40 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 07 May 2007 14:15:40 -0700
Subject: [ python-Bugs-1714381 ] Universal line ending mode duplicates all
	line endings
Message-ID: <E1HlAYW-0002ak-DH@sc8-sf-web21.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Geoffrey Bache (gjb1002)
Assigned to: Nobody/Anonymous (nobody)
Summary: Universal line ending mode duplicates all line endings

Initial Comment:
On Windows XP, reading a file produced by Windows XP with universal line endings produces twice as many lines!

Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> open("winlineend").read()
'Hello\r\n'
>>> open("winlineend", "rU").read()
'Hello\n\n'


I would expect the last to give "Hello\n". 

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

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-07 18:15

Message:
Logged In: YES 
user_id=479790
Originator: NO

> file.write("Hello" + os.linesep)

The line separator for a file opened in *text*mode* is *always* \n in
Python code. It gets converted to os.linesep when you write the file; and
conversely, os.linesep get translated into a single \n when you read the
file.
On Windows, os.linesep is "\r\n". The argument to file.write above is 
"Hello\r\n". That "\n" gets translated into "\r\n" when it is written, so
the actual file contents will be "Hello\r\n\n"

In short: if you open a file in text mode (the default) *don't* use
os.linesep to terminate lines. Only use os.linesep when writing text files
open in binary mode (and that's not a common case).


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

Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-07 17:27

Message:
Logged In: YES 
user_id=769182
Originator: YES

I create the file as follows: 

>>> import os
>>> file = open("test.txt", "w")
>>> file.write("Hello" + os.linesep)
>>> file.close()
>>> open("test.txt").read()
'Hello\r\n'
>>> open("test.txt", "rU").read()
'Hello\n\n'


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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-07 14:39

Message:
Logged In: YES 
user_id=984087
Originator: NO


I created a file "test.txt" with notepad whose contents are "hello\r\n".
Both open().read() and open("rU").read() returned 'hello\n'. I tested with
both 2.5 and 2.5.1 (installed using installers from python.org) and the
result is same on both. Can you elaborate your test case more? How is this
file "winlineend" created?

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

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

From noreply at sourceforge.net  Mon May  7 23:36:56 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 07 May 2007 14:36:56 -0700
Subject: [ python-Bugs-1714381 ] Universal line ending mode duplicates all
	line endings
Message-ID: <E1HlAt6-0004v9-Tk@sc8-sf-web21.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Geoffrey Bache (gjb1002)
Assigned to: Nobody/Anonymous (nobody)
Summary: Universal line ending mode duplicates all line endings

Initial Comment:
On Windows XP, reading a file produced by Windows XP with universal line endings produces twice as many lines!

Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> open("winlineend").read()
'Hello\r\n'
>>> open("winlineend", "rU").read()
'Hello\n\n'


I would expect the last to give "Hello\n". 

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

>Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-07 23:36

Message:
Logged In: YES 
user_id=769182
Originator: YES

I see. This seems like something of a gotcha to me: is it documented
anywhere? Seems to make os.linesep not very useful in fact, especially if
"\n" will work fine everywhere and is shorter. 

It isn't at all obvious that file.write(os.linesep) will in fact write two
lines...


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

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-07 23:15

Message:
Logged In: YES 
user_id=479790
Originator: NO

> file.write("Hello" + os.linesep)

The line separator for a file opened in *text*mode* is *always* \n in
Python code. It gets converted to os.linesep when you write the file; and
conversely, os.linesep get translated into a single \n when you read the
file.
On Windows, os.linesep is "\r\n". The argument to file.write above is 
"Hello\r\n". That "\n" gets translated into "\r\n" when it is written, so
the actual file contents will be "Hello\r\n\n"

In short: if you open a file in text mode (the default) *don't* use
os.linesep to terminate lines. Only use os.linesep when writing text files
open in binary mode (and that's not a common case).


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

Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-07 22:27

Message:
Logged In: YES 
user_id=769182
Originator: YES

I create the file as follows: 

>>> import os
>>> file = open("test.txt", "w")
>>> file.write("Hello" + os.linesep)
>>> file.close()
>>> open("test.txt").read()
'Hello\r\n'
>>> open("test.txt", "rU").read()
'Hello\n\n'


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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-07 19:39

Message:
Logged In: YES 
user_id=984087
Originator: NO


I created a file "test.txt" with notepad whose contents are "hello\r\n".
Both open().read() and open("rU").read() returned 'hello\n'. I tested with
both 2.5 and 2.5.1 (installed using installers from python.org) and the
result is same on both. Can you elaborate your test case more? How is this
file "winlineend" created?

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

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

From noreply at sourceforge.net  Tue May  8 03:48:32 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 07 May 2007 18:48:32 -0700
Subject: [ python-Bugs-1714381 ] Universal line ending mode duplicates all
	line endings
Message-ID: <E1HlEoa-0003k2-Bk@sc8-sf-web21.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Geoffrey Bache (gjb1002)
Assigned to: Nobody/Anonymous (nobody)
Summary: Universal line ending mode duplicates all line endings

Initial Comment:
On Windows XP, reading a file produced by Windows XP with universal line endings produces twice as many lines!

Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> open("winlineend").read()
'Hello\r\n'
>>> open("winlineend", "rU").read()
'Hello\n\n'


I would expect the last to give "Hello\n". 

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

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-07 22:48

Message:
Logged In: YES 
user_id=479790
Originator: NO

Yes, it's not so obvious, and the same question was posted a few days ago
on comp.lang.python.
I'll review the documentation and make it more clearly stated.


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

Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-07 18:36

Message:
Logged In: YES 
user_id=769182
Originator: YES

I see. This seems like something of a gotcha to me: is it documented
anywhere? Seems to make os.linesep not very useful in fact, especially if
"\n" will work fine everywhere and is shorter. 

It isn't at all obvious that file.write(os.linesep) will in fact write two
lines...


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

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-07 18:15

Message:
Logged In: YES 
user_id=479790
Originator: NO

> file.write("Hello" + os.linesep)

The line separator for a file opened in *text*mode* is *always* \n in
Python code. It gets converted to os.linesep when you write the file; and
conversely, os.linesep get translated into a single \n when you read the
file.
On Windows, os.linesep is "\r\n". The argument to file.write above is 
"Hello\r\n". That "\n" gets translated into "\r\n" when it is written, so
the actual file contents will be "Hello\r\n\n"

In short: if you open a file in text mode (the default) *don't* use
os.linesep to terminate lines. Only use os.linesep when writing text files
open in binary mode (and that's not a common case).


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

Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-07 17:27

Message:
Logged In: YES 
user_id=769182
Originator: YES

I create the file as follows: 

>>> import os
>>> file = open("test.txt", "w")
>>> file.write("Hello" + os.linesep)
>>> file.close()
>>> open("test.txt").read()
'Hello\r\n'
>>> open("test.txt", "rU").read()
'Hello\n\n'


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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-07 14:39

Message:
Logged In: YES 
user_id=984087
Originator: NO


I created a file "test.txt" with notepad whose contents are "hello\r\n".
Both open().read() and open("rU").read() returned 'hello\n'. I tested with
both 2.5 and 2.5.1 (installed using installers from python.org) and the
result is same on both. Can you elaborate your test case more? How is this
file "winlineend" created?

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

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

From noreply at sourceforge.net  Tue May  8 10:23:05 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 08 May 2007 01:23:05 -0700
Subject: [ python-Bugs-1714773 ] python throws an error when unpacking bz2 file
Message-ID: <E1HlKyP-0001Zs-6D@sc8-sf-web23.sourceforge.net>

Bugs item #1714773, was opened at 2007-05-08 17: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=1714773&group_id=5470

Please note that this 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
Private: No
Submitted By: runnig (runnig)
Assigned to: Nobody/Anonymous (nobody)
Summary: python throws an error when unpacking bz2 file

Initial Comment:
C:\work\python>c:\work\python\25\py.exe
Python 2.5 (r25:51908, Feb 13 2007, 14:33:20) [MSC v.1400 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
C:\work\python>ez_setup.py wxpython
Searching for wxpython
Reading http://cheeseshop.python.org/pypi/wxpython/
Couldn't find index page for 'wxpython' (maybe misspelled?)
Scanning index of all packages (this may take a while)
Reading http://cheeseshop.python.org/pypi/
Reading http://cheeseshop.python.org/pypi/wxPython/2.6.3.2
Reading http://wxPython.org/
Reading http://wxPython.org/download.php
Best match: wxPython src-2.8.3.0
Downloading http://prdownloads.sourceforge.net/wxpython/wxPython-src-2.8.3.0.tar.bz2
Processing wxPython-src-2.8.3.0.tar.bz2


I think, when unpacking bz2, an error occurs and windows shows an error about 
"python.exe has encountered a problem and needs to close"


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

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

From noreply at sourceforge.net  Tue May  8 14:50:16 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 08 May 2007 05:50:16 -0700
Subject: [ python-Bugs-1707768 ] os.path.normpath changes path (chops of
	trailing slash)
Message-ID: <E1HlP8y-0006kK-QL@sc8-sf-web21.sourceforge.net>

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

Please note that this message will contain a full 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
Private: No
Submitted By: Robert Siemer (siemer)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.normpath changes path (chops of trailing slash)

Initial Comment:
Hello everybody!

>>> os.path.normpath('/etc/passwd')
'/etc/passwd'


I don't know any environment at all where

a) '/etc/passwd/'
b) '/etc/passwd'

are treated the same. It clearly does not apply for the path part of http urls (this is left as an exercise for the reader).

But it also does not apply for (e.g.) Linux either:
an open() on path a) return ENOTDIR while it succeeds with b).

(assuming /etc/passwd is a file)

This is definitively not a documentation bug, as "normpath" should normalize a path and not fuck it up.


Robert

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

Comment By: Istvan Szegedi (iszegedi)
Date: 2007-05-08 14:50

Message:
Logged In: YES 
user_id=1772412
Originator: NO

I agree with the approach that josm suggested. That is a reasonable way to
get the fix approved or declined.

To response to the remarks from siemer:

1 - 2./ I think what we miss here is the exact definition what path
normalization means. All examples that I have seen so far - including the
comments in the posixpath python module as well - are about removing
redundant information or extra dots and double dots from the path (e.g.
A//B, A/./B and A/foo/../B all become A/B). I have not seen any precise
definition how to deal with trailing slash in a pathname (except for the
one that I copy&pasted from POSIX standard). 
That says explicitly that "a pathname ... SHALL BE RESOLVED as if a single
dot .. were appended". 

Nevertheless, I can accept that since it is not implemented neither in
regular UNIX shell utilities nor in C system libraries, we may opt for a
"common sense solution" meaning that 

os.path.normpath('/etc/passwd/')  -->  '/etc/passwd/'


In fact, this is pretty simple to implement as I have already given an
example; the original proposal needs to be modified by one character only:

Instead of adding '/.' to the end of the path, just add a '/': 

# The next two lines were added by iszegedi
    if trailing_slash:
        path = path + '/'



3./ path = path.rstrip()
This doesn't remove any significant whitespaces from the pathname, as far
as I see. It only removes the trailing whitespaces from the pathname, the
rest is going to stay as is. An example:

In the current posixpath module, if you use spaces at the end of the
pathname string, it will be displayed like:

os.path.normpath('/etc/password/   ')   --->  '/etc/passwd/    '

if we use rstrip() as suggested, then the result would be:

os.path.normpath('/etc/password/   ')   --->  '/etc/passwd/'

which makes more sense to me.

But for instance:

os.path.normpath('/etc/   /passwd/')   ---> '/etc/   /passwd/'


Istvan

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

Comment By: jos (josm)
Date: 2007-05-06 11:31

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Like all other python libraries, posixpath.normpath has its test cases,
which specify what normpath is supposed to work.
See test_normpath() in Lib/test/test_posixpath.py.

siemer, would you add some test cases for this problem to
test_posixpath.py?
I think it needs not just adding but also need to update existent cases.
That means it would break backwards-compatibility.

According to http://www.python.org/dev/intro/,
changing existing functionality "requires python- dev as a whole to agree
to the change."

So the TODO list would be

1. Write test cases for this problem and post it to the patch manager
2. Discuss the changes on python-dev at python.org and get agreement
3. Write patch and post it to the patch manager
4. Get some reviews
5. Commit

Correct Me If I'm Wrong.

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

Comment By: Robert Siemer (siemer)
Date: 2007-05-06 06:15

Message:
Logged In: YES 
user_id=150699
Originator: YES

1) I (submitter) didn't specify what I expected to see:

os.path.normpath('/etc/passwd/') --> '/etc/passwd/'

So, I agree with the latest consensus, but definitely not with the
"/etc/passwd/." version...


2) I can't draw any explicit normalization rules from the excerpts of the
POSIX standard posted by iszegedi. Saying that "dir/" should be treated as
"dir/." doesn't mean that it is the normalized version of the first one. -
I actually read implicitly that the first one is the habitual one that
needs interpretation.

And I think everybody agrees that - beeing the same or not - "dir/." is
unusual.

3) I don't know what this is good for in the proposal:
path = path.rstrip()

It removes significant whitespace from the path, what must be avoided.

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

Comment By: Istvan Szegedi (iszegedi)
Date: 2007-05-01 20:05

Message:
Logged In: YES 
user_id=1772412
Originator: NO

I must admit that josm's comments make sense: in fact, I quickly tried out
how mkdir command from a bash shell would behave and it does the same:

# mkdir hello
# rmdir hello/. 
Invalid argument

whereas
# rmdir hello/

works fine. I also wrote a small C program using mkdir() and rmdir()
functions and they behave exactly the same as mkdir/rmdir from bash (well,
no real suprise).

My suggestion to get the original issue fixed was based on POSIX standard
and apparently the Linux commands are not fully POSIX compliant, either...
Or do I misunderstand the quotes from the standard?  Anyway, it is pretty
easy to modify my fix to be inline with Linux commands and C functions -
everything could be the same, apart from the last line where I added "/." 
-- this should be only "/".  So the entire function could look like this:

-- clip --


def normpath(path):
    """Normalize path, eliminating double slashes, etc."""
    if path == '':
        return '.'
    initial_slashes = path.startswith('/')
    # The next two lines were added by iszegedi
    path = path.rstrip()
    trailing_slash = path.endswith('/')
    # POSIX allows one or two initial slashes, but treats three or more
    # as single slash.
    if (initial_slashes and
        path.startswith('//') and not path.startswith('///')):
        initial_slashes = 2
    comps = path.split('/')
    new_comps = []
    for comp in comps:
        if comp in ('', '.'):
            continue
        if (comp != '..' or (not initial_slashes and not new_comps) or
             (new_comps and new_comps[-1] == '..')):
            new_comps.append(comp)
        elif new_comps:
            new_comps.pop()
    comps = new_comps
    path = '/'.join(comps)
    if initial_slashes:
        path = '/'*initial_slashes + path
    # The next two lines were added by iszegedi
    if trailing_slash:
        path = path + '/'
    return path or '.'


-- clip --

Nevertheless, I would really appreciate to receive some comments from
POSIX gurus, how they see this problem.


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

Comment By: jos (josm)
Date: 2007-04-30 08:48

Message:
Logged In: YES 
user_id=1776568
Originator: NO

I think we should be careful enough to tackle on this.
iszegedi's patch seems to work correctly,
but XBD's spec itself has some defect.
http://www.opengroup.org/austin/mailarchives/ag-review/msg01722.html

What do you think of the follow behavior?
>>> os.mkdir('dir/')
>>> os.mkdir('dir2/')
>>> os.rmdir(os.path.normpath('dir'))
>>> os.rmdir(os.path.normpath('dir2/'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 22] Invalid argument: 'dir2/.'




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

Comment By: Istvan Szegedi (iszegedi)
Date: 2007-04-28 22:27

Message:
Logged In: YES 
user_id=1772412
Originator: NO


Here is what Posix standard says about pathnames:

"Base Definitions volume of IEEE Std 1003.1-2001, Section 3.266,
Pathname.

A character string that is used to identify a file. In the context of IEEE
Std 1003.1-2001, a pathname consists of, at most, {PATH_MAX} bytes,
including the terminating null byte. It has an optional beginning slash,
followed by zero or more filenames separated by slashes. A pathname may
optionally contain one or more trailing slashes. Multiple successive
slashes are considered to be the same as one slash."

And in the details:

"A pathname that contains at least one non-slash character and that ends
with one or more trailing slashes shall be resolved as if a single dot
character ( '.' ) were appended to the pathname."

So if I am not mistaken, according to the POSIX standard the example that
you gave - '/etc/passwd/' - should be normalized to '/etc/passwd/.' That
does not happen, indeed.

The reason for that is that in posixpath.py file the normpath() function
is using a split('/') function to split up the path into smaller chunks,
skips everything which is empty or '.' and at the end of the normpath()
function it adds slash(es) only to the beginning of the string. 

As a test, I modified the normpath() function in the posixpath.py as
follows:

--- clip ---

def normpath(path):
    """Normalize path, eliminating double slashes, etc."""
    if path == '':
        return '.'
    initial_slashes = path.startswith('/')
    # The next two lines were added by iszegedi
    path = path.rstrip()
    trailing_slash = path.endswith('/')
    # POSIX allows one or two initial slashes, but treats three or more
    # as single slash.
    if (initial_slashes and
        path.startswith('//') and not path.startswith('///')):
        initial_slashes = 2
    comps = path.split('/')
    new_comps = []
    for comp in comps:
        if comp in ('', '.'):
            continue
        if (comp != '..' or (not initial_slashes and not new_comps) or
             (new_comps and new_comps[-1] == '..')):
            new_comps.append(comp)
        elif new_comps:
            new_comps.pop()
    comps = new_comps
    path = '/'.join(comps)
    if initial_slashes:
        path = '/'*initial_slashes + path
    # The next two lines were added by iszegedi
    if trailing_slash:
        path = path + '/.'
    return path or '.'
  
-- clip --

So I added two lines (marked as "added by iszegedi" ) in the beginning to
remove any trailing whitespaces and check whether the path ends with slash.
Then at the end of the function I added another two lines to append '/.' to
the end of the return value if the input path variable ended by slash

This works now fine.

What makes it a bit tricky is that python os module imports different
xxxpath.py module depending on the host operating system. So it imports
different modules for nt, for mac, for os2, for posix, etc.  The solution
above works for posix, but the other modules need to be checked, to.


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

Comment By: Robert Siemer (siemer)
Date: 2007-04-26 01:47

Message:
Logged In: YES 
user_id=150699
Originator: YES

A bugreport bug:

The example should read os.path.normpath('/etc/passwd/')...

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

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

From noreply at sourceforge.net  Tue May  8 16:24:54 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 08 May 2007 07:24:54 -0700
Subject: [ python-Bugs-1707768 ] os.path.normpath changes path (chops of
	trailing slash)
Message-ID: <E1HlQcY-0008Bd-0u@sc8-sf-web24.sourceforge.net>

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

Please note that this message will contain a full 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
Private: No
Submitted By: Robert Siemer (siemer)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.normpath changes path (chops of trailing slash)

Initial Comment:
Hello everybody!

>>> os.path.normpath('/etc/passwd')
'/etc/passwd'


I don't know any environment at all where

a) '/etc/passwd/'
b) '/etc/passwd'

are treated the same. It clearly does not apply for the path part of http urls (this is left as an exercise for the reader).

But it also does not apply for (e.g.) Linux either:
an open() on path a) return ENOTDIR while it succeeds with b).

(assuming /etc/passwd is a file)

This is definitively not a documentation bug, as "normpath" should normalize a path and not fuck it up.


Robert

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

>Comment By: Robert Siemer (siemer)
Date: 2007-05-08 16:24

Message:
Logged In: YES 
user_id=150699
Originator: YES

Istvan, you seem to think that trailing whitespace is not significant.
That assumption is wrong. '   ' is a perfect file name... Apart from spaces
even newlines, etc. are okay - and not the same.

I'm also "working" on a good path name handling essay. (-:

Robert

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

Comment By: Istvan Szegedi (iszegedi)
Date: 2007-05-08 14:50

Message:
Logged In: YES 
user_id=1772412
Originator: NO

I agree with the approach that josm suggested. That is a reasonable way to
get the fix approved or declined.

To response to the remarks from siemer:

1 - 2./ I think what we miss here is the exact definition what path
normalization means. All examples that I have seen so far - including the
comments in the posixpath python module as well - are about removing
redundant information or extra dots and double dots from the path (e.g.
A//B, A/./B and A/foo/../B all become A/B). I have not seen any precise
definition how to deal with trailing slash in a pathname (except for the
one that I copy&pasted from POSIX standard). 
That says explicitly that "a pathname ... SHALL BE RESOLVED as if a single
dot .. were appended". 

Nevertheless, I can accept that since it is not implemented neither in
regular UNIX shell utilities nor in C system libraries, we may opt for a
"common sense solution" meaning that 

os.path.normpath('/etc/passwd/')  -->  '/etc/passwd/'


In fact, this is pretty simple to implement as I have already given an
example; the original proposal needs to be modified by one character only:

Instead of adding '/.' to the end of the path, just add a '/': 

# The next two lines were added by iszegedi
    if trailing_slash:
        path = path + '/'



3./ path = path.rstrip()
This doesn't remove any significant whitespaces from the pathname, as far
as I see. It only removes the trailing whitespaces from the pathname, the
rest is going to stay as is. An example:

In the current posixpath module, if you use spaces at the end of the
pathname string, it will be displayed like:

os.path.normpath('/etc/password/   ')   --->  '/etc/passwd/    '

if we use rstrip() as suggested, then the result would be:

os.path.normpath('/etc/password/   ')   --->  '/etc/passwd/'

which makes more sense to me.

But for instance:

os.path.normpath('/etc/   /passwd/')   ---> '/etc/   /passwd/'


Istvan

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

Comment By: jos (josm)
Date: 2007-05-06 11:31

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Like all other python libraries, posixpath.normpath has its test cases,
which specify what normpath is supposed to work.
See test_normpath() in Lib/test/test_posixpath.py.

siemer, would you add some test cases for this problem to
test_posixpath.py?
I think it needs not just adding but also need to update existent cases.
That means it would break backwards-compatibility.

According to http://www.python.org/dev/intro/,
changing existing functionality "requires python- dev as a whole to agree
to the change."

So the TODO list would be

1. Write test cases for this problem and post it to the patch manager
2. Discuss the changes on python-dev at python.org and get agreement
3. Write patch and post it to the patch manager
4. Get some reviews
5. Commit

Correct Me If I'm Wrong.

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

Comment By: Robert Siemer (siemer)
Date: 2007-05-06 06:15

Message:
Logged In: YES 
user_id=150699
Originator: YES

1) I (submitter) didn't specify what I expected to see:

os.path.normpath('/etc/passwd/') --> '/etc/passwd/'

So, I agree with the latest consensus, but definitely not with the
"/etc/passwd/." version...


2) I can't draw any explicit normalization rules from the excerpts of the
POSIX standard posted by iszegedi. Saying that "dir/" should be treated as
"dir/." doesn't mean that it is the normalized version of the first one. -
I actually read implicitly that the first one is the habitual one that
needs interpretation.

And I think everybody agrees that - beeing the same or not - "dir/." is
unusual.

3) I don't know what this is good for in the proposal:
path = path.rstrip()

It removes significant whitespace from the path, what must be avoided.

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

Comment By: Istvan Szegedi (iszegedi)
Date: 2007-05-01 20:05

Message:
Logged In: YES 
user_id=1772412
Originator: NO

I must admit that josm's comments make sense: in fact, I quickly tried out
how mkdir command from a bash shell would behave and it does the same:

# mkdir hello
# rmdir hello/. 
Invalid argument

whereas
# rmdir hello/

works fine. I also wrote a small C program using mkdir() and rmdir()
functions and they behave exactly the same as mkdir/rmdir from bash (well,
no real suprise).

My suggestion to get the original issue fixed was based on POSIX standard
and apparently the Linux commands are not fully POSIX compliant, either...
Or do I misunderstand the quotes from the standard?  Anyway, it is pretty
easy to modify my fix to be inline with Linux commands and C functions -
everything could be the same, apart from the last line where I added "/." 
-- this should be only "/".  So the entire function could look like this:

-- clip --


def normpath(path):
    """Normalize path, eliminating double slashes, etc."""
    if path == '':
        return '.'
    initial_slashes = path.startswith('/')
    # The next two lines were added by iszegedi
    path = path.rstrip()
    trailing_slash = path.endswith('/')
    # POSIX allows one or two initial slashes, but treats three or more
    # as single slash.
    if (initial_slashes and
        path.startswith('//') and not path.startswith('///')):
        initial_slashes = 2
    comps = path.split('/')
    new_comps = []
    for comp in comps:
        if comp in ('', '.'):
            continue
        if (comp != '..' or (not initial_slashes and not new_comps) or
             (new_comps and new_comps[-1] == '..')):
            new_comps.append(comp)
        elif new_comps:
            new_comps.pop()
    comps = new_comps
    path = '/'.join(comps)
    if initial_slashes:
        path = '/'*initial_slashes + path
    # The next two lines were added by iszegedi
    if trailing_slash:
        path = path + '/'
    return path or '.'


-- clip --

Nevertheless, I would really appreciate to receive some comments from
POSIX gurus, how they see this problem.


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

Comment By: jos (josm)
Date: 2007-04-30 08:48

Message:
Logged In: YES 
user_id=1776568
Originator: NO

I think we should be careful enough to tackle on this.
iszegedi's patch seems to work correctly,
but XBD's spec itself has some defect.
http://www.opengroup.org/austin/mailarchives/ag-review/msg01722.html

What do you think of the follow behavior?
>>> os.mkdir('dir/')
>>> os.mkdir('dir2/')
>>> os.rmdir(os.path.normpath('dir'))
>>> os.rmdir(os.path.normpath('dir2/'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 22] Invalid argument: 'dir2/.'




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

Comment By: Istvan Szegedi (iszegedi)
Date: 2007-04-28 22:27

Message:
Logged In: YES 
user_id=1772412
Originator: NO


Here is what Posix standard says about pathnames:

"Base Definitions volume of IEEE Std 1003.1-2001, Section 3.266,
Pathname.

A character string that is used to identify a file. In the context of IEEE
Std 1003.1-2001, a pathname consists of, at most, {PATH_MAX} bytes,
including the terminating null byte. It has an optional beginning slash,
followed by zero or more filenames separated by slashes. A pathname may
optionally contain one or more trailing slashes. Multiple successive
slashes are considered to be the same as one slash."

And in the details:

"A pathname that contains at least one non-slash character and that ends
with one or more trailing slashes shall be resolved as if a single dot
character ( '.' ) were appended to the pathname."

So if I am not mistaken, according to the POSIX standard the example that
you gave - '/etc/passwd/' - should be normalized to '/etc/passwd/.' That
does not happen, indeed.

The reason for that is that in posixpath.py file the normpath() function
is using a split('/') function to split up the path into smaller chunks,
skips everything which is empty or '.' and at the end of the normpath()
function it adds slash(es) only to the beginning of the string. 

As a test, I modified the normpath() function in the posixpath.py as
follows:

--- clip ---

def normpath(path):
    """Normalize path, eliminating double slashes, etc."""
    if path == '':
        return '.'
    initial_slashes = path.startswith('/')
    # The next two lines were added by iszegedi
    path = path.rstrip()
    trailing_slash = path.endswith('/')
    # POSIX allows one or two initial slashes, but treats three or more
    # as single slash.
    if (initial_slashes and
        path.startswith('//') and not path.startswith('///')):
        initial_slashes = 2
    comps = path.split('/')
    new_comps = []
    for comp in comps:
        if comp in ('', '.'):
            continue
        if (comp != '..' or (not initial_slashes and not new_comps) or
             (new_comps and new_comps[-1] == '..')):
            new_comps.append(comp)
        elif new_comps:
            new_comps.pop()
    comps = new_comps
    path = '/'.join(comps)
    if initial_slashes:
        path = '/'*initial_slashes + path
    # The next two lines were added by iszegedi
    if trailing_slash:
        path = path + '/.'
    return path or '.'
  
-- clip --

So I added two lines (marked as "added by iszegedi" ) in the beginning to
remove any trailing whitespaces and check whether the path ends with slash.
Then at the end of the function I added another two lines to append '/.' to
the end of the return value if the input path variable ended by slash

This works now fine.

What makes it a bit tricky is that python os module imports different
xxxpath.py module depending on the host operating system. So it imports
different modules for nt, for mac, for os2, for posix, etc.  The solution
above works for posix, but the other modules need to be checked, to.


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

Comment By: Robert Siemer (siemer)
Date: 2007-04-26 01:47

Message:
Logged In: YES 
user_id=150699
Originator: YES

A bugreport bug:

The example should read os.path.normpath('/etc/passwd/')...

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

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

From noreply at sourceforge.net  Tue May  8 18:01:45 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 08 May 2007 09:01:45 -0700
Subject: [ python-Bugs-1707768 ] os.path.normpath changes path (chops of
	trailing slash)
Message-ID: <E1HlS8H-00068L-Tw@sc8-sf-web22.sourceforge.net>

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

Please note that this message will contain a full 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
Private: No
Submitted By: Robert Siemer (siemer)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.normpath changes path (chops of trailing slash)

Initial Comment:
Hello everybody!

>>> os.path.normpath('/etc/passwd')
'/etc/passwd'


I don't know any environment at all where

a) '/etc/passwd/'
b) '/etc/passwd'

are treated the same. It clearly does not apply for the path part of http urls (this is left as an exercise for the reader).

But it also does not apply for (e.g.) Linux either:
an open() on path a) return ENOTDIR while it succeeds with b).

(assuming /etc/passwd is a file)

This is definitively not a documentation bug, as "normpath" should normalize a path and not fuck it up.


Robert

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

Comment By: Istvan Szegedi (iszegedi)
Date: 2007-05-08 18:01

Message:
Logged In: YES 
user_id=1772412
Originator: NO

Robert,
I checked once again the POSIX definition of filenames and you are right;
trailing whitespaces are allowed:

-- clip --
 3.169 Filename

A name consisting of 1 to {NAME_MAX} bytes used to name a file. The
characters composing the name may be selected from the set of all character
values excluding the slash character and the null byte. The filenames dot
and dot-dot have special meaning. A filename is sometimes referred to as a
"pathname component".
-- clip --


So I agree that this line

path = path.rstrip()

should be removed from the correction suggested by me.


-- clip --


def normpath(path):
    """Normalize path, eliminating double slashes, etc."""
    if path == '':
        return '.'
    initial_slashes = path.startswith('/')
    # The next line was added by iszegedi
    trailing_slash = path.endswith('/')
    # POSIX allows one or two initial slashes, but treats three or more
    # as single slash.
    if (initial_slashes and
        path.startswith('//') and not path.startswith('///')):
        initial_slashes = 2
    comps = path.split('/')
    new_comps = []
    for comp in comps:
        if comp in ('', '.'):
            continue
        if (comp != '..' or (not initial_slashes and not new_comps) or
             (new_comps and new_comps[-1] == '..')):
            new_comps.append(comp)
        elif new_comps:
            new_comps.pop()
    comps = new_comps
    path = '/'.join(comps)
    if initial_slashes:
        path = '/'*initial_slashes + path
    # The next two lines were added by iszegedi
    if trailing_slash:
        path = path + '/'
    return path or '.'


-- clip --

Nevertheless, the remaining question for me is still the same: what is the
exact definition of normalized path in regards with trailing slash (in
other words what is the correct solution: no slash at the end of the path
OR there should be a slash at the end of the path OR or there should be a
single . appended to the end of the path):

So what is the correct answer:
os.path.normpath('/etc/passwd/')  ---> '/etc/passwd'   OR
os.path.normpath('/etc/passwd/')  ---> '/etc/passwd/'  OR
os.path.normpath('/etc/passwd/')  ---> '/etc/passwd/.'

Once this is clarified, the solution is pretty easy.

Istvan

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

Comment By: Robert Siemer (siemer)
Date: 2007-05-08 16:24

Message:
Logged In: YES 
user_id=150699
Originator: YES

Istvan, you seem to think that trailing whitespace is not significant.
That assumption is wrong. '   ' is a perfect file name... Apart from spaces
even newlines, etc. are okay - and not the same.

I'm also "working" on a good path name handling essay. (-:

Robert

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

Comment By: Istvan Szegedi (iszegedi)
Date: 2007-05-08 14:50

Message:
Logged In: YES 
user_id=1772412
Originator: NO

I agree with the approach that josm suggested. That is a reasonable way to
get the fix approved or declined.

To response to the remarks from siemer:

1 - 2./ I think what we miss here is the exact definition what path
normalization means. All examples that I have seen so far - including the
comments in the posixpath python module as well - are about removing
redundant information or extra dots and double dots from the path (e.g.
A//B, A/./B and A/foo/../B all become A/B). I have not seen any precise
definition how to deal with trailing slash in a pathname (except for the
one that I copy&pasted from POSIX standard). 
That says explicitly that "a pathname ... SHALL BE RESOLVED as if a single
dot .. were appended". 

Nevertheless, I can accept that since it is not implemented neither in
regular UNIX shell utilities nor in C system libraries, we may opt for a
"common sense solution" meaning that 

os.path.normpath('/etc/passwd/')  -->  '/etc/passwd/'


In fact, this is pretty simple to implement as I have already given an
example; the original proposal needs to be modified by one character only:

Instead of adding '/.' to the end of the path, just add a '/': 

# The next two lines were added by iszegedi
    if trailing_slash:
        path = path + '/'



3./ path = path.rstrip()
This doesn't remove any significant whitespaces from the pathname, as far
as I see. It only removes the trailing whitespaces from the pathname, the
rest is going to stay as is. An example:

In the current posixpath module, if you use spaces at the end of the
pathname string, it will be displayed like:

os.path.normpath('/etc/password/   ')   --->  '/etc/passwd/    '

if we use rstrip() as suggested, then the result would be:

os.path.normpath('/etc/password/   ')   --->  '/etc/passwd/'

which makes more sense to me.

But for instance:

os.path.normpath('/etc/   /passwd/')   ---> '/etc/   /passwd/'


Istvan

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

Comment By: jos (josm)
Date: 2007-05-06 11:31

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Like all other python libraries, posixpath.normpath has its test cases,
which specify what normpath is supposed to work.
See test_normpath() in Lib/test/test_posixpath.py.

siemer, would you add some test cases for this problem to
test_posixpath.py?
I think it needs not just adding but also need to update existent cases.
That means it would break backwards-compatibility.

According to http://www.python.org/dev/intro/,
changing existing functionality "requires python- dev as a whole to agree
to the change."

So the TODO list would be

1. Write test cases for this problem and post it to the patch manager
2. Discuss the changes on python-dev at python.org and get agreement
3. Write patch and post it to the patch manager
4. Get some reviews
5. Commit

Correct Me If I'm Wrong.

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

Comment By: Robert Siemer (siemer)
Date: 2007-05-06 06:15

Message:
Logged In: YES 
user_id=150699
Originator: YES

1) I (submitter) didn't specify what I expected to see:

os.path.normpath('/etc/passwd/') --> '/etc/passwd/'

So, I agree with the latest consensus, but definitely not with the
"/etc/passwd/." version...


2) I can't draw any explicit normalization rules from the excerpts of the
POSIX standard posted by iszegedi. Saying that "dir/" should be treated as
"dir/." doesn't mean that it is the normalized version of the first one. -
I actually read implicitly that the first one is the habitual one that
needs interpretation.

And I think everybody agrees that - beeing the same or not - "dir/." is
unusual.

3) I don't know what this is good for in the proposal:
path = path.rstrip()

It removes significant whitespace from the path, what must be avoided.

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

Comment By: Istvan Szegedi (iszegedi)
Date: 2007-05-01 20:05

Message:
Logged In: YES 
user_id=1772412
Originator: NO

I must admit that josm's comments make sense: in fact, I quickly tried out
how mkdir command from a bash shell would behave and it does the same:

# mkdir hello
# rmdir hello/. 
Invalid argument

whereas
# rmdir hello/

works fine. I also wrote a small C program using mkdir() and rmdir()
functions and they behave exactly the same as mkdir/rmdir from bash (well,
no real suprise).

My suggestion to get the original issue fixed was based on POSIX standard
and apparently the Linux commands are not fully POSIX compliant, either...
Or do I misunderstand the quotes from the standard?  Anyway, it is pretty
easy to modify my fix to be inline with Linux commands and C functions -
everything could be the same, apart from the last line where I added "/." 
-- this should be only "/".  So the entire function could look like this:

-- clip --


def normpath(path):
    """Normalize path, eliminating double slashes, etc."""
    if path == '':
        return '.'
    initial_slashes = path.startswith('/')
    # The next two lines were added by iszegedi
    path = path.rstrip()
    trailing_slash = path.endswith('/')
    # POSIX allows one or two initial slashes, but treats three or more
    # as single slash.
    if (initial_slashes and
        path.startswith('//') and not path.startswith('///')):
        initial_slashes = 2
    comps = path.split('/')
    new_comps = []
    for comp in comps:
        if comp in ('', '.'):
            continue
        if (comp != '..' or (not initial_slashes and not new_comps) or
             (new_comps and new_comps[-1] == '..')):
            new_comps.append(comp)
        elif new_comps:
            new_comps.pop()
    comps = new_comps
    path = '/'.join(comps)
    if initial_slashes:
        path = '/'*initial_slashes + path
    # The next two lines were added by iszegedi
    if trailing_slash:
        path = path + '/'
    return path or '.'


-- clip --

Nevertheless, I would really appreciate to receive some comments from
POSIX gurus, how they see this problem.


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

Comment By: jos (josm)
Date: 2007-04-30 08:48

Message:
Logged In: YES 
user_id=1776568
Originator: NO

I think we should be careful enough to tackle on this.
iszegedi's patch seems to work correctly,
but XBD's spec itself has some defect.
http://www.opengroup.org/austin/mailarchives/ag-review/msg01722.html

What do you think of the follow behavior?
>>> os.mkdir('dir/')
>>> os.mkdir('dir2/')
>>> os.rmdir(os.path.normpath('dir'))
>>> os.rmdir(os.path.normpath('dir2/'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 22] Invalid argument: 'dir2/.'




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

Comment By: Istvan Szegedi (iszegedi)
Date: 2007-04-28 22:27

Message:
Logged In: YES 
user_id=1772412
Originator: NO


Here is what Posix standard says about pathnames:

"Base Definitions volume of IEEE Std 1003.1-2001, Section 3.266,
Pathname.

A character string that is used to identify a file. In the context of IEEE
Std 1003.1-2001, a pathname consists of, at most, {PATH_MAX} bytes,
including the terminating null byte. It has an optional beginning slash,
followed by zero or more filenames separated by slashes. A pathname may
optionally contain one or more trailing slashes. Multiple successive
slashes are considered to be the same as one slash."

And in the details:

"A pathname that contains at least one non-slash character and that ends
with one or more trailing slashes shall be resolved as if a single dot
character ( '.' ) were appended to the pathname."

So if I am not mistaken, according to the POSIX standard the example that
you gave - '/etc/passwd/' - should be normalized to '/etc/passwd/.' That
does not happen, indeed.

The reason for that is that in posixpath.py file the normpath() function
is using a split('/') function to split up the path into smaller chunks,
skips everything which is empty or '.' and at the end of the normpath()
function it adds slash(es) only to the beginning of the string. 

As a test, I modified the normpath() function in the posixpath.py as
follows:

--- clip ---

def normpath(path):
    """Normalize path, eliminating double slashes, etc."""
    if path == '':
        return '.'
    initial_slashes = path.startswith('/')
    # The next two lines were added by iszegedi
    path = path.rstrip()
    trailing_slash = path.endswith('/')
    # POSIX allows one or two initial slashes, but treats three or more
    # as single slash.
    if (initial_slashes and
        path.startswith('//') and not path.startswith('///')):
        initial_slashes = 2
    comps = path.split('/')
    new_comps = []
    for comp in comps:
        if comp in ('', '.'):
            continue
        if (comp != '..' or (not initial_slashes and not new_comps) or
             (new_comps and new_comps[-1] == '..')):
            new_comps.append(comp)
        elif new_comps:
            new_comps.pop()
    comps = new_comps
    path = '/'.join(comps)
    if initial_slashes:
        path = '/'*initial_slashes + path
    # The next two lines were added by iszegedi
    if trailing_slash:
        path = path + '/.'
    return path or '.'
  
-- clip --

So I added two lines (marked as "added by iszegedi" ) in the beginning to
remove any trailing whitespaces and check whether the path ends with slash.
Then at the end of the function I added another two lines to append '/.' to
the end of the return value if the input path variable ended by slash

This works now fine.

What makes it a bit tricky is that python os module imports different
xxxpath.py module depending on the host operating system. So it imports
different modules for nt, for mac, for os2, for posix, etc.  The solution
above works for posix, but the other modules need to be checked, to.


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

Comment By: Robert Siemer (siemer)
Date: 2007-04-26 01:47

Message:
Logged In: YES 
user_id=150699
Originator: YES

A bugreport bug:

The example should read os.path.normpath('/etc/passwd/')...

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

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

From noreply at sourceforge.net  Tue May  8 21:05:36 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 08 May 2007 12:05:36 -0700
Subject: [ python-Bugs-1713252 ] character set in Japanese on Ubuntu
	distribution
Message-ID: <E1HlV0C-0005gQ-WD@sc8-sf-web23.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.5
Status: Open
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Christopher Grell (cgrell)
Assigned to: Nobody/Anonymous (nobody)
Summary: character set in Japanese on Ubuntu distribution

Initial Comment:
I tried to use IDLE on new Ubuntu 7.04 and the window opens with Japanese character set

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

>Comment By: Martin v. L?wis (loewis)
Date: 2007-05-08 21:05

Message:
Logged In: YES 
user_id=21627
Originator: NO

What do you mean by "opens with Japanese character set"? Can you provide a
screenshot?

Can you figure out what font it is using?

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

Comment By: Christopher Grell (cgrell)
Date: 2007-05-07 04:42

Message:
Logged In: YES 
user_id=1785859
Originator: YES

Changing default character size to 20 removes the issue

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

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-05 09:08

Message:
Logged In: YES 
user_id=849994
Originator: NO

As this is certainly not the case in other distributions, this is
something you should file with the Ubuntu bug tracker.

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

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

From noreply at sourceforge.net  Tue May  8 21:07:04 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 08 May 2007 12:07:04 -0700
Subject: [ python-Bugs-1711605 ] CGIHttpServer leaves traces of previous
	requests in env
Message-ID: <E1HlV1c-0005t9-L4@sc8-sf-web23.sourceforge.net>

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

Please note that this 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
Private: No
Submitted By: Steve Cassidy (stevecassidy)
Assigned to: Nobody/Anonymous (nobody)
Summary: CGIHttpServer leaves traces of previous requests in env

Initial Comment:
CGIHttpserver tries to reset the environment between calls to CGI scripts by setting various variables to '' if they are not needed in the current request. In some cases this is not the correct behaviour since the presence of a null value can be interpreted by a CGI script as being significant. 

For example, if HTTP_COOKIE has a null value then a script doing the standard test:

if os.environ.has_key('HTTP_COOKIE'):
   # get the cookie

will have trouble

The problem is that CGIHTTPserver.py resets the entries in the env array which is then passed to os.environ.update(), this can only overwrite the env variables, not remove them.

An alternative is to call 

if os.environ.has_key(k):
    del os.environ[k]

inside the loop that updates the empty keys, then these variables will not be passed on to the CGI script.

Steve


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

>Comment By: Martin v. L?wis (loewis)
Date: 2007-05-08 21:07

Message:
Logged In: YES 
user_id=21627
Originator: NO

Can you provide a patch?

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

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

From noreply at sourceforge.net  Tue May  8 21:11:51 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 08 May 2007 12:11:51 -0700
Subject: [ python-Bugs-1711608 ] CGIHttpServer fails if python exe has spaces
Message-ID: <E1HlV6F-0006zi-6t@sc8-sf-web24.sourceforge.net>

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

Please note that this 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
Private: No
Submitted By: Steve Cassidy (stevecassidy)
Assigned to: Nobody/Anonymous (nobody)
Summary: CGIHttpServer fails if python exe has spaces

Initial Comment:
In addition to the problem noted in #1436206 with spaces in the file names of scripts being executed, if Python has been installed in a directory with spaces (C:\Program Files\Python) the server will fail to execute the script because the name of the executable is not quoted properly.

My attempts to fix this have failed since just putting quotes around the exe name "C:\\Program Files\..." doesn't work, however we have found that just quoting the part of the path with spaces 'C:\\"Program Files"\\...' will work.  

It seems a bit odd that this bug has persisted for so long. A fix would be nice since this module is really good to give to my students (doing python web development for the first time) so they don't have to worry about server installation issues. 

Steve



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

>Comment By: Martin v. L?wis (loewis)
Date: 2007-05-08 21:11

Message:
Logged In: YES 
user_id=21627
Originator: NO

I don't find it odd that the bug persisted for so long: there is a reason
that the default installation of Python does *not* go into "Program Files",
as spaces in file names produce endless problems.

Quoting the paths should work, though - don't forget to quote arguments as
well.

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

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

From noreply at sourceforge.net  Tue May  8 22:15:07 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 08 May 2007 13:15:07 -0700
Subject: [ python-Bugs-856047 ] urllib.py does not use "no_proxy";
Message-ID: <E1HlW5T-0005oh-SN@sc8-sf-web21.sourceforge.net>

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

Please note that this message will contain a full 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
Private: No
Submitted By: Donovan Baarda (abo)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib.py does not use "no_proxy";

Initial Comment:
urllib.py uses &quot;*_proxy&quot; variables to identify proxies
to use in the &quot;getproxies()&quot; function. However, it does
not use the corresponding &quot;no_proxy&quot; variable in the
&quot;proxy_bypass()&quot; method.

This affects any platform that can use &quot;*_proxy&quot;
environment variables to specify proxies. This includes
win32, which will use environment variables before the
registry if they are defined.

On win32 this causes the confusing behaviour of using
the registry for &quot;proxy_bypass()&quot; checking when
&quot;*_proxy&quot; environment variables are used to identify
the proxies.

Attached is a patch against python-2.3.2 that adds
support for &quot;no_proxy&quot;. Note that win32 will correctly
favor using &quot;no_proxy&quot; over using the registry if any
&quot;*_proxy&quot; variables are defined.


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

Comment By: Till Maas (tmaas)
Date: 2007-05-08 22:15

Message:
Logged In: YES 
user_id=60606
Originator: NO

So, it is two years later now, will this ever be fixed? Is there a way to
disable to use of proxies completely without having to change the
enviroment when http_proxy is set? It is a bad user experience, when one is
only able to change a proxy but not to disable the use of proxies
completely.

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

Comment By: Donovan Baarda (abo)
Date: 2005-02-19 06:21

Message:
Logged In: YES 
user_id=10273

This bug is still present in current versions of Python.

The biggest problem with this patch is it only addresses urllib, 
when urllib2 has the same problem.

I have been meaning to put together a new patch that fixes 
both urllib and urllib2, but haven't had time or external 
motivation yet.

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

Comment By: Enrico Scholz (ensc)
Date: 2005-02-18 12:13

Message:
Logged In: YES 
user_id=10773

What is the state of this bug? Is something wrong with the
patch that it was not applied yet?

It is something annoying to unset $http_proxy manually for
some programs.

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

Comment By: Donovan Baarda (abo)
Date: 2003-12-08 05:27

Message:
Logged In: YES 
user_id=10273

Whups... failed to attach patch.

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

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

From noreply at sourceforge.net  Tue May  8 23:49:32 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 08 May 2007 14:49:32 -0700
Subject: [ python-Bugs-1715302 ] datetime.date won't accept 08 or 09 as valid
	days.
Message-ID: <E1HlXYq-0007wB-Lt@sc8-sf-web21.sourceforge.net>

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

Please note that this message will contain a full 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
Private: No
Submitted By: Erik Wickstrom (erikcw)
Assigned to: Nobody/Anonymous (nobody)
Summary: datetime.date won't accept 08 or 09 as valid days.

Initial Comment:
The method won't accept 08 or 09 as valid days, but will accept 07.

Here is my output:

Python 2.5.1c1 (release25-maint, Apr 12 2007, 21:00:25)
[GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime
>>> t = datetime.date(2007, 05, 07)
>>> print t
2007-05-07
>>> t = datetime.date(2007, 05, 08)
  File "<stdin>", line 1
    t = datetime.date(2007, 05, 08)
                                 ^
SyntaxError: invalid token
>>> t = datetime.date(2007, 05, 09)
  File "<stdin>", line 1
    t = datetime.date(2007, 05, 09)
                                 ^
SyntaxError: invalid token
>>> t = datetime.date(2007, 05, 10)
>>> print t
2007-05-10
>>>

I was able to reproduce this on another machine as well:
Python 2.4.3 (#1, Aug  6 2006, 20:52:01)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.


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

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

From noreply at sourceforge.net  Wed May  9 00:24:04 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 08 May 2007 15:24:04 -0700
Subject: [ python-Bugs-1715302 ] datetime.date won't accept 08 or 09 as valid
	days.
Message-ID: <E1HlY6G-0000ZT-DR@sc8-sf-web24.sourceforge.net>

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

Please note that this message will contain a full 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
Private: No
Submitted By: Erik Wickstrom (erikcw)
Assigned to: Nobody/Anonymous (nobody)
Summary: datetime.date won't accept 08 or 09 as valid days.

Initial Comment:
The method won't accept 08 or 09 as valid days, but will accept 07.

Here is my output:

Python 2.5.1c1 (release25-maint, Apr 12 2007, 21:00:25)
[GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime
>>> t = datetime.date(2007, 05, 07)
>>> print t
2007-05-07
>>> t = datetime.date(2007, 05, 08)
  File "<stdin>", line 1
    t = datetime.date(2007, 05, 08)
                                 ^
SyntaxError: invalid token
>>> t = datetime.date(2007, 05, 09)
  File "<stdin>", line 1
    t = datetime.date(2007, 05, 09)
                                 ^
SyntaxError: invalid token
>>> t = datetime.date(2007, 05, 10)
>>> print t
2007-05-10
>>>

I was able to reproduce this on another machine as well:
Python 2.4.3 (#1, Aug  6 2006, 20:52:01)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.


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

Comment By: Alan McIntyre (alanmcintyre)
Date: 2007-05-08 17:24

Message:
Logged In: YES 
user_id=1115903
Originator: NO

Recommend closing this as not a bug.

A number with a leading zero is interpreted as octal literal, so trying to
interpret 08 gives an error, since anything bigger than 7 isn't allowed in
octal numbers.  For your examples above, you should do this:

t = datetime.date(2007, 5, 8)
t = datetime.date(2007, 5, 9)

and then it works as expected. 



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

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

From noreply at sourceforge.net  Wed May  9 05:46:00 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 08 May 2007 20:46:00 -0700
Subject: [ python-Bugs-1715302 ] datetime.date won't accept 08 or 09 as valid
	days.
Message-ID: <E1Hld7o-0002rk-0n@sc8-sf-web22.sourceforge.net>

Bugs item #1715302, was opened at 2007-05-08 17:49
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1715302&group_id=5470

Please note that this message will contain a full 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: Invalid
Priority: 5
Private: No
Submitted By: Erik Wickstrom (erikcw)
Assigned to: Nobody/Anonymous (nobody)
Summary: datetime.date won't accept 08 or 09 as valid days.

Initial Comment:
The method won't accept 08 or 09 as valid days, but will accept 07.

Here is my output:

Python 2.5.1c1 (release25-maint, Apr 12 2007, 21:00:25)
[GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime
>>> t = datetime.date(2007, 05, 07)
>>> print t
2007-05-07
>>> t = datetime.date(2007, 05, 08)
  File "<stdin>", line 1
    t = datetime.date(2007, 05, 08)
                                 ^
SyntaxError: invalid token
>>> t = datetime.date(2007, 05, 09)
  File "<stdin>", line 1
    t = datetime.date(2007, 05, 09)
                                 ^
SyntaxError: invalid token
>>> t = datetime.date(2007, 05, 10)
>>> print t
2007-05-10
>>>

I was able to reproduce this on another machine as well:
Python 2.4.3 (#1, Aug  6 2006, 20:52:01)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.


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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2007-05-08 23:45

Message:
Logged In: YES 
user_id=3066
Originator: NO

Agreed -- not a bug.

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

Comment By: Alan McIntyre (alanmcintyre)
Date: 2007-05-08 18:24

Message:
Logged In: YES 
user_id=1115903
Originator: NO

Recommend closing this as not a bug.

A number with a leading zero is interpreted as octal literal, so trying to
interpret 08 gives an error, since anything bigger than 7 isn't allowed in
octal numbers.  For your examples above, you should do this:

t = datetime.date(2007, 5, 8)
t = datetime.date(2007, 5, 9)

and then it works as expected. 



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

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

From noreply at sourceforge.net  Wed May  9 10:19:18 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 09 May 2007 01:19:18 -0700
Subject: [ python-Bugs-1293741 ] doctest runner cannot handle non-ascii
	characters 
Message-ID: <E1HlhOI-0001vZ-I4@sc8-sf-web24.sourceforge.net>

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

Please note that this 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
Private: No
Submitted By: GRISEL (ogrisel)
Assigned to: Nobody/Anonymous (nobody)
Summary: doctest runner cannot handle non-ascii characters 

Initial Comment:
The doctest module fails when the expected result
string has non-ascii charcaters even if the # -*-
coding: XXX -*- line is properly set.

The enclosed code sample produce the following error:

Traceback (most recent call last):
  File "test_iso-8859-15.py", line 41, in ?
    _test()
  File "test_iso-8859-15.py", line 26, in _test
    tried, failed = runner.run(t)
  File "/usr/lib/python2.4/doctest.py", line 1376, in run
    return self.__run(test, compileflags, out)
  File "/usr/lib/python2.4/doctest.py", line 1259, in __run
    if check(example.want, got, self.optionflags):
  File "/usr/lib/python2.4/doctest.py", line 1475, in
check_output
    if got == want:
UnicodeDecodeError: 'ascii' codec can't decode byte
0xe9 in position 8: ordinal not in range(128)



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

Comment By: akaihola (akaihola)
Date: 2007-05-09 11:19

Message:
Logged In: YES 
user_id=1432932
Originator: NO

I made some tests with Python 2.5 on an Ubuntu Edgy system with an UTF-8
terminal. Here's the basic test which does work correctly:

# -*- encoding: utf-8 -*-
__doc__ = u"""
>>> print u'?'
?
""" ; import doctest ; doctest.testmod()

If I start to vary the "?" (a with umlaut) characters in "print u'?'"
(the test) and the "?" below it (expected result), I get a
UnicodeEncodeError whenever doctest tries to print a message about
non-matching test output.

Here's a summary of my results in the format of
test | expected result | success/failure
Note that \u00e4 is unicode for the "?" character.

?      | ?      | success
\u00e4 | ?      | success
?      | \u00e4 | success
\u00e4 | \u00e4 | success
?      | x      | fails to display message
x      | ?      | fails to display message
\u00e4 | x      | fails to display message
x      | \u00e4 | fails to display message

Conclusion: test running and output checking do work correctly, but
there's a problem displaying messages about non-matching output whenever
either the expected output or the output produced by the test contain any
extended characters.

The doctest documentation doesn't give any hint on work-arounds.

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

Comment By: Tim Peters (tim_one)
Date: 2006-04-24 04:21

Message:
Logged In: YES 
user_id=31435

Unassigned myself -- don't know enough about encodings.

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

Comment By: Bjorn Tillenius (bjoti)
Date: 2006-02-16 13:41

Message:
Logged In: YES 
user_id=1032069

I'm quite sure that you can use non-ASCII characters in 
your doctest, given that it's a unicode string. So if you 
make your docstring a unicode string, it should work. That 
is:

u"""Docstring containing non-ASCII characters.
...
"""


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

Comment By: GRISEL (ogrisel)
Date: 2005-09-18 13:25

Message:
Logged In: YES 
user_id=795041

Unfortunateny that patch does not fix my problem. The patch
at bug #1080727 fixes the problem for doctests written in
external reST files (testfile and DocFileTest functions). My
problem is related to internal docstring encoding (testmod
for instance). However, Bjorn Tillenius says:
"""
If one writes doctests within documentation strings of
classes and
functions, it's possible to use non-ASCII characters since
one can
specify the encoding used in the source file.
"""
So according to him, docstrings' doctests with non-ascii
characters should work by default. So maybe my system setup
is somewhat broken. Could somebody please confirm/infirm
this by running the attached sample script on his system?

My system config:
LANG=fr_FR at euro (on linux)
python 2.4.1 with:  sys.getdefaultencoding() == 'ascii' 
and locale.getpreferredencoding() == 'ISO-8859-15'
$ file test_iso-8859-15.py
test_iso-8859-15.py: ISO-8859 English text


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

Comment By: Tim Peters (tim_one)
Date: 2005-09-17 20:42

Message:
Logged In: YES 
user_id=31435

Please try the patch at

http://www.python.org/sf/1080727

and report back on whether it solves your problem (attaching 
comments to the patch report would be most useful).

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

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

From noreply at sourceforge.net  Wed May  9 11:53:29 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 09 May 2007 02:53:29 -0700
Subject: [ python-Bugs-1715581 ] Const(None) in compiler.ast.Return.value
Message-ID: <E1HlirR-0006Sh-R0@sc8-sf-web23.sourceforge.net>

Bugs item #1715581, was opened at 2007-05-09 13: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=1715581&group_id=5470

Please note that this message will contain a full 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
Private: No
Submitted By: Ali Gholami Rudi (aligrudi)
Assigned to: Nobody/Anonymous (nobody)
Summary: Const(None) in compiler.ast.Return.value

Initial Comment:
The problem happens when::

  import compiler

  class Visitor(object):
      def visitReturn(self, node):
          print node.value

  source = """
  def f():
      return
  """
  compiler.walk(compiler.parse(source), Visitor())

I think the value of `node.value` should have been `None` instead of
`Const(None)` as it is for most other nodes when an optional part is
missing.  The same problem (getting `Const(None)` instead of `None`)
exists for `Sliceobj.nodes[i]` and `Discard.expr`.


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

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

From noreply at sourceforge.net  Wed May  9 23:40:46 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 09 May 2007 14:40:46 -0700
Subject: [ python-Bugs-1710703 ] zipfile.ZipFile behavior inconsistent.
Message-ID: <E1Hlttu-0005CF-SF@sc8-sf-web24.sourceforge.net>

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

Please note that this message will contain a full 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
Private: No
Submitted By: Mark Flacy (markaflacy)
Assigned to: Nobody/Anonymous (nobody)
Summary: zipfile.ZipFile behavior inconsistent.

Initial Comment:
In short, ZipFile() will not write the Central Directory entry unless you have added a file to it.  That makes it impossible to create a valid empty zip archive.

In one of my applications, I have the need to extract a partial set of information from one zip file and insert it into another.  There are valid use cases where the source zip archive will not have any of the files which I am looking for.  In Python 2.4, I would end up with an empty file which was considered to be a valid empty zip archive.  In Python 2.5, an empty file is not considered a valid zip archive.  

One would reasonably expect that creating a new ZipFile(mode="r") and successfully closing it without writing any entries would result in a valid zip archive that could be re-opened later without throwing an exception.



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

Comment By: Alan McIntyre (alanmcintyre)
Date: 2007-05-09 16:40

Message:
Logged In: YES 
user_id=1115903
Originator: NO

I tried out a change to set the modified flag (_didModify) if the ZipFile
constructor ends up having mode  'w' or decides that it's appending to a
file with no existing zip structure at the end.  I'm waiting on the full
regression test suite to run against it, but it passes everything in
test_zipfile.py (and I added new tests to check for the behavior with empty
files).  I can post the patch if Mark hasn't had a chance to work one up
yet.

The docs don't seem to say anything about what happens if you open a
ZipFile in 'w' or 'a' and then just close it.  I wouldn't mind updating the
docs to cover this if desired.

As a side note, when attempting to open an empty file in 'r' mode, a
mostly unhelpful IOError (with message "invalid parameter") gets raised in
_EndRecData when attempting to seek backwards.  It seems that it would be
preferable to catch any exceptions raised by _EndRecData and raise a
BadZipFile so that it's not as cryptic.

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

Comment By: Mark Flacy (markaflacy)
Date: 2007-05-04 02:26

Message:
Logged In: YES 
user_id=1344993
Originator: YES

No wonder you're confused.  My description of how 2.4 worked was flat-out
wrong; empty files opened as zip files will throw IOExceptions and have
done so since 2.4 at least (I didn't look further back than that). 
However, it *is* the case that 2.4 would correctly write the Central
Directory entry on zipfile close for "w" and "a" modes, even for zip files
that never had any entries written into them.

In 2.4, the ZipFile.close() method contains the line...

        if self.mode in ("w", "a"):             # write ending records

...while in 2.5, the test was changed to...

        if self.mode in ("w", "a") and self._didModify: # write ending
records

That change was added in revision 46967 as part of the ZIP64 support and
that change breaks backwards compatibility (as well as not making a lot of
sense for the "w" case).

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-02 01:06

Message:
Logged In: YES 
user_id=33168
Originator: NO

Mark, can you create a patch for zipfile to make it do what you want?  Do
the docs mention anything about this either way?  Perhaps the docs also
need updating?

I don't know about what happened here, but I'm guessing there was some bug
fix.  This change could have been intentional or not.  I patch will help us
figure out what went wrong and how to proceed.  

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

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

From noreply at sourceforge.net  Thu May 10 22:11:53 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 10 May 2007 13:11:53 -0700
Subject: [ python-Bugs-1713252 ] character set in Japanese on Ubuntu
	distribution
Message-ID: <E1HmEzR-0006VB-5r@sc8-sf-web23.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.5
Status: Open
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Christopher Grell (cgrell)
Assigned to: Nobody/Anonymous (nobody)
Summary: character set in Japanese on Ubuntu distribution

Initial Comment:
I tried to use IDLE on new Ubuntu 7.04 and the window opens with Japanese character set

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

>Comment By: Christopher Grell (cgrell)
Date: 2007-05-10 13:11

Message:
Logged In: YES 
user_id=1785859
Originator: YES

File Added: Screenshot-Python Shell.png

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

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-08 12:05

Message:
Logged In: YES 
user_id=21627
Originator: NO

What do you mean by "opens with Japanese character set"? Can you provide a
screenshot?

Can you figure out what font it is using?

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

Comment By: Christopher Grell (cgrell)
Date: 2007-05-06 19:42

Message:
Logged In: YES 
user_id=1785859
Originator: YES

Changing default character size to 20 removes the issue

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

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

Message:
Logged In: YES 
user_id=849994
Originator: NO

As this is certainly not the case in other distributions, this is
something you should file with the Ubuntu bug tracker.

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

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

From noreply at sourceforge.net  Fri May 11 00:35:55 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 10 May 2007 15:35:55 -0700
Subject: [ python-Bugs-1713252 ] character set in Japanese on Ubuntu
	distribution
Message-ID: <E1HmHEp-0007HC-TV@sc8-sf-web24.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.5
Status: Open
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Christopher Grell (cgrell)
Assigned to: Nobody/Anonymous (nobody)
Summary: character set in Japanese on Ubuntu distribution

Initial Comment:
I tried to use IDLE on new Ubuntu 7.04 and the window opens with Japanese character set

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

>Comment By: Martin v. L?wis (loewis)
Date: 2007-05-11 00:35

Message:
Logged In: YES 
user_id=21627
Originator: NO

Why do you think it is Japanese? It is fairly unreadable, but it looks
like Latin to me. In particular, I can recognize the text "Personal
firewall software may warn..."

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

Comment By: Christopher Grell (cgrell)
Date: 2007-05-10 22:11

Message:
Logged In: YES 
user_id=1785859
Originator: YES

File Added: Screenshot-Python Shell.png

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

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-08 21:05

Message:
Logged In: YES 
user_id=21627
Originator: NO

What do you mean by "opens with Japanese character set"? Can you provide a
screenshot?

Can you figure out what font it is using?

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

Comment By: Christopher Grell (cgrell)
Date: 2007-05-07 04:42

Message:
Logged In: YES 
user_id=1785859
Originator: YES

Changing default character size to 20 removes the issue

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

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-05 09:08

Message:
Logged In: YES 
user_id=849994
Originator: NO

As this is certainly not the case in other distributions, this is
something you should file with the Ubuntu bug tracker.

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

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

From noreply at sourceforge.net  Fri May 11 13:06:57 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 11 May 2007 04:06:57 -0700
Subject: [ python-Bugs-1714381 ] Universal line ending mode duplicates all
	line endings
Message-ID: <E1HmSxd-0001M5-TL@sc8-sf-web21.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Geoffrey Bache (gjb1002)
Assigned to: Nobody/Anonymous (nobody)
Summary: Universal line ending mode duplicates all line endings

Initial Comment:
On Windows XP, reading a file produced by Windows XP with universal line endings produces twice as many lines!

Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> open("winlineend").read()
'Hello\r\n'
>>> open("winlineend", "rU").read()
'Hello\n\n'


I would expect the last to give "Hello\n". 

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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-11 11:06

Message:
Logged In: YES 
user_id=849994
Originator: NO

To the OP: what does "open("winlineend", "rb").read()" return?

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

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-08 01:48

Message:
Logged In: YES 
user_id=479790
Originator: NO

Yes, it's not so obvious, and the same question was posted a few days ago
on comp.lang.python.
I'll review the documentation and make it more clearly stated.


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

Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-07 21:36

Message:
Logged In: YES 
user_id=769182
Originator: YES

I see. This seems like something of a gotcha to me: is it documented
anywhere? Seems to make os.linesep not very useful in fact, especially if
"\n" will work fine everywhere and is shorter. 

It isn't at all obvious that file.write(os.linesep) will in fact write two
lines...


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

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-07 21:15

Message:
Logged In: YES 
user_id=479790
Originator: NO

> file.write("Hello" + os.linesep)

The line separator for a file opened in *text*mode* is *always* \n in
Python code. It gets converted to os.linesep when you write the file; and
conversely, os.linesep get translated into a single \n when you read the
file.
On Windows, os.linesep is "\r\n". The argument to file.write above is 
"Hello\r\n". That "\n" gets translated into "\r\n" when it is written, so
the actual file contents will be "Hello\r\n\n"

In short: if you open a file in text mode (the default) *don't* use
os.linesep to terminate lines. Only use os.linesep when writing text files
open in binary mode (and that's not a common case).


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

Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-07 20:27

Message:
Logged In: YES 
user_id=769182
Originator: YES

I create the file as follows: 

>>> import os
>>> file = open("test.txt", "w")
>>> file.write("Hello" + os.linesep)
>>> file.close()
>>> open("test.txt").read()
'Hello\r\n'
>>> open("test.txt", "rU").read()
'Hello\n\n'


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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-07 17:39

Message:
Logged In: YES 
user_id=984087
Originator: NO


I created a file "test.txt" with notepad whose contents are "hello\r\n".
Both open().read() and open("rU").read() returned 'hello\n'. I tested with
both 2.5 and 2.5.1 (installed using installers from python.org) and the
result is same on both. Can you elaborate your test case more? How is this
file "winlineend" created?

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

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

From noreply at sourceforge.net  Fri May 11 13:08:28 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 11 May 2007 04:08:28 -0700
Subject: [ python-Bugs-1697916 ] Segfaults on memory error
Message-ID: <E1HmSz6-0001Zr-F5@sc8-sf-web21.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 6
Private: No
Submitted By: STINNER Victor (haypo)
Assigned to: Georg Brandl (gbrandl)
Summary: Segfaults on memory error

Initial Comment:
Hi, I'm playing with resource.setrlimit(resource.RLIMIT_AS) to limit memory usage during fuzzing tests. It works quite well but Python crashs sometimes (with SEGFAULT).

I downloaded Python source code and recompiled it with EXTRA_FLAGS="-g -O0" to find errors. I found three bugs and wrote a patch for all of them.

Comments:
* Objects/exceptions.c:33: allocation may returns NULL on memory error
* Objects/longobject.c:2511: long_divrem() may allocate new long integers but l_divmod() doesn't check that div and mod are not NULL
* Objects/object.c:1284: problem with NULL mro. I don't understand how mro works, but I think that the error may be catched when mro is assigned. Problem: where is it done? in Objects/typeobject.c?

So don't apply my patch directly: fix for object.c may be wrong.

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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-11 11:08

Message:
Logged In: YES 
user_id=849994
Originator: NO

Backported in rev 54902.

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

Comment By: Georg Brandl (gbrandl)
Date: 2007-04-11 20:11

Message:
Logged In: YES 
user_id=849994
Originator: NO

Reopening until I can backport this to the 2.5 branch.

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

Comment By: STINNER Victor (haypo)
Date: 2007-04-11 16:53

Message:
Logged In: YES 
user_id=365388
Originator: YES

Ignore my bug about NULL mro since i'm not able to reproduce it. Thanks
for the 3 other fixes ;-)

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

Comment By: Georg Brandl (gbrandl)
Date: 2007-04-11 16:11

Message:
Logged In: YES 
user_id=849994
Originator: NO

Status update: Fixed the first two bugs locally, and a third one
discovered by Victor on #python-dev.

The mro one is unclear -- we've asked him to reproduce it and poke around
in gdb to see why tp_mro is NULL, which it shouldn't be.

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

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

From noreply at sourceforge.net  Fri May 11 13:09:48 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 11 May 2007 04:09:48 -0700
Subject: [ python-Bugs-1697782 ] types.InstanceType is missing but used by
	pydoc
Message-ID: <E1HmT0O-0001hH-Hw@sc8-sf-web21.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 3000
>Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Christian Heimes (tiran)
Assigned to: Georg Brandl (gbrandl)
Summary: types.InstanceType is missing but used by pydoc

Initial Comment:
>>> help(callable.__call__)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/heimes/dev/python/p3yk/Lib/site.py", line 348, in __call__
    return pydoc.help(*args, **kwds)
  File "/home/heimes/dev/python/p3yk/Lib/pydoc.py", line 1658, in __call__
    self.help(request)
  File "/home/heimes/dev/python/p3yk/Lib/pydoc.py", line 1702, in help
    else: doc(request, 'Help on %s:')
  File "/home/heimes/dev/python/p3yk/Lib/pydoc.py", line 1477, in doc
    desc = describe(object)
  File "/home/heimes/dev/python/p3yk/Lib/pydoc.py", line 1436, in describe
    if type(thing) is types.InstanceType:
AttributeError: 'module' object has no attribute 'InstanceType'


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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-11 11:09

Message:
Logged In: YES 
user_id=849994
Originator: NO

Backported in rev 54905.

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

Comment By: Georg Brandl (gbrandl)
Date: 2007-04-11 20:11

Message:
Logged In: YES 
user_id=849994
Originator: NO

Reopening until I can backport this to the 2.5 branch.

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

Comment By: Georg Brandl (gbrandl)
Date: 2007-04-11 19:25

Message:
Logged In: YES 
user_id=849994
Originator: NO

Fixed all instances of types.InstanceType in rev. 54761.

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

Comment By: Christian Heimes (tiran)
Date: 2007-04-11 13:52

Message:
Logged In: YES 
user_id=560817
Originator: YES

types.InstanceType is still used by several stdlib modules.

FIX: svn cp the types.py module from Python 2.6 to the p3yk branh

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

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

From noreply at sourceforge.net  Fri May 11 13:17:14 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 11 May 2007 04:17:14 -0700
Subject: [ python-Bugs-1707255 ] lost global variables in main memory
	intensive execution
Message-ID: <E1HmT7a-0002Zg-51@sc8-sf-web21.sourceforge.net>

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

Please note that this 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: Pending
Resolution: None
Priority: 5
Private: No
Submitted By: Jordi Pujol Ahull? (jpahullo)
Assigned to: Nobody/Anonymous (nobody)
Summary: lost global variables in main memory intensive execution

Initial Comment:
Hello,

I was running a very main memory intensive program in my computer. I looked for similar bugs or troubles in the site and I didn't found any similar to this. I know that the use of global variables is not recommended by software engineering, but for special cases it is very fast to develop/test some ideas.

My problem statement is the following (very simplified and also attached):

########## BEGINNING OF CODE
#test for globals

counter_1 = 0

def modifierfunction():
    global counter_1

    #some code
    counter_1 += 1
    #some other code

def test():
    for i in range(2):
        global counter_1
        counter_1 = 0

        for j in range(10):
            modifierfunction()

        print "COUNTER_1:", counter_1

def test2():
    global counter_1
    for i in range(2):
        counter_1 = 0

        for j in range(10):
            modifierfunction()

        print "COUNTER_1:", counter_1

if __name__ == "__main__":
    test()
    test2()
########## END OF CODE

Globally speaking, it is a global variable, defined at the begining of the python file (counter_1), and it is modified in some functions within it (in this example, modifierfunction). At the end, it appear some tests that make what I need. 

If you try to run this code, it will always show the expected values in the standard out. But, let me to show you my problem.

In the beginning, I have the global statement as in test2. But I found that it only take a corrent value for the first iteration. The others it has always a zero value. I didn't understand anything.

Then, some collegue suggested me to change the place of the global statement (as in test()), and then it worked correctly, as it was expected.

I repeat. The above example works fine. But when this same structure, but with my big problem, very main memory intensive, test2() didn't work correctly.

Thank you for your attention.

Regards,

Jordi

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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-11 11:17

Message:
Logged In: YES 
user_id=849994
Originator: NO

The resulting bytecode the functions are compiled to is exactly the same,
no matter where the global statement is.

So I cannot believe that moving the global statement alone causes
something that failed to work.

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

Comment By: Calvin Spealman (ironfroggy)
Date: 2007-04-28 14:59

Message:
Logged In: YES 
user_id=112166
Originator: NO

If you really think there is a bug, don't post working code, post code
that actually demonstrates the problem. Something anyone else could use to
reproduce the bug.

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

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

From noreply at sourceforge.net  Fri May 11 20:34:39 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 11 May 2007 11:34:39 -0700
Subject: [ python-Bugs-1714381 ] Universal line ending mode duplicates all
	line endings
Message-ID: <E1HmZwt-00048h-FK@sc8-sf-web23.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Geoffrey Bache (gjb1002)
Assigned to: Nobody/Anonymous (nobody)
Summary: Universal line ending mode duplicates all line endings

Initial Comment:
On Windows XP, reading a file produced by Windows XP with universal line endings produces twice as many lines!

Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> open("winlineend").read()
'Hello\r\n'
>>> open("winlineend", "rU").read()
'Hello\n\n'


I would expect the last to give "Hello\n". 

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

>Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-11 20:34

Message:
Logged In: YES 
user_id=769182
Originator: YES

It returns "Hello\r\r\n" (not "Hello\r\n\n" as was suggested earlier)
Don't know quite how it does this from simply writing os.linesep.


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

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-11 13:06

Message:
Logged In: YES 
user_id=849994
Originator: NO

To the OP: what does "open("winlineend", "rb").read()" return?

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

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-08 03:48

Message:
Logged In: YES 
user_id=479790
Originator: NO

Yes, it's not so obvious, and the same question was posted a few days ago
on comp.lang.python.
I'll review the documentation and make it more clearly stated.


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

Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-07 23:36

Message:
Logged In: YES 
user_id=769182
Originator: YES

I see. This seems like something of a gotcha to me: is it documented
anywhere? Seems to make os.linesep not very useful in fact, especially if
"\n" will work fine everywhere and is shorter. 

It isn't at all obvious that file.write(os.linesep) will in fact write two
lines...


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

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-07 23:15

Message:
Logged In: YES 
user_id=479790
Originator: NO

> file.write("Hello" + os.linesep)

The line separator for a file opened in *text*mode* is *always* \n in
Python code. It gets converted to os.linesep when you write the file; and
conversely, os.linesep get translated into a single \n when you read the
file.
On Windows, os.linesep is "\r\n". The argument to file.write above is 
"Hello\r\n". That "\n" gets translated into "\r\n" when it is written, so
the actual file contents will be "Hello\r\n\n"

In short: if you open a file in text mode (the default) *don't* use
os.linesep to terminate lines. Only use os.linesep when writing text files
open in binary mode (and that's not a common case).


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

Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-07 22:27

Message:
Logged In: YES 
user_id=769182
Originator: YES

I create the file as follows: 

>>> import os
>>> file = open("test.txt", "w")
>>> file.write("Hello" + os.linesep)
>>> file.close()
>>> open("test.txt").read()
'Hello\r\n'
>>> open("test.txt", "rU").read()
'Hello\n\n'


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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-07 19:39

Message:
Logged In: YES 
user_id=984087
Originator: NO


I created a file "test.txt" with notepad whose contents are "hello\r\n".
Both open().read() and open("rU").read() returned 'hello\n'. I tested with
both 2.5 and 2.5.1 (installed using installers from python.org) and the
result is same on both. Can you elaborate your test case more? How is this
file "winlineend" created?

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

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

From noreply at sourceforge.net  Fri May 11 20:41:19 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 11 May 2007 11:41:19 -0700
Subject: [ python-Bugs-1714381 ] Universal line ending mode duplicates all
	line endings
Message-ID: <E1Hma3L-00080z-LE@sc8-sf-web24.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.5
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: Geoffrey Bache (gjb1002)
Assigned to: Nobody/Anonymous (nobody)
Summary: Universal line ending mode duplicates all line endings

Initial Comment:
On Windows XP, reading a file produced by Windows XP with universal line endings produces twice as many lines!

Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> open("winlineend").read()
'Hello\r\n'
>>> open("winlineend", "rU").read()
'Hello\n\n'


I would expect the last to give "Hello\n". 

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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-11 18:41

Message:
Logged In: YES 
user_id=849994
Originator: NO

Okay, that settles it.

When you write "\r\n" to a Windows text file, it writes "\r\r\n"
(since "\n" is converted to "\r\n"). When universal newline mode
sees that, it thinks of it as Mac-lineend followed by a Windows-
lineend.

The doc fix has been committed, closing this one as "won't fix".

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

Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-11 18:34

Message:
Logged In: YES 
user_id=769182
Originator: YES

It returns "Hello\r\r\n" (not "Hello\r\n\n" as was suggested earlier)
Don't know quite how it does this from simply writing os.linesep.


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

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-11 11:06

Message:
Logged In: YES 
user_id=849994
Originator: NO

To the OP: what does "open("winlineend", "rb").read()" return?

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

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-08 01:48

Message:
Logged In: YES 
user_id=479790
Originator: NO

Yes, it's not so obvious, and the same question was posted a few days ago
on comp.lang.python.
I'll review the documentation and make it more clearly stated.


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

Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-07 21:36

Message:
Logged In: YES 
user_id=769182
Originator: YES

I see. This seems like something of a gotcha to me: is it documented
anywhere? Seems to make os.linesep not very useful in fact, especially if
"\n" will work fine everywhere and is shorter. 

It isn't at all obvious that file.write(os.linesep) will in fact write two
lines...


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

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-07 21:15

Message:
Logged In: YES 
user_id=479790
Originator: NO

> file.write("Hello" + os.linesep)

The line separator for a file opened in *text*mode* is *always* \n in
Python code. It gets converted to os.linesep when you write the file; and
conversely, os.linesep get translated into a single \n when you read the
file.
On Windows, os.linesep is "\r\n". The argument to file.write above is 
"Hello\r\n". That "\n" gets translated into "\r\n" when it is written, so
the actual file contents will be "Hello\r\n\n"

In short: if you open a file in text mode (the default) *don't* use
os.linesep to terminate lines. Only use os.linesep when writing text files
open in binary mode (and that's not a common case).


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

Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-07 20:27

Message:
Logged In: YES 
user_id=769182
Originator: YES

I create the file as follows: 

>>> import os
>>> file = open("test.txt", "w")
>>> file.write("Hello" + os.linesep)
>>> file.close()
>>> open("test.txt").read()
'Hello\r\n'
>>> open("test.txt", "rU").read()
'Hello\n\n'


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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-07 17:39

Message:
Logged In: YES 
user_id=984087
Originator: NO


I created a file "test.txt" with notepad whose contents are "hello\r\n".
Both open().read() and open("rU").read() returned 'hello\n'. I tested with
both 2.5 and 2.5.1 (installed using installers from python.org) and the
result is same on both. Can you elaborate your test case more? How is this
file "winlineend" created?

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

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

From noreply at sourceforge.net  Fri May 11 20:50:56 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 11 May 2007 11:50:56 -0700
Subject: [ python-Bugs-1714381 ] Universal line ending mode duplicates all
	line endings
Message-ID: <E1HmaCe-0000Yd-Dt@sc8-sf-web24.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.5
Status: Closed
Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: Geoffrey Bache (gjb1002)
Assigned to: Nobody/Anonymous (nobody)
Summary: Universal line ending mode duplicates all line endings

Initial Comment:
On Windows XP, reading a file produced by Windows XP with universal line endings produces twice as many lines!

Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> open("winlineend").read()
'Hello\r\n'
>>> open("winlineend", "rU").read()
'Hello\n\n'


I would expect the last to give "Hello\n". 

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

>Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-11 20:50

Message:
Logged In: YES 
user_id=769182
Originator: YES

Which doc has been changed? Can I review it somewhere? 

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

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-11 20:41

Message:
Logged In: YES 
user_id=849994
Originator: NO

Okay, that settles it.

When you write "\r\n" to a Windows text file, it writes "\r\r\n"
(since "\n" is converted to "\r\n"). When universal newline mode
sees that, it thinks of it as Mac-lineend followed by a Windows-
lineend.

The doc fix has been committed, closing this one as "won't fix".

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

Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-11 20:34

Message:
Logged In: YES 
user_id=769182
Originator: YES

It returns "Hello\r\r\n" (not "Hello\r\n\n" as was suggested earlier)
Don't know quite how it does this from simply writing os.linesep.


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

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-11 13:06

Message:
Logged In: YES 
user_id=849994
Originator: NO

To the OP: what does "open("winlineend", "rb").read()" return?

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

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-08 03:48

Message:
Logged In: YES 
user_id=479790
Originator: NO

Yes, it's not so obvious, and the same question was posted a few days ago
on comp.lang.python.
I'll review the documentation and make it more clearly stated.


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

Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-07 23:36

Message:
Logged In: YES 
user_id=769182
Originator: YES

I see. This seems like something of a gotcha to me: is it documented
anywhere? Seems to make os.linesep not very useful in fact, especially if
"\n" will work fine everywhere and is shorter. 

It isn't at all obvious that file.write(os.linesep) will in fact write two
lines...


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

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-07 23:15

Message:
Logged In: YES 
user_id=479790
Originator: NO

> file.write("Hello" + os.linesep)

The line separator for a file opened in *text*mode* is *always* \n in
Python code. It gets converted to os.linesep when you write the file; and
conversely, os.linesep get translated into a single \n when you read the
file.
On Windows, os.linesep is "\r\n". The argument to file.write above is 
"Hello\r\n". That "\n" gets translated into "\r\n" when it is written, so
the actual file contents will be "Hello\r\n\n"

In short: if you open a file in text mode (the default) *don't* use
os.linesep to terminate lines. Only use os.linesep when writing text files
open in binary mode (and that's not a common case).


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

Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-07 22:27

Message:
Logged In: YES 
user_id=769182
Originator: YES

I create the file as follows: 

>>> import os
>>> file = open("test.txt", "w")
>>> file.write("Hello" + os.linesep)
>>> file.close()
>>> open("test.txt").read()
'Hello\r\n'
>>> open("test.txt", "rU").read()
'Hello\n\n'


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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-07 19:39

Message:
Logged In: YES 
user_id=984087
Originator: NO


I created a file "test.txt" with notepad whose contents are "hello\r\n".
Both open().read() and open("rU").read() returned 'hello\n'. I tested with
both 2.5 and 2.5.1 (installed using installers from python.org) and the
result is same on both. Can you elaborate your test case more? How is this
file "winlineend" created?

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

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

From noreply at sourceforge.net  Fri May 11 21:38:22 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 11 May 2007 12:38:22 -0700
Subject: [ python-Bugs-1714381 ] Universal line ending mode duplicates all
	line endings
Message-ID: <E1HmawY-0004KF-5B@sc8-sf-web21.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.5
Status: Closed
Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: Geoffrey Bache (gjb1002)
Assigned to: Nobody/Anonymous (nobody)
Summary: Universal line ending mode duplicates all line endings

Initial Comment:
On Windows XP, reading a file produced by Windows XP with universal line endings produces twice as many lines!

Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> open("winlineend").read()
'Hello\r\n'
>>> open("winlineend", "rU").read()
'Hello\n\n'


I would expect the last to give "Hello\n". 

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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-11 19:38

Message:
Logged In: YES 
user_id=849994
Originator: NO

The doc for os.linesep. The change is in Subversion, and will be at
docs.python.org/dev when the build script runs the next time.

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

Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-11 18:50

Message:
Logged In: YES 
user_id=769182
Originator: YES

Which doc has been changed? Can I review it somewhere? 

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

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-11 18:41

Message:
Logged In: YES 
user_id=849994
Originator: NO

Okay, that settles it.

When you write "\r\n" to a Windows text file, it writes "\r\r\n"
(since "\n" is converted to "\r\n"). When universal newline mode
sees that, it thinks of it as Mac-lineend followed by a Windows-
lineend.

The doc fix has been committed, closing this one as "won't fix".

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

Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-11 18:34

Message:
Logged In: YES 
user_id=769182
Originator: YES

It returns "Hello\r\r\n" (not "Hello\r\n\n" as was suggested earlier)
Don't know quite how it does this from simply writing os.linesep.


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

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-11 11:06

Message:
Logged In: YES 
user_id=849994
Originator: NO

To the OP: what does "open("winlineend", "rb").read()" return?

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

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-08 01:48

Message:
Logged In: YES 
user_id=479790
Originator: NO

Yes, it's not so obvious, and the same question was posted a few days ago
on comp.lang.python.
I'll review the documentation and make it more clearly stated.


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

Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-07 21:36

Message:
Logged In: YES 
user_id=769182
Originator: YES

I see. This seems like something of a gotcha to me: is it documented
anywhere? Seems to make os.linesep not very useful in fact, especially if
"\n" will work fine everywhere and is shorter. 

It isn't at all obvious that file.write(os.linesep) will in fact write two
lines...


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

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-07 21:15

Message:
Logged In: YES 
user_id=479790
Originator: NO

> file.write("Hello" + os.linesep)

The line separator for a file opened in *text*mode* is *always* \n in
Python code. It gets converted to os.linesep when you write the file; and
conversely, os.linesep get translated into a single \n when you read the
file.
On Windows, os.linesep is "\r\n". The argument to file.write above is 
"Hello\r\n". That "\n" gets translated into "\r\n" when it is written, so
the actual file contents will be "Hello\r\n\n"

In short: if you open a file in text mode (the default) *don't* use
os.linesep to terminate lines. Only use os.linesep when writing text files
open in binary mode (and that's not a common case).


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

Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-07 20:27

Message:
Logged In: YES 
user_id=769182
Originator: YES

I create the file as follows: 

>>> import os
>>> file = open("test.txt", "w")
>>> file.write("Hello" + os.linesep)
>>> file.close()
>>> open("test.txt").read()
'Hello\r\n'
>>> open("test.txt", "rU").read()
'Hello\n\n'


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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-07 17:39

Message:
Logged In: YES 
user_id=984087
Originator: NO


I created a file "test.txt" with notepad whose contents are "hello\r\n".
Both open().read() and open("rU").read() returned 'hello\n'. I tested with
both 2.5 and 2.5.1 (installed using installers from python.org) and the
result is same on both. Can you elaborate your test case more? How is this
file "winlineend" created?

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

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

From noreply at sourceforge.net  Sat May 12 18:17:10 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 12 May 2007 09:17:10 -0700
Subject: [ python-Bugs-1633621 ] curses should reset curses.{COLS,
	LINES} when term. resized
Message-ID: <E1HmuHO-0001HV-Db@sc8-sf-web24.sourceforge.net>

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

Please note that this message will contain a full 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: 3
Private: No
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: curses should reset curses.{COLS,LINES} when term. resized

Initial Comment:
[forwarded from http://bugs.debian.org/366698]

The curses module does not reset curses.COLS and curses.LINES when the terminal is resized.


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

Comment By: blubb (machamalahalaba)
Date: 2007-05-12 18:17

Message:
Logged In: YES 
user_id=1791654
Originator: NO

I'm still able to reproduce this bug with Python 2.5.1. The following
script always gives the same size:

import curses

while True:
	scr = curses.initscr()
	print curses.LINES, curses.COLS
	scr.getch()
	scr.getch()
	curses.endwin()


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

Comment By: Walter D?rwald (doerwalter)
Date: 2007-03-06 21:47

Message:
Logged In: YES 
user_id=89016
Originator: NO

Checked in as revision 54180 and 54181 (2.5)

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

Comment By: Scott Dial (geekmug)
Date: 2007-03-05 23:14

Message:
Logged In: YES 
user_id=383208
Originator: NO

I've reviewed this patch and I believe it to be the correct patch. I
believe it would be prudent to add a test case for this. I'm unable to
attach, but here is a link to a patch for that:
http://scottdial.com/python-dev/curses-test.patch

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

Comment By: Walter D?rwald (doerwalter)
Date: 2007-02-12 19:59

Message:
Logged In: YES 
user_id=89016
Originator: NO

Here's a patch that implements the requested changes.
File Added: diff.txt

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

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

From noreply at sourceforge.net  Sat May 12 22:41:54 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 12 May 2007 13:41:54 -0700
Subject: [ python-Bugs-1717900 ] Destructor behavior faulty
Message-ID: <E1HmyPa-0002jB-AC@sc8-sf-web23.sourceforge.net>

Bugs item #1717900, was opened at 2007-05-12 22: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=1717900&group_id=5470

Please note that this message 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
Private: No
Submitted By: Wolf Rogner (wrogner)
Assigned to: Nobody/Anonymous (nobody)
Summary: Destructor behavior faulty

Initial Comment:
I tried example 11.4. from bytesofpython (by C.H. Swaroop).
Example works fine.

Added a new Person instance 'wolf' -> Program terminated with:
Exception exceptions.AttributeError: "'NoneType' object has no attribute 'population'" in <bound method Person.__del__ of <__main__.Person instance at 0xb7d48d6c>> ignored

added print list(globals()) ->
['kalam', '__builtins__', '__file__', 'DBGPHideChildren', 'swaroop', 'Person', 'wolf', '__name__', '__doc__']

changed wolf to aaa:

print list(globals()) ->
['aaa', 'kalam', '__builtins__', '__file__', 'DBGPHideChildren', 'swaroop', 'Person', '__name__', '__doc__']

Please note the position of 'aaa' at the beginning of the list, before 'Person'. With 'wolf' being after 'Person'.

If the destructing code removes items in this order, no wonder I get an error.

Person should not get deleted if refcount is still > 0.

Wolf Rogner


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

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

From noreply at sourceforge.net  Sat May 12 23:07:16 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 12 May 2007 14:07:16 -0700
Subject: [ python-Bugs-1046945 ] improving distutils swig support -
	documentation
Message-ID: <E1Hmyo8-00009f-UD@sc8-sf-web22.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils
Group: Python 2.4
>Status: Closed
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Lars Immisch (larsimmisch)
Assigned to: Nobody/Anonymous (nobody)
Summary: improving distutils swig support - documentation

Initial Comment:
This patch updates the documentation of distutils to
describe the new swig_opts Extension keyword argument
and the new --swig-opts commandline option.

The --swig and --swig-cpp commandline options are not
mentioned.

This patch belongs to patch 1046644 or:

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

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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-12 21:07

Message:
Logged In: YES 
user_id=849994
Originator: NO

Committed as rev. 55287, 55288 (2.5).

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

Comment By: Morten Lied Johansen (epcylon)
Date: 2007-04-24 08:26

Message:
Logged In: YES 
user_id=574105
Originator: NO

Err... did this patch ever get in? (I've been looking in the docs for this
information, but couldn't find it anywhere)

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

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

Message:
Logged In: YES 
user_id=3066

This looks fine to go in after the 2.4b1 release; it's too late to 
change the docs for that one (the tarball has already been built). 

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

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

From noreply at sourceforge.net  Sat May 12 23:17:22 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 12 May 2007 14:17:22 -0700
Subject: [ python-Bugs-1583862 ] yield+break stops tracing
Message-ID: <E1Hmyxu-0001Ek-Hl@sc8-sf-web22.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
>Status: Pending
Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: Lukas Lalinsky (luks)
Assigned to: Nobody/Anonymous (nobody)
Summary: yield+break stops tracing

Initial Comment:
Here is an example script:

def myiter():
    for i in range(10):
        yield i
for i in myiter():
    break
print "foo"

Now, if I try to trace it:

$ python -m trace --trace --count test.py
 --- modulename: threading, funcname: settrace
threading.py(70):     _trace_hook = func
 --- modulename: test, funcname: <module>
test.py(1): def myiter():
test.py(5): for i in myiter():
 --- modulename: test, funcname: myiter
test.py(2):     for i in range(10):
test.py(3):         yield i
test.py(6):     break
c:\python25\lib\ntpath.py:190: RuntimeWarning:
tp_compare didn't return -1 or -2 for exception
  if i<=max(p.rfind('/'), p.rfind('\\')):
foo

It stops tracing after the `break` statement. The line
after, `print "foo"`, is not traced nor included in the
coverage output.

I'm not sure RuntimeWarning from ntpath.py is relevant
here, because if I use the trace module in some other
situation it doesn't print it. IMO, it's just a side
effect of some different problem.


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

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-04-11 16:52

Message:
Logged In: YES 
user_id=80475
Originator: NO

Using Py2.5.1, the problem seems to have gone away.
Lukas, can you please verify that it is solved and then close.


=======================================================================
rhettinger at localhost ~ $ py25/python -m trace --trace --count test.py
 --- modulename: threading, funcname: settrace
threading.py(70):     _trace_hook = func
 --- modulename: trace, funcname: <module>
<string>(1):   --- modulename: trace, funcname: <module>
test.py(1): def myiter():
test.py(6): for i in myiter():
 --- modulename: trace, funcname: myiter
test.py(2):     for i in range(10):
test.py(3):         yield i
test.py(7):     break
 --- modulename: trace, funcname: myiter
test.py(9): print 'foo'
foo


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

Comment By: Lukas Lalinsky (luks)
Date: 2006-10-24 16:05

Message:
Logged In: YES 
user_id=587716

Oh, I forgot. This bug is specific to Python 2.5. It works
fine in 2.4.

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

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

From noreply at sourceforge.net  Sat May 12 23:21:10 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 12 May 2007 14:21:10 -0700
Subject: [ python-Bugs-1700132 ] import and capital letters
Message-ID: <E1Hmz1a-0001fQ-7x@sc8-sf-web22.sourceforge.net>

Bugs item #1700132, was opened at 2007-04-13 15:06
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1700132&group_id=5470

Please note that this message 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: 5
Private: No
Submitted By: omsynge (omsynge)
Assigned to: Nobody/Anonymous (nobody)
Summary: import and capital letters

Initial Comment:
Interactive and relative paths allow unlimited
(Or at least I have not found a limit yet) number of characters to be uppercase. This is fine, but when the python interpreter reads directories from PYTHONPATH with 3 capital letters you then get a failure to locate the files.

I have replicated this issue with python 2.2 and python 2.4. These where with red hat el3 and ubuntu (Some version not sure which)

and an example

import dcacheYaimInstallerTest.logger as logger

works fine in interactive or relative paths, but not when installed via an RPM.


import dcacheYaimInstallertest.logger as logger

is just fine in both scenarios. 

This bug cost me some hours to trace and would have cost more had I not had a lot of experience of packaging, so I would be pleased if this could be fixed in all versions of Python.

Regards

Owen








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

Comment By: Martin v. L?wis (loewis)
Date: 2007-04-16 05:09

Message:
Logged In: YES 
user_id=21627
Originator: NO

I cannot reproduce the problem. The import statement works fine for me
when I create 

/usr/lib/python2.4/site-packages/dcacheYaimInstallerTest/logger.py

Can you share the RPM file that causes the problem?

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

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

From noreply at sourceforge.net  Sun May 13 01:36:03 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 12 May 2007 16:36:03 -0700
Subject: [ python-Bugs-1717900 ] Destructor behavior faulty
Message-ID: <E1Hn187-0007i8-Ea@sc8-sf-web22.sourceforge.net>

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

Please note that this message 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
Private: No
Submitted By: Wolf Rogner (wrogner)
Assigned to: Nobody/Anonymous (nobody)
Summary: Destructor behavior faulty

Initial Comment:
I tried example 11.4. from bytesofpython (by C.H. Swaroop).
Example works fine.

Added a new Person instance 'wolf' -> Program terminated with:
Exception exceptions.AttributeError: "'NoneType' object has no attribute 'population'" in <bound method Person.__del__ of <__main__.Person instance at 0xb7d48d6c>> ignored

added print list(globals()) ->
['kalam', '__builtins__', '__file__', 'DBGPHideChildren', 'swaroop', 'Person', 'wolf', '__name__', '__doc__']

changed wolf to aaa:

print list(globals()) ->
['aaa', 'kalam', '__builtins__', '__file__', 'DBGPHideChildren', 'swaroop', 'Person', '__name__', '__doc__']

Please note the position of 'aaa' at the beginning of the list, before 'Person'. With 'wolf' being after 'Person'.

If the destructing code removes items in this order, no wonder I get an error.

Person should not get deleted if refcount is still > 0.

Wolf Rogner


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

Comment By: Alan McIntyre (alanmcintyre)
Date: 2007-05-12 18:36

Message:
Logged In: YES 
user_id=1115903
Originator: NO

Could you post the code for your entire script? It makes it a lot easier
to figure out what's going on.

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

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

From noreply at sourceforge.net  Sun May 13 08:21:50 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 12 May 2007 23:21:50 -0700
Subject: [ python-Bugs-1718017 ] posixpath and friends have uses that should
	be documented
Message-ID: <E1Hn7So-0001dU-Sk@sc8-sf-web21.sourceforge.net>

Bugs item #1718017, was opened at 2007-05-13 08: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=1718017&group_id=5470

Please note that this 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
Private: No
Submitted By: Gabriel de Perthuis (onyxg7)
Assigned to: Nobody/Anonymous (nobody)
Summary: posixpath and friends have uses that should be documented

Initial Comment:
At this page: http://docs.python.org/lib/module-os.html

It should be suggested that the modules: posixpath, macpath, ntpath, os2emxpath are available on all platforms to handle the path conventions of that platform. The current phrasing, along with the documentation for each of these modules, does not imply that.

In particular, posixpath is useful to handle the URI path conventions in http://tools.ietf.org/html/rfc2396 , for example handling repeated slashes and references to .. and .

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

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

From noreply at sourceforge.net  Sun May 13 09:52:24 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 13 May 2007 00:52:24 -0700
Subject: [ python-Bugs-1717900 ] Destructor behavior faulty
Message-ID: <E1Hn8sS-0006h5-D4@sc8-sf-web23.sourceforge.net>

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

Please note that this message 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: Pending
Resolution: None
Priority: 5
Private: No
Submitted By: Wolf Rogner (wrogner)
Assigned to: Nobody/Anonymous (nobody)
Summary: Destructor behavior faulty

Initial Comment:
I tried example 11.4. from bytesofpython (by C.H. Swaroop).
Example works fine.

Added a new Person instance 'wolf' -> Program terminated with:
Exception exceptions.AttributeError: "'NoneType' object has no attribute 'population'" in <bound method Person.__del__ of <__main__.Person instance at 0xb7d48d6c>> ignored

added print list(globals()) ->
['kalam', '__builtins__', '__file__', 'DBGPHideChildren', 'swaroop', 'Person', 'wolf', '__name__', '__doc__']

changed wolf to aaa:

print list(globals()) ->
['aaa', 'kalam', '__builtins__', '__file__', 'DBGPHideChildren', 'swaroop', 'Person', '__name__', '__doc__']

Please note the position of 'aaa' at the beginning of the list, before 'Person'. With 'wolf' being after 'Person'.

If the destructing code removes items in this order, no wonder I get an error.

Person should not get deleted if refcount is still > 0.

Wolf Rogner


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

Comment By: Alan McIntyre (alanmcintyre)
Date: 2007-05-12 23:36

Message:
Logged In: YES 
user_id=1115903
Originator: NO

Could you post the code for your entire script? It makes it a lot easier
to figure out what's going on.

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

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

From noreply at sourceforge.net  Sun May 13 09:54:17 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 13 May 2007 00:54:17 -0700
Subject: [ python-Bugs-1714773 ] python throws an error when unpacking bz2 file
Message-ID: <E1Hn8uH-0006u6-PD@sc8-sf-web23.sourceforge.net>

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

Please note that this 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
Private: No
Submitted By: runnig (runnig)
Assigned to: Nobody/Anonymous (nobody)
Summary: python throws an error when unpacking bz2 file

Initial Comment:
C:\work\python>c:\work\python\25\py.exe
Python 2.5 (r25:51908, Feb 13 2007, 14:33:20) [MSC v.1400 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
C:\work\python>ez_setup.py wxpython
Searching for wxpython
Reading http://cheeseshop.python.org/pypi/wxpython/
Couldn't find index page for 'wxpython' (maybe misspelled?)
Scanning index of all packages (this may take a while)
Reading http://cheeseshop.python.org/pypi/
Reading http://cheeseshop.python.org/pypi/wxPython/2.6.3.2
Reading http://wxPython.org/
Reading http://wxPython.org/download.php
Best match: wxPython src-2.8.3.0
Downloading http://prdownloads.sourceforge.net/wxpython/wxPython-src-2.8.3.0.tar.bz2
Processing wxPython-src-2.8.3.0.tar.bz2


I think, when unpacking bz2, an error occurs and windows shows an error about 
"python.exe has encountered a problem and needs to close"


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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-13 07:54

Message:
Logged In: YES 
user_id=849994
Originator: NO

Can you try to take the .tar.bz2 file and unpack it yourself using
Python's bz2 module?
We can then find out where exactly the segfault occurs.

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

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

From noreply at sourceforge.net  Sun May 13 09:54:44 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 13 May 2007 00:54:44 -0700
Subject: [ python-Feature Requests-1713624 ] commands module
Message-ID: <E1Hn8ui-0006uW-6r@sc8-sf-web23.sourceforge.net>

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

Please note that this 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.6
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: Joseph Armbruster (joearmbruster)
Assigned to: Nobody/Anonymous (nobody)
Summary: commands module

Initial Comment:
In reference to the commands module, and it's simple self   :-)

Current comments in the module state the following:

# Module 'commands'
#
# Various tools for executing commands and looking at their output and status.
#
# NB This only works (and is only relevant) for UNIX.

Ultimately, I would like to see the following:

1) This comment removed:
# NB This only works (and is only relevant) for UNIX.

1) A change to getstatusoutput along these lines:
    if os.name == 'nt':
        pipe = os.popen(cmd + ' 2>&1','r')
    else:
        pipe = os.popen('{ ' + cmd + '; } 2>&1', 'r')

* I was going to suggest having a more pythonic getstatus method, that would act reasonably similar across platforms (maybe using some combination of os.listdir and os.stat or something), however, it is being deprecated, so onward!

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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-13 07:54

Message:
Logged In: YES 
user_id=849994
Originator: NO

I agree.

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

Comment By: Josiah Carlson (josiahcarlson)
Date: 2007-05-06 06:46

Message:
Logged In: YES 
user_id=341410
Originator: NO

Recent discussions in one of the python development lists has basically
stated that the commands module will be deprecated in favor of being
replaced by equivalent platform independent versions based on subprocess,
which will be placed in the subprocess module.  As such, it is doubtful
that your request will be fulfilled.  Suggested close as 'wont fix'.

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

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

From noreply at sourceforge.net  Sun May 13 09:55:35 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 13 May 2007 00:55:35 -0700
Subject: [ python-Feature Requests-840034 ] additions to commands lib
Message-ID: <E1Hn8vX-00070x-7B@sc8-sf-web23.sourceforge.net>

Feature Requests item #840034, was opened at 2003-11-11 15:41
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=840034&group_id=5470

Please note that this message will contain 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: Rejected
Priority: 5
Private: No
Submitted By: Mark Hattarki (mindfunk)
Assigned to: Nobody/Anonymous (nobody)
Summary: additions to commands lib

Initial Comment:
 
There currently is a function, commands.getstatusoutput. This, simply, 
runs a command, returns it's exit code and and output. The problem 
is, stderr and stdout are mixed. There are many real world examples 
where this is not desirable. In fact, I've written the following function 
in various forms many, many times: 
 
def run_cmd(cmd): 
    pipe = popen2.Popen3(cmd, 1) 
    ret = pipe.wait() 
    return (ret, pipe.fromchild.readlines(-1), 
            pipe.childerr.readlines(-1)) 
 
This is a very simple command. Anyone could write it. But, I still think 
is should be added because there is a function that is very similar to it 
(getstatusoutput) that comes extremely close, but does something 
that renders it useless if one wants to separate the two. It would be a 
useful addition to the commands lib.  
 
Also, I wouldn't nessesarily name it &quot;run_cmd&quot; if added to the lib. 
 
I suppose one could have it throw exceptions as well: 
 
def getouterr(cmd): 
    if not os.path.exists((cmd.split(' '))[0]): 
        raise ATSCommandPath(cmd, &quot;command not found&quot;) 
    return run_cmd(cmd) 
 
... obviously, one could do better error checking (searching $PATH, 
etc). But, that is the basic point. 
 
If you guys/gals will allow it, I would also like to submit the patch. 
 
namaste, 
Mark &lt;mindfunk at mindfunk.net 

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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-13 07:55

Message:
Logged In: YES 
user_id=849994
Originator: NO

You can/should use the subprocess module for this kind of process
handling.

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

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

From noreply at sourceforge.net  Sun May 13 09:57:15 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 13 May 2007 00:57:15 -0700
Subject: [ python-Feature Requests-711268 ] A large block of commands after an
	&quot; if&quot; cannot be 
Message-ID: <E1Hn8x9-0007Dv-3e@sc8-sf-web23.sourceforge.net>

Feature Requests item #711268, was opened at 2003-03-28 10:47
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=711268&group_id=5470

Please note that this 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: Wont Fix
Priority: 5
Private: No
Submitted By: Bram Moolenaar (vimboss)
Assigned to: Nobody/Anonymous (nobody)
Summary: A large block of commands after an &quot;if&quot; cannot be 

Initial Comment:
A Generated Python script Contains the code:
    if 1:
          file = bugreport.vim
          ... long list of commands ....

Executing this code with:
      exec cmds in globals(), globals()

Results in the error:
      SystemError: com_backpatch: offset too large

Looking into the code for com_backpatch() it appears
that the code is more than what can be jumped over.

Possible solutions:
1.  When there is too much code, use another jump
statement that allows for a larger offset.
2.  Always use a jump statement with a large offset
3.  When &quot;if 1&quot; is used, don't generate a jump
statement (not a real fix, but works for the situation
where I ran into the bug).

It looks like this bug exists in all versions of Python.

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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-13 07:57

Message:
Logged In: YES 
user_id=849994
Originator: NO

#3 is already implemented. Note that there are some internal limits to the
bytecode interpreter's code sizes etc., they can
be circumvented by putting the code in several functions and calling them
in order.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-01-02 02:40

Message:
Logged In: YES 
user_id=80475

Re-classifying this as a feature request for CPython
implementation to be expanded to handle larger relative
jumps.  The current behavior of raising a SystemError is
correct, non-buggy behavior.

One solution is to introduce a new bytecode for indirect
jumps based on an entry into the constants table.  Whenever
the distance is too large to backpatch a JUMP_FORWARD, that
opcode can be replaced with JUMP_INDIRECT and given an
offset into the constant table.  This solution is easy to
implement.  (Reminder, the peepholer should skip any code
containing the new opcode.)

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

Comment By: Jeff Epler (jepler)
Date: 2005-01-02 00:33

Message:
Logged In: YES 
user_id=2772

Please see my (unsuitable for inclusion) patch at
http://mail.python.org/pipermail/python-list/2004-November/249827.html
I think that message suggests some steps that might result
in an acceptable patch.

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

Comment By: Facundo Batista (facundobatista)
Date: 2004-12-27 16:10

Message:
Logged In: YES 
user_id=752496

Also happens in 2.4.

I'm reopening the bug, in group 2.4.

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

Comment By: Bram Moolenaar (vimboss)
Date: 2004-12-27 16:04

Message:
Logged In: YES 
user_id=57665

It appears between Python 2.2 and 2.3 the efficiency of the
produced bytecode was improved.  You now need to repeat the
command 10923 times to produce the error.  Thus the problem
remains, it's just further away.

You can reproduce the problem with this program:
cmds = "if 1:\n"
for i in xrange(1, 10923):
    cmds = cmds + " a = 'a'\n"
exec cmds in globals(), globals()

I verified with Python 2.3.3, don't have a newer version
right now.

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

Comment By: Brett Cannon (bcannon)
Date: 2004-12-26 19:11

Message:
Logged In: YES 
user_id=357491

I can't reproduce it with 2.3, 2.3 maintenance, 2.4 maintenance, or 2.5 in

CVS using 8000 lines.

Closing as out of date.

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

Comment By: Facundo Batista (facundobatista)
Date: 2004-12-26 15:00

Message:
Logged In: YES 
user_id=752496

Please, could you verify if this problem persists in Python 2.3.4
or 2.4?

If yes, in which version? Can you provide a test case?

If the problem is solved, from which version?

Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".

Thank you! 

.    Facundo

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

Comment By: Facundo Batista (facundobatista)
Date: 2004-12-26 15:00

Message:
Logged In: YES 
user_id=752496

Can not reproduce the problem in Py2.3.4 using the method
posted by vimboss. It's already fixed?

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

Comment By: Bram Moolenaar (vimboss)
Date: 2003-03-28 20:03

Message:
Logged In: YES 
user_id=57665

I can reproduce the problem with this text:
if 1:
   a = &quot;a&quot;

Repeat the assignment 7282 times.  Feed this text to &quot;exec&quot;.
With 7281 assignments you do not get the error.
Looks like 9 bytes are produced per assignment.

Good luck fixing this!

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-03-28 19:18

Message:
Logged In: YES 
user_id=6380

Hm, the 32-bit argument doesn't work because of what
backpatch does. It would require a totally different
approach to allow backpatching a larer offset, or we'd
always have to reserve 4 bytes for the offset. :-(

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-03-28 19:13

Message:
Logged In: YES 
user_id=6380

Just curious. How big was the block of code?

Also, I wonder if the error message is bogus; opcode
arguments can now be 32 bits AFAIK.

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

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

From noreply at sourceforge.net  Sun May 13 10:04:18 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 13 May 2007 01:04:18 -0700
Subject: [ python-Feature Requests-1707693 ] Please add .bz2 in encodings_map
	(in the module mimetypes)
Message-ID: <E1Hn93y-00070g-2w@sc8-sf-web22.sourceforge.net>

Feature Requests item #1707693, was opened at 2007-04-25 20:46
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1707693&group_id=5470

Please note that this message will contain 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
Private: No
Submitted By: elghinn (elghinn)
Assigned to: Nobody/Anonymous (nobody)
Summary: Please add .bz2 in encodings_map (in the module mimetypes)

Initial Comment:
In the module mimetypes, can you add .bz2 in 
    encodings_map = {
        '.gz': 'gzip',
        '.Z': 'compress',
        }
please ?

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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-13 08:04

Message:
Logged In: YES 
user_id=849994
Originator: NO

Done in rev. 55290.

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

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

From noreply at sourceforge.net  Sun May 13 10:05:45 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 13 May 2007 01:05:45 -0700
Subject: [ python-Feature Requests-1705362 ] cannot change cursor color in
	IDLE 
Message-ID: <E1Hn95N-00077b-EJ@sc8-sf-web22.sourceforge.net>

Feature Requests item #1705362, was opened at 2007-04-22 19:14
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1705362&group_id=5470

Please note that this 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
Private: No
Submitted By: zorkin (zorkin)
Assigned to: Nobody/Anonymous (nobody)
Summary: cannot change cursor color in IDLE 

Initial Comment:
Python 2.5.1 for windows
When I change the cursor color to another color, it still stays black, so I can't really make black background.

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

Comment By: zorkin (zorkin)
Date: 2007-04-23 07:33

Message:
Logged In: YES 
user_id=1741501
Originator: YES

The page on the link says you can invert it. As I understand, the caret
color is either black or background color. You could force it to be
black/white.

Also you should hide this option in selector - it's misleading, because I
thought i does something.

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

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-04-23 05:48

Message:
Logged In: YES 
user_id=479790
Originator: NO

IDLE on Windows appears to be using an always-black caret (cursor) - not
the standard caret behavior, which does its "blinking" by inverting the
background color.
So something might be improved here, but I doubt you can reliably set the
caret color on Windows; see http://support.microsoft.com/kb/84054/en-us


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

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

From noreply at sourceforge.net  Sun May 13 10:07:43 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 13 May 2007 01:07:43 -0700
Subject: [ python-Bugs-1633621 ] curses should reset curses.{COLS,
	LINES} when term. resized
Message-ID: <E1Hn97H-00019E-Rd@sc8-sf-web24.sourceforge.net>

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

Please note that this message will contain a full 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: 3
Private: No
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: curses should reset curses.{COLS,LINES} when term. resized

Initial Comment:
[forwarded from http://bugs.debian.org/366698]

The curses module does not reset curses.COLS and curses.LINES when the terminal is resized.


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

>Comment By: Walter D?rwald (doerwalter)
Date: 2007-05-13 10:07

Message:
Logged In: YES 
user_id=89016
Originator: NO

Updating LINES and COLS is done in curses.resize_term() and
curses.resizeterm(), so you have to call one of those functions.

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

Comment By: blubb (machamalahalaba)
Date: 2007-05-12 18:17

Message:
Logged In: YES 
user_id=1791654
Originator: NO

I'm still able to reproduce this bug with Python 2.5.1. The following
script always gives the same size:

import curses

while True:
	scr = curses.initscr()
	print curses.LINES, curses.COLS
	scr.getch()
	scr.getch()
	curses.endwin()


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

Comment By: Walter D?rwald (doerwalter)
Date: 2007-03-06 21:47

Message:
Logged In: YES 
user_id=89016
Originator: NO

Checked in as revision 54180 and 54181 (2.5)

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

Comment By: Scott Dial (geekmug)
Date: 2007-03-05 23:14

Message:
Logged In: YES 
user_id=383208
Originator: NO

I've reviewed this patch and I believe it to be the correct patch. I
believe it would be prudent to add a test case for this. I'm unable to
attach, but here is a link to a patch for that:
http://scottdial.com/python-dev/curses-test.patch

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

Comment By: Walter D?rwald (doerwalter)
Date: 2007-02-12 19:59

Message:
Logged In: YES 
user_id=89016
Originator: NO

Here's a patch that implements the requested changes.
File Added: diff.txt

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

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

From noreply at sourceforge.net  Sun May 13 21:53:34 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 13 May 2007 12:53:34 -0700
Subject: [ python-Bugs-1718017 ] posixpath and friends have uses that should
	be documented
Message-ID: <E1HnK8M-0005Y7-IZ@sc8-sf-web21.sourceforge.net>

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

Please note that this 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
Private: No
Submitted By: Gabriel de Perthuis (onyxg7)
Assigned to: Nobody/Anonymous (nobody)
Summary: posixpath and friends have uses that should be documented

Initial Comment:
At this page: http://docs.python.org/lib/module-os.html

It should be suggested that the modules: posixpath, macpath, ntpath, os2emxpath are available on all platforms to handle the path conventions of that platform. The current phrasing, along with the documentation for each of these modules, does not imply that.

In particular, posixpath is useful to handle the URI path conventions in http://tools.ietf.org/html/rfc2396 , for example handling repeated slashes and references to .. and .

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-13 12:53

Message:
Logged In: YES 
user_id=33168
Originator: NO

Gabriel, could you try to work up a patch which demonstrates what you
would like changed?  It would be great if you could do this against the
latex source in Doc/lib/libos.tex (presumably).  If you don't know latex,
that's ok, even a plain text patch would help a lot.

Thanks!

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

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

From noreply at sourceforge.net  Mon May 14 14:08:19 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 14 May 2007 05:08:19 -0700
Subject: [ python-Bugs-1718574 ] build_clib --build-clib/--build-temp option
	bugs
Message-ID: <E1HnZLf-0004N6-7U@sc8-sf-web21.sourceforge.net>

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

Please note that this 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
Private: No
Submitted By: Pearu Peterson (pearu)
Assigned to: Nobody/Anonymous (nobody)
Summary: build_clib --build-clib/--build-temp option bugs

Initial Comment:

build_clib --build-clib and --build-temp options
do not take arguments in Python 2.5 (as well as in 
versions 2.4 and down (I guess)).

This bug has easy fix: in distutils/commands/build_clib.py
file add `=' to the definitions of the
corresponding options as follows:
...
    user_options = [
        ('build-clib=', 'b',
         "directory to build C/C++ libraries to"),
        ('build-temp=', 't',
...


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

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

From noreply at sourceforge.net  Mon May 14 17:38:19 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 14 May 2007 08:38:19 -0700
Subject: [ python-Bugs-1717900 ] Destructor behavior faulty
Message-ID: <E1Hncct-0002lW-VY@sc8-sf-web21.sourceforge.net>

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

Please note that this message 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: Pending
Resolution: None
Priority: 5
Private: No
Submitted By: Wolf Rogner (wrogner)
Assigned to: Nobody/Anonymous (nobody)
Summary: Destructor behavior faulty

Initial Comment:
I tried example 11.4. from bytesofpython (by C.H. Swaroop).
Example works fine.

Added a new Person instance 'wolf' -> Program terminated with:
Exception exceptions.AttributeError: "'NoneType' object has no attribute 'population'" in <bound method Person.__del__ of <__main__.Person instance at 0xb7d48d6c>> ignored

added print list(globals()) ->
['kalam', '__builtins__', '__file__', 'DBGPHideChildren', 'swaroop', 'Person', 'wolf', '__name__', '__doc__']

changed wolf to aaa:

print list(globals()) ->
['aaa', 'kalam', '__builtins__', '__file__', 'DBGPHideChildren', 'swaroop', 'Person', '__name__', '__doc__']

Please note the position of 'aaa' at the beginning of the list, before 'Person'. With 'wolf' being after 'Person'.

If the destructing code removes items in this order, no wonder I get an error.

Person should not get deleted if refcount is still > 0.

Wolf Rogner


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

Comment By: Alan McIntyre (alanmcintyre)
Date: 2007-05-14 10:38

Message:
Logged In: YES 
user_id=1115903
Originator: NO

I took the example mentioned from here: 
    http://www.python.org/doc/essays/cleanup/

and added this line to the end:

wolf = Person('wolf')

and it gives the reported error.  Here is a minimal snippet that produces
the same error when executed as the top-level module:

class Person:
        population = 0
        def __del__(self):
                Person.population -= 1

wolf = Person()


This appears to be consistent with the behavior described here:
     http://www.python.org/doc/essays/cleanup/

While I understand that cleaning up a module at exit time is probably not
an easy thing to make arbitrarily smart, this behavior seems a little too
not-smart to me.  It seems like it's not all that hard to get bitten by 
it, and the error makes no sense unless you're familiar with the module
cleanup algorithm.

For what it's worth, I offer to help make module cleanup a little smarter,
although I may not be able to spend much time on it until I finish some
things I'm already committed to do.

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

Comment By: Alan McIntyre (alanmcintyre)
Date: 2007-05-12 18:36

Message:
Logged In: YES 
user_id=1115903
Originator: NO

Could you post the code for your entire script? It makes it a lot easier
to figure out what's going on.

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

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

From noreply at sourceforge.net  Mon May 14 18:53:47 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 14 May 2007 09:53:47 -0700
Subject: [ python-Bugs-1714773 ] python throws an error when unpacking bz2 file
Message-ID: <E1Hndnv-0002ox-Py@sc8-sf-web21.sourceforge.net>

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

Please note that this 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
Private: No
Submitted By: runnig (runnig)
Assigned to: Nobody/Anonymous (nobody)
Summary: python throws an error when unpacking bz2 file

Initial Comment:
C:\work\python>c:\work\python\25\py.exe
Python 2.5 (r25:51908, Feb 13 2007, 14:33:20) [MSC v.1400 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
C:\work\python>ez_setup.py wxpython
Searching for wxpython
Reading http://cheeseshop.python.org/pypi/wxpython/
Couldn't find index page for 'wxpython' (maybe misspelled?)
Scanning index of all packages (this may take a while)
Reading http://cheeseshop.python.org/pypi/
Reading http://cheeseshop.python.org/pypi/wxPython/2.6.3.2
Reading http://wxPython.org/
Reading http://wxPython.org/download.php
Best match: wxPython src-2.8.3.0
Downloading http://prdownloads.sourceforge.net/wxpython/wxPython-src-2.8.3.0.tar.bz2
Processing wxPython-src-2.8.3.0.tar.bz2


I think, when unpacking bz2, an error occurs and windows shows an error about 
"python.exe has encountered a problem and needs to close"


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

Comment By: Alan McIntyre (alanmcintyre)
Date: 2007-05-14 11:53

Message:
Logged In: YES 
user_id=1115903
Originator: NO

I downloaded the file from the URL given above, and when I tried to
decompress it in a single shot (with bz2.decompress), python crashes. 
Reading the raw bz2 data from file into a string in memory works ok, but
attempting to use bz2.decompress on that data causes the crash.

I could only get this to happen under 2.5.1 on a Windows XP machine (media
center edition); it seems to work ok on OSX (Python 2.5) and Linux (both
2.4.4 and the current trunk).  I will be able to take a closer look at this
tomorrow when I have access to a Windows machine with a compiler on it.



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

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-13 02:54

Message:
Logged In: YES 
user_id=849994
Originator: NO

Can you try to take the .tar.bz2 file and unpack it yourself using
Python's bz2 module?
We can then find out where exactly the segfault occurs.

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

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

From noreply at sourceforge.net  Mon May 14 23:28:54 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 14 May 2007 14:28:54 -0700
Subject: [ python-Bugs-1718942 ] glibc error: corrupted double linked list
	(CPython 2.5.1)
Message-ID: <E1Hni6A-0006O0-LB@sc8-sf-web21.sourceforge.net>

Bugs item #1718942, was opened at 2007-05-14 14: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=1718942&group_id=5470

Please note that this message 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
Private: No
Submitted By: Yang Zhang (yangzhang)
Assigned to: Nobody/Anonymous (nobody)
Summary: glibc error: corrupted double linked list (CPython 2.5.1)

Initial Comment:
I'm sometimes (50% of the time) getting the following CPython 2.5.1 crash when my program terminates. I would include the source to my program, but it has lots of dependencies, and it would be a substantial task to find a minimal case.

*** glibc detected *** python: corrupted double-linked list: 0x0a2018a0 ***
======= Backtrace: =========
/lib/libc.so.6[0xd14e9f]
/lib/libc.so.6[0xd167ae]
/lib/libc.so.6(__libc_free+0x78)[0xd19f6f]
/usr/local/lib/libpython2.5.so.1.0(PyObject_Free+0x53)[0x211933]
/usr/local/lib/libpython2.5.so.1.0(PyObject_GC_Del+0x53)[0x288fc3]
/usr/local/lib/libpython2.5.so.1.0(PyFrame_Fini+0x31)[0x1f8f81]
/usr/local/lib/libpython2.5.so.1.0(Py_Finalize+0x105)[0x27d825]
/usr/local/lib/libpython2.5.so.1.0(Py_Exit+0x17)[0x27d927]
/usr/local/lib/libpython2.5.so.1.0[0x27da4f]
/usr/local/lib/libpython2.5.so.1.0(PyErr_PrintEx+0x1aa)[0x27dc6a]
/usr/local/lib/libpython2.5.so.1.0(PyErr_Print+0x1e)[0x27de6e]
/usr/local/lib/libpython2.5.so.1.0(PyRun_SimpleFileExFlags+0xf1)[0x27f0d1]
/usr/local/lib/libpython2.5.so.1.0(PyRun_AnyFileExFlags+0x7a)[0x27f46a]
/usr/local/lib/libpython2.5.so.1.0(Py_Main+0xae8)[0x288a78]
python(main+0x32)[0x8048592]
/lib/libc.so.6(__libc_start_main+0xdc)[0xcc84e4]
python[0x80484d1]
======= Memory map: ========
00110000-00120000 r-xp 00000000 08:02 489896     /lib/libpthread-2.4.so
00120000-00121000 r--p 0000f000 08:02 489896     /lib/libpthread-2.4.so
00121000-00122000 rw-p 00010000 08:02 489896     /lib/libpthread-2.4.so
00122000-00124000 rw-p 00122000 00:00 0
00124000-00147000 r-xp 00000000 08:02 489888     /lib/libm-2.4.so
00147000-00148000 r--p 00022000 08:02 489888     /lib/libm-2.4.so
00148000-00149000 rw-p 00023000 08:02 489888     /lib/libm-2.4.so
00149000-00159000 r-xp 00000000 08:02 2154663    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/cPickle.so
00159000-0015a000 rw-p 00010000 08:02 2154663    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/cPickle.so
0015a000-0015d000 r-xp 00000000 08:02 2154640    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/cStringIO.so
0015d000-0015e000 rw-p 00003000 08:02 2154640    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/cStringIO.so
0015e000-00161000 r-xp 00000000 08:02 2154619    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/time.so
00161000-00163000 rw-p 00002000 08:02 2154619    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/time.so
00163000-00167000 r-xp 00000000 08:02 2154653    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/collections.so
00167000-00168000 rw-p 00004000 08:02 2154653    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/collections.so
00168000-001a9000 r-xp 00000000 08:02 490243     /lib/libssl.so.0.9.8a
001a9000-001ad000 rw-p 00040000 08:02 490243     /lib/libssl.so.0.9.8a
001ad000-001af000 r-xp 00000000 08:02 2154635    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/fcntl.so
001af000-001b0000 rw-p 00002000 08:02 2154635    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/fcntl.so
001b0000-001b2000 r-xp 00000000 08:02 2154613    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/grp.so
001b2000-001b3000 rw-p 00001000 08:02 2154613    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/grp.so
001b3000-001b4000 r-xp 00000000 08:02 2154641    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/_bisect.so
001b4000-001b5000 rw-p 00001000 08:02 2154641    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/_bisect.so
001b5000-002bd000 r-xp 00000000 08:02 2139893    /toast/pkg/python/v2.5.1/1/root/lib/libpython2.5.so.1.0
002bd000-002e3000 rw-p 00107000 08:02 2139893    /toast/pkg/python/v2.5.1/1/root/lib/libpython2.5.so.1.0
002e3000-002e9000 rw-p 002e3000 00:00 0
002e9000-002f8000 r-xp 00000000 08:02 489892     /lib/libresolv-2.4.so
002f8000-002f9000 r--p 0000e000 08:02 489892     /lib/libresolv-2.4.so
002f9000-002fa000 rw-p 0000f000 08:02 489892     /lib/libresolv-2.4.so
002fa000-002fc000 rw-p 002fa000 00:00 0
002fc000-0030e000 r-xp 00000000 08:02 1290756    /usr/lib/libz.so.1.2.3
0030e000-0030f000 rw-p 00011000 08:02 1290756    /usr/lib/libz.so.1.2.3
0030f000-0032f000 r-xp 00000000 08:02 565445     /usr/lib/libpq.so.4.1
0032f000-00330000 rw-p 0001f000 08:02 565445     /usr/lib/libpq.so.4.1
00330000-0033f000 r-xp 00000000 08:02 2154660    /toast/pkg/pAborted

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

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

From noreply at sourceforge.net  Mon May 14 23:31:38 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 14 May 2007 14:31:38 -0700
Subject: [ python-Bugs-1718942 ] glibc error: corrupted double linked list
	(CPython 2.5.1)
Message-ID: <E1Hni8o-0006jE-DT@sc8-sf-web21.sourceforge.net>

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

Please note that this message 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
Private: No
Submitted By: Yang Zhang (yangzhang)
Assigned to: Nobody/Anonymous (nobody)
Summary: glibc error: corrupted double linked list (CPython 2.5.1)

Initial Comment:
I'm sometimes (50% of the time) getting the following CPython 2.5.1 crash when my program terminates. I would include the source to my program, but it has lots of dependencies, and it would be a substantial task to find a minimal case.

*** glibc detected *** python: corrupted double-linked list: 0x0a2018a0 ***
======= Backtrace: =========
/lib/libc.so.6[0xd14e9f]
/lib/libc.so.6[0xd167ae]
/lib/libc.so.6(__libc_free+0x78)[0xd19f6f]
/usr/local/lib/libpython2.5.so.1.0(PyObject_Free+0x53)[0x211933]
/usr/local/lib/libpython2.5.so.1.0(PyObject_GC_Del+0x53)[0x288fc3]
/usr/local/lib/libpython2.5.so.1.0(PyFrame_Fini+0x31)[0x1f8f81]
/usr/local/lib/libpython2.5.so.1.0(Py_Finalize+0x105)[0x27d825]
/usr/local/lib/libpython2.5.so.1.0(Py_Exit+0x17)[0x27d927]
/usr/local/lib/libpython2.5.so.1.0[0x27da4f]
/usr/local/lib/libpython2.5.so.1.0(PyErr_PrintEx+0x1aa)[0x27dc6a]
/usr/local/lib/libpython2.5.so.1.0(PyErr_Print+0x1e)[0x27de6e]
/usr/local/lib/libpython2.5.so.1.0(PyRun_SimpleFileExFlags+0xf1)[0x27f0d1]
/usr/local/lib/libpython2.5.so.1.0(PyRun_AnyFileExFlags+0x7a)[0x27f46a]
/usr/local/lib/libpython2.5.so.1.0(Py_Main+0xae8)[0x288a78]
python(main+0x32)[0x8048592]
/lib/libc.so.6(__libc_start_main+0xdc)[0xcc84e4]
python[0x80484d1]
======= Memory map: ========
00110000-00120000 r-xp 00000000 08:02 489896     /lib/libpthread-2.4.so
00120000-00121000 r--p 0000f000 08:02 489896     /lib/libpthread-2.4.so
00121000-00122000 rw-p 00010000 08:02 489896     /lib/libpthread-2.4.so
00122000-00124000 rw-p 00122000 00:00 0
00124000-00147000 r-xp 00000000 08:02 489888     /lib/libm-2.4.so
00147000-00148000 r--p 00022000 08:02 489888     /lib/libm-2.4.so
00148000-00149000 rw-p 00023000 08:02 489888     /lib/libm-2.4.so
00149000-00159000 r-xp 00000000 08:02 2154663    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/cPickle.so
00159000-0015a000 rw-p 00010000 08:02 2154663    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/cPickle.so
0015a000-0015d000 r-xp 00000000 08:02 2154640    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/cStringIO.so
0015d000-0015e000 rw-p 00003000 08:02 2154640    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/cStringIO.so
0015e000-00161000 r-xp 00000000 08:02 2154619    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/time.so
00161000-00163000 rw-p 00002000 08:02 2154619    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/time.so
00163000-00167000 r-xp 00000000 08:02 2154653    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/collections.so
00167000-00168000 rw-p 00004000 08:02 2154653    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/collections.so
00168000-001a9000 r-xp 00000000 08:02 490243     /lib/libssl.so.0.9.8a
001a9000-001ad000 rw-p 00040000 08:02 490243     /lib/libssl.so.0.9.8a
001ad000-001af000 r-xp 00000000 08:02 2154635    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/fcntl.so
001af000-001b0000 rw-p 00002000 08:02 2154635    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/fcntl.so
001b0000-001b2000 r-xp 00000000 08:02 2154613    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/grp.so
001b2000-001b3000 rw-p 00001000 08:02 2154613    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/grp.so
001b3000-001b4000 r-xp 00000000 08:02 2154641    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/_bisect.so
001b4000-001b5000 rw-p 00001000 08:02 2154641    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/_bisect.so
001b5000-002bd000 r-xp 00000000 08:02 2139893    /toast/pkg/python/v2.5.1/1/root/lib/libpython2.5.so.1.0
002bd000-002e3000 rw-p 00107000 08:02 2139893    /toast/pkg/python/v2.5.1/1/root/lib/libpython2.5.so.1.0
002e3000-002e9000 rw-p 002e3000 00:00 0
002e9000-002f8000 r-xp 00000000 08:02 489892     /lib/libresolv-2.4.so
002f8000-002f9000 r--p 0000e000 08:02 489892     /lib/libresolv-2.4.so
002f9000-002fa000 rw-p 0000f000 08:02 489892     /lib/libresolv-2.4.so
002fa000-002fc000 rw-p 002fa000 00:00 0
002fc000-0030e000 r-xp 00000000 08:02 1290756    /usr/lib/libz.so.1.2.3
0030e000-0030f000 rw-p 00011000 08:02 1290756    /usr/lib/libz.so.1.2.3
0030f000-0032f000 r-xp 00000000 08:02 565445     /usr/lib/libpq.so.4.1
0032f000-00330000 rw-p 0001f000 08:02 565445     /usr/lib/libpq.so.4.1
00330000-0033f000 r-xp 00000000 08:02 2154660    /toast/pkg/pAborted

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

>Comment By: Yang Zhang (yangzhang)
Date: 2007-05-14 14:31

Message:
Logged In: YES 
user_id=1207658
Originator: YES

just to add some more details:

this is on my up2date fedora core 5 box, with a built-from-source cpython
2.5.1. afaik i'm not using any non-standard extension modules.

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

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

From noreply at sourceforge.net  Tue May 15 07:48:13 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 14 May 2007 22:48:13 -0700
Subject: [ python-Bugs-1718942 ] glibc error: corrupted double linked list
	(CPython 2.5.1)
Message-ID: <E1HnptN-0003yN-NH@sc8-sf-web24.sourceforge.net>

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

Please note that this message 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
Private: No
Submitted By: Yang Zhang (yangzhang)
Assigned to: Nobody/Anonymous (nobody)
Summary: glibc error: corrupted double linked list (CPython 2.5.1)

Initial Comment:
I'm sometimes (50% of the time) getting the following CPython 2.5.1 crash when my program terminates. I would include the source to my program, but it has lots of dependencies, and it would be a substantial task to find a minimal case.

*** glibc detected *** python: corrupted double-linked list: 0x0a2018a0 ***
======= Backtrace: =========
/lib/libc.so.6[0xd14e9f]
/lib/libc.so.6[0xd167ae]
/lib/libc.so.6(__libc_free+0x78)[0xd19f6f]
/usr/local/lib/libpython2.5.so.1.0(PyObject_Free+0x53)[0x211933]
/usr/local/lib/libpython2.5.so.1.0(PyObject_GC_Del+0x53)[0x288fc3]
/usr/local/lib/libpython2.5.so.1.0(PyFrame_Fini+0x31)[0x1f8f81]
/usr/local/lib/libpython2.5.so.1.0(Py_Finalize+0x105)[0x27d825]
/usr/local/lib/libpython2.5.so.1.0(Py_Exit+0x17)[0x27d927]
/usr/local/lib/libpython2.5.so.1.0[0x27da4f]
/usr/local/lib/libpython2.5.so.1.0(PyErr_PrintEx+0x1aa)[0x27dc6a]
/usr/local/lib/libpython2.5.so.1.0(PyErr_Print+0x1e)[0x27de6e]
/usr/local/lib/libpython2.5.so.1.0(PyRun_SimpleFileExFlags+0xf1)[0x27f0d1]
/usr/local/lib/libpython2.5.so.1.0(PyRun_AnyFileExFlags+0x7a)[0x27f46a]
/usr/local/lib/libpython2.5.so.1.0(Py_Main+0xae8)[0x288a78]
python(main+0x32)[0x8048592]
/lib/libc.so.6(__libc_start_main+0xdc)[0xcc84e4]
python[0x80484d1]
======= Memory map: ========
00110000-00120000 r-xp 00000000 08:02 489896     /lib/libpthread-2.4.so
00120000-00121000 r--p 0000f000 08:02 489896     /lib/libpthread-2.4.so
00121000-00122000 rw-p 00010000 08:02 489896     /lib/libpthread-2.4.so
00122000-00124000 rw-p 00122000 00:00 0
00124000-00147000 r-xp 00000000 08:02 489888     /lib/libm-2.4.so
00147000-00148000 r--p 00022000 08:02 489888     /lib/libm-2.4.so
00148000-00149000 rw-p 00023000 08:02 489888     /lib/libm-2.4.so
00149000-00159000 r-xp 00000000 08:02 2154663    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/cPickle.so
00159000-0015a000 rw-p 00010000 08:02 2154663    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/cPickle.so
0015a000-0015d000 r-xp 00000000 08:02 2154640    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/cStringIO.so
0015d000-0015e000 rw-p 00003000 08:02 2154640    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/cStringIO.so
0015e000-00161000 r-xp 00000000 08:02 2154619    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/time.so
00161000-00163000 rw-p 00002000 08:02 2154619    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/time.so
00163000-00167000 r-xp 00000000 08:02 2154653    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/collections.so
00167000-00168000 rw-p 00004000 08:02 2154653    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/collections.so
00168000-001a9000 r-xp 00000000 08:02 490243     /lib/libssl.so.0.9.8a
001a9000-001ad000 rw-p 00040000 08:02 490243     /lib/libssl.so.0.9.8a
001ad000-001af000 r-xp 00000000 08:02 2154635    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/fcntl.so
001af000-001b0000 rw-p 00002000 08:02 2154635    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/fcntl.so
001b0000-001b2000 r-xp 00000000 08:02 2154613    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/grp.so
001b2000-001b3000 rw-p 00001000 08:02 2154613    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/grp.so
001b3000-001b4000 r-xp 00000000 08:02 2154641    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/_bisect.so
001b4000-001b5000 rw-p 00001000 08:02 2154641    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/_bisect.so
001b5000-002bd000 r-xp 00000000 08:02 2139893    /toast/pkg/python/v2.5.1/1/root/lib/libpython2.5.so.1.0
002bd000-002e3000 rw-p 00107000 08:02 2139893    /toast/pkg/python/v2.5.1/1/root/lib/libpython2.5.so.1.0
002e3000-002e9000 rw-p 002e3000 00:00 0
002e9000-002f8000 r-xp 00000000 08:02 489892     /lib/libresolv-2.4.so
002f8000-002f9000 r--p 0000e000 08:02 489892     /lib/libresolv-2.4.so
002f9000-002fa000 rw-p 0000f000 08:02 489892     /lib/libresolv-2.4.so
002fa000-002fc000 rw-p 002fa000 00:00 0
002fc000-0030e000 r-xp 00000000 08:02 1290756    /usr/lib/libz.so.1.2.3
0030e000-0030f000 rw-p 00011000 08:02 1290756    /usr/lib/libz.so.1.2.3
0030f000-0032f000 r-xp 00000000 08:02 565445     /usr/lib/libpq.so.4.1
0032f000-00330000 rw-p 0001f000 08:02 565445     /usr/lib/libpq.so.4.1
00330000-0033f000 r-xp 00000000 08:02 2154660    /toast/pkg/pAborted

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-14 22:48

Message:
Logged In: YES 
user_id=33168
Originator: NO

Yang Zhang, thanks for the report.  Unfortunately, it will be virtually
impossible for us to try to debug this without a test case.  I see libpq.so
in there, which I believe is from Postgres.  Is that correct?  There is no
postgres module that's part of standard python.  The extension module is a
third party extension.  It's possible that's where the problem is.  Without
more info, it could really be anywhere.

Perhaps you could run this under valgrind or some other memory debugger
and find the problem or at least narrow it down?  

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

Comment By: Yang Zhang (yangzhang)
Date: 2007-05-14 14:31

Message:
Logged In: YES 
user_id=1207658
Originator: YES

just to add some more details:

this is on my up2date fedora core 5 box, with a built-from-source cpython
2.5.1. afaik i'm not using any non-standard extension modules.

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

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

From noreply at sourceforge.net  Tue May 15 13:42:21 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 15 May 2007 04:42:21 -0700
Subject: [ python-Bugs-1719222 ] new functools
Message-ID: <E1HnvQ5-0004u7-3S@sc8-sf-web24.sourceforge.net>

Bugs item #1719222, was opened at 2007-05-15 06: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=1719222&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Aaron Brady (ascription)
Assigned to: Nobody/Anonymous (nobody)
Summary: new functools

Initial Comment:
Python feature

Functools gains a new decorator.

`Defaults' allows its caller to placehold non-None defaults; it becomes unnecessary to know the value a place defaults to.

It might be useful in cases where you want the calling signature to look alike for a group of dispatched functions and the added overhead the decorator adds isn't a problem.  But you probably wouldn't want that overhead all the time, so having it as an optional decorator would be good. -Ron Adam


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

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

From noreply at sourceforge.net  Tue May 15 15:37:11 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 15 May 2007 06:37:11 -0700
Subject: [ python-Feature Requests-634412 ] RFC 2112 in email package
Message-ID: <E1HnxDD-0005CK-Le@sc8-sf-web21.sourceforge.net>

Feature Requests item #634412, was opened at 2002-11-06 08:14
Message generated for change (Comment added) made by etiffany
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=634412&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Private: No
Submitted By: Barry A. Warsaw (bwarsaw)
Assigned to: Nobody/Anonymous (nobody)
Summary: RFC 2112 in email package

Initial Comment:
Figure out if and how to support multipart/related as
specified in RFC 2112, in the email package.

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

Comment By: Eric Tiffany (etiffany)
Date: 2007-05-15 09:37

Message:
Logged In: YES 
user_id=875244
Originator: NO

What is the status of this item?  I don't seem to find support for
mulitpart/related in the email library in python 2.4.

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

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-11-21 15:24

Message:
Logged In: YES 
user_id=12800

Also moving to Feature Requests

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

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-11-21 15:23

Message:
Logged In: YES 
user_id=12800

Moving this to Python 2.4.  The email-sig should address
this for email 3.0/Python 2.4.

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

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

From noreply at sourceforge.net  Tue May 15 16:25:32 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 15 May 2007 07:25:32 -0700
Subject: [ python-Bugs-1719222 ] new functools
Message-ID: <E1Hnxy0-0002D5-LM@sc8-sf-web21.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Aaron Brady (ascription)
Assigned to: Nobody/Anonymous (nobody)
Summary: new functools

Initial Comment:
Python feature

Functools gains a new decorator.

`Defaults' allows its caller to placehold non-None defaults; it becomes unnecessary to know the value a place defaults to.

It might be useful in cases where you want the calling signature to look alike for a group of dispatched functions and the added overhead the decorator adds isn't a problem.  But you probably wouldn't want that overhead all the time, so having it as an optional decorator would be good. -Ron Adam


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

Comment By: Josiah Carlson (josiahcarlson)
Date: 2007-05-15 07:25

Message:
Logged In: YES 
user_id=341410
Originator: NO

This is not a bug.  Should move to Feature Requests at minimum, patches if
the text file is an actual patch.

Generally the poster desires that a catch-all default argument be allowed
to be passed to any function with default arguments to signal that the
original defaults should be used; like foo(123, default, 456) rather than
foo(123, arg3=456).

This proposal received no support in python-ideas.

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

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

From noreply at sourceforge.net  Tue May 15 16:47:09 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 15 May 2007 07:47:09 -0700
Subject: [ python-Feature Requests-1719222 ] new functool: "defaults" decorator
Message-ID: <E1HnyIv-0004OU-MK@sc8-sf-web22.sourceforge.net>

Feature Requests item #1719222, was opened at 2007-05-15 11:42
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1719222&group_id=5470

Please note that this message will contain 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
Private: No
Submitted By: Aaron Brady (ascription)
Assigned to: Nobody/Anonymous (nobody)
>Summary: new functool: "defaults" decorator

Initial Comment:
Python feature

Functools gains a new decorator.

`Defaults' allows its caller to placehold non-None defaults; it becomes unnecessary to know the value a place defaults to.

It might be useful in cases where you want the calling signature to look alike for a group of dispatched functions and the added overhead the decorator adds isn't a problem.  But you probably wouldn't want that overhead all the time, so having it as an optional decorator would be good. -Ron Adam


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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-15 14:47

Message:
Logged In: YES 
user_id=849994
Originator: NO

Moving to Feature Requests, adapting summary.

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

Comment By: Josiah Carlson (josiahcarlson)
Date: 2007-05-15 14:25

Message:
Logged In: YES 
user_id=341410
Originator: NO

This is not a bug.  Should move to Feature Requests at minimum, patches if
the text file is an actual patch.

Generally the poster desires that a catch-all default argument be allowed
to be passed to any function with default arguments to signal that the
original defaults should be used; like foo(123, default, 456) rather than
foo(123, arg3=456).

This proposal received no support in python-ideas.

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

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

From noreply at sourceforge.net  Tue May 15 18:39:34 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 15 May 2007 09:39:34 -0700
Subject: [ python-Bugs-1719423 ] Python package support not properly documented
Message-ID: <E1Ho03i-0000px-Ps@sc8-sf-web22.sourceforge.net>

Bugs item #1719423, was opened at 2007-05-15 17: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=1719423&group_id=5470

Please note that this 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
Private: No
Submitted By: Michael Abbott (araneidae)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python package support not properly documented

Initial Comment:
I can sum this report up most simply by quoting the message below:

http://mail.python.org/pipermail/python-list/2001-October/107699.html

Note that this message was posted 5 1/2 years ago (by myself, as it happens), had no follow up, and the problem referred to remains current!  (The chapter on "import" is now section 6.12: nothing else has changed.)

The comment below that "presum[ably] nothing significant has changed" seems less than probable now!

I was looking to understand modules and packages a bit better: they don't behave like proper first class objects (is module.sub_module an attribute?  not really), and so the lack of definitive documentation in this area is sad, particularly after such a long time.


Body of original message follows


Package support in Python 2

Michael Abbott michael at rcp.co.uk
Wed Oct 3 10:58:08 CEST 2001


Is there up to date documentation for package support in Python 2?

Section 6.11 of the "Python Reference Manual" has the following nice quote:


[XXX Can't be bothered to spell this out right now; see the URL http://www.python.org/doc/essays/packages.html for more details, also about how the module search works from inside a package.] 


and the referred URL documents Python 1.5.  I presume that nothing significant has changed recently, but it's certainly disconcerting for something as fundamental as module importing to not actually be part of the core language documentation!


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

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

From noreply at sourceforge.net  Tue May 15 20:44:49 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 15 May 2007 11:44:49 -0700
Subject: [ python-Bugs-1717900 ] Destructor behavior faulty
Message-ID: <E1Ho20v-0002u3-Hg@sc8-sf-web24.sourceforge.net>

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

Please note that this message 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: Pending
Resolution: None
Priority: 5
Private: No
Submitted By: Wolf Rogner (wrogner)
Assigned to: Nobody/Anonymous (nobody)
Summary: Destructor behavior faulty

Initial Comment:
I tried example 11.4. from bytesofpython (by C.H. Swaroop).
Example works fine.

Added a new Person instance 'wolf' -> Program terminated with:
Exception exceptions.AttributeError: "'NoneType' object has no attribute 'population'" in <bound method Person.__del__ of <__main__.Person instance at 0xb7d48d6c>> ignored

added print list(globals()) ->
['kalam', '__builtins__', '__file__', 'DBGPHideChildren', 'swaroop', 'Person', 'wolf', '__name__', '__doc__']

changed wolf to aaa:

print list(globals()) ->
['aaa', 'kalam', '__builtins__', '__file__', 'DBGPHideChildren', 'swaroop', 'Person', '__name__', '__doc__']

Please note the position of 'aaa' at the beginning of the list, before 'Person'. With 'wolf' being after 'Person'.

If the destructing code removes items in this order, no wonder I get an error.

Person should not get deleted if refcount is still > 0.

Wolf Rogner


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

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-15 15:44

Message:
Logged In: YES 
user_id=479790
Originator: NO

FWIW, the script name appears to be relevant as well. I were going to say
that I could not reproduce it as it was; this same example saved as "a.py"
doesn't show the error; "w.py" does.

To the OP: Module finalization is a fragile step; this is a long standing
issue and could be improved, but anyway I don't think it can be made robust
enough (this is just my opinion!). I usually try to *never* reference any
globals in destructors. In this case, using self.__class__ instead of
Person is safer and works fine; if other globals were needed they could be
passed as default argument values.

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

Comment By: Alan McIntyre (alanmcintyre)
Date: 2007-05-14 12:38

Message:
Logged In: YES 
user_id=1115903
Originator: NO

I took the example mentioned from here: 
    http://www.python.org/doc/essays/cleanup/

and added this line to the end:

wolf = Person('wolf')

and it gives the reported error.  Here is a minimal snippet that produces
the same error when executed as the top-level module:

class Person:
        population = 0
        def __del__(self):
                Person.population -= 1

wolf = Person()


This appears to be consistent with the behavior described here:
     http://www.python.org/doc/essays/cleanup/

While I understand that cleaning up a module at exit time is probably not
an easy thing to make arbitrarily smart, this behavior seems a little too
not-smart to me.  It seems like it's not all that hard to get bitten by 
it, and the error makes no sense unless you're familiar with the module
cleanup algorithm.

For what it's worth, I offer to help make module cleanup a little smarter,
although I may not be able to spend much time on it until I finish some
things I'm already committed to do.

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

Comment By: Alan McIntyre (alanmcintyre)
Date: 2007-05-12 20:36

Message:
Logged In: YES 
user_id=1115903
Originator: NO

Could you post the code for your entire script? It makes it a lot easier
to figure out what's going on.

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

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

From noreply at sourceforge.net  Tue May 15 22:41:21 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 15 May 2007 13:41:21 -0700
Subject: [ python-Bugs-1719423 ] Python package support not properly documented
Message-ID: <E1Ho3ph-000332-Gq@sc8-sf-web22.sourceforge.net>

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

Please note that this 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: 6
Private: No
Submitted By: Michael Abbott (araneidae)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python package support not properly documented

Initial Comment:
I can sum this report up most simply by quoting the message below:

http://mail.python.org/pipermail/python-list/2001-October/107699.html

Note that this message was posted 5 1/2 years ago (by myself, as it happens), had no follow up, and the problem referred to remains current!  (The chapter on "import" is now section 6.12: nothing else has changed.)

The comment below that "presum[ably] nothing significant has changed" seems less than probable now!

I was looking to understand modules and packages a bit better: they don't behave like proper first class objects (is module.sub_module an attribute?  not really), and so the lack of definitive documentation in this area is sad, particularly after such a long time.


Body of original message follows


Package support in Python 2

Michael Abbott michael at rcp.co.uk
Wed Oct 3 10:58:08 CEST 2001


Is there up to date documentation for package support in Python 2?

Section 6.11 of the "Python Reference Manual" has the following nice quote:


[XXX Can't be bothered to spell this out right now; see the URL http://www.python.org/doc/essays/packages.html for more details, also about how the module search works from inside a package.] 


and the referred URL documents Python 1.5.  I presume that nothing significant has changed recently, but it's certainly disconcerting for something as fundamental as module importing to not actually be part of the core language documentation!


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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-15 20:41

Message:
Logged In: YES 
user_id=849994
Originator: NO

You are certainly right that this should be documented properly.

BTW, after you import x.y, y is an attribute of module x. When you write
"x.y.foo", Python knows nothing about modules any more, it just handles
attribute access of arbitrary objects which happen to be modules.

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

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

From noreply at sourceforge.net  Wed May 16 04:34:16 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 15 May 2007 19:34:16 -0700
Subject: [ python-Bugs-1714773 ] python throws an error when unpacking bz2 file
Message-ID: <E1Ho9LE-0007X1-SW@sc8-sf-web24.sourceforge.net>

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

Please note that this 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
Private: No
Submitted By: runnig (runnig)
Assigned to: Nobody/Anonymous (nobody)
Summary: python throws an error when unpacking bz2 file

Initial Comment:
C:\work\python>c:\work\python\25\py.exe
Python 2.5 (r25:51908, Feb 13 2007, 14:33:20) [MSC v.1400 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
C:\work\python>ez_setup.py wxpython
Searching for wxpython
Reading http://cheeseshop.python.org/pypi/wxpython/
Couldn't find index page for 'wxpython' (maybe misspelled?)
Scanning index of all packages (this may take a while)
Reading http://cheeseshop.python.org/pypi/
Reading http://cheeseshop.python.org/pypi/wxPython/2.6.3.2
Reading http://wxPython.org/
Reading http://wxPython.org/download.php
Best match: wxPython src-2.8.3.0
Downloading http://prdownloads.sourceforge.net/wxpython/wxPython-src-2.8.3.0.tar.bz2
Processing wxPython-src-2.8.3.0.tar.bz2


I think, when unpacking bz2, an error occurs and windows shows an error about 
"python.exe has encountered a problem and needs to close"


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

Comment By: Alan McIntyre (alanmcintyre)
Date: 2007-05-15 21:34

Message:
Logged In: YES 
user_id=1115903
Originator: NO

Well, this problem doesn't seem to occur on my Windows XP Pro (SP2)
machine for 2.5.1 (both the "official" build and one I built locally). 
It's going to be a week or two before I'll be able to get back to the one
machine on which it crashes.  If the original poster can provide any
additional information (crash logs, etc) before then I'll try to have a
look.

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

Comment By: Alan McIntyre (alanmcintyre)
Date: 2007-05-14 11:53

Message:
Logged In: YES 
user_id=1115903
Originator: NO

I downloaded the file from the URL given above, and when I tried to
decompress it in a single shot (with bz2.decompress), python crashes. 
Reading the raw bz2 data from file into a string in memory works ok, but
attempting to use bz2.decompress on that data causes the crash.

I could only get this to happen under 2.5.1 on a Windows XP machine (media
center edition); it seems to work ok on OSX (Python 2.5) and Linux (both
2.4.4 and the current trunk).  I will be able to take a closer look at this
tomorrow when I have access to a Windows machine with a compiler on it.



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

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-13 02:54

Message:
Logged In: YES 
user_id=849994
Originator: NO

Can you try to take the .tar.bz2 file and unpack it yourself using
Python's bz2 module?
We can then find out where exactly the segfault occurs.

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

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

From noreply at sourceforge.net  Wed May 16 06:54:26 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 15 May 2007 21:54:26 -0700
Subject: [ python-Bugs-1714773 ] python throws an error when unpacking bz2 file
Message-ID: <E1HoBWs-00034R-BD@sc8-sf-web23.sourceforge.net>

Bugs item #1714773, was opened at 2007-05-08 17:23
Message generated for change (Comment added) made by runnig
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1714773&group_id=5470

Please note that this 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
Private: No
Submitted By: runnig (runnig)
Assigned to: Nobody/Anonymous (nobody)
Summary: python throws an error when unpacking bz2 file

Initial Comment:
C:\work\python>c:\work\python\25\py.exe
Python 2.5 (r25:51908, Feb 13 2007, 14:33:20) [MSC v.1400 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
C:\work\python>ez_setup.py wxpython
Searching for wxpython
Reading http://cheeseshop.python.org/pypi/wxpython/
Couldn't find index page for 'wxpython' (maybe misspelled?)
Scanning index of all packages (this may take a while)
Reading http://cheeseshop.python.org/pypi/
Reading http://cheeseshop.python.org/pypi/wxPython/2.6.3.2
Reading http://wxPython.org/
Reading http://wxPython.org/download.php
Best match: wxPython src-2.8.3.0
Downloading http://prdownloads.sourceforge.net/wxpython/wxPython-src-2.8.3.0.tar.bz2
Processing wxPython-src-2.8.3.0.tar.bz2


I think, when unpacking bz2, an error occurs and windows shows an error about 
"python.exe has encountered a problem and needs to close"


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

>Comment By: runnig (runnig)
Date: 2007-05-16 13:54

Message:
Logged In: YES 
user_id=1729909
Originator: YES

i've downloaded file wxPython-src-2.8.4.0.tar.bz2 manually and wrote a
test script:
----------
import bz2

arch = bz2.BZ2File( 'wxPython-src-2.8.4.0.tar.bz2','r' )
lines = arch.readlines()
----------
as i can understand, python crashes right after start of reading this bz2
file

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

Comment By: Alan McIntyre (alanmcintyre)
Date: 2007-05-16 11:34

Message:
Logged In: YES 
user_id=1115903
Originator: NO

Well, this problem doesn't seem to occur on my Windows XP Pro (SP2)
machine for 2.5.1 (both the "official" build and one I built locally). 
It's going to be a week or two before I'll be able to get back to the one
machine on which it crashes.  If the original poster can provide any
additional information (crash logs, etc) before then I'll try to have a
look.

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

Comment By: Alan McIntyre (alanmcintyre)
Date: 2007-05-15 01:53

Message:
Logged In: YES 
user_id=1115903
Originator: NO

I downloaded the file from the URL given above, and when I tried to
decompress it in a single shot (with bz2.decompress), python crashes. 
Reading the raw bz2 data from file into a string in memory works ok, but
attempting to use bz2.decompress on that data causes the crash.

I could only get this to happen under 2.5.1 on a Windows XP machine (media
center edition); it seems to work ok on OSX (Python 2.5) and Linux (both
2.4.4 and the current trunk).  I will be able to take a closer look at this
tomorrow when I have access to a Windows machine with a compiler on it.



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

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-13 16:54

Message:
Logged In: YES 
user_id=849994
Originator: NO

Can you try to take the .tar.bz2 file and unpack it yourself using
Python's bz2 module?
We can then find out where exactly the segfault occurs.

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

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

From noreply at sourceforge.net  Wed May 16 11:25:44 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 16 May 2007 02:25:44 -0700
Subject: [ python-Bugs-1467619 ] Header.decode_header eats up spaces
Message-ID: <E1HoFlQ-0003G9-TC@sc8-sf-web24.sourceforge.net>

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

Please note that this message will contain a full 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
Private: No
Submitted By: Mathieu Goutelle (mgoutell)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Header.decode_header eats up spaces

Initial Comment:
The Header.decode_header function eats up spaces in
non-encoded part of a header.

See the following source:
# -*- coding: iso-8859-1 -*-
from email.Header import Header, decode_header
h = Header('Essai ', None)
h.append('??', 'iso-8859-1')
print h
print decode_header(h)

This prints:
Essai =?iso-8859-1?q?=E9=E8?=
[('Test', None), ('\xe9\xe8', 'iso-8859-1')]

This should print:
Essai =?iso-8859-1?q?=E9=E8?=
[('Test ', None), ('\xe9\xe8', 'iso-8859-1')]
       ^ This space disappears

This appears in Python 2.3 but the source code of the
function didn't change in 2.4 so the same problem
should still exist. Bug "[ 1372770 ] email.Header
should preserve original FWS" may be linked to that one
although I'm not sure this is exactly the same.

This patch (not extensively tested though) seems to
solve this problem:

--- /usr/lib/python2.3/email/Header.py  2005-09-05
00:20:03.000000000 +0200
+++ Header.py   2006-04-10 12:27:27.000000000 +0200
@@ -90,7 +90,7 @@
             continue
         parts = ecre.split(line)
         while parts:
-            unenc = parts.pop(0).strip()
+            unenc = parts.pop(0).rstrip()
             if unenc:
                 # Should we continue a long line?
                 if decoded and decoded[-1][1] is None:


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

>Comment By: Mathieu Goutelle (mgoutell)
Date: 2007-05-16 11:25

Message:
Logged In: YES 
user_id=719862
Originator: YES

Hello,
Any news about this bug. It seems still there in 2.5 after a one year
notice...
Regards,

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

Comment By: Alexander Schremmer (alexanderweb)
Date: 2006-05-13 00:28

Message:
Logged In: YES 
user_id=254738

I can confirm this bug and have been bitten by it as well.

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

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

From noreply at sourceforge.net  Wed May 16 11:32:20 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 16 May 2007 02:32:20 -0700
Subject: [ python-Bugs-1719898 ] tarfile stops expanding with long filenames
Message-ID: <E1HoFro-0005by-AG@sc8-sf-web24.sourceforge.net>

Bugs item #1719898, was opened at 2007-05-16 09: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=1719898&group_id=5470

Please note that this message will contain a full 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
Private: No
Submitted By: Christian Zagrodnick (zagy)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile stops expanding with long filenames

Initial Comment:
The tarfile module fixes an issue with "Some old tar programs represent a directory as a regular file with a trailing slash.":

    if tarinfo.isreg() and tarinfo.name.endswith("/"):
        tarinfo.type = DIRTYPE

*After* that the full filename is composed. The chars >100 are stored in "prefix":

    if tarinfo.type != GNUTYPE_SPARSE:
        tarinfo.name normpath(os.path.join(nts(tarinfo.prefix), tarinfo.name))


So guess what happens if you filename has a / at the 100th character. Right, its considered a directory. Since directories have no data, the next metadata block is read from your file data which fails in various ways.

Patch attached.

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

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

From noreply at sourceforge.net  Wed May 16 12:55:39 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 16 May 2007 03:55:39 -0700
Subject: [ python-Bugs-1719933 ] No docs for PyEval_EvalCode and related
	functions
Message-ID: <E1HoHAR-0006Ep-S9@sc8-sf-web24.sourceforge.net>

Bugs item #1719933, was opened at 2007-05-16 10: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=1719933&group_id=5470

Please note that this 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
Private: No
Submitted By: Joseph Eagar (joeedh)
Assigned to: Nobody/Anonymous (nobody)
Summary: No docs for PyEval_EvalCode and related functions

Initial Comment:
Hi.  There's no documentation for PyEval_EvalCode and related functions.

Joe

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

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

From noreply at sourceforge.net  Wed May 16 13:19:01 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 16 May 2007 04:19:01 -0700
Subject: [ python-Bugs-1717900 ] Destructor behavior faulty
Message-ID: <E1HoHX3-0005O9-H0@sc8-sf-web22.sourceforge.net>

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

Please note that this message 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: Pending
Resolution: None
Priority: 5
Private: No
Submitted By: Wolf Rogner (wrogner)
Assigned to: Nobody/Anonymous (nobody)
Summary: Destructor behavior faulty

Initial Comment:
I tried example 11.4. from bytesofpython (by C.H. Swaroop).
Example works fine.

Added a new Person instance 'wolf' -> Program terminated with:
Exception exceptions.AttributeError: "'NoneType' object has no attribute 'population'" in <bound method Person.__del__ of <__main__.Person instance at 0xb7d48d6c>> ignored

added print list(globals()) ->
['kalam', '__builtins__', '__file__', 'DBGPHideChildren', 'swaroop', 'Person', 'wolf', '__name__', '__doc__']

changed wolf to aaa:

print list(globals()) ->
['aaa', 'kalam', '__builtins__', '__file__', 'DBGPHideChildren', 'swaroop', 'Person', '__name__', '__doc__']

Please note the position of 'aaa' at the beginning of the list, before 'Person'. With 'wolf' being after 'Person'.

If the destructing code removes items in this order, no wonder I get an error.

Person should not get deleted if refcount is still > 0.

Wolf Rogner


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

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-16 08:19

Message:
Logged In: YES 
user_id=479790
Originator: NO

FWIW, the script name appears to be relevant as well. I were going to say
that I could not reproduce it as it was; this same example saved as "a.py"
doesn't show the error; "w.py" does.

To the OP: Module finalization is a fragile step; this is a long standing
issue and could be improved, but anyway I don't think it can be made robust
enough (this is just my opinion!). I usually try to *never* reference any
globals in destructors. In this case, using self.__class__ instead of
Person is safer and works fine; if other globals were needed they could be
passed as default argument values.

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

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-15 15:44

Message:
Logged In: YES 
user_id=479790
Originator: NO

FWIW, the script name appears to be relevant as well. I were going to say
that I could not reproduce it as it was; this same example saved as "a.py"
doesn't show the error; "w.py" does.

To the OP: Module finalization is a fragile step; this is a long standing
issue and could be improved, but anyway I don't think it can be made robust
enough (this is just my opinion!). I usually try to *never* reference any
globals in destructors. In this case, using self.__class__ instead of
Person is safer and works fine; if other globals were needed they could be
passed as default argument values.

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

Comment By: Alan McIntyre (alanmcintyre)
Date: 2007-05-14 12:38

Message:
Logged In: YES 
user_id=1115903
Originator: NO

I took the example mentioned from here: 
    http://www.python.org/doc/essays/cleanup/

and added this line to the end:

wolf = Person('wolf')

and it gives the reported error.  Here is a minimal snippet that produces
the same error when executed as the top-level module:

class Person:
        population = 0
        def __del__(self):
                Person.population -= 1

wolf = Person()


This appears to be consistent with the behavior described here:
     http://www.python.org/doc/essays/cleanup/

While I understand that cleaning up a module at exit time is probably not
an easy thing to make arbitrarily smart, this behavior seems a little too
not-smart to me.  It seems like it's not all that hard to get bitten by 
it, and the error makes no sense unless you're familiar with the module
cleanup algorithm.

For what it's worth, I offer to help make module cleanup a little smarter,
although I may not be able to spend much time on it until I finish some
things I'm already committed to do.

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

Comment By: Alan McIntyre (alanmcintyre)
Date: 2007-05-12 20:36

Message:
Logged In: YES 
user_id=1115903
Originator: NO

Could you post the code for your entire script? It makes it a lot easier
to figure out what's going on.

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

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

From noreply at sourceforge.net  Wed May 16 14:47:22 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 16 May 2007 05:47:22 -0700
Subject: [ python-Bugs-1719898 ] tarfile stops expanding with long filenames
Message-ID: <E1HoIuY-0005sP-HA@sc8-sf-web21.sourceforge.net>

Bugs item #1719898, was opened at 2007-05-16 11:32
Message generated for change (Settings changed) made by gustaebel
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1719898&group_id=5470

Please note that this message will contain a full 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
Private: No
Submitted By: Christian Zagrodnick (zagy)
>Assigned to: Lars Gust?bel (gustaebel)
Summary: tarfile stops expanding with long filenames

Initial Comment:
The tarfile module fixes an issue with "Some old tar programs represent a directory as a regular file with a trailing slash.":

    if tarinfo.isreg() and tarinfo.name.endswith("/"):
        tarinfo.type = DIRTYPE

*After* that the full filename is composed. The chars >100 are stored in "prefix":

    if tarinfo.type != GNUTYPE_SPARSE:
        tarinfo.name normpath(os.path.join(nts(tarinfo.prefix), tarinfo.name))


So guess what happens if you filename has a / at the 100th character. Right, its considered a directory. Since directories have no data, the next metadata block is read from your file data which fails in various ways.

Patch attached.

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

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

From noreply at sourceforge.net  Wed May 16 14:51:48 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 16 May 2007 05:51:48 -0700
Subject: [ python-Bugs-1467619 ] Header.decode_header eats up spaces
Message-ID: <E1HoIyq-00027M-Sp@sc8-sf-web24.sourceforge.net>

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

Please note that this message will contain a full 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
Private: No
Submitted By: Mathieu Goutelle (mgoutell)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Header.decode_header eats up spaces

Initial Comment:
The Header.decode_header function eats up spaces in
non-encoded part of a header.

See the following source:
# -*- coding: iso-8859-1 -*-
from email.Header import Header, decode_header
h = Header('Essai ', None)
h.append('??', 'iso-8859-1')
print h
print decode_header(h)

This prints:
Essai =?iso-8859-1?q?=E9=E8?=
[('Test', None), ('\xe9\xe8', 'iso-8859-1')]

This should print:
Essai =?iso-8859-1?q?=E9=E8?=
[('Test ', None), ('\xe9\xe8', 'iso-8859-1')]
       ^ This space disappears

This appears in Python 2.3 but the source code of the
function didn't change in 2.4 so the same problem
should still exist. Bug "[ 1372770 ] email.Header
should preserve original FWS" may be linked to that one
although I'm not sure this is exactly the same.

This patch (not extensively tested though) seems to
solve this problem:

--- /usr/lib/python2.3/email/Header.py  2005-09-05
00:20:03.000000000 +0200
+++ Header.py   2006-04-10 12:27:27.000000000 +0200
@@ -90,7 +90,7 @@
             continue
         parts = ecre.split(line)
         while parts:
-            unenc = parts.pop(0).strip()
+            unenc = parts.pop(0).rstrip()
             if unenc:
                 # Should we continue a long line?
                 if decoded and decoded[-1][1] is None:


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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-16 12:51

Message:
Logged In: YES 
user_id=849994
Originator: NO

I propose the attached patch. RFC 2047 specifies to ignore whitespace
between encoded-words, but IMHO not between ordinary text and
encoded-words.
File Added: emailheader.diff

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

Comment By: Mathieu Goutelle (mgoutell)
Date: 2007-05-16 09:25

Message:
Logged In: YES 
user_id=719862
Originator: YES

Hello,
Any news about this bug. It seems still there in 2.5 after a one year
notice...
Regards,

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

Comment By: Alexander Schremmer (alexanderweb)
Date: 2006-05-12 22:28

Message:
Logged In: YES 
user_id=254738

I can confirm this bug and have been bitten by it as well.

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

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

From noreply at sourceforge.net  Wed May 16 15:08:32 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 16 May 2007 06:08:32 -0700
Subject: [ python-Bugs-1467619 ] Header.decode_header eats up spaces
Message-ID: <E1HoJF2-0003y4-Vz@sc8-sf-web24.sourceforge.net>

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

Please note that this message will contain a full 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
Private: No
Submitted By: Mathieu Goutelle (mgoutell)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Header.decode_header eats up spaces

Initial Comment:
The Header.decode_header function eats up spaces in
non-encoded part of a header.

See the following source:
# -*- coding: iso-8859-1 -*-
from email.Header import Header, decode_header
h = Header('Essai ', None)
h.append('??', 'iso-8859-1')
print h
print decode_header(h)

This prints:
Essai =?iso-8859-1?q?=E9=E8?=
[('Test', None), ('\xe9\xe8', 'iso-8859-1')]

This should print:
Essai =?iso-8859-1?q?=E9=E8?=
[('Test ', None), ('\xe9\xe8', 'iso-8859-1')]
       ^ This space disappears

This appears in Python 2.3 but the source code of the
function didn't change in 2.4 so the same problem
should still exist. Bug "[ 1372770 ] email.Header
should preserve original FWS" may be linked to that one
although I'm not sure this is exactly the same.

This patch (not extensively tested though) seems to
solve this problem:

--- /usr/lib/python2.3/email/Header.py  2005-09-05
00:20:03.000000000 +0200
+++ Header.py   2006-04-10 12:27:27.000000000 +0200
@@ -90,7 +90,7 @@
             continue
         parts = ecre.split(line)
         while parts:
-            unenc = parts.pop(0).strip()
+            unenc = parts.pop(0).rstrip()
             if unenc:
                 # Should we continue a long line?
                 if decoded and decoded[-1][1] is None:


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

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2007-05-16 09:08

Message:
Logged In: YES 
user_id=12800
Originator: NO

IIRC, I tried the OP's patch and it broke too many of the email package's
test suite.  I made an attempt at fixing the problem to be much more RFC
compliant, but couldn't get the test suite to pass completely.  This points
to a much deeper problem with email package header management.  I don't
think the problem is a bug, I think it's a design flaw.


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

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-16 08:51

Message:
Logged In: YES 
user_id=849994
Originator: NO

I propose the attached patch. RFC 2047 specifies to ignore whitespace
between encoded-words, but IMHO not between ordinary text and
encoded-words.
File Added: emailheader.diff

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

Comment By: Mathieu Goutelle (mgoutell)
Date: 2007-05-16 05:25

Message:
Logged In: YES 
user_id=719862
Originator: YES

Hello,
Any news about this bug. It seems still there in 2.5 after a one year
notice...
Regards,

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

Comment By: Alexander Schremmer (alexanderweb)
Date: 2006-05-12 18:28

Message:
Logged In: YES 
user_id=254738

I can confirm this bug and have been bitten by it as well.

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

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

From noreply at sourceforge.net  Wed May 16 15:12:17 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 16 May 2007 06:12:17 -0700
Subject: [ python-Bugs-1719995 ] sets module documentation: example uses
	deprecated method
Message-ID: <E1HoJIf-0000w7-QT@sc8-sf-web23.sourceforge.net>

Bugs item #1719995, was opened at 2007-05-16 15: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=1719995&group_id=5470

Please note that this 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
Private: No
Submitted By: Jens Quade (snejsource)
Assigned to: Nobody/Anonymous (nobody)
Summary: sets module documentation: example uses deprecated method

Initial Comment:
In 5.7.1 the text deprecates the use of .union_update in favour of .update (Last sentence)

http://docs.python.org/lib/set-objects.html


The example in 5.7.2 still uses union_update.

http://docs.python.org/lib/set-example.html

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

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

From noreply at sourceforge.net  Wed May 16 15:32:51 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 16 May 2007 06:32:51 -0700
Subject: [ python-Bugs-1719898 ] tarfile stops expanding with long filenames
Message-ID: <E1HoJcZ-00064Z-QX@sc8-sf-web22.sourceforge.net>

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

Please note that this message will contain a full 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
Private: No
Submitted By: Christian Zagrodnick (zagy)
Assigned to: Lars Gust?bel (gustaebel)
Summary: tarfile stops expanding with long filenames

Initial Comment:
The tarfile module fixes an issue with "Some old tar programs represent a directory as a regular file with a trailing slash.":

    if tarinfo.isreg() and tarinfo.name.endswith("/"):
        tarinfo.type = DIRTYPE

*After* that the full filename is composed. The chars >100 are stored in "prefix":

    if tarinfo.type != GNUTYPE_SPARSE:
        tarinfo.name normpath(os.path.join(nts(tarinfo.prefix), tarinfo.name))


So guess what happens if you filename has a / at the 100th character. Right, its considered a directory. Since directories have no data, the next metadata block is read from your file data which fails in various ways.

Patch attached.

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

>Comment By: Lars Gust?bel (gustaebel)
Date: 2007-05-16 15:32

Message:
Logged In: YES 
user_id=642936
Originator: NO

Did you also test Python 2.5? If this error occurs with that version too
(which it should not), please attach a small test tar archive to this
tracker item.

Python 2.4 is no longer maintained, sorry.

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

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

From noreply at sourceforge.net  Wed May 16 15:44:39 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 16 May 2007 06:44:39 -0700
Subject: [ python-Bugs-1719995 ] sets module documentation: example uses
	deprecated method
Message-ID: <E1HoJnz-0004m3-CE@sc8-sf-web21.sourceforge.net>

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

Please note that this 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
Private: No
Submitted By: Jens Quade (snejsource)
Assigned to: Nobody/Anonymous (nobody)
Summary: sets module documentation: example uses deprecated method

Initial Comment:
In 5.7.1 the text deprecates the use of .union_update in favour of .update (Last sentence)

http://docs.python.org/lib/set-objects.html


The example in 5.7.2 still uses union_update.

http://docs.python.org/lib/set-example.html

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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-16 13:44

Message:
Logged In: YES 
user_id=849994
Originator: NO

Thanks for the report, fixed in rev. 55383, 55384 (2.5).

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

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

From noreply at sourceforge.net  Wed May 16 17:47:10 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 16 May 2007 08:47:10 -0700
Subject: [ python-Bugs-1668596 ] distutils chops the first character of
	filenames
Message-ID: <E1HoLiY-0005dz-4x@sc8-sf-web23.sourceforge.net>

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

Please note that this 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
Private: No
Submitted By: Sam Pointon (freecondiments)
Assigned to: Nobody/Anonymous (nobody)
Summary: distutils chops the first character of filenames

Initial Comment:
Python 2.5c1, Windows XP SP2.

distutils chops the first character from some filenames if the package_data key is ''.

Minimal example:
The setup.py attached, and a directory named 'doc' in the same directory as setup.py with files in it. Running "python setup.py bdist" triggers the error.

On my box, this fails with:
running bdist
running bdist_dumb
running build
running build_py
error: can't copy 'oc\architecture.rst': doesn't exist or not a regular file

http://mail.python.org/pipermail/distutils-sig/2005-April/004453.html 
describes the same problem, and http://mail.python.org/pipermail/distutils-sig/2005-April/004458.html has a commentary on the code in distutils/commands/build_py.py which causes the error.

On lines 117-122, it tries to chop the directory path from the files it has found, using len() and slicing. This job is better done by os.path.split (and is probably more portable, too).

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-16 11:47

Message:
Logged In: YES 
user_id=984087
Originator: NO


After reading the distutils example section today, I did find one example
using null string as package_dir value. So there may be something to this
bug after all.

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-03-27 12:19

Message:
Logged In: YES 
user_id=984087
Originator: NO


Hi,

I reproduced the problem with the latest build on linux. The "fix" may be
trivial but I am not entirely sure if there is a problem in the first
place. The distutils document does not mention about having null value for
package_dir as is the case in your setup.py. I may be missing something
here but can you please explain the conclusion that "" is a perfectly valid
value for package_dir (as mentioned in one of the threads in mailing list)?
I am assuming that you mean "distribution root" directory by "". If this is
found to be valid usage, the  document should be updated along with the
code fix. Otherwise, a check can be put in to disallow null values. 

Raghu.




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

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

From noreply at sourceforge.net  Wed May 16 21:38:54 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 16 May 2007 12:38:54 -0700
Subject: [ python-Bugs-1720241 ] Compiler is not thread safe?
Message-ID: <E1HoPKo-00082Y-MN@sc8-sf-web21.sourceforge.net>

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

Please note that this 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
Private: No
Submitted By: ??PC?? (zpcz)
Assigned to: Nobody/Anonymous (nobody)
Summary: Compiler is not thread safe?

Initial Comment:
r = '''
a(b(c[d]))
'''
from threading import Thread
from compiler import parse
Thread(target = parse, args = (r,)).start()

leads to 
Bus error (core dumped)

When runs not in thread everything is OK.
OS FreeBSD 5.4.
Python 2.5.1 (seems that 2.5 also has this error)
(Runs perfectly on Linux, and on FreeBSD with Python 2.4)

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

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

From noreply at sourceforge.net  Wed May 16 21:46:29 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 16 May 2007 12:46:29 -0700
Subject: [ python-Bugs-1720250 ] PyGILState_Ensure does not acquires GIL
Message-ID: <E1HoPS9-00025R-4N@sc8-sf-web22.sourceforge.net>

Bugs item #1720250, was opened at 2007-05-16 19: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=1720250&group_id=5470

Please note that this message 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
Private: No
Submitted By: Kuno Ospald (kunoospald)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyGILState_Ensure does not acquires GIL

Initial Comment:
The function PyGILState_Ensure doesn't acquire the GIL if current thread state is valid. In contrast to that PyGILState_Release deletes the thread state (PyThreadState_DeleteCurrent) which releases the GIL which got not acquired before (=> mutex->owned = -2).

Here is an example which locks at PyRun_SimpleString:

// initialize the Python interpreter
Py_Initialize();

PyEval_InitThreads();

// release the GIL as PyEval_InitThreads 
// implicitly acquires the GIL
PyEval_ReleaseLock();

PyGILState_STATE gstate;
gstate = PyGILState_Ensure();

PyRun_SimpleString("import random\n");

PyGILState_Release(gstate); 

In that simple example the problem can be fixed by removing the call to PyEval_ReleaseLock. But that is needed for applications that call into the interpreter from multiple threads. 

The only solution I could found up to that point is the following:

// initialize the Python interpreter
Py_Initialize();

PyEval_InitThreads();

PyThreadState* tcur = PyThreadState_Get() ;

PyThreadState_Swap(NULL);
PyThreadState_Clear(tcur);
PyThreadState_Delete(tcur);

// release the GIL as PyEval_InitThreads 
// implicitly acquires the GIL
PyEval_ReleaseLock();

PyGILState_STATE gstate;
gstate = PyGILState_Ensure();

PyRun_SimpleString("import random\n");

PyGILState_Release(gstate);

Which seems to works fine. But I think that this behavior of PyGILState_Ensure should be either documented or fixed.

Thanks,
Kuno



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

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

From noreply at sourceforge.net  Thu May 17 00:06:29 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 16 May 2007 15:06:29 -0700
Subject: [ python-Bugs-1717900 ] Destructor behavior faulty
Message-ID: <E1HoRdd-0007O2-KJ@sc8-sf-web23.sourceforge.net>

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

Please note that this message 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: Pending
Resolution: None
Priority: 5
Private: No
Submitted By: Wolf Rogner (wrogner)
Assigned to: Nobody/Anonymous (nobody)
Summary: Destructor behavior faulty

Initial Comment:
I tried example 11.4. from bytesofpython (by C.H. Swaroop).
Example works fine.

Added a new Person instance 'wolf' -> Program terminated with:
Exception exceptions.AttributeError: "'NoneType' object has no attribute 'population'" in <bound method Person.__del__ of <__main__.Person instance at 0xb7d48d6c>> ignored

added print list(globals()) ->
['kalam', '__builtins__', '__file__', 'DBGPHideChildren', 'swaroop', 'Person', 'wolf', '__name__', '__doc__']

changed wolf to aaa:

print list(globals()) ->
['aaa', 'kalam', '__builtins__', '__file__', 'DBGPHideChildren', 'swaroop', 'Person', '__name__', '__doc__']

Please note the position of 'aaa' at the beginning of the list, before 'Person'. With 'wolf' being after 'Person'.

If the destructing code removes items in this order, no wonder I get an error.

Person should not get deleted if refcount is still > 0.

Wolf Rogner


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

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-16 19:06

Message:
Logged In: YES 
user_id=479790
Originator: NO

FWIW, the script name appears to be relevant as well. I were going to say
that I could not reproduce it as it was; this same example saved as "a.py"
doesn't show the error; "w.py" does.

To the OP: Module finalization is a fragile step; this is a long standing
issue and could be improved, but anyway I don't think it can be made robust
enough (this is just my opinion!). I usually try to *never* reference any
globals in destructors. In this case, using self.__class__ instead of
Person is safer and works fine; if other globals were needed they could be
passed as default argument values.

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

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-16 08:19

Message:
Logged In: YES 
user_id=479790
Originator: NO

FWIW, the script name appears to be relevant as well. I were going to say
that I could not reproduce it as it was; this same example saved as "a.py"
doesn't show the error; "w.py" does.

To the OP: Module finalization is a fragile step; this is a long standing
issue and could be improved, but anyway I don't think it can be made robust
enough (this is just my opinion!). I usually try to *never* reference any
globals in destructors. In this case, using self.__class__ instead of
Person is safer and works fine; if other globals were needed they could be
passed as default argument values.

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

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-15 15:44

Message:
Logged In: YES 
user_id=479790
Originator: NO

FWIW, the script name appears to be relevant as well. I were going to say
that I could not reproduce it as it was; this same example saved as "a.py"
doesn't show the error; "w.py" does.

To the OP: Module finalization is a fragile step; this is a long standing
issue and could be improved, but anyway I don't think it can be made robust
enough (this is just my opinion!). I usually try to *never* reference any
globals in destructors. In this case, using self.__class__ instead of
Person is safer and works fine; if other globals were needed they could be
passed as default argument values.

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

Comment By: Alan McIntyre (alanmcintyre)
Date: 2007-05-14 12:38

Message:
Logged In: YES 
user_id=1115903
Originator: NO

I took the example mentioned from here: 
    http://www.python.org/doc/essays/cleanup/

and added this line to the end:

wolf = Person('wolf')

and it gives the reported error.  Here is a minimal snippet that produces
the same error when executed as the top-level module:

class Person:
        population = 0
        def __del__(self):
                Person.population -= 1

wolf = Person()


This appears to be consistent with the behavior described here:
     http://www.python.org/doc/essays/cleanup/

While I understand that cleaning up a module at exit time is probably not
an easy thing to make arbitrarily smart, this behavior seems a little too
not-smart to me.  It seems like it's not all that hard to get bitten by 
it, and the error makes no sense unless you're familiar with the module
cleanup algorithm.

For what it's worth, I offer to help make module cleanup a little smarter,
although I may not be able to spend much time on it until I finish some
things I'm already committed to do.

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

Comment By: Alan McIntyre (alanmcintyre)
Date: 2007-05-12 20:36

Message:
Logged In: YES 
user_id=1115903
Originator: NO

Could you post the code for your entire script? It makes it a lot easier
to figure out what's going on.

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

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

From noreply at sourceforge.net  Thu May 17 00:58:30 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 16 May 2007 15:58:30 -0700
Subject: [ python-Bugs-1717900 ] Destructor behavior faulty
Message-ID: <E1HoSRy-0003k5-6l@sc8-sf-web22.sourceforge.net>

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

Please note that this message 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: Pending
Resolution: None
Priority: 5
Private: No
Submitted By: Wolf Rogner (wrogner)
Assigned to: Nobody/Anonymous (nobody)
Summary: Destructor behavior faulty

Initial Comment:
I tried example 11.4. from bytesofpython (by C.H. Swaroop).
Example works fine.

Added a new Person instance 'wolf' -> Program terminated with:
Exception exceptions.AttributeError: "'NoneType' object has no attribute 'population'" in <bound method Person.__del__ of <__main__.Person instance at 0xb7d48d6c>> ignored

added print list(globals()) ->
['kalam', '__builtins__', '__file__', 'DBGPHideChildren', 'swaroop', 'Person', 'wolf', '__name__', '__doc__']

changed wolf to aaa:

print list(globals()) ->
['aaa', 'kalam', '__builtins__', '__file__', 'DBGPHideChildren', 'swaroop', 'Person', '__name__', '__doc__']

Please note the position of 'aaa' at the beginning of the list, before 'Person'. With 'wolf' being after 'Person'.

If the destructing code removes items in this order, no wonder I get an error.

Person should not get deleted if refcount is still > 0.

Wolf Rogner


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

Comment By: Alan McIntyre (alanmcintyre)
Date: 2007-05-16 17:58

Message:
Logged In: YES 
user_id=1115903
Originator: NO

I tried out a simple change (to the trunk) in _PyModule_Clear to prevent
this particular problem.  Between the "remove everything beginning with an
underscore" and the "remove everything except __builtins__" steps, I added
a step to remove all instance objects in the module's dictionary.  It
appears to stop this problem and passes the regression test suite.  I can
post it as a patch if this seems like a reasonable change to make. 

Also, I noticed that earlier I posted the wrong link for the location of
the example code; it should have been:
     http://www.dpawson.co.uk/bop/byteofpython_120.txt

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

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-16 17:06

Message:
Logged In: YES 
user_id=479790
Originator: NO

FWIW, the script name appears to be relevant as well. I were going to say
that I could not reproduce it as it was; this same example saved as "a.py"
doesn't show the error; "w.py" does.

To the OP: Module finalization is a fragile step; this is a long standing
issue and could be improved, but anyway I don't think it can be made robust
enough (this is just my opinion!). I usually try to *never* reference any
globals in destructors. In this case, using self.__class__ instead of
Person is safer and works fine; if other globals were needed they could be
passed as default argument values.

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

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-16 06:19

Message:
Logged In: YES 
user_id=479790
Originator: NO

FWIW, the script name appears to be relevant as well. I were going to say
that I could not reproduce it as it was; this same example saved as "a.py"
doesn't show the error; "w.py" does.

To the OP: Module finalization is a fragile step; this is a long standing
issue and could be improved, but anyway I don't think it can be made robust
enough (this is just my opinion!). I usually try to *never* reference any
globals in destructors. In this case, using self.__class__ instead of
Person is safer and works fine; if other globals were needed they could be
passed as default argument values.

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

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-15 13:44

Message:
Logged In: YES 
user_id=479790
Originator: NO

FWIW, the script name appears to be relevant as well. I were going to say
that I could not reproduce it as it was; this same example saved as "a.py"
doesn't show the error; "w.py" does.

To the OP: Module finalization is a fragile step; this is a long standing
issue and could be improved, but anyway I don't think it can be made robust
enough (this is just my opinion!). I usually try to *never* reference any
globals in destructors. In this case, using self.__class__ instead of
Person is safer and works fine; if other globals were needed they could be
passed as default argument values.

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

Comment By: Alan McIntyre (alanmcintyre)
Date: 2007-05-14 10:38

Message:
Logged In: YES 
user_id=1115903
Originator: NO

I took the example mentioned from here: 
    http://www.python.org/doc/essays/cleanup/

and added this line to the end:

wolf = Person('wolf')

and it gives the reported error.  Here is a minimal snippet that produces
the same error when executed as the top-level module:

class Person:
        population = 0
        def __del__(self):
                Person.population -= 1

wolf = Person()


This appears to be consistent with the behavior described here:
     http://www.python.org/doc/essays/cleanup/

While I understand that cleaning up a module at exit time is probably not
an easy thing to make arbitrarily smart, this behavior seems a little too
not-smart to me.  It seems like it's not all that hard to get bitten by 
it, and the error makes no sense unless you're familiar with the module
cleanup algorithm.

For what it's worth, I offer to help make module cleanup a little smarter,
although I may not be able to spend much time on it until I finish some
things I'm already committed to do.

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

Comment By: Alan McIntyre (alanmcintyre)
Date: 2007-05-12 18:36

Message:
Logged In: YES 
user_id=1115903
Originator: NO

Could you post the code for your entire script? It makes it a lot easier
to figure out what's going on.

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

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

From noreply at sourceforge.net  Thu May 17 01:30:13 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 16 May 2007 16:30:13 -0700
Subject: [ python-Bugs-1720241 ] Compiler is not thread safe?
Message-ID: <E1HoSwf-0005i6-C8@sc8-sf-web24.sourceforge.net>

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

Please note that this 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
Private: No
Submitted By: ??PC?? (zpcz)
Assigned to: Nobody/Anonymous (nobody)
Summary: Compiler is not thread safe?

Initial Comment:
r = '''
a(b(c[d]))
'''
from threading import Thread
from compiler import parse
Thread(target = parse, args = (r,)).start()

leads to 
Bus error (core dumped)

When runs not in thread everything is OK.
OS FreeBSD 5.4.
Python 2.5.1 (seems that 2.5 also has this error)
(Runs perfectly on Linux, and on FreeBSD with Python 2.4)

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

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-16 20:30

Message:
Logged In: YES 
user_id=479790
Originator: NO

No problem either on Windows with 2.4.3 and 2.5 (2.5.1 untested)


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

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

From noreply at sourceforge.net  Thu May 17 10:15:50 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 17 May 2007 01:15:50 -0700
Subject: [ python-Bugs-1717900 ] Destructor behavior faulty
Message-ID: <E1Hob9K-00089U-Un@sc8-sf-web22.sourceforge.net>

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

Please note that this message 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: Pending
Resolution: None
Priority: 5
Private: No
Submitted By: Wolf Rogner (wrogner)
Assigned to: Nobody/Anonymous (nobody)
Summary: Destructor behavior faulty

Initial Comment:
I tried example 11.4. from bytesofpython (by C.H. Swaroop).
Example works fine.

Added a new Person instance 'wolf' -> Program terminated with:
Exception exceptions.AttributeError: "'NoneType' object has no attribute 'population'" in <bound method Person.__del__ of <__main__.Person instance at 0xb7d48d6c>> ignored

added print list(globals()) ->
['kalam', '__builtins__', '__file__', 'DBGPHideChildren', 'swaroop', 'Person', 'wolf', '__name__', '__doc__']

changed wolf to aaa:

print list(globals()) ->
['aaa', 'kalam', '__builtins__', '__file__', 'DBGPHideChildren', 'swaroop', 'Person', '__name__', '__doc__']

Please note the position of 'aaa' at the beginning of the list, before 'Person'. With 'wolf' being after 'Person'.

If the destructing code removes items in this order, no wonder I get an error.

Person should not get deleted if refcount is still > 0.

Wolf Rogner


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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-17 08:15

Message:
Logged In: YES 
user_id=849994
Originator: NO

Alan: you should bring that up on python-dev.

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

Comment By: Alan McIntyre (alanmcintyre)
Date: 2007-05-16 22:58

Message:
Logged In: YES 
user_id=1115903
Originator: NO

I tried out a simple change (to the trunk) in _PyModule_Clear to prevent
this particular problem.  Between the "remove everything beginning with an
underscore" and the "remove everything except __builtins__" steps, I added
a step to remove all instance objects in the module's dictionary.  It
appears to stop this problem and passes the regression test suite.  I can
post it as a patch if this seems like a reasonable change to make. 

Also, I noticed that earlier I posted the wrong link for the location of
the example code; it should have been:
     http://www.dpawson.co.uk/bop/byteofpython_120.txt

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

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-16 22:06

Message:
Logged In: YES 
user_id=479790
Originator: NO

FWIW, the script name appears to be relevant as well. I were going to say
that I could not reproduce it as it was; this same example saved as "a.py"
doesn't show the error; "w.py" does.

To the OP: Module finalization is a fragile step; this is a long standing
issue and could be improved, but anyway I don't think it can be made robust
enough (this is just my opinion!). I usually try to *never* reference any
globals in destructors. In this case, using self.__class__ instead of
Person is safer and works fine; if other globals were needed they could be
passed as default argument values.

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

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-16 11:19

Message:
Logged In: YES 
user_id=479790
Originator: NO

FWIW, the script name appears to be relevant as well. I were going to say
that I could not reproduce it as it was; this same example saved as "a.py"
doesn't show the error; "w.py" does.

To the OP: Module finalization is a fragile step; this is a long standing
issue and could be improved, but anyway I don't think it can be made robust
enough (this is just my opinion!). I usually try to *never* reference any
globals in destructors. In this case, using self.__class__ instead of
Person is safer and works fine; if other globals were needed they could be
passed as default argument values.

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

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-15 18:44

Message:
Logged In: YES 
user_id=479790
Originator: NO

FWIW, the script name appears to be relevant as well. I were going to say
that I could not reproduce it as it was; this same example saved as "a.py"
doesn't show the error; "w.py" does.

To the OP: Module finalization is a fragile step; this is a long standing
issue and could be improved, but anyway I don't think it can be made robust
enough (this is just my opinion!). I usually try to *never* reference any
globals in destructors. In this case, using self.__class__ instead of
Person is safer and works fine; if other globals were needed they could be
passed as default argument values.

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

Comment By: Alan McIntyre (alanmcintyre)
Date: 2007-05-14 15:38

Message:
Logged In: YES 
user_id=1115903
Originator: NO

I took the example mentioned from here: 
    http://www.python.org/doc/essays/cleanup/

and added this line to the end:

wolf = Person('wolf')

and it gives the reported error.  Here is a minimal snippet that produces
the same error when executed as the top-level module:

class Person:
        population = 0
        def __del__(self):
                Person.population -= 1

wolf = Person()


This appears to be consistent with the behavior described here:
     http://www.python.org/doc/essays/cleanup/

While I understand that cleaning up a module at exit time is probably not
an easy thing to make arbitrarily smart, this behavior seems a little too
not-smart to me.  It seems like it's not all that hard to get bitten by 
it, and the error makes no sense unless you're familiar with the module
cleanup algorithm.

For what it's worth, I offer to help make module cleanup a little smarter,
although I may not be able to spend much time on it until I finish some
things I'm already committed to do.

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

Comment By: Alan McIntyre (alanmcintyre)
Date: 2007-05-12 23:36

Message:
Logged In: YES 
user_id=1115903
Originator: NO

Could you post the code for your entire script? It makes it a lot easier
to figure out what's going on.

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

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

From noreply at sourceforge.net  Thu May 17 15:08:39 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 17 May 2007 06:08:39 -0700
Subject: [ python-Bugs-1720705 ] Tkinter + thread + urllib => crashes?
Message-ID: <E1Hofih-0007uU-Q0@sc8-sf-web21.sourceforge.net>

Bugs item #1720705, was opened at 2007-05-17 22: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=1720705&group_id=5470

Please note that this 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
Private: No
Submitted By: Hirokazu Yamamoto (ocean-city)
Assigned to: Nobody/Anonymous (nobody)
Summary: Tkinter + thread + urllib => crashes?

Initial Comment:
I got some experience of crash on Tkinter, so I minimized triger code. (I'll attach it as 'bug.py')
Same error happens on released python 2.5.1 binary, trunk built with VC6, and release25-maint built with VC6. (Not every time this error occurs, but frequently)

# Here is error message.

S:\python\tkinter>bug.py
Traceback (most recent call last):
  File "S:\python\tkinter\bug.py", line 13, in <module>
    raise RuntimeError()
RuntimeError
Fatal Python error: PyImport_GetModuleDict: no module dictionary!

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

# Here is stack trace. (Win2000SP4 + VC6)

NTDLL! 77f9193c()
PyImport_GetModuleDict() line 361 + 10 bytes
import_submodule(_object * 0x1e3148b8 __Py_NoneStruct, char * 0x013fe440, char * 0x013fe440) line 2357 + 5 bytes
load_next(_object * 0x1e3148b8 __Py_NoneStruct, _object * 0x1e3148b8 __Py_NoneStruct, char * * 0x013fe554, char * 0x013fe440, int * 0x013fe43c) line 2216 + 17 bytes
import_module_level(char * 0x00000000, _object * 0x008e6620, _object * 0x1e3148b8 __Py_NoneStruct, _object * 0x1e3148b8 __Py_NoneStruct, int -1) line 1997 + 35 bytes
PyImport_ImportModuleLevel(char * 0x009408cc, _object * 0x008e6620, _object * 0x1e3148b8 __Py_NoneStruct, _object * 0x1e3148b8 __Py_NoneStruct, int -1) line 2068 + 25 bytes
builtin___import__(_object * 0x00000000, _object * 0x00b0aaa0, _object * 0x00000000) line 48 + 25 bytes
PyCFunction_Call(_object * 0x008cf478, _object * 0x00b0aaa0, _object * 0x00000000) line 77 + 15 bytes
PyObject_Call(_object * 0x008cf478, _object * 0x00b0aaa0, _object * 0x00000000) line 1860 + 15 bytes
PyEval_CallObjectWithKeywords(_object * 0x008cf478, _object * 0x00b0aaa0, _object * 0x00000000) line 3434
PyEval_EvalFrameEx(_frame * 0x00a5d3e8, int 107) line 2065
fast_function(_object * 0x00000000, _object * * * 0x013fef00, int 1, int 1, int 10152296) line 3651
call_function(_object * * * 0x013fef00, int 0) line 3585 + 16 bytes
PyEval_EvalFrameEx(_frame * 0x00a706b8, int 131) line 2269
PyEval_EvalCodeEx(PyCodeObject * 0x009e80e8, _object * 0x00a706b8, _object * 0x00000002, _object * * 0x00ac86a0, int 2, _object * * 0x00ac86a8, int 0, _object * * 0x00a1ccfc, int 1, _object * 0x00000000) line 2831 + 11 bytes
fast_function(_object * 0x00000001, _object * * * 0x013ff418, int 2, int 2, int 0) line 3663 + 53 bytes
call_function(_object * * * 0x013ff418, int 0) line 3585 + 16 bytes
PyEval_EvalFrameEx(_frame * 0x00ac8528, int 131) line 2269
PyEval_EvalCodeEx(PyCodeObject * 0x009e4c88, _object * 0x00ac8528, _object * 0x00000002, _object * * 0x00a5b590, int 2, _object * * 0x00a5b598, int 0, _object * * 0x00a1cc1c, int 1, _object * 0x00000000) line 2831 + 11 bytes
fast_function(_object * 0x00000001, _object * * * 0x013ff930, int 2, int 2, int 0) line 3663 + 53 bytes
call_function(_object * * * 0x013ff930, int 0) line 3585 + 16 bytes
PyEval_EvalFrameEx(_frame * 0x00a5b440, int 131) line 2269
PyEval_EvalCodeEx(PyCodeObject * 0x009e44a8, _object * 0x00a5b440, _object * 0x00000001, _object * * 0x00a5b224, int 1, _object * * 0x00a5b228, int 0, _object * * 0x00a1e9cc, int 2, _object * 0x00000000) line 2831 + 11 bytes
fast_function(_object * 0x00000002, _object * * * 0x013ffe48, int 1, int 1, int 0) line 3663 + 53 bytes
call_function(_object * * * 0x013ffe48, int 0) line 3585 + 16 bytes
PyEval_EvalFrameEx(_frame * 0x00a5b0e0, int 131) line 2269
PyEval_EvalCodeEx(PyCodeObject * 0x009d5ce8, _object * 0x00a5b0e0, _object * 0x00000000, _object * * 0x008c104c, int 0, _object * * 0x00000000, int 0, _object * * 0x00000000, int 0, _object * 0x00000000) line 2831 + 11 bytes
function_call(_object * 0x00a2b140, _object * 0x008c1038, _object * 0x00000000) line 522 + 64 bytes
PyObject_Call(_object * 0x00a2b140, _object * 0x008c1038, _object * 0x00000000) line 1860 + 15 bytes
PyEval_CallObjectWithKeywords(_object * 0x00a2b140, _object * 0x008c1038, _object * 0x00000000) line 3434
t_bootstrap(void * 0x008c8508) line 425 + 26 bytes
bootstrap(void * 0x0022f8cc) line 179 + 7 bytes
_threadstart(void * 0x009bff78) line 187 + 13 bytes
KERNEL32! 77e5b396()


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

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

From noreply at sourceforge.net  Thu May 17 15:09:26 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 17 May 2007 06:09:26 -0700
Subject: [ python-Bugs-1720705 ] Tkinter + thread + urllib => crashes?
Message-ID: <E1HofjS-00051V-EV@sc8-sf-web24.sourceforge.net>

Bugs item #1720705, was opened at 2007-05-17 22:08
Message generated for change (Settings changed) made by ocean-city
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1720705&group_id=5470

Please note that this 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: 6
Private: No
Submitted By: Hirokazu Yamamoto (ocean-city)
Assigned to: Nobody/Anonymous (nobody)
Summary: Tkinter + thread + urllib => crashes?

Initial Comment:
I got some experience of crash on Tkinter, so I minimized triger code. (I'll attach it as 'bug.py')
Same error happens on released python 2.5.1 binary, trunk built with VC6, and release25-maint built with VC6. (Not every time this error occurs, but frequently)

# Here is error message.

S:\python\tkinter>bug.py
Traceback (most recent call last):
  File "S:\python\tkinter\bug.py", line 13, in <module>
    raise RuntimeError()
RuntimeError
Fatal Python error: PyImport_GetModuleDict: no module dictionary!

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

# Here is stack trace. (Win2000SP4 + VC6)

NTDLL! 77f9193c()
PyImport_GetModuleDict() line 361 + 10 bytes
import_submodule(_object * 0x1e3148b8 __Py_NoneStruct, char * 0x013fe440, char * 0x013fe440) line 2357 + 5 bytes
load_next(_object * 0x1e3148b8 __Py_NoneStruct, _object * 0x1e3148b8 __Py_NoneStruct, char * * 0x013fe554, char * 0x013fe440, int * 0x013fe43c) line 2216 + 17 bytes
import_module_level(char * 0x00000000, _object * 0x008e6620, _object * 0x1e3148b8 __Py_NoneStruct, _object * 0x1e3148b8 __Py_NoneStruct, int -1) line 1997 + 35 bytes
PyImport_ImportModuleLevel(char * 0x009408cc, _object * 0x008e6620, _object * 0x1e3148b8 __Py_NoneStruct, _object * 0x1e3148b8 __Py_NoneStruct, int -1) line 2068 + 25 bytes
builtin___import__(_object * 0x00000000, _object * 0x00b0aaa0, _object * 0x00000000) line 48 + 25 bytes
PyCFunction_Call(_object * 0x008cf478, _object * 0x00b0aaa0, _object * 0x00000000) line 77 + 15 bytes
PyObject_Call(_object * 0x008cf478, _object * 0x00b0aaa0, _object * 0x00000000) line 1860 + 15 bytes
PyEval_CallObjectWithKeywords(_object * 0x008cf478, _object * 0x00b0aaa0, _object * 0x00000000) line 3434
PyEval_EvalFrameEx(_frame * 0x00a5d3e8, int 107) line 2065
fast_function(_object * 0x00000000, _object * * * 0x013fef00, int 1, int 1, int 10152296) line 3651
call_function(_object * * * 0x013fef00, int 0) line 3585 + 16 bytes
PyEval_EvalFrameEx(_frame * 0x00a706b8, int 131) line 2269
PyEval_EvalCodeEx(PyCodeObject * 0x009e80e8, _object * 0x00a706b8, _object * 0x00000002, _object * * 0x00ac86a0, int 2, _object * * 0x00ac86a8, int 0, _object * * 0x00a1ccfc, int 1, _object * 0x00000000) line 2831 + 11 bytes
fast_function(_object * 0x00000001, _object * * * 0x013ff418, int 2, int 2, int 0) line 3663 + 53 bytes
call_function(_object * * * 0x013ff418, int 0) line 3585 + 16 bytes
PyEval_EvalFrameEx(_frame * 0x00ac8528, int 131) line 2269
PyEval_EvalCodeEx(PyCodeObject * 0x009e4c88, _object * 0x00ac8528, _object * 0x00000002, _object * * 0x00a5b590, int 2, _object * * 0x00a5b598, int 0, _object * * 0x00a1cc1c, int 1, _object * 0x00000000) line 2831 + 11 bytes
fast_function(_object * 0x00000001, _object * * * 0x013ff930, int 2, int 2, int 0) line 3663 + 53 bytes
call_function(_object * * * 0x013ff930, int 0) line 3585 + 16 bytes
PyEval_EvalFrameEx(_frame * 0x00a5b440, int 131) line 2269
PyEval_EvalCodeEx(PyCodeObject * 0x009e44a8, _object * 0x00a5b440, _object * 0x00000001, _object * * 0x00a5b224, int 1, _object * * 0x00a5b228, int 0, _object * * 0x00a1e9cc, int 2, _object * 0x00000000) line 2831 + 11 bytes
fast_function(_object * 0x00000002, _object * * * 0x013ffe48, int 1, int 1, int 0) line 3663 + 53 bytes
call_function(_object * * * 0x013ffe48, int 0) line 3585 + 16 bytes
PyEval_EvalFrameEx(_frame * 0x00a5b0e0, int 131) line 2269
PyEval_EvalCodeEx(PyCodeObject * 0x009d5ce8, _object * 0x00a5b0e0, _object * 0x00000000, _object * * 0x008c104c, int 0, _object * * 0x00000000, int 0, _object * * 0x00000000, int 0, _object * 0x00000000) line 2831 + 11 bytes
function_call(_object * 0x00a2b140, _object * 0x008c1038, _object * 0x00000000) line 522 + 64 bytes
PyObject_Call(_object * 0x00a2b140, _object * 0x008c1038, _object * 0x00000000) line 1860 + 15 bytes
PyEval_CallObjectWithKeywords(_object * 0x00a2b140, _object * 0x008c1038, _object * 0x00000000) line 3434
t_bootstrap(void * 0x008c8508) line 425 + 26 bytes
bootstrap(void * 0x0022f8cc) line 179 + 7 bytes
_threadstart(void * 0x009bff78) line 187 + 13 bytes
KERNEL32! 77e5b396()


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

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

From noreply at sourceforge.net  Thu May 17 15:20:44 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 17 May 2007 06:20:44 -0700
Subject: [ python-Bugs-1720726 ] docu enhancement for
	logging.handlers.SysLogHandler
Message-ID: <E1HofuO-0006F8-Uc@sc8-sf-web24.sourceforge.net>

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

Please note that this 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
Private: No
Submitted By: rhunger (rhunger)
Assigned to: Nobody/Anonymous (nobody)
Summary: docu enhancement for logging.handlers.SysLogHandler

Initial Comment:
The documentation for "logging.handlers.SysLogHandler" is somewhat incomplete. This class can be used to communicate to a local syslogd too (not only to log to a remote syslogd, or a local syslogd with enabled remote logging capabilities ("-r" option)).

The documentation on:

http://docs.python.org/lib/node417.html

for SysLogHandler([address[, facility]]) should be expanded with something like the following:

"""
If address is specified as a string, a UNIX socket is used. To log to a local syslogd "SysLogHandler(address="/dev/log")" can be used.
"""

The docstring "import logging.handlers;help(logging.handlers.SysLogHandler.__init__)" is rather short and could be replaced with above documentation.




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

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

From noreply at sourceforge.net  Thu May 17 16:49:11 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 17 May 2007 07:49:11 -0700
Subject: [ python-Bugs-1720705 ] thread + import => crashes?
Message-ID: <E1HohHz-0007dy-SA@sc8-sf-web24.sourceforge.net>

Bugs item #1720705, was opened at 2007-05-17 22:08
Message generated for change (Comment added) made by ocean-city
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1720705&group_id=5470

Please note that this 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: 6
Private: No
Submitted By: Hirokazu Yamamoto (ocean-city)
Assigned to: Nobody/Anonymous (nobody)
>Summary: thread + import => crashes?

Initial Comment:
I got some experience of crash on Tkinter, so I minimized triger code. (I'll attach it as 'bug.py')
Same error happens on released python 2.5.1 binary, trunk built with VC6, and release25-maint built with VC6. (Not every time this error occurs, but frequently)

# Here is error message.

S:\python\tkinter>bug.py
Traceback (most recent call last):
  File "S:\python\tkinter\bug.py", line 13, in <module>
    raise RuntimeError()
RuntimeError
Fatal Python error: PyImport_GetModuleDict: no module dictionary!

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

# Here is stack trace. (Win2000SP4 + VC6)

NTDLL! 77f9193c()
PyImport_GetModuleDict() line 361 + 10 bytes
import_submodule(_object * 0x1e3148b8 __Py_NoneStruct, char * 0x013fe440, char * 0x013fe440) line 2357 + 5 bytes
load_next(_object * 0x1e3148b8 __Py_NoneStruct, _object * 0x1e3148b8 __Py_NoneStruct, char * * 0x013fe554, char * 0x013fe440, int * 0x013fe43c) line 2216 + 17 bytes
import_module_level(char * 0x00000000, _object * 0x008e6620, _object * 0x1e3148b8 __Py_NoneStruct, _object * 0x1e3148b8 __Py_NoneStruct, int -1) line 1997 + 35 bytes
PyImport_ImportModuleLevel(char * 0x009408cc, _object * 0x008e6620, _object * 0x1e3148b8 __Py_NoneStruct, _object * 0x1e3148b8 __Py_NoneStruct, int -1) line 2068 + 25 bytes
builtin___import__(_object * 0x00000000, _object * 0x00b0aaa0, _object * 0x00000000) line 48 + 25 bytes
PyCFunction_Call(_object * 0x008cf478, _object * 0x00b0aaa0, _object * 0x00000000) line 77 + 15 bytes
PyObject_Call(_object * 0x008cf478, _object * 0x00b0aaa0, _object * 0x00000000) line 1860 + 15 bytes
PyEval_CallObjectWithKeywords(_object * 0x008cf478, _object * 0x00b0aaa0, _object * 0x00000000) line 3434
PyEval_EvalFrameEx(_frame * 0x00a5d3e8, int 107) line 2065
fast_function(_object * 0x00000000, _object * * * 0x013fef00, int 1, int 1, int 10152296) line 3651
call_function(_object * * * 0x013fef00, int 0) line 3585 + 16 bytes
PyEval_EvalFrameEx(_frame * 0x00a706b8, int 131) line 2269
PyEval_EvalCodeEx(PyCodeObject * 0x009e80e8, _object * 0x00a706b8, _object * 0x00000002, _object * * 0x00ac86a0, int 2, _object * * 0x00ac86a8, int 0, _object * * 0x00a1ccfc, int 1, _object * 0x00000000) line 2831 + 11 bytes
fast_function(_object * 0x00000001, _object * * * 0x013ff418, int 2, int 2, int 0) line 3663 + 53 bytes
call_function(_object * * * 0x013ff418, int 0) line 3585 + 16 bytes
PyEval_EvalFrameEx(_frame * 0x00ac8528, int 131) line 2269
PyEval_EvalCodeEx(PyCodeObject * 0x009e4c88, _object * 0x00ac8528, _object * 0x00000002, _object * * 0x00a5b590, int 2, _object * * 0x00a5b598, int 0, _object * * 0x00a1cc1c, int 1, _object * 0x00000000) line 2831 + 11 bytes
fast_function(_object * 0x00000001, _object * * * 0x013ff930, int 2, int 2, int 0) line 3663 + 53 bytes
call_function(_object * * * 0x013ff930, int 0) line 3585 + 16 bytes
PyEval_EvalFrameEx(_frame * 0x00a5b440, int 131) line 2269
PyEval_EvalCodeEx(PyCodeObject * 0x009e44a8, _object * 0x00a5b440, _object * 0x00000001, _object * * 0x00a5b224, int 1, _object * * 0x00a5b228, int 0, _object * * 0x00a1e9cc, int 2, _object * 0x00000000) line 2831 + 11 bytes
fast_function(_object * 0x00000002, _object * * * 0x013ffe48, int 1, int 1, int 0) line 3663 + 53 bytes
call_function(_object * * * 0x013ffe48, int 0) line 3585 + 16 bytes
PyEval_EvalFrameEx(_frame * 0x00a5b0e0, int 131) line 2269
PyEval_EvalCodeEx(PyCodeObject * 0x009d5ce8, _object * 0x00a5b0e0, _object * 0x00000000, _object * * 0x008c104c, int 0, _object * * 0x00000000, int 0, _object * * 0x00000000, int 0, _object * 0x00000000) line 2831 + 11 bytes
function_call(_object * 0x00a2b140, _object * 0x008c1038, _object * 0x00000000) line 522 + 64 bytes
PyObject_Call(_object * 0x00a2b140, _object * 0x008c1038, _object * 0x00000000) line 1860 + 15 bytes
PyEval_CallObjectWithKeywords(_object * 0x00a2b140, _object * 0x008c1038, _object * 0x00000000) line 3434
t_bootstrap(void * 0x008c8508) line 425 + 26 bytes
bootstrap(void * 0x0022f8cc) line 179 + 7 bytes
_threadstart(void * 0x009bff78) line 187 + 13 bytes
KERNEL32! 77e5b396()


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

>Comment By: Hirokazu Yamamoto (ocean-city)
Date: 2007-05-17 23:49

Message:
Logged In: YES 
user_id=1200846
Originator: YES

Sorry, Tkinter and urllib is not source of problem. I changed summary to
"thread + import => crashes?".

# I'll attach reproducable script as "bug.zip". please run main.py

Probabry "import" in another thread causes crash, but I'll investigate
more.
File Added: bug.zip

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

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

From noreply at sourceforge.net  Thu May 17 17:59:01 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 17 May 2007 08:59:01 -0700
Subject: [ python-Bugs-1720241 ] Compiler is not thread safe?
Message-ID: <E1HoiNZ-0006rp-PQ@sc8-sf-web24.sourceforge.net>

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

Please note that this 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
Private: No
Submitted By: ??PC?? (zpcz)
Assigned to: Nobody/Anonymous (nobody)
Summary: Compiler is not thread safe?

Initial Comment:
r = '''
a(b(c[d]))
'''
from threading import Thread
from compiler import parse
Thread(target = parse, args = (r,)).start()

leads to 
Bus error (core dumped)

When runs not in thread everything is OK.
OS FreeBSD 5.4.
Python 2.5.1 (seems that 2.5 also has this error)
(Runs perfectly on Linux, and on FreeBSD with Python 2.4)

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

>Comment By: ??PC?? (zpcz)
Date: 2007-05-17 18:59

Message:
Logged In: YES 
user_id=1395738
Originator: YES

Actually here is the simpler test cases:
r = '(((a)))'
or
r = '[[[a]]]'

info threads in GDB prints folowing:
  4 Thread 2 (LWP 100196)  0x281a02fb in pthread_testcancel () from
/usr/lib/libpthread.so.1
* 3 Thread 3 (LWP 100119)  0x28195aca in _pthread_mutex_lock () from
/usr/lib/libpthread.so.1
  2 Thread 1 (runnable)  0x28198207 in pthread_mutexattr_init () from
/usr/lib/libpthread.so.1
I can also attach traceback if it can help.

Does it means that something wrong with libpthread?

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

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-17 02:30

Message:
Logged In: YES 
user_id=479790
Originator: NO

No problem either on Windows with 2.4.3 and 2.5 (2.5.1 untested)


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

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

From noreply at sourceforge.net  Thu May 17 20:21:50 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 17 May 2007 11:21:50 -0700
Subject: [ python-Bugs-1668596 ] distutils chops the first character of
	filenames
Message-ID: <E1Hokbm-00046c-AO@sc8-sf-web22.sourceforge.net>

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

Please note that this 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
Private: No
Submitted By: Sam Pointon (freecondiments)
Assigned to: Nobody/Anonymous (nobody)
Summary: distutils chops the first character of filenames

Initial Comment:
Python 2.5c1, Windows XP SP2.

distutils chops the first character from some filenames if the package_data key is ''.

Minimal example:
The setup.py attached, and a directory named 'doc' in the same directory as setup.py with files in it. Running "python setup.py bdist" triggers the error.

On my box, this fails with:
running bdist
running bdist_dumb
running build
running build_py
error: can't copy 'oc\architecture.rst': doesn't exist or not a regular file

http://mail.python.org/pipermail/distutils-sig/2005-April/004453.html 
describes the same problem, and http://mail.python.org/pipermail/distutils-sig/2005-April/004458.html has a commentary on the code in distutils/commands/build_py.py which causes the error.

On lines 117-122, it tries to chop the directory path from the files it has found, using len() and slicing. This job is better done by os.path.split (and is probably more portable, too).

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-17 14:21

Message:
Logged In: YES 
user_id=984087
Originator: NO


It appears that I misunderstood the problem. Also, the attached setup.py
has a typo. Instead of

package_data = {'': ['doc/*']}

it should read

package_data = {'foobar': ['doc/*']}

Any way, I reproduced the problem and created a patch (1720897).

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-16 11:47

Message:
Logged In: YES 
user_id=984087
Originator: NO


After reading the distutils example section today, I did find one example
using null string as package_dir value. So there may be something to this
bug after all.

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-03-27 12:19

Message:
Logged In: YES 
user_id=984087
Originator: NO


Hi,

I reproduced the problem with the latest build on linux. The "fix" may be
trivial but I am not entirely sure if there is a problem in the first
place. The distutils document does not mention about having null value for
package_dir as is the case in your setup.py. I may be missing something
here but can you please explain the conclusion that "" is a perfectly valid
value for package_dir (as mentioned in one of the threads in mailing list)?
I am assuming that you mean "distribution root" directory by "". If this is
found to be valid usage, the  document should be updated along with the
code fix. Otherwise, a check can be put in to disallow null values. 

Raghu.




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

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

From noreply at sourceforge.net  Thu May 17 22:23:56 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 17 May 2007 13:23:56 -0700
Subject: [ python-Bugs-1720959 ] Please make sqlite3.Row iterable
Message-ID: <E1HomVw-0002oP-Og@sc8-sf-web23.sourceforge.net>

Bugs item #1720959, was opened at 2007-05-17 16: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=1720959&group_id=5470

Please note that this 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
Private: No
Submitted By: phil (philipdumont)
Assigned to: Nobody/Anonymous (nobody)
Summary: Please make sqlite3.Row iterable

Initial Comment:
Sometimes I'd like to get row values with columnname
indexes, sometimes by iterating over the row.

The default (not setting the connection's row_factory)
is to return a tuple, which gives the latter, but not
the former.

Setting row_factory to sqlite3.Row gives the former,
but (surprisingly) not the latter.

It's a surprise because back when pysqlite was not part
of the Python distrib (I don't recall what version), its
Row type was iterable.  Any chance that bit of
functionality could be put back?

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

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

From noreply at sourceforge.net  Thu May 17 23:14:17 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 17 May 2007 14:14:17 -0700
Subject: [ python-Bugs-1720959 ] Please make sqlite3.Row iterable
Message-ID: <E1HonIf-000061-KU@sc8-sf-web21.sourceforge.net>

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

Please note that this 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
Private: No
Submitted By: phil (philipdumont)
>Assigned to: Gerhard H?ring (ghaering)
Summary: Please make sqlite3.Row iterable

Initial Comment:
Sometimes I'd like to get row values with columnname
indexes, sometimes by iterating over the row.

The default (not setting the connection's row_factory)
is to return a tuple, which gives the latter, but not
the former.

Setting row_factory to sqlite3.Row gives the former,
but (surprisingly) not the latter.

It's a surprise because back when pysqlite was not part
of the Python distrib (I don't recall what version), its
Row type was iterable.  Any chance that bit of
functionality could be put back?

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-17 14:14

Message:
Logged In: YES 
user_id=33168
Originator: NO

Gerhard, could you take a look?

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

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

From noreply at sourceforge.net  Thu May 17 23:30:24 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 17 May 2007 14:30:24 -0700
Subject: [ python-Bugs-1720726 ] docu enhancement for
	logging.handlers.SysLogHandler
Message-ID: <E1HonYG-0001kS-Ox@sc8-sf-web23.sourceforge.net>

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

Please note that this 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
Private: No
Submitted By: rhunger (rhunger)
>Assigned to: Vinay Sajip (vsajip)
Summary: docu enhancement for logging.handlers.SysLogHandler

Initial Comment:
The documentation for "logging.handlers.SysLogHandler" is somewhat incomplete. This class can be used to communicate to a local syslogd too (not only to log to a remote syslogd, or a local syslogd with enabled remote logging capabilities ("-r" option)).

The documentation on:

http://docs.python.org/lib/node417.html

for SysLogHandler([address[, facility]]) should be expanded with something like the following:

"""
If address is specified as a string, a UNIX socket is used. To log to a local syslogd "SysLogHandler(address="/dev/log")" can be used.
"""

The docstring "import logging.handlers;help(logging.handlers.SysLogHandler.__init__)" is rather short and could be replaced with above documentation.




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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-17 14:30

Message:
Logged In: YES 
user_id=33168
Originator: NO

Vinay, any comment?

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

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

From noreply at sourceforge.net  Thu May 17 23:36:05 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 17 May 2007 14:36:05 -0700
Subject: [ python-Bugs-1720992 ] automatic imports
Message-ID: <E1Hondl-0002PE-Rj@sc8-sf-web23.sourceforge.net>

Bugs item #1720992, was opened at 2007-05-17 21: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=1720992&group_id=5470

Please note that this 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
Private: No
Submitted By: Juan Manuel Borges Ca?o (juanmabc3)
Assigned to: Nobody/Anonymous (nobody)
Summary: automatic imports

Initial Comment:
I don't need to declare a variable but I need to declare a module, i.e import module, can this be done automatically?, so time.strftime requires import time automatically in the spirit of the python language, it saves typing and synchronization of the imports with the changes of the source code

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

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

From noreply at sourceforge.net  Fri May 18 04:12:37 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 17 May 2007 19:12:37 -0700
Subject: [ python-Feature Requests-1714448 ] if something as x:
Message-ID: <E1HorxN-0002fS-4B@sc8-sf-web24.sourceforge.net>

Feature Requests item #1714448, was opened at 2007-05-07 12:09
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1714448&group_id=5470

Please note that this 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.6
Status: Open
Resolution: None
>Priority: 5
Private: No
Submitted By: k0wax (k0wax)
Assigned to: Nobody/Anonymous (nobody)
Summary: if something as x:

Initial Comment:
---

if map[x][y].overlay:
   map[x][y].overlay.blit(x,y)

---

... and ...

---

if map[x][y].overpay as ob:
   ob.blit(x, y)

---

the second one looks much more fun I think.

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-05-17 21:12

Message:
Logged In: YES 
user_id=80475
Originator: NO

Toss your idea out on python-ideas.
It isn't horrible.
And it helps with while-statement issues.

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

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

From noreply at sourceforge.net  Fri May 18 04:15:52 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 17 May 2007 19:15:52 -0700
Subject: [ python-Feature Requests-1721083 ] Add File - Reload
Message-ID: <E1Hos0W-0002zs-Ka@sc8-sf-web24.sourceforge.net>

Feature Requests item #1721083, was opened at 2007-05-17 21:15
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=1721083&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Kurt B. Kaiser (kbk)
Summary: Add File - Reload

Initial Comment:
When using CVS or SVN, it is common to revert or merge a file that is open in the editor.  It would be great to have a reload/refresh option on the menu to bring in the changed file.  Without that option, the only approach is to close without saving, fire-up the editor again, and reload the file manually.

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

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

From noreply at sourceforge.net  Fri May 18 06:04:04 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 17 May 2007 21:04:04 -0700
Subject: [ python-Feature Requests-1720992 ] automatic imports
Message-ID: <E1HothE-0007rG-U4@sc8-sf-web21.sourceforge.net>

Feature Requests item #1720992, was opened at 2007-05-17 14:36
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1720992&group_id=5470

Please note that this 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
Private: No
Submitted By: Juan Manuel Borges Ca?o (juanmabc3)
Assigned to: Nobody/Anonymous (nobody)
Summary: automatic imports

Initial Comment:
I don't need to declare a variable but I need to declare a module, i.e import module, can this be done automatically?, so time.strftime requires import time automatically in the spirit of the python language, it saves typing and synchronization of the imports with the changes of the source code

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

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

From noreply at sourceforge.net  Fri May 18 07:57:52 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 17 May 2007 22:57:52 -0700
Subject: [ python-Feature Requests-1714448 ] if something as x:
Message-ID: <E1HovTM-0003Nd-G4@sc8-sf-web21.sourceforge.net>

Feature Requests item #1714448, was opened at 2007-05-07 17:09
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1714448&group_id=5470

Please note that this 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.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: k0wax (k0wax)
Assigned to: Nobody/Anonymous (nobody)
Summary: if something as x:

Initial Comment:
---

if map[x][y].overlay:
   map[x][y].overlay.blit(x,y)

---

... and ...

---

if map[x][y].overpay as ob:
   ob.blit(x, y)

---

the second one looks much more fun I think.

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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-18 05:57

Message:
Logged In: YES 
user_id=849994
Originator: NO

FWIW, I have a patch for it. :)

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-05-18 02:12

Message:
Logged In: YES 
user_id=80475
Originator: NO

Toss your idea out on python-ideas.
It isn't horrible.
And it helps with while-statement issues.

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

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

From noreply at sourceforge.net  Fri May 18 08:52:42 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 17 May 2007 23:52:42 -0700
Subject: [ python-Bugs-1720241 ] Compiler is not thread safe?
Message-ID: <E1HowKQ-0000pC-Qf@sc8-sf-web22.sourceforge.net>

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

Please note that this 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
Private: No
Submitted By: ??PC?? (zpcz)
Assigned to: Nobody/Anonymous (nobody)
Summary: Compiler is not thread safe?

Initial Comment:
r = '''
a(b(c[d]))
'''
from threading import Thread
from compiler import parse
Thread(target = parse, args = (r,)).start()

leads to 
Bus error (core dumped)

When runs not in thread everything is OK.
OS FreeBSD 5.4.
Python 2.5.1 (seems that 2.5 also has this error)
(Runs perfectly on Linux, and on FreeBSD with Python 2.4)

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

>Comment By: Martin v. L?wis (loewis)
Date: 2007-05-18 08:52

Message:
Logged In: YES 
user_id=21627
Originator: NO

The compiler package is written in pure Python, so no matter what
statements it makes, it should not crash the interpreter.

Given that this is not easily reproducable on other systems, chances are
high that this is indeed an operating system bug or limitation.

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

Comment By: ??PC?? (zpcz)
Date: 2007-05-17 17:59

Message:
Logged In: YES 
user_id=1395738
Originator: YES

Actually here is the simpler test cases:
r = '(((a)))'
or
r = '[[[a]]]'

info threads in GDB prints folowing:
  4 Thread 2 (LWP 100196)  0x281a02fb in pthread_testcancel () from
/usr/lib/libpthread.so.1
* 3 Thread 3 (LWP 100119)  0x28195aca in _pthread_mutex_lock () from
/usr/lib/libpthread.so.1
  2 Thread 1 (runnable)  0x28198207 in pthread_mutexattr_init () from
/usr/lib/libpthread.so.1
I can also attach traceback if it can help.

Does it means that something wrong with libpthread?

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

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-17 01:30

Message:
Logged In: YES 
user_id=479790
Originator: NO

No problem either on Windows with 2.4.3 and 2.5 (2.5.1 untested)


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

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

From noreply at sourceforge.net  Fri May 18 10:12:21 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 18 May 2007 01:12:21 -0700
Subject: [ python-Bugs-1721161 ] ERROR - Microsoft Visual C++ Runtime Library
Message-ID: <E1HoxZV-0002jt-Eo@sc8-sf-web24.sourceforge.net>

Bugs item #1721161, was opened at 2007-05-18 10: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=1721161&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: darioUniPD (dariounipd)
Assigned to: Nobody/Anonymous (nobody)
Summary: ERROR - Microsoft Visual C++ Runtime Library

Initial Comment:
While runnin a process in IDLE error (Python 2.5.1):

==============================================================
TitleOfMessageBox:
  Microsoft Visual C++ Runtime Library

TheMessage:
  Runtime Error!

  Program: C:\[...]\python.exe

  The application has requested the Runtime to terminate it in an unusual
way.
  Please content the application's support team for more information.
==============================================================

How to repair?!

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

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

From noreply at sourceforge.net  Fri May 18 11:37:10 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 18 May 2007 02:37:10 -0700
Subject: [ python-Bugs-1720241 ] Compiler is not thread safe?
Message-ID: <E1Hoyta-0000St-Hl@sc8-sf-web23.sourceforge.net>

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

Please note that this 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
Private: No
Submitted By: ??PC?? (zpcz)
Assigned to: Nobody/Anonymous (nobody)
Summary: Compiler is not thread safe?

Initial Comment:
r = '''
a(b(c[d]))
'''
from threading import Thread
from compiler import parse
Thread(target = parse, args = (r,)).start()

leads to 
Bus error (core dumped)

When runs not in thread everything is OK.
OS FreeBSD 5.4.
Python 2.5.1 (seems that 2.5 also has this error)
(Runs perfectly on Linux, and on FreeBSD with Python 2.4)

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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-18 09:37

Message:
Logged In: YES 
user_id=849994
Originator: NO

> The compiler package is written in pure Python, so no matter what
> statements it makes, it should not crash the interpreter.

This is not entirely true, it uses the C-written parser module to parse
its input.

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

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-18 06:52

Message:
Logged In: YES 
user_id=21627
Originator: NO

The compiler package is written in pure Python, so no matter what
statements it makes, it should not crash the interpreter.

Given that this is not easily reproducable on other systems, chances are
high that this is indeed an operating system bug or limitation.

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

Comment By: ??PC?? (zpcz)
Date: 2007-05-17 15:59

Message:
Logged In: YES 
user_id=1395738
Originator: YES

Actually here is the simpler test cases:
r = '(((a)))'
or
r = '[[[a]]]'

info threads in GDB prints folowing:
  4 Thread 2 (LWP 100196)  0x281a02fb in pthread_testcancel () from
/usr/lib/libpthread.so.1
* 3 Thread 3 (LWP 100119)  0x28195aca in _pthread_mutex_lock () from
/usr/lib/libpthread.so.1
  2 Thread 1 (runnable)  0x28198207 in pthread_mutexattr_init () from
/usr/lib/libpthread.so.1
I can also attach traceback if it can help.

Does it means that something wrong with libpthread?

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

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-16 23:30

Message:
Logged In: YES 
user_id=479790
Originator: NO

No problem either on Windows with 2.4.3 and 2.5 (2.5.1 untested)


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

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

From noreply at sourceforge.net  Fri May 18 11:39:32 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 18 May 2007 02:39:32 -0700
Subject: [ python-Bugs-1721161 ] ERROR - Microsoft Visual C++ Runtime Library
Message-ID: <E1Hoyvs-0000gi-Hv@sc8-sf-web23.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.5
>Status: Pending
Resolution: None
Priority: 5
Private: No
Submitted By: darioUniPD (dariounipd)
Assigned to: Nobody/Anonymous (nobody)
Summary: ERROR - Microsoft Visual C++ Runtime Library

Initial Comment:
While runnin a process in IDLE error (Python 2.5.1):

==============================================================
TitleOfMessageBox:
  Microsoft Visual C++ Runtime Library

TheMessage:
  Runtime Error!

  Program: C:\[...]\python.exe

  The application has requested the Runtime to terminate it in an unusual
way.
  Please content the application's support team for more information.
==============================================================

How to repair?!

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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-18 09:39

Message:
Logged In: YES 
user_id=849994
Originator: NO

Please provide more information. What process did you try to run, and when
did the error occur?

It is very likely that the cause of this problem is a third-party
extension module. Which
modules do you load in your program?

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

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

From noreply at sourceforge.net  Fri May 18 13:10:56 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 18 May 2007 04:10:56 -0700
Subject: [ python-Bugs-1721241 ] code that writes the PKG-INFO file doesnt
	handle unicode
Message-ID: <E1Hp0MK-0005Yt-PS@sc8-sf-web22.sourceforge.net>

Bugs item #1721241, was opened at 2007-05-18 13: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=1721241&group_id=5470

Please note that this 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
Private: No
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: code that writes the PKG-INFO file doesnt handle unicode

Initial Comment:
[forwarded from http://bugs.debian.org/422604 ]

http://www.mail-archive.com/distutils-sig at python.org/msg03007.html

Analysis from Phillip J. Eby:

That's not the problem, it's that the code that writes the PKG-INFO file 
doesn't handle Unicode.  See 
distutils.dist.DistributionMetadata.write_pkg_info().  It needs to use a 
file with encoding support, if it's doing unicode

However, there's currently no standard, as far as I know, for what encoding 
the PKG-INFO file should use.  Meanwhile, the 'register' command accepts 
Unicode, but is broken in handling it.

Essentially, the problem is that Python 2.5 broke this by adding a unicode 
*requirement* to the "register" command.  Previously, register simply sent 
whatever you gave it, and the PKG-INFO writing code still 
does.  Unfortunately, this means that there is no longer any one value that 
you can use for your name that will be accepted by both "register" and 
anything that writes a PKG-INFO file.

Both register and write_pkg_info() are arguably broken here, and should be 
able to work with either strings or unicode, and degrade gracefully in the 
event of non-ASCII characters in a string.  (Because even though "register" 
is only run by the package's author, users may run other commands that 
require a PKG-INFO, so a package prepared using Python <2.5 must still be 
usable with Python 2.5 distutils, and Python <2.5 allows 8-bit maintainer 
names.)

Unfortunately, this isn't fixable until there's a new 2.5.x release.  For 
previous Python versions, both register and write_pkg_info() accepted 8-bit 
strings and passed them on as-is, so the only workaround for this issue at 
the moment is to revert to Python 2.4 or less.


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

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

From noreply at sourceforge.net  Fri May 18 14:27:17 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 18 May 2007 05:27:17 -0700
Subject: [ python-Bugs-1721161 ] ERROR - Microsoft Visual C++ Runtime Library
Message-ID: <E1Hp1YD-0006JJ-9u@sc8-sf-web24.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.5
>Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: darioUniPD (dariounipd)
Assigned to: Nobody/Anonymous (nobody)
Summary: ERROR - Microsoft Visual C++ Runtime Library

Initial Comment:
While runnin a process in IDLE error (Python 2.5.1):

==============================================================
TitleOfMessageBox:
  Microsoft Visual C++ Runtime Library

TheMessage:
  Runtime Error!

  Program: C:\[...]\python.exe

  The application has requested the Runtime to terminate it in an unusual
way.
  Please content the application's support team for more information.
==============================================================

How to repair?!

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

>Comment By: darioUniPD (dariounipd)
Date: 2007-05-18 14:27

Message:
Logged In: YES 
user_id=1796163
Originator: YES

Sorry, I forget about it!
I'm using PyLab (MatPlotLib) and ftplib mainly.
Other packages I used are os and time, but I think that the problem is not
here.

Thanks!

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

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-18 11:39

Message:
Logged In: YES 
user_id=849994
Originator: NO

Please provide more information. What process did you try to run, and when
did the error occur?

It is very likely that the cause of this problem is a third-party
extension module. Which
modules do you load in your program?

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

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

From noreply at sourceforge.net  Fri May 18 15:42:48 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 18 May 2007 06:42:48 -0700
Subject: [ python-Bugs-1721309 ] make testall shows many glibc detected malloc
	corruptions
Message-ID: <E1Hp2jI-00069K-4J@sc8-sf-web24.sourceforge.net>

Bugs item #1721309, was opened at 2007-05-18 08: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=1721309&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: David Favor (dfavor)
Assigned to: Nobody/Anonymous (nobody)
Summary: make testall shows many glibc detected malloc corruptions

Initial Comment:
export _MALLOC_CHECK_=1
make testall

test_bsddb3
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***

followed by deadlock errors.

malloc: using debugging hooks
blattest test_tempfile failed -- Traceback (most recent call last):
  File "/build/work/Python-2.5.1/Lib/test/test_tempfile.py", line 310, in test_noinherit
    self.failIf(retval > 0, "child process reports failure %d"%retval)
AssertionError: child process reports failure 1

test_timeout
test test_timeout failed -- Traceback (most recent call last):
  File "/build/work/Python-2.5.1/Lib/test/test_timeout.py", line 128, in testConnectTimeout
    %(_delta, self.fuzz, _timeout))
AssertionError: timeout (8.20631) is more than 2 seconds more than expected (0.001)


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721309&group_id=5470

From noreply at sourceforge.net  Fri May 18 15:46:33 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 18 May 2007 06:46:33 -0700
Subject: [ python-Bugs-1721313 ] test_bsddb3 malloc corruption
Message-ID: <E1Hp2mv-0000JU-OE@sc8-sf-web23.sourceforge.net>

Bugs item #1721313, was opened at 2007-05-18 08: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=1721313&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: David Favor (dfavor)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_bsddb3 malloc corruption

Initial Comment:
export MALLOC_CHECK_=1
make testall

test_bsddb3
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***

Followed by many deadlock exceptions.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721313&group_id=5470

From noreply at sourceforge.net  Fri May 18 15:47:25 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 18 May 2007 06:47:25 -0700
Subject: [ python-Bugs-1721313 ] test_bsddb3 malloc corruption
Message-ID: <E1Hp2nl-0000QK-DH@sc8-sf-web23.sourceforge.net>

Bugs item #1721313, was opened at 2007-05-18 08:46
Message generated for change (Comment added) made by dfavor
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721313&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: David Favor (dfavor)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_bsddb3 malloc corruption

Initial Comment:
export MALLOC_CHECK_=1
make testall

test_bsddb3
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***

Followed by many deadlock exceptions.

----------------------------------------------------------------------

>Comment By: David Favor (dfavor)
Date: 2007-05-18 08:47

Message:
Logged In: YES 
user_id=370230
Originator: YES

Duplicate of 1721309.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721313&group_id=5470

From noreply at sourceforge.net  Fri May 18 17:06:26 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 18 May 2007 08:06:26 -0700
Subject: [ python-Bugs-1721368 ] emphasize iteration volatility for dict
Message-ID: <E1Hp42E-0000Eh-6O@sc8-sf-web24.sourceforge.net>

Bugs item #1721368, was opened at 2007-05-18 10: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=1721368&group_id=5470

Please note that this 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
Private: No
Submitted By: Alan (aisaac0)
Assigned to: Nobody/Anonymous (nobody)
Summary: emphasize iteration volatility for dict

Initial Comment:
In footnote (3) at <URL:http://docs.python.org/lib/typesmapping.html>, delete the first two sentences and substitute:

    Keys and values are listed in an arbitrary order.  This order is indeterminate and generally depends on factors outside the scope of the containing program.  However, if items(), keys(), values(), iteritems(), iterkeys(), and itervalues() are called with no intervening modifications to the dictionary, the lists will directly correspond.

*Justification:* users should not be expected to understand without being told that iteration order depends on factors outside the scope of the containing program.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721368&group_id=5470

From noreply at sourceforge.net  Fri May 18 17:10:28 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 18 May 2007 08:10:28 -0700
Subject: [ python-Bugs-1721372 ] emphasize iteration volatility for set
Message-ID: <E1Hp468-0000fe-ED@sc8-sf-web24.sourceforge.net>

Bugs item #1721372, was opened at 2007-05-18 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=1721372&group_id=5470

Please note that this 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
Private: No
Submitted By: Alan (aisaac0)
Assigned to: Nobody/Anonymous (nobody)
Summary: emphasize iteration volatility for set

Initial Comment:
For <URL:http://docs.python.org/lib/types-set.html>, append the following new sentence to the 2nd paragraph.

    Iteration over a set returns elements in an indeterminate order, which generally depends on factors outside the scope of the containing program.

*Justification:* users should not be expected to understand without being told that iteration order depends on factors outside the scope of the containing program. (Additionally, unlike the documentation for dictionaries, the documentation for sets fails to give a serious warning not to rely on iteration order.)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721372&group_id=5470

From noreply at sourceforge.net  Fri May 18 18:01:23 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 18 May 2007 09:01:23 -0700
Subject: [ python-Bugs-1721313 ] test_bsddb3 malloc corruption
Message-ID: <E1Hp4tP-0006tD-3G@sc8-sf-web23.sourceforge.net>

Bugs item #1721313, was opened at 2007-05-18 13:46
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721313&group_id=5470

Please note that this 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: Duplicate
Priority: 5
Private: No
Submitted By: David Favor (dfavor)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_bsddb3 malloc corruption

Initial Comment:
export MALLOC_CHECK_=1
make testall

test_bsddb3
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***

Followed by many deadlock exceptions.

----------------------------------------------------------------------

Comment By: David Favor (dfavor)
Date: 2007-05-18 13:47

Message:
Logged In: YES 
user_id=370230
Originator: YES

Duplicate of 1721309.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721313&group_id=5470

From noreply at sourceforge.net  Fri May 18 19:05:23 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 18 May 2007 10:05:23 -0700
Subject: [ python-Bugs-1721372 ] emphasize iteration volatility for set
Message-ID: <E1Hp5tL-0005dT-I1@sc8-sf-web23.sourceforge.net>

Bugs item #1721372, was opened at 2007-05-18 17:10
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721372&group_id=5470

Please note that this 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
Private: No
Submitted By: Alan (aisaac0)
Assigned to: Nobody/Anonymous (nobody)
Summary: emphasize iteration volatility for set

Initial Comment:
For <URL:http://docs.python.org/lib/types-set.html>, append the following new sentence to the 2nd paragraph.

    Iteration over a set returns elements in an indeterminate order, which generally depends on factors outside the scope of the containing program.

*Justification:* users should not be expected to understand without being told that iteration order depends on factors outside the scope of the containing program. (Additionally, unlike the documentation for dictionaries, the documentation for sets fails to give a serious warning not to rely on iteration order.)


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2007-05-18 19:05

Message:
Logged In: YES 
user_id=21627
Originator: NO

What factors outside the containing program influence iteration order?
Iteration is completely deterministic, and only depends on the items
inserted, and the order in which they were inserted, neither of which is
outside the scope of the containing program. It's just that the order is
not easily predictable.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721372&group_id=5470

From noreply at sourceforge.net  Fri May 18 19:43:48 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 18 May 2007 10:43:48 -0700
Subject: [ python-Bugs-1721309 ] make testall shows many glibc detected malloc
	corruptions
Message-ID: <E1Hp6UW-0005Y5-Og@sc8-sf-web22.sourceforge.net>

Bugs item #1721309, was opened at 2007-05-18 15:42
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721309&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: David Favor (dfavor)
Assigned to: Nobody/Anonymous (nobody)
Summary: make testall shows many glibc detected malloc corruptions

Initial Comment:
export _MALLOC_CHECK_=1
make testall

test_bsddb3
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***

followed by deadlock errors.

malloc: using debugging hooks
blattest test_tempfile failed -- Traceback (most recent call last):
  File "/build/work/Python-2.5.1/Lib/test/test_tempfile.py", line 310, in test_noinherit
    self.failIf(retval > 0, "child process reports failure %d"%retval)
AssertionError: child process reports failure 1

test_timeout
test test_timeout failed -- Traceback (most recent call last):
  File "/build/work/Python-2.5.1/Lib/test/test_timeout.py", line 128, in testConnectTimeout
    %(_delta, self.fuzz, _timeout))
AssertionError: timeout (8.20631) is more than 2 seconds more than expected (0.001)


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2007-05-18 19:43

Message:
Logged In: YES 
user_id=21627
Originator: NO

Unfortunately, I cannot reproduce this problem on Debian unstable (x86,
gcc 4.1.3, glibc 2.5) - 
the test passes just fine with _MALLOC_CHECK set.

Can you provide a few more details: glibc version, compiler version, Linux
distribution, processor architecture, precise Python version being test,
does the error happen on the first or a subsequent cycle of all tests?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721309&group_id=5470

From noreply at sourceforge.net  Fri May 18 20:00:32 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 18 May 2007 11:00:32 -0700
Subject: [ python-Bugs-1721372 ] emphasize iteration volatility for set
Message-ID: <E1Hp6ki-0003qo-Pz@sc8-sf-web21.sourceforge.net>

Bugs item #1721372, was opened at 2007-05-18 10:10
Message generated for change (Comment added) made by aisaac0
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721372&group_id=5470

Please note that this 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
Private: No
Submitted By: Alan (aisaac0)
Assigned to: Nobody/Anonymous (nobody)
Summary: emphasize iteration volatility for set

Initial Comment:
For <URL:http://docs.python.org/lib/types-set.html>, append the following new sentence to the 2nd paragraph.

    Iteration over a set returns elements in an indeterminate order, which generally depends on factors outside the scope of the containing program.

*Justification:* users should not be expected to understand without being told that iteration order depends on factors outside the scope of the containing program. (Additionally, unlike the documentation for dictionaries, the documentation for sets fails to give a serious warning not to rely on iteration order.)


----------------------------------------------------------------------

>Comment By: Alan (aisaac0)
Date: 2007-05-18 13:00

Message:
Logged In: YES 
user_id=1025672
Originator: YES

Location in memory.
See Peter Otten's discussion at
http://www.thescripts.com/forum/post2552380-16.html

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-18 12:05

Message:
Logged In: YES 
user_id=21627
Originator: NO

What factors outside the containing program influence iteration order?
Iteration is completely deterministic, and only depends on the items
inserted, and the order in which they were inserted, neither of which is
outside the scope of the containing program. It's just that the order is
not easily predictable.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721372&group_id=5470

From noreply at sourceforge.net  Fri May 18 22:12:09 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 18 May 2007 13:12:09 -0700
Subject: [ python-Bugs-1721518 ] Small case which hangs
Message-ID: <E1Hp8o5-0006AM-GX@sc8-sf-web23.sourceforge.net>

Bugs item #1721518, was opened at 2007-05-18 20: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=1721518&group_id=5470

Please note that this 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
Private: No
Submitted By: Julian Todd (goatchurch)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: Small case which hangs

Initial Comment:
import re
s = "Add.1, 2020 and Add.1, 2021-2023, 2025, 2028 and 2029 and Add.1) R"
r = "(?:\s|,|and|Add\S*?|Parts?|\([^\)]*\)|[IV\-\d]+)*$"
print "It's going to crash"
print re.search(r, s)
print "It hasn't crashed"

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721518&group_id=5470

From noreply at sourceforge.net  Fri May 18 22:55:28 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 18 May 2007 13:55:28 -0700
Subject: [ python-Bugs-1721518 ] Small case which hangs
Message-ID: <E1Hp9U0-0002yq-T5@sc8-sf-web23.sourceforge.net>

Bugs item #1721518, was opened at 2007-05-18 20:12
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721518&group_id=5470

Please note that this 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: 4
Private: No
Submitted By: Julian Todd (goatchurch)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: Small case which hangs

Initial Comment:
import re
s = "Add.1, 2020 and Add.1, 2021-2023, 2025, 2028 and 2029 and Add.1) R"
r = "(?:\s|,|and|Add\S*?|Parts?|\([^\)]*\)|[IV\-\d]+)*$"
print "It's going to crash"
print re.search(r, s)
print "It hasn't crashed"

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-18 20:55

Message:
Logged In: YES 
user_id=849994
Originator: NO

I assume this is one of the pathological cases where the RE algorithm
backtracks "to death". That's not really a bug, but a limitation.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721518&group_id=5470

From noreply at sourceforge.net  Fri May 18 23:02:14 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 18 May 2007 14:02:14 -0700
Subject: [ python-Bugs-1721309 ] make testall shows many glibc detected malloc
	corruptions
Message-ID: <E1Hp9aY-00080x-6J@sc8-sf-web23.sourceforge.net>

Bugs item #1721309, was opened at 2007-05-18 13:42
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721309&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: David Favor (dfavor)
Assigned to: Nobody/Anonymous (nobody)
Summary: make testall shows many glibc detected malloc corruptions

Initial Comment:
export _MALLOC_CHECK_=1
make testall

test_bsddb3
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***

followed by deadlock errors.

malloc: using debugging hooks
blattest test_tempfile failed -- Traceback (most recent call last):
  File "/build/work/Python-2.5.1/Lib/test/test_tempfile.py", line 310, in test_noinherit
    self.failIf(retval > 0, "child process reports failure %d"%retval)
AssertionError: child process reports failure 1

test_timeout
test test_timeout failed -- Traceback (most recent call last):
  File "/build/work/Python-2.5.1/Lib/test/test_timeout.py", line 128, in testConnectTimeout
    %(_delta, self.fuzz, _timeout))
AssertionError: timeout (8.20631) is more than 2 seconds more than expected (0.001)


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-18 21:02

Message:
Logged In: YES 
user_id=849994
Originator: NO

I don't even need to set an environment variable to get

~/devel/python> ./python Lib/test/regrtest.py -uall test_bsddb3
test_bsddb3
*** glibc detected *** ./python: free(): invalid pointer: 0x0827874c ***
[1]    17141 abort      ./python Lib/test/regrtest.py -uall test_bsddb3

(HEAD, linux x86, gcc 4.1.2, glibc 2.5)

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-18 17:43

Message:
Logged In: YES 
user_id=21627
Originator: NO

Unfortunately, I cannot reproduce this problem on Debian unstable (x86,
gcc 4.1.3, glibc 2.5) - 
the test passes just fine with _MALLOC_CHECK set.

Can you provide a few more details: glibc version, compiler version, Linux
distribution, processor architecture, precise Python version being test,
does the error happen on the first or a subsequent cycle of all tests?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721309&group_id=5470

From noreply at sourceforge.net  Fri May 18 23:26:58 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 18 May 2007 14:26:58 -0700
Subject: [ python-Bugs-1721309 ] make testall shows many glibc detected malloc
	corruptions
Message-ID: <E1Hp9yU-0003Wp-RI@sc8-sf-web24.sourceforge.net>

Bugs item #1721309, was opened at 2007-05-18 08:42
Message generated for change (Comment added) made by dfavor
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721309&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: David Favor (dfavor)
Assigned to: Nobody/Anonymous (nobody)
Summary: make testall shows many glibc detected malloc corruptions

Initial Comment:
export _MALLOC_CHECK_=1
make testall

test_bsddb3
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***

followed by deadlock errors.

malloc: using debugging hooks
blattest test_tempfile failed -- Traceback (most recent call last):
  File "/build/work/Python-2.5.1/Lib/test/test_tempfile.py", line 310, in test_noinherit
    self.failIf(retval > 0, "child process reports failure %d"%retval)
AssertionError: child process reports failure 1

test_timeout
test test_timeout failed -- Traceback (most recent call last):
  File "/build/work/Python-2.5.1/Lib/test/test_timeout.py", line 128, in testConnectTimeout
    %(_delta, self.fuzz, _timeout))
AssertionError: timeout (8.20631) is more than 2 seconds more than expected (0.001)


----------------------------------------------------------------------

>Comment By: David Favor (dfavor)
Date: 2007-05-18 16:26

Message:
Logged In: YES 
user_id=370230
Originator: YES

The os I'm running is Fedora 6 with latest patches.

gcc is 4.1.1

glibc is 2.5

I had to set MALLOC_CHECK_=1 just to get the suite to run as normal
MALLOC_CHECK_ defaults to die when something evil occurs.

I'll build gcc 4.2, rebuild and see what occurs.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-18 16:02

Message:
Logged In: YES 
user_id=849994
Originator: NO

I don't even need to set an environment variable to get

~/devel/python> ./python Lib/test/regrtest.py -uall test_bsddb3
test_bsddb3
*** glibc detected *** ./python: free(): invalid pointer: 0x0827874c ***
[1]    17141 abort      ./python Lib/test/regrtest.py -uall test_bsddb3

(HEAD, linux x86, gcc 4.1.2, glibc 2.5)

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-18 12:43

Message:
Logged In: YES 
user_id=21627
Originator: NO

Unfortunately, I cannot reproduce this problem on Debian unstable (x86,
gcc 4.1.3, glibc 2.5) - 
the test passes just fine with _MALLOC_CHECK set.

Can you provide a few more details: glibc version, compiler version, Linux
distribution, processor architecture, precise Python version being test,
does the error happen on the first or a subsequent cycle of all tests?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721309&group_id=5470

From noreply at sourceforge.net  Sat May 19 00:37:25 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 18 May 2007 15:37:25 -0700
Subject: [ python-Bugs-1721518 ] Small case which hangs
Message-ID: <E1HpB4f-0007Jm-Jg@sc8-sf-web22.sourceforge.net>

Bugs item #1721518, was opened at 2007-05-18 20:12
Message generated for change (Comment added) made by goatchurch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721518&group_id=5470

Please note that this 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: 4
Private: No
Submitted By: Julian Todd (goatchurch)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: Small case which hangs

Initial Comment:
import re
s = "Add.1, 2020 and Add.1, 2021-2023, 2025, 2028 and 2029 and Add.1) R"
r = "(?:\s|,|and|Add\S*?|Parts?|\([^\)]*\)|[IV\-\d]+)*$"
print "It's going to crash"
print re.search(r, s)
print "It hasn't crashed"

----------------------------------------------------------------------

>Comment By: Julian Todd (goatchurch)
Date: 2007-05-18 22:37

Message:
Logged In: YES 
user_id=301384
Originator: YES

I can shorten it further to: 

s = "Add.1, 2020 Add.1, 20212023, 2025, 2028 and 2029 Add.1) R"
r = "(?:\s|,|and|Add\S*?|[\d]+)*$"

Sometimes it finishes after a long time when you shorten the s-string from
the front.  If you take the "R" from the end it goes through straight away.
 It's even very slow with match.  

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-18 20:55

Message:
Logged In: YES 
user_id=849994
Originator: NO

I assume this is one of the pathological cases where the RE algorithm
backtracks "to death". That's not really a bug, but a limitation.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721518&group_id=5470

From noreply at sourceforge.net  Sat May 19 01:07:28 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 18 May 2007 16:07:28 -0700
Subject: [ python-Bugs-1721368 ] emphasize iteration volatility for dict
Message-ID: <E1HpBXk-0002lt-Ny@sc8-sf-web24.sourceforge.net>

Bugs item #1721368, was opened at 2007-05-18 10:06
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721368&group_id=5470

Please note that this 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: Rejected
Priority: 5
Private: No
Submitted By: Alan (aisaac0)
Assigned to: Nobody/Anonymous (nobody)
Summary: emphasize iteration volatility for dict

Initial Comment:
In footnote (3) at <URL:http://docs.python.org/lib/typesmapping.html>, delete the first two sentences and substitute:

    Keys and values are listed in an arbitrary order.  This order is indeterminate and generally depends on factors outside the scope of the containing program.  However, if items(), keys(), values(), iteritems(), iterkeys(), and itervalues() are called with no intervening modifications to the dictionary, the lists will directly correspond.

*Justification:* users should not be expected to understand without being told that iteration order depends on factors outside the scope of the containing program.



----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-05-18 18:07

Message:
Logged In: YES 
user_id=80475
Originator: NO

While the OP knows what he means here, the suggested text does not add
clarity, it only makes the subject harder to understand and implies that
some mysterious, dark force is in place.  Further, the suggested text is
simply incorrect.  Given deterministic assignment of hash values and a
consistent insertion order, the order of keys in a set or dictionary is
fully determined.

I've read the source of this suggestion on comp.lang.python and commented
there.  The underlying issue had nothing to do with either sets or dicts. 
The code in question "re-discovered" that the location of objects in memory
 would vary between runs if the user deleted a pyc file for a module.  The
OP's script used object ids as hash values, hence the set/dict ordering
could vary between runs.  This was at odds with his expectation that that
the ordering would be deterministic.  The moral is that non-deterministic
hash values lead to non-deterministic set/dict ordering.

The docs for sets and dicts should not be muddled with tangential
discussions about implementation specific details regarding what governs
where objects are placed in memory.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721368&group_id=5470

From noreply at sourceforge.net  Sat May 19 01:08:44 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 18 May 2007 16:08:44 -0700
Subject: [ python-Bugs-1721372 ] emphasize iteration volatility for set
Message-ID: <E1HpBYy-0002sd-Iq@sc8-sf-web24.sourceforge.net>

Bugs item #1721372, was opened at 2007-05-18 10:10
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721372&group_id=5470

Please note that this 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: Rejected
Priority: 5
Private: No
Submitted By: Alan (aisaac0)
Assigned to: Nobody/Anonymous (nobody)
Summary: emphasize iteration volatility for set

Initial Comment:
For <URL:http://docs.python.org/lib/types-set.html>, append the following new sentence to the 2nd paragraph.

    Iteration over a set returns elements in an indeterminate order, which generally depends on factors outside the scope of the containing program.

*Justification:* users should not be expected to understand without being told that iteration order depends on factors outside the scope of the containing program. (Additionally, unlike the documentation for dictionaries, the documentation for sets fails to give a serious warning not to rely on iteration order.)


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-05-18 18:08

Message:
Logged In: YES 
user_id=80475
Originator: NO

While the OP knows what he means here, the suggested text does not add
clarity, it only makes the subject harder to understand and implies that
some mysterious, dark force is in place.  Further, the suggested text is
simply incorrect.  Given deterministic assignment of hash values and a
consistent insertion order, the order of keys in a set or dictionary is
fully determined.

I've read the source of this suggestion on comp.lang.python and commented
there.  The underlying issue had nothing to do with either sets or dicts. 
The code in question "re-discovered" that the location of objects in memory
 would vary between runs if the user deleted a pyc file for a module.  The
OP's script used object ids as hash values, hence the set/dict ordering
could vary between runs.  This was at odds with his expectation that that
the ordering would be deterministic.  The moral is that non-deterministic
hash values lead to non-deterministic set/dict ordering.

The docs for sets and dicts should not be muddled with tangential
discussions about implementation specific details regarding what governs
where objects are placed in memory.


----------------------------------------------------------------------

Comment By: Alan (aisaac0)
Date: 2007-05-18 13:00

Message:
Logged In: YES 
user_id=1025672
Originator: YES

Location in memory.
See Peter Otten's discussion at
http://www.thescripts.com/forum/post2552380-16.html

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-18 12:05

Message:
Logged In: YES 
user_id=21627
Originator: NO

What factors outside the containing program influence iteration order?
Iteration is completely deterministic, and only depends on the items
inserted, and the order in which they were inserted, neither of which is
outside the scope of the containing program. It's just that the order is
not easily predictable.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721372&group_id=5470

From noreply at sourceforge.net  Sat May 19 01:14:21 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 18 May 2007 16:14:21 -0700
Subject: [ python-Bugs-1720241 ] Compiler is not thread safe?
Message-ID: <E1HpBeP-0003W8-7c@sc8-sf-web24.sourceforge.net>

Bugs item #1720241, was opened at 2007-05-16 14:38
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1720241&group_id=5470

Please note that this 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
Private: No
Submitted By: ??PC?? (zpcz)
Assigned to: Nobody/Anonymous (nobody)
Summary: Compiler is not thread safe?

Initial Comment:
r = '''
a(b(c[d]))
'''
from threading import Thread
from compiler import parse
Thread(target = parse, args = (r,)).start()

leads to 
Bus error (core dumped)

When runs not in thread everything is OK.
OS FreeBSD 5.4.
Python 2.5.1 (seems that 2.5 also has this error)
(Runs perfectly on Linux, and on FreeBSD with Python 2.4)

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-05-18 18:14

Message:
Logged In: YES 
user_id=80475
Originator: NO

FWIW, I cannot get the OP's script to fail on Py2.5.1 on either Windows XP
or on Gentoo Linux.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-18 04:37

Message:
Logged In: YES 
user_id=849994
Originator: NO

> The compiler package is written in pure Python, so no matter what
> statements it makes, it should not crash the interpreter.

This is not entirely true, it uses the C-written parser module to parse
its input.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-18 01:52

Message:
Logged In: YES 
user_id=21627
Originator: NO

The compiler package is written in pure Python, so no matter what
statements it makes, it should not crash the interpreter.

Given that this is not easily reproducable on other systems, chances are
high that this is indeed an operating system bug or limitation.

----------------------------------------------------------------------

Comment By: ??PC?? (zpcz)
Date: 2007-05-17 10:59

Message:
Logged In: YES 
user_id=1395738
Originator: YES

Actually here is the simpler test cases:
r = '(((a)))'
or
r = '[[[a]]]'

info threads in GDB prints folowing:
  4 Thread 2 (LWP 100196)  0x281a02fb in pthread_testcancel () from
/usr/lib/libpthread.so.1
* 3 Thread 3 (LWP 100119)  0x28195aca in _pthread_mutex_lock () from
/usr/lib/libpthread.so.1
  2 Thread 1 (runnable)  0x28198207 in pthread_mutexattr_init () from
/usr/lib/libpthread.so.1
I can also attach traceback if it can help.

Does it means that something wrong with libpthread?

----------------------------------------------------------------------

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-16 18:30

Message:
Logged In: YES 
user_id=479790
Originator: NO

No problem either on Windows with 2.4.3 and 2.5 (2.5.1 untested)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1720241&group_id=5470

From noreply at sourceforge.net  Sat May 19 01:27:13 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 18 May 2007 16:27:13 -0700
Subject: [ python-Bugs-1718942 ] glibc error: corrupted double linked list
	(CPython 2.5.1)
Message-ID: <E1HpBqr-0004tk-8f@sc8-sf-web24.sourceforge.net>

Bugs item #1718942, was opened at 2007-05-14 16:28
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1718942&group_id=5470

Please note that this message 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
Private: No
Submitted By: Yang Zhang (yangzhang)
Assigned to: Nobody/Anonymous (nobody)
Summary: glibc error: corrupted double linked list (CPython 2.5.1)

Initial Comment:
I'm sometimes (50% of the time) getting the following CPython 2.5.1 crash when my program terminates. I would include the source to my program, but it has lots of dependencies, and it would be a substantial task to find a minimal case.

*** glibc detected *** python: corrupted double-linked list: 0x0a2018a0 ***
======= Backtrace: =========
/lib/libc.so.6[0xd14e9f]
/lib/libc.so.6[0xd167ae]
/lib/libc.so.6(__libc_free+0x78)[0xd19f6f]
/usr/local/lib/libpython2.5.so.1.0(PyObject_Free+0x53)[0x211933]
/usr/local/lib/libpython2.5.so.1.0(PyObject_GC_Del+0x53)[0x288fc3]
/usr/local/lib/libpython2.5.so.1.0(PyFrame_Fini+0x31)[0x1f8f81]
/usr/local/lib/libpython2.5.so.1.0(Py_Finalize+0x105)[0x27d825]
/usr/local/lib/libpython2.5.so.1.0(Py_Exit+0x17)[0x27d927]
/usr/local/lib/libpython2.5.so.1.0[0x27da4f]
/usr/local/lib/libpython2.5.so.1.0(PyErr_PrintEx+0x1aa)[0x27dc6a]
/usr/local/lib/libpython2.5.so.1.0(PyErr_Print+0x1e)[0x27de6e]
/usr/local/lib/libpython2.5.so.1.0(PyRun_SimpleFileExFlags+0xf1)[0x27f0d1]
/usr/local/lib/libpython2.5.so.1.0(PyRun_AnyFileExFlags+0x7a)[0x27f46a]
/usr/local/lib/libpython2.5.so.1.0(Py_Main+0xae8)[0x288a78]
python(main+0x32)[0x8048592]
/lib/libc.so.6(__libc_start_main+0xdc)[0xcc84e4]
python[0x80484d1]
======= Memory map: ========
00110000-00120000 r-xp 00000000 08:02 489896     /lib/libpthread-2.4.so
00120000-00121000 r--p 0000f000 08:02 489896     /lib/libpthread-2.4.so
00121000-00122000 rw-p 00010000 08:02 489896     /lib/libpthread-2.4.so
00122000-00124000 rw-p 00122000 00:00 0
00124000-00147000 r-xp 00000000 08:02 489888     /lib/libm-2.4.so
00147000-00148000 r--p 00022000 08:02 489888     /lib/libm-2.4.so
00148000-00149000 rw-p 00023000 08:02 489888     /lib/libm-2.4.so
00149000-00159000 r-xp 00000000 08:02 2154663    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/cPickle.so
00159000-0015a000 rw-p 00010000 08:02 2154663    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/cPickle.so
0015a000-0015d000 r-xp 00000000 08:02 2154640    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/cStringIO.so
0015d000-0015e000 rw-p 00003000 08:02 2154640    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/cStringIO.so
0015e000-00161000 r-xp 00000000 08:02 2154619    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/time.so
00161000-00163000 rw-p 00002000 08:02 2154619    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/time.so
00163000-00167000 r-xp 00000000 08:02 2154653    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/collections.so
00167000-00168000 rw-p 00004000 08:02 2154653    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/collections.so
00168000-001a9000 r-xp 00000000 08:02 490243     /lib/libssl.so.0.9.8a
001a9000-001ad000 rw-p 00040000 08:02 490243     /lib/libssl.so.0.9.8a
001ad000-001af000 r-xp 00000000 08:02 2154635    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/fcntl.so
001af000-001b0000 rw-p 00002000 08:02 2154635    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/fcntl.so
001b0000-001b2000 r-xp 00000000 08:02 2154613    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/grp.so
001b2000-001b3000 rw-p 00001000 08:02 2154613    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/grp.so
001b3000-001b4000 r-xp 00000000 08:02 2154641    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/_bisect.so
001b4000-001b5000 rw-p 00001000 08:02 2154641    /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/_bisect.so
001b5000-002bd000 r-xp 00000000 08:02 2139893    /toast/pkg/python/v2.5.1/1/root/lib/libpython2.5.so.1.0
002bd000-002e3000 rw-p 00107000 08:02 2139893    /toast/pkg/python/v2.5.1/1/root/lib/libpython2.5.so.1.0
002e3000-002e9000 rw-p 002e3000 00:00 0
002e9000-002f8000 r-xp 00000000 08:02 489892     /lib/libresolv-2.4.so
002f8000-002f9000 r--p 0000e000 08:02 489892     /lib/libresolv-2.4.so
002f9000-002fa000 rw-p 0000f000 08:02 489892     /lib/libresolv-2.4.so
002fa000-002fc000 rw-p 002fa000 00:00 0
002fc000-0030e000 r-xp 00000000 08:02 1290756    /usr/lib/libz.so.1.2.3
0030e000-0030f000 rw-p 00011000 08:02 1290756    /usr/lib/libz.so.1.2.3
0030f000-0032f000 r-xp 00000000 08:02 565445     /usr/lib/libpq.so.4.1
0032f000-00330000 rw-p 0001f000 08:02 565445     /usr/lib/libpq.so.4.1
00330000-0033f000 r-xp 00000000 08:02 2154660    /toast/pkg/pAborted

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-05-18 18:27

Message:
Logged In: YES 
user_id=80475
Originator: NO

Recommend closing this as a third-party bug (Python doesn't have a
doubly-linked list object).

FWIW, I would guess this bug has to do with violating the tight invariants
around this data structure (i.e. linked elements having to subclass from a
link object, avoiding circular references, keeping the length attribute
up-to-date, and assuring that the endpoint links point to something
indicated the end of the chain).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-15 00:48

Message:
Logged In: YES 
user_id=33168
Originator: NO

Yang Zhang, thanks for the report.  Unfortunately, it will be virtually
impossible for us to try to debug this without a test case.  I see libpq.so
in there, which I believe is from Postgres.  Is that correct?  There is no
postgres module that's part of standard python.  The extension module is a
third party extension.  It's possible that's where the problem is.  Without
more info, it could really be anywhere.

Perhaps you could run this under valgrind or some other memory debugger
and find the problem or at least narrow it down?  

----------------------------------------------------------------------

Comment By: Yang Zhang (yangzhang)
Date: 2007-05-14 16:31

Message:
Logged In: YES 
user_id=1207658
Originator: YES

just to add some more details:

this is on my up2date fedora core 5 box, with a built-from-source cpython
2.5.1. afaik i'm not using any non-standard extension modules.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1718942&group_id=5470

From noreply at sourceforge.net  Sat May 19 01:41:19 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 18 May 2007 16:41:19 -0700
Subject: [ python-Bugs-1487481 ] Could BIND_FIRST be removed on HP-UX?
Message-ID: <E1HpC4V-0007yH-Gv@sc8-sf-web21.sourceforge.net>

Bugs item #1487481, was opened at 2006-05-12 08:32
Message generated for change (Comment added) made by atyutyunnik
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1487481&group_id=5470

Please note that this message 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
Private: No
Submitted By: G?ran Uddeborg (goeran)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Could BIND_FIRST be removed on HP-UX?

Initial Comment:
I'm trying to build Python 2.4.3 on HP-UX 11.  I need
tkinter, so I have first built Tcl and Tk 8.4.13.

During the build, the python interpreter crashes.  When
running the setup.py script, just after making the
_tkinter.sl module, it crashes with a memory fault.

I've tried to investigate this, and it seems that
malloc and friends gets confused by the dynamic
loading.  I've filed a support request with HP about this.

One observation I made is that this malloc bug seems to
be connected with the use of BIND_FIRST in
dynload_hpux.c.  If I just remove this flag (in two
places) it appears as if Python works normally.

I'm hesitant if this is a good idea.  BIND_FIRST is
there as an explicit, non-default, flag.  Somebody must
have choosen to do so for some reason.  What was that
reason?  And is it still valid?  If not, maybe the flag
could be removed, and this problem in HP-UX be avoided?

----------------------------------------------------------------------

Comment By: Alexander Tyutyunnik (atyutyunnik)
Date: 2007-05-18 16:41

Message:
Logged In: YES 
user_id=1558596
Originator: NO

I am using on SWIG 1.3.29+ with Python 2.5 on HP-UX 11.23, Itanium 64bit.
It had failed to work (unresolved symbols) until I fixed code this way:
//	flags = BIND_FIRST | BIND_DEFERRED;
	flags = BIND_DEFERRED|BIND_VERBOSE;

instead of:
	flags = BIND_FIRST | BIND_DEFERRED;

Can anyone please fix it?


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2006-05-18 22:45

Message:
Logged In: YES 
user_id=6380

Peter Kropf wrote:

"""
BIND_FIRST causes the dynamic loader to place the newly
loaded shared
library symbol table at the head of the lookup order. This
causes
symbol lookups from that time forward to check the newly
loaded symbol
table before everything else. I can see this causing interesting
things to happen to a program if a shared library contains
symbol
names that are the same as those of, let's say, the C
runtime library.

>From what I remember of Python and HP-UX, I'd guess that
this was
added for an extension module. I don't think that it would
be from the
standard Python libraries but rather for a user's custom
extension.
"""

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2006-05-18 15:51

Message:
Logged In: YES 
user_id=6380

Sorry, I don't have access to email that old any more.

HP-UX is quite different now than it was then.

It would make more sense to ask an HP-UX expert.  I'll ask
Peter Kropf, who helped Elemental with the HP-UX port.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-05-13 09:38

Message:
Logged In: YES 
user_id=21627

BIND_FIRST was added with this commit:

------------------------------------------------------------------------
r7068 | guido | 1996-12-06 00:15:35 +0100 (Fr, 06 Dez 1996)
| 2 lines
Ge??nderte Pfade:
   M /python/trunk/Python/importdl.c

Some extra flags that an HPUX user wants me to add.

------------------------------------------------------------------------

Guido, do you have any records on which user that was
and why he wanted these flags to be added?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1487481&group_id=5470

From noreply at sourceforge.net  Sat May 19 01:51:44 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 18 May 2007 16:51:44 -0700
Subject: [ python-Bugs-1712236 ] __getslice__ changes integer arguments
Message-ID: <E1HpCEa-0000d5-Ca@sc8-sf-web21.sourceforge.net>

Bugs item #1712236, was opened at 2007-05-03 13:20
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1712236&group_id=5470

Please note that this message 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
Private: No
Submitted By: Imri Goldberg (lorgandon)
Assigned to: Nobody/Anonymous (nobody)
Summary: __getslice__ changes integer arguments

Initial Comment:
When using slicing for a sequence object, with a user defined __getslice__ function, the arguments to __getslice__ are changed.
This does not happen when __getslice__is called directly.
Attached is some code that demonstrates the problem.

I checked it on various versions, including my
"Python 2.5.1 (r251:54863, May  2 2007, 16:56:35)", on my Ubuntu machine.

Although __getslice__ is deprecated, there is still usage of the function, and a fix would be useful.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-05-18 18:51

Message:
Logged In: YES 
user_id=80475
Originator: NO

Unfortunately, this is a feature, not a bug.  The relevant code is in
Python/ceval.c apply_slice().  Calls to s[a:b] get pre-processed before
being handed-off to s.__getslice__.  This behavior has been around so long,
that it is almost certain that there is a good body of existing code that
relies on the behavior.

----------------------------------------------------------------------

Comment By: Imri Goldberg (lorgandon)
Date: 2007-05-03 13:23

Message:
Logged In: YES 
user_id=1715564
Originator: YES

This also seems to be the cause of bug "[ 908441 ] default index for
__getslice__ is not sys.maxint"

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1712236&group_id=5470

From noreply at sourceforge.net  Sat May 19 01:53:24 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 18 May 2007 16:53:24 -0700
Subject: [ python-Feature Requests-1712419 ] Cannot use dict with unicode keys
	as keyword arguments
Message-ID: <E1HpCGC-0000qa-H6@sc8-sf-web21.sourceforge.net>

Feature Requests item #1712419, was opened at 2007-05-03 17:49
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1712419&group_id=5470

Please note that this 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
Private: No
Submitted By: Viktor Ferenczi (complex)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cannot use dict with unicode keys as keyword arguments

Initial Comment:
Unicode strings cannot be used as keys in dictionaries passed as keyword argument to a function. For example:

Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> def fn(**kw):
...     print repr(kw)
...
>>> fn(**{u'x':1})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: fn() keywords must be strings
>>>

Unicode strings should be converted to str automatically using the site specific default encoding or something similar solution.

This bug caused problems when decoding dictionaries from data formats such as XML or JSON. Usually unicode strings are returned from such modules, such as simplejson. Manual encoding from unicode to str causes performance loss if this cannot be done by Python automatically.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-05-18 18:53

Message:
Logged In: YES 
user_id=80475
Originator: NO

Recommend closing this as not-a-bug. 

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2007-05-04 05:27

Message:
Logged In: YES 
user_id=38388
Originator: NO

Python (currently) does not allow non-ASCII identifiers, so it's not
surprising that Unicode parameter names don't work.

It's also a really bad idea to pass data from an AJAX XML or JSON request
directly to a function without doing at least some post-processing of the
data in order to prevent DOS attacks, code injection, etc.

dict((str(key), value) for key, value in kw.iteritems()) is all that's
needed for the above. 

BTW, I don't think those few micro-seconds really matter in the face of
XML or JSON decoding, network latency, etc. ;-)


----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-03 23:10

Message:
Logged In: YES 
user_id=849994
Originator: NO

In any case, this is a feature request.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1712419&group_id=5470

From noreply at sourceforge.net  Sat May 19 02:25:44 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 18 May 2007 17:25:44 -0700
Subject: [ python-Bugs-1487481 ] Could BIND_FIRST be removed on HP-UX?
Message-ID: <E1HpClU-0005yO-5t@sc8-sf-web23.sourceforge.net>

Bugs item #1487481, was opened at 2006-05-12 11:32
Message generated for change (Settings changed) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1487481&group_id=5470

Please note that this message 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
Private: No
Submitted By: G?ran Uddeborg (goeran)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Could BIND_FIRST be removed on HP-UX?

Initial Comment:
I'm trying to build Python 2.4.3 on HP-UX 11.  I need
tkinter, so I have first built Tcl and Tk 8.4.13.

During the build, the python interpreter crashes.  When
running the setup.py script, just after making the
_tkinter.sl module, it crashes with a memory fault.

I've tried to investigate this, and it seems that
malloc and friends gets confused by the dynamic
loading.  I've filed a support request with HP about this.

One observation I made is that this malloc bug seems to
be connected with the use of BIND_FIRST in
dynload_hpux.c.  If I just remove this flag (in two
places) it appears as if Python works normally.

I'm hesitant if this is a good idea.  BIND_FIRST is
there as an explicit, non-default, flag.  Somebody must
have choosen to do so for some reason.  What was that
reason?  And is it still valid?  If not, maybe the flag
could be removed, and this problem in HP-UX be avoided?

----------------------------------------------------------------------

Comment By: Alexander Tyutyunnik (atyutyunnik)
Date: 2007-05-18 19:41

Message:
Logged In: YES 
user_id=1558596
Originator: NO

I am using on SWIG 1.3.29+ with Python 2.5 on HP-UX 11.23, Itanium 64bit.
It had failed to work (unresolved symbols) until I fixed code this way:
//	flags = BIND_FIRST | BIND_DEFERRED;
	flags = BIND_DEFERRED|BIND_VERBOSE;

instead of:
	flags = BIND_FIRST | BIND_DEFERRED;

Can anyone please fix it?


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2006-05-19 01:45

Message:
Logged In: YES 
user_id=6380

Peter Kropf wrote:

"""
BIND_FIRST causes the dynamic loader to place the newly
loaded shared
library symbol table at the head of the lookup order. This
causes
symbol lookups from that time forward to check the newly
loaded symbol
table before everything else. I can see this causing interesting
things to happen to a program if a shared library contains
symbol
names that are the same as those of, let's say, the C
runtime library.

>From what I remember of Python and HP-UX, I'd guess that
this was
added for an extension module. I don't think that it would
be from the
standard Python libraries but rather for a user's custom
extension.
"""

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2006-05-18 18:51

Message:
Logged In: YES 
user_id=6380

Sorry, I don't have access to email that old any more.

HP-UX is quite different now than it was then.

It would make more sense to ask an HP-UX expert.  I'll ask
Peter Kropf, who helped Elemental with the HP-UX port.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-05-13 12:38

Message:
Logged In: YES 
user_id=21627

BIND_FIRST was added with this commit:

------------------------------------------------------------------------
r7068 | guido | 1996-12-06 00:15:35 +0100 (Fr, 06 Dez 1996)
| 2 lines
Ge??nderte Pfade:
   M /python/trunk/Python/importdl.c

Some extra flags that an HPUX user wants me to add.

------------------------------------------------------------------------

Guido, do you have any records on which user that was
and why he wanted these flags to be added?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1487481&group_id=5470

From noreply at sourceforge.net  Sat May 19 04:28:37 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 18 May 2007 19:28:37 -0700
Subject: [ python-Bugs-1721372 ] emphasize iteration volatility for set
Message-ID: <E1HpEgP-0006iZ-Nc@sc8-sf-web22.sourceforge.net>

Bugs item #1721372, was opened at 2007-05-18 10:10
Message generated for change (Comment added) made by aisaac0
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721372&group_id=5470

Please note that this 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: Rejected
Priority: 5
Private: No
Submitted By: Alan (aisaac0)
Assigned to: Nobody/Anonymous (nobody)
Summary: emphasize iteration volatility for set

Initial Comment:
For <URL:http://docs.python.org/lib/types-set.html>, append the following new sentence to the 2nd paragraph.

    Iteration over a set returns elements in an indeterminate order, which generally depends on factors outside the scope of the containing program.

*Justification:* users should not be expected to understand without being told that iteration order depends on factors outside the scope of the containing program. (Additionally, unlike the documentation for dictionaries, the documentation for sets fails to give a serious warning not to rely on iteration order.)


----------------------------------------------------------------------

>Comment By: Alan (aisaac0)
Date: 2007-05-18 21:28

Message:
Logged In: YES 
user_id=1025672
Originator: YES

While I do not mind my language being rejected, *something* should be
added to warn users.  What the previous comment fails to mention is the
number of people on c.l.python, some of whom are quite sophisticated users,
who failed to discover the source of indeterminacy.  Users should not have
to "rediscover" this because of a documentation failure.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-05-18 18:08

Message:
Logged In: YES 
user_id=80475
Originator: NO

While the OP knows what he means here, the suggested text does not add
clarity, it only makes the subject harder to understand and implies that
some mysterious, dark force is in place.  Further, the suggested text is
simply incorrect.  Given deterministic assignment of hash values and a
consistent insertion order, the order of keys in a set or dictionary is
fully determined.

I've read the source of this suggestion on comp.lang.python and commented
there.  The underlying issue had nothing to do with either sets or dicts. 
The code in question "re-discovered" that the location of objects in memory
 would vary between runs if the user deleted a pyc file for a module.  The
OP's script used object ids as hash values, hence the set/dict ordering
could vary between runs.  This was at odds with his expectation that that
the ordering would be deterministic.  The moral is that non-deterministic
hash values lead to non-deterministic set/dict ordering.

The docs for sets and dicts should not be muddled with tangential
discussions about implementation specific details regarding what governs
where objects are placed in memory.


----------------------------------------------------------------------

Comment By: Alan (aisaac0)
Date: 2007-05-18 13:00

Message:
Logged In: YES 
user_id=1025672
Originator: YES

Location in memory.
See Peter Otten's discussion at
http://www.thescripts.com/forum/post2552380-16.html

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-18 12:05

Message:
Logged In: YES 
user_id=21627
Originator: NO

What factors outside the containing program influence iteration order?
Iteration is completely deterministic, and only depends on the items
inserted, and the order in which they were inserted, neither of which is
outside the scope of the containing program. It's just that the order is
not easily predictable.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721372&group_id=5470

From noreply at sourceforge.net  Sat May 19 05:54:33 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 18 May 2007 20:54:33 -0700
Subject: [ python-Bugs-1721309 ] make testall shows many glibc detected malloc
	corruptions
Message-ID: <E1HpG1Z-0002ub-1P@sc8-sf-web23.sourceforge.net>

Bugs item #1721309, was opened at 2007-05-18 06:42
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721309&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Extension Modules
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: David Favor (dfavor)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: make testall shows many glibc detected malloc corruptions

Initial Comment:
export _MALLOC_CHECK_=1
make testall

test_bsddb3
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***

followed by deadlock errors.

malloc: using debugging hooks
blattest test_tempfile failed -- Traceback (most recent call last):
  File "/build/work/Python-2.5.1/Lib/test/test_tempfile.py", line 310, in test_noinherit
    self.failIf(retval > 0, "child process reports failure %d"%retval)
AssertionError: child process reports failure 1

test_timeout
test test_timeout failed -- Traceback (most recent call last):
  File "/build/work/Python-2.5.1/Lib/test/test_timeout.py", line 128, in testConnectTimeout
    %(_delta, self.fuzz, _timeout))
AssertionError: timeout (8.20631) is more than 2 seconds more than expected (0.001)


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-18 20:54

Message:
Logged In: YES 
user_id=33168
Originator: NO

Thanks for the report David.  It would be great if you could test the
change.  I couldn't find any other places that had a similar problem, but
you never know.  You will need to pull out of SVN.  It's a one line change
if you want to apply manually.

Committed revision 55450.
Committed revision 55451. (2.5)


----------------------------------------------------------------------

Comment By: David Favor (dfavor)
Date: 2007-05-18 14:26

Message:
Logged In: YES 
user_id=370230
Originator: YES

The os I'm running is Fedora 6 with latest patches.

gcc is 4.1.1

glibc is 2.5

I had to set MALLOC_CHECK_=1 just to get the suite to run as normal
MALLOC_CHECK_ defaults to die when something evil occurs.

I'll build gcc 4.2, rebuild and see what occurs.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-18 14:02

Message:
Logged In: YES 
user_id=849994
Originator: NO

I don't even need to set an environment variable to get

~/devel/python> ./python Lib/test/regrtest.py -uall test_bsddb3
test_bsddb3
*** glibc detected *** ./python: free(): invalid pointer: 0x0827874c ***
[1]    17141 abort      ./python Lib/test/regrtest.py -uall test_bsddb3

(HEAD, linux x86, gcc 4.1.2, glibc 2.5)

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-18 10:43

Message:
Logged In: YES 
user_id=21627
Originator: NO

Unfortunately, I cannot reproduce this problem on Debian unstable (x86,
gcc 4.1.3, glibc 2.5) - 
the test passes just fine with _MALLOC_CHECK set.

Can you provide a few more details: glibc version, compiler version, Linux
distribution, processor architecture, precise Python version being test,
does the error happen on the first or a subsequent cycle of all tests?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721309&group_id=5470

From noreply at sourceforge.net  Sat May 19 06:38:32 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 18 May 2007 21:38:32 -0700
Subject: [ python-Bugs-1721309 ] make testall shows many glibc detected malloc
	corruptions
Message-ID: <E1HpGi8-0007bU-CF@sc8-sf-web23.sourceforge.net>

Bugs item #1721309, was opened at 2007-05-18 06:42
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721309&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.5
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: David Favor (dfavor)
Assigned to: Neal Norwitz (nnorwitz)
Summary: make testall shows many glibc detected malloc corruptions

Initial Comment:
export _MALLOC_CHECK_=1
make testall

test_bsddb3
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***

followed by deadlock errors.

malloc: using debugging hooks
blattest test_tempfile failed -- Traceback (most recent call last):
  File "/build/work/Python-2.5.1/Lib/test/test_tempfile.py", line 310, in test_noinherit
    self.failIf(retval > 0, "child process reports failure %d"%retval)
AssertionError: child process reports failure 1

test_timeout
test test_timeout failed -- Traceback (most recent call last):
  File "/build/work/Python-2.5.1/Lib/test/test_timeout.py", line 128, in testConnectTimeout
    %(_delta, self.fuzz, _timeout))
AssertionError: timeout (8.20631) is more than 2 seconds more than expected (0.001)


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-18 21:38

Message:
Logged In: YES 
user_id=33168
Originator: NO

I screwed up the first checkin.  The CLEAR_DBT was in the wrong place. 
The fixes are in:

Committed revision 55452. 
Committed revision 55454. (2.5)


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-18 20:54

Message:
Logged In: YES 
user_id=33168
Originator: NO

Thanks for the report David.  It would be great if you could test the
change.  I couldn't find any other places that had a similar problem, but
you never know.  You will need to pull out of SVN.  It's a one line change
if you want to apply manually.

Committed revision 55450.
Committed revision 55451. (2.5)


----------------------------------------------------------------------

Comment By: David Favor (dfavor)
Date: 2007-05-18 14:26

Message:
Logged In: YES 
user_id=370230
Originator: YES

The os I'm running is Fedora 6 with latest patches.

gcc is 4.1.1

glibc is 2.5

I had to set MALLOC_CHECK_=1 just to get the suite to run as normal
MALLOC_CHECK_ defaults to die when something evil occurs.

I'll build gcc 4.2, rebuild and see what occurs.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-18 14:02

Message:
Logged In: YES 
user_id=849994
Originator: NO

I don't even need to set an environment variable to get

~/devel/python> ./python Lib/test/regrtest.py -uall test_bsddb3
test_bsddb3
*** glibc detected *** ./python: free(): invalid pointer: 0x0827874c ***
[1]    17141 abort      ./python Lib/test/regrtest.py -uall test_bsddb3

(HEAD, linux x86, gcc 4.1.2, glibc 2.5)

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-18 10:43

Message:
Logged In: YES 
user_id=21627
Originator: NO

Unfortunately, I cannot reproduce this problem on Debian unstable (x86,
gcc 4.1.3, glibc 2.5) - 
the test passes just fine with _MALLOC_CHECK set.

Can you provide a few more details: glibc version, compiler version, Linux
distribution, processor architecture, precise Python version being test,
does the error happen on the first or a subsequent cycle of all tests?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721309&group_id=5470

From noreply at sourceforge.net  Sat May 19 08:38:18 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 18 May 2007 23:38:18 -0700
Subject: [ python-Bugs-1721372 ] emphasize iteration volatility for set
Message-ID: <E1HpIa2-0008SI-D7@sc8-sf-web24.sourceforge.net>

Bugs item #1721372, was opened at 2007-05-18 17:10
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721372&group_id=5470

Please note that this 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: Rejected
Priority: 5
Private: No
Submitted By: Alan (aisaac0)
Assigned to: Nobody/Anonymous (nobody)
Summary: emphasize iteration volatility for set

Initial Comment:
For <URL:http://docs.python.org/lib/types-set.html>, append the following new sentence to the 2nd paragraph.

    Iteration over a set returns elements in an indeterminate order, which generally depends on factors outside the scope of the containing program.

*Justification:* users should not be expected to understand without being told that iteration order depends on factors outside the scope of the containing program. (Additionally, unlike the documentation for dictionaries, the documentation for sets fails to give a serious warning not to rely on iteration order.)


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2007-05-19 08:38

Message:
Logged In: YES 
user_id=21627
Originator: NO

The documentation already says "Being an unordered collection, sets do not
record element position or order of insertion."

If users read this and fail to understand the notion of an unordered
collection, I see no way of "fixing" this.

----------------------------------------------------------------------

Comment By: Alan (aisaac0)
Date: 2007-05-19 04:28

Message:
Logged In: YES 
user_id=1025672
Originator: YES

While I do not mind my language being rejected, *something* should be
added to warn users.  What the previous comment fails to mention is the
number of people on c.l.python, some of whom are quite sophisticated users,
who failed to discover the source of indeterminacy.  Users should not have
to "rediscover" this because of a documentation failure.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-05-19 01:08

Message:
Logged In: YES 
user_id=80475
Originator: NO

While the OP knows what he means here, the suggested text does not add
clarity, it only makes the subject harder to understand and implies that
some mysterious, dark force is in place.  Further, the suggested text is
simply incorrect.  Given deterministic assignment of hash values and a
consistent insertion order, the order of keys in a set or dictionary is
fully determined.

I've read the source of this suggestion on comp.lang.python and commented
there.  The underlying issue had nothing to do with either sets or dicts. 
The code in question "re-discovered" that the location of objects in memory
 would vary between runs if the user deleted a pyc file for a module.  The
OP's script used object ids as hash values, hence the set/dict ordering
could vary between runs.  This was at odds with his expectation that that
the ordering would be deterministic.  The moral is that non-deterministic
hash values lead to non-deterministic set/dict ordering.

The docs for sets and dicts should not be muddled with tangential
discussions about implementation specific details regarding what governs
where objects are placed in memory.


----------------------------------------------------------------------

Comment By: Alan (aisaac0)
Date: 2007-05-18 20:00

Message:
Logged In: YES 
user_id=1025672
Originator: YES

Location in memory.
See Peter Otten's discussion at
http://www.thescripts.com/forum/post2552380-16.html

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-18 19:05

Message:
Logged In: YES 
user_id=21627
Originator: NO

What factors outside the containing program influence iteration order?
Iteration is completely deterministic, and only depends on the items
inserted, and the order in which they were inserted, neither of which is
outside the scope of the containing program. It's just that the order is
not easily predictable.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721372&group_id=5470

From noreply at sourceforge.net  Sat May 19 09:04:25 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 19 May 2007 00:04:25 -0700
Subject: [ python-Bugs-1721309 ] make testall shows many glibc detected malloc
	corruptions
Message-ID: <E1HpIzJ-0006FB-AP@sc8-sf-web23.sourceforge.net>

Bugs item #1721309, was opened at 2007-05-18 15:42
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721309&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.5
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: David Favor (dfavor)
Assigned to: Neal Norwitz (nnorwitz)
Summary: make testall shows many glibc detected malloc corruptions

Initial Comment:
export _MALLOC_CHECK_=1
make testall

test_bsddb3
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***

followed by deadlock errors.

malloc: using debugging hooks
blattest test_tempfile failed -- Traceback (most recent call last):
  File "/build/work/Python-2.5.1/Lib/test/test_tempfile.py", line 310, in test_noinherit
    self.failIf(retval > 0, "child process reports failure %d"%retval)
AssertionError: child process reports failure 1

test_timeout
test test_timeout failed -- Traceback (most recent call last):
  File "/build/work/Python-2.5.1/Lib/test/test_timeout.py", line 128, in testConnectTimeout
    %(_delta, self.fuzz, _timeout))
AssertionError: timeout (8.20631) is more than 2 seconds more than expected (0.001)


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2007-05-19 09:04

Message:
Logged In: YES 
user_id=21627
Originator: NO

dfavor: I see. It is MALLOC_CHECK_, not _MALLOC_CHECK (as I used it), and
not _MALLOC_CHECK_ (as you wrote). I now see that debug hooks are used, but
I still cannot reproduce the problem...

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-19 06:38

Message:
Logged In: YES 
user_id=33168
Originator: NO

I screwed up the first checkin.  The CLEAR_DBT was in the wrong place. 
The fixes are in:

Committed revision 55452. 
Committed revision 55454. (2.5)


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-19 05:54

Message:
Logged In: YES 
user_id=33168
Originator: NO

Thanks for the report David.  It would be great if you could test the
change.  I couldn't find any other places that had a similar problem, but
you never know.  You will need to pull out of SVN.  It's a one line change
if you want to apply manually.

Committed revision 55450.
Committed revision 55451. (2.5)


----------------------------------------------------------------------

Comment By: David Favor (dfavor)
Date: 2007-05-18 23:26

Message:
Logged In: YES 
user_id=370230
Originator: YES

The os I'm running is Fedora 6 with latest patches.

gcc is 4.1.1

glibc is 2.5

I had to set MALLOC_CHECK_=1 just to get the suite to run as normal
MALLOC_CHECK_ defaults to die when something evil occurs.

I'll build gcc 4.2, rebuild and see what occurs.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-18 23:02

Message:
Logged In: YES 
user_id=849994
Originator: NO

I don't even need to set an environment variable to get

~/devel/python> ./python Lib/test/regrtest.py -uall test_bsddb3
test_bsddb3
*** glibc detected *** ./python: free(): invalid pointer: 0x0827874c ***
[1]    17141 abort      ./python Lib/test/regrtest.py -uall test_bsddb3

(HEAD, linux x86, gcc 4.1.2, glibc 2.5)

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-18 19:43

Message:
Logged In: YES 
user_id=21627
Originator: NO

Unfortunately, I cannot reproduce this problem on Debian unstable (x86,
gcc 4.1.3, glibc 2.5) - 
the test passes just fine with _MALLOC_CHECK set.

Can you provide a few more details: glibc version, compiler version, Linux
distribution, processor architecture, precise Python version being test,
does the error happen on the first or a subsequent cycle of all tests?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721309&group_id=5470

From noreply at sourceforge.net  Sat May 19 09:08:26 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 19 May 2007 00:08:26 -0700
Subject: [ python-Bugs-1721309 ] make testall shows many glibc detected malloc
	corruptions
Message-ID: <E1HpJ3C-0006g9-V1@sc8-sf-web23.sourceforge.net>

Bugs item #1721309, was opened at 2007-05-18 15:42
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721309&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.5
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: David Favor (dfavor)
Assigned to: Neal Norwitz (nnorwitz)
Summary: make testall shows many glibc detected malloc corruptions

Initial Comment:
export _MALLOC_CHECK_=1
make testall

test_bsddb3
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***

followed by deadlock errors.

malloc: using debugging hooks
blattest test_tempfile failed -- Traceback (most recent call last):
  File "/build/work/Python-2.5.1/Lib/test/test_tempfile.py", line 310, in test_noinherit
    self.failIf(retval > 0, "child process reports failure %d"%retval)
AssertionError: child process reports failure 1

test_timeout
test test_timeout failed -- Traceback (most recent call last):
  File "/build/work/Python-2.5.1/Lib/test/test_timeout.py", line 128, in testConnectTimeout
    %(_delta, self.fuzz, _timeout))
AssertionError: timeout (8.20631) is more than 2 seconds more than expected (0.001)


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2007-05-19 09:08

Message:
Logged In: YES 
user_id=21627
Originator: NO

(I'm not convinced that Neal's patch could actually fix anything)

Can people who were able to reproduce this please report their bdb version
also; I was using 4.4.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-19 09:04

Message:
Logged In: YES 
user_id=21627
Originator: NO

dfavor: I see. It is MALLOC_CHECK_, not _MALLOC_CHECK (as I used it), and
not _MALLOC_CHECK_ (as you wrote). I now see that debug hooks are used, but
I still cannot reproduce the problem...

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-19 06:38

Message:
Logged In: YES 
user_id=33168
Originator: NO

I screwed up the first checkin.  The CLEAR_DBT was in the wrong place. 
The fixes are in:

Committed revision 55452. 
Committed revision 55454. (2.5)


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-19 05:54

Message:
Logged In: YES 
user_id=33168
Originator: NO

Thanks for the report David.  It would be great if you could test the
change.  I couldn't find any other places that had a similar problem, but
you never know.  You will need to pull out of SVN.  It's a one line change
if you want to apply manually.

Committed revision 55450.
Committed revision 55451. (2.5)


----------------------------------------------------------------------

Comment By: David Favor (dfavor)
Date: 2007-05-18 23:26

Message:
Logged In: YES 
user_id=370230
Originator: YES

The os I'm running is Fedora 6 with latest patches.

gcc is 4.1.1

glibc is 2.5

I had to set MALLOC_CHECK_=1 just to get the suite to run as normal
MALLOC_CHECK_ defaults to die when something evil occurs.

I'll build gcc 4.2, rebuild and see what occurs.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-18 23:02

Message:
Logged In: YES 
user_id=849994
Originator: NO

I don't even need to set an environment variable to get

~/devel/python> ./python Lib/test/regrtest.py -uall test_bsddb3
test_bsddb3
*** glibc detected *** ./python: free(): invalid pointer: 0x0827874c ***
[1]    17141 abort      ./python Lib/test/regrtest.py -uall test_bsddb3

(HEAD, linux x86, gcc 4.1.2, glibc 2.5)

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-18 19:43

Message:
Logged In: YES 
user_id=21627
Originator: NO

Unfortunately, I cannot reproduce this problem on Debian unstable (x86,
gcc 4.1.3, glibc 2.5) - 
the test passes just fine with _MALLOC_CHECK set.

Can you provide a few more details: glibc version, compiler version, Linux
distribution, processor architecture, precise Python version being test,
does the error happen on the first or a subsequent cycle of all tests?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721309&group_id=5470

From noreply at sourceforge.net  Sat May 19 12:31:18 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 19 May 2007 03:31:18 -0700
Subject: [ python-Bugs-1721309 ] make testall shows many glibc detected malloc
	corruptions
Message-ID: <E1HpMDW-0000zg-Vj@sc8-sf-web23.sourceforge.net>

Bugs item #1721309, was opened at 2007-05-18 13:42
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721309&group_id=5470

Please note that this 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: Fixed
Priority: 5
Private: No
Submitted By: David Favor (dfavor)
Assigned to: Neal Norwitz (nnorwitz)
Summary: make testall shows many glibc detected malloc corruptions

Initial Comment:
export _MALLOC_CHECK_=1
make testall

test_bsddb3
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***

followed by deadlock errors.

malloc: using debugging hooks
blattest test_tempfile failed -- Traceback (most recent call last):
  File "/build/work/Python-2.5.1/Lib/test/test_tempfile.py", line 310, in test_noinherit
    self.failIf(retval > 0, "child process reports failure %d"%retval)
AssertionError: child process reports failure 1

test_timeout
test test_timeout failed -- Traceback (most recent call last):
  File "/build/work/Python-2.5.1/Lib/test/test_timeout.py", line 128, in testConnectTimeout
    %(_delta, self.fuzz, _timeout))
AssertionError: timeout (8.20631) is more than 2 seconds more than expected (0.001)


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-19 10:31

Message:
Logged In: YES 
user_id=849994
Originator: NO

I can confirm that the checkin didn't change anything for me.

I use bsddb version 4.5.20_p2 from Gentoo.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-19 07:08

Message:
Logged In: YES 
user_id=21627
Originator: NO

(I'm not convinced that Neal's patch could actually fix anything)

Can people who were able to reproduce this please report their bdb version
also; I was using 4.4.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-19 07:04

Message:
Logged In: YES 
user_id=21627
Originator: NO

dfavor: I see. It is MALLOC_CHECK_, not _MALLOC_CHECK (as I used it), and
not _MALLOC_CHECK_ (as you wrote). I now see that debug hooks are used, but
I still cannot reproduce the problem...

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-19 04:38

Message:
Logged In: YES 
user_id=33168
Originator: NO

I screwed up the first checkin.  The CLEAR_DBT was in the wrong place. 
The fixes are in:

Committed revision 55452. 
Committed revision 55454. (2.5)


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-19 03:54

Message:
Logged In: YES 
user_id=33168
Originator: NO

Thanks for the report David.  It would be great if you could test the
change.  I couldn't find any other places that had a similar problem, but
you never know.  You will need to pull out of SVN.  It's a one line change
if you want to apply manually.

Committed revision 55450.
Committed revision 55451. (2.5)


----------------------------------------------------------------------

Comment By: David Favor (dfavor)
Date: 2007-05-18 21:26

Message:
Logged In: YES 
user_id=370230
Originator: YES

The os I'm running is Fedora 6 with latest patches.

gcc is 4.1.1

glibc is 2.5

I had to set MALLOC_CHECK_=1 just to get the suite to run as normal
MALLOC_CHECK_ defaults to die when something evil occurs.

I'll build gcc 4.2, rebuild and see what occurs.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-18 21:02

Message:
Logged In: YES 
user_id=849994
Originator: NO

I don't even need to set an environment variable to get

~/devel/python> ./python Lib/test/regrtest.py -uall test_bsddb3
test_bsddb3
*** glibc detected *** ./python: free(): invalid pointer: 0x0827874c ***
[1]    17141 abort      ./python Lib/test/regrtest.py -uall test_bsddb3

(HEAD, linux x86, gcc 4.1.2, glibc 2.5)

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-18 17:43

Message:
Logged In: YES 
user_id=21627
Originator: NO

Unfortunately, I cannot reproduce this problem on Debian unstable (x86,
gcc 4.1.3, glibc 2.5) - 
the test passes just fine with _MALLOC_CHECK set.

Can you provide a few more details: glibc version, compiler version, Linux
distribution, processor architecture, precise Python version being test,
does the error happen on the first or a subsequent cycle of all tests?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721309&group_id=5470

From noreply at sourceforge.net  Sat May 19 15:09:36 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 19 May 2007 06:09:36 -0700
Subject: [ python-Bugs-1721372 ] emphasize iteration volatility for set
Message-ID: <E1HpOgi-0001AO-Ky@sc8-sf-web23.sourceforge.net>

Bugs item #1721372, was opened at 2007-05-18 10:10
Message generated for change (Comment added) made by aisaac0
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721372&group_id=5470

Please note that this 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: Rejected
Priority: 5
Private: No
Submitted By: Alan (aisaac0)
Assigned to: Nobody/Anonymous (nobody)
Summary: emphasize iteration volatility for set

Initial Comment:
For <URL:http://docs.python.org/lib/types-set.html>, append the following new sentence to the 2nd paragraph.

    Iteration over a set returns elements in an indeterminate order, which generally depends on factors outside the scope of the containing program.

*Justification:* users should not be expected to understand without being told that iteration order depends on factors outside the scope of the containing program. (Additionally, unlike the documentation for dictionaries, the documentation for sets fails to give a serious warning not to rely on iteration order.)


----------------------------------------------------------------------

>Comment By: Alan (aisaac0)
Date: 2007-05-19 08:09

Message:
Logged In: YES 
user_id=1025672
Originator: YES

The previous comment completely misses the point.  Again, please see the
discussion on c.l.python.  Not one of the participants expected sets to be
"ordered". What was suprising to them was the order can *change* across
sequential executions of an **unchanged** source.   This is of course
*quite* different than expecting that sets are ordered; I am perplexed that
anyone would conflate the two.  One cannot credibly argue that anyone who
understands that sets are not ordered will not be surprised, since even
sophisticated users were as a matter of fact surprised in the c.l.python
discussion.  (Until it was explained by Peter of course.)  A natural
conclusion is that the docs should offer better protection against such
surprise, since we have concrete evidence that even sophisticated users can
be surprised by this.

In sum, the previous comment conflates two distinct issues and so fails to
address the reasons for the proposed docs patch.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-19 01:38

Message:
Logged In: YES 
user_id=21627
Originator: NO

The documentation already says "Being an unordered collection, sets do not
record element position or order of insertion."

If users read this and fail to understand the notion of an unordered
collection, I see no way of "fixing" this.

----------------------------------------------------------------------

Comment By: Alan (aisaac0)
Date: 2007-05-18 21:28

Message:
Logged In: YES 
user_id=1025672
Originator: YES

While I do not mind my language being rejected, *something* should be
added to warn users.  What the previous comment fails to mention is the
number of people on c.l.python, some of whom are quite sophisticated users,
who failed to discover the source of indeterminacy.  Users should not have
to "rediscover" this because of a documentation failure.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-05-18 18:08

Message:
Logged In: YES 
user_id=80475
Originator: NO

While the OP knows what he means here, the suggested text does not add
clarity, it only makes the subject harder to understand and implies that
some mysterious, dark force is in place.  Further, the suggested text is
simply incorrect.  Given deterministic assignment of hash values and a
consistent insertion order, the order of keys in a set or dictionary is
fully determined.

I've read the source of this suggestion on comp.lang.python and commented
there.  The underlying issue had nothing to do with either sets or dicts. 
The code in question "re-discovered" that the location of objects in memory
 would vary between runs if the user deleted a pyc file for a module.  The
OP's script used object ids as hash values, hence the set/dict ordering
could vary between runs.  This was at odds with his expectation that that
the ordering would be deterministic.  The moral is that non-deterministic
hash values lead to non-deterministic set/dict ordering.

The docs for sets and dicts should not be muddled with tangential
discussions about implementation specific details regarding what governs
where objects are placed in memory.


----------------------------------------------------------------------

Comment By: Alan (aisaac0)
Date: 2007-05-18 13:00

Message:
Logged In: YES 
user_id=1025672
Originator: YES

Location in memory.
See Peter Otten's discussion at
http://www.thescripts.com/forum/post2552380-16.html

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-18 12:05

Message:
Logged In: YES 
user_id=21627
Originator: NO

What factors outside the containing program influence iteration order?
Iteration is completely deterministic, and only depends on the items
inserted, and the order in which they were inserted, neither of which is
outside the scope of the containing program. It's just that the order is
not easily predictable.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721372&group_id=5470

From noreply at sourceforge.net  Sat May 19 16:03:55 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 19 May 2007 07:03:55 -0700
Subject: [ python-Bugs-1721812 ] A subclass of set doesn't always have
	__init__ called.
Message-ID: <E1HpPXH-0002m3-6f@sc8-sf-web21.sourceforge.net>

Bugs item #1721812, was opened at 2007-05-19 10: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=1721812&group_id=5470

Please note that this message will contain 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
Private: No
Submitted By: David Benbennick (dbenbenn)
Assigned to: Nobody/Anonymous (nobody)
Summary: A subclass of set doesn't always have __init__ called.

Initial Comment:
Consider the following code:

>>> class foo(set):
...     def __init__(self, iter):
...         print "foo.__init__"
...         set.__init__(self, iter)
... 
>>> x = foo([1,2])
foo.__init__
>>> y = foo([2,3])
foo.__init__
>>> x & y
foo([2])

As you can see, the foo.__and__ method creates a new foo object without calling foo.__init__.

The problem is in Objects/setobject.c:make_new_set().

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721812&group_id=5470

From noreply at sourceforge.net  Sat May 19 17:04:10 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 19 May 2007 08:04:10 -0700
Subject: [ python-Bugs-1721309 ] make testall shows many glibc detected malloc
	corruptions
Message-ID: <E1HpQTa-0005Bq-2O@sc8-sf-web23.sourceforge.net>

Bugs item #1721309, was opened at 2007-05-18 08:42
Message generated for change (Comment added) made by dfavor
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721309&group_id=5470

Please note that this 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: Fixed
Priority: 5
Private: No
Submitted By: David Favor (dfavor)
Assigned to: Neal Norwitz (nnorwitz)
Summary: make testall shows many glibc detected malloc corruptions

Initial Comment:
export _MALLOC_CHECK_=1
make testall

test_bsddb3
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***

followed by deadlock errors.

malloc: using debugging hooks
blattest test_tempfile failed -- Traceback (most recent call last):
  File "/build/work/Python-2.5.1/Lib/test/test_tempfile.py", line 310, in test_noinherit
    self.failIf(retval > 0, "child process reports failure %d"%retval)
AssertionError: child process reports failure 1

test_timeout
test test_timeout failed -- Traceback (most recent call last):
  File "/build/work/Python-2.5.1/Lib/test/test_timeout.py", line 128, in testConnectTimeout
    %(_delta, self.fuzz, _timeout))
AssertionError: timeout (8.20631) is more than 2 seconds more than expected (0.001)


----------------------------------------------------------------------

>Comment By: David Favor (dfavor)
Date: 2007-05-19 10:04

Message:
Logged In: YES 
user_id=370230
Originator: YES

My test was done with latest BerkeleyDB 4.5.20 plain (no patches).

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-19 05:31

Message:
Logged In: YES 
user_id=849994
Originator: NO

I can confirm that the checkin didn't change anything for me.

I use bsddb version 4.5.20_p2 from Gentoo.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-19 02:08

Message:
Logged In: YES 
user_id=21627
Originator: NO

(I'm not convinced that Neal's patch could actually fix anything)

Can people who were able to reproduce this please report their bdb version
also; I was using 4.4.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-19 02:04

Message:
Logged In: YES 
user_id=21627
Originator: NO

dfavor: I see. It is MALLOC_CHECK_, not _MALLOC_CHECK (as I used it), and
not _MALLOC_CHECK_ (as you wrote). I now see that debug hooks are used, but
I still cannot reproduce the problem...

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-18 23:38

Message:
Logged In: YES 
user_id=33168
Originator: NO

I screwed up the first checkin.  The CLEAR_DBT was in the wrong place. 
The fixes are in:

Committed revision 55452. 
Committed revision 55454. (2.5)


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-18 22:54

Message:
Logged In: YES 
user_id=33168
Originator: NO

Thanks for the report David.  It would be great if you could test the
change.  I couldn't find any other places that had a similar problem, but
you never know.  You will need to pull out of SVN.  It's a one line change
if you want to apply manually.

Committed revision 55450.
Committed revision 55451. (2.5)


----------------------------------------------------------------------

Comment By: David Favor (dfavor)
Date: 2007-05-18 16:26

Message:
Logged In: YES 
user_id=370230
Originator: YES

The os I'm running is Fedora 6 with latest patches.

gcc is 4.1.1

glibc is 2.5

I had to set MALLOC_CHECK_=1 just to get the suite to run as normal
MALLOC_CHECK_ defaults to die when something evil occurs.

I'll build gcc 4.2, rebuild and see what occurs.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-18 16:02

Message:
Logged In: YES 
user_id=849994
Originator: NO

I don't even need to set an environment variable to get

~/devel/python> ./python Lib/test/regrtest.py -uall test_bsddb3
test_bsddb3
*** glibc detected *** ./python: free(): invalid pointer: 0x0827874c ***
[1]    17141 abort      ./python Lib/test/regrtest.py -uall test_bsddb3

(HEAD, linux x86, gcc 4.1.2, glibc 2.5)

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-18 12:43

Message:
Logged In: YES 
user_id=21627
Originator: NO

Unfortunately, I cannot reproduce this problem on Debian unstable (x86,
gcc 4.1.3, glibc 2.5) - 
the test passes just fine with _MALLOC_CHECK set.

Can you provide a few more details: glibc version, compiler version, Linux
distribution, processor architecture, precise Python version being test,
does the error happen on the first or a subsequent cycle of all tests?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721309&group_id=5470

From noreply at sourceforge.net  Sat May 19 17:05:47 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 19 May 2007 08:05:47 -0700
Subject: [ python-Bugs-1721309 ] make testall shows many glibc detected malloc
	corruptions
Message-ID: <E1HpQV9-0005JE-JO@sc8-sf-web23.sourceforge.net>

Bugs item #1721309, was opened at 2007-05-18 08:42
Message generated for change (Comment added) made by dfavor
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721309&group_id=5470

Please note that this 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: Fixed
Priority: 5
Private: No
Submitted By: David Favor (dfavor)
Assigned to: Neal Norwitz (nnorwitz)
Summary: make testall shows many glibc detected malloc corruptions

Initial Comment:
export _MALLOC_CHECK_=1
make testall

test_bsddb3
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***

followed by deadlock errors.

malloc: using debugging hooks
blattest test_tempfile failed -- Traceback (most recent call last):
  File "/build/work/Python-2.5.1/Lib/test/test_tempfile.py", line 310, in test_noinherit
    self.failIf(retval > 0, "child process reports failure %d"%retval)
AssertionError: child process reports failure 1

test_timeout
test test_timeout failed -- Traceback (most recent call last):
  File "/build/work/Python-2.5.1/Lib/test/test_timeout.py", line 128, in testConnectTimeout
    %(_delta, self.fuzz, _timeout))
AssertionError: timeout (8.20631) is more than 2 seconds more than expected (0.001)


----------------------------------------------------------------------

>Comment By: David Favor (dfavor)
Date: 2007-05-19 10:05

Message:
Logged In: YES 
user_id=370230
Originator: YES

Just built with latest
http://svn.python.org/projects/python/branches/release25-maint
pull and problem still remains.

----------------------------------------------------------------------

Comment By: David Favor (dfavor)
Date: 2007-05-19 10:04

Message:
Logged In: YES 
user_id=370230
Originator: YES

My test was done with latest BerkeleyDB 4.5.20 plain (no patches).

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-19 05:31

Message:
Logged In: YES 
user_id=849994
Originator: NO

I can confirm that the checkin didn't change anything for me.

I use bsddb version 4.5.20_p2 from Gentoo.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-19 02:08

Message:
Logged In: YES 
user_id=21627
Originator: NO

(I'm not convinced that Neal's patch could actually fix anything)

Can people who were able to reproduce this please report their bdb version
also; I was using 4.4.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-19 02:04

Message:
Logged In: YES 
user_id=21627
Originator: NO

dfavor: I see. It is MALLOC_CHECK_, not _MALLOC_CHECK (as I used it), and
not _MALLOC_CHECK_ (as you wrote). I now see that debug hooks are used, but
I still cannot reproduce the problem...

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-18 23:38

Message:
Logged In: YES 
user_id=33168
Originator: NO

I screwed up the first checkin.  The CLEAR_DBT was in the wrong place. 
The fixes are in:

Committed revision 55452. 
Committed revision 55454. (2.5)


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-18 22:54

Message:
Logged In: YES 
user_id=33168
Originator: NO

Thanks for the report David.  It would be great if you could test the
change.  I couldn't find any other places that had a similar problem, but
you never know.  You will need to pull out of SVN.  It's a one line change
if you want to apply manually.

Committed revision 55450.
Committed revision 55451. (2.5)


----------------------------------------------------------------------

Comment By: David Favor (dfavor)
Date: 2007-05-18 16:26

Message:
Logged In: YES 
user_id=370230
Originator: YES

The os I'm running is Fedora 6 with latest patches.

gcc is 4.1.1

glibc is 2.5

I had to set MALLOC_CHECK_=1 just to get the suite to run as normal
MALLOC_CHECK_ defaults to die when something evil occurs.

I'll build gcc 4.2, rebuild and see what occurs.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-18 16:02

Message:
Logged In: YES 
user_id=849994
Originator: NO

I don't even need to set an environment variable to get

~/devel/python> ./python Lib/test/regrtest.py -uall test_bsddb3
test_bsddb3
*** glibc detected *** ./python: free(): invalid pointer: 0x0827874c ***
[1]    17141 abort      ./python Lib/test/regrtest.py -uall test_bsddb3

(HEAD, linux x86, gcc 4.1.2, glibc 2.5)

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-18 12:43

Message:
Logged In: YES 
user_id=21627
Originator: NO

Unfortunately, I cannot reproduce this problem on Debian unstable (x86,
gcc 4.1.3, glibc 2.5) - 
the test passes just fine with _MALLOC_CHECK set.

Can you provide a few more details: glibc version, compiler version, Linux
distribution, processor architecture, precise Python version being test,
does the error happen on the first or a subsequent cycle of all tests?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721309&group_id=5470

From noreply at sourceforge.net  Sat May 19 18:06:25 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 19 May 2007 09:06:25 -0700
Subject: [ python-Bugs-1721862 ] email.FeedParser.BufferedSubFile improperly
	handles "\r\n"
Message-ID: <E1HpRRp-0001pA-TK@sc8-sf-web22.sourceforge.net>

Bugs item #1721862, was opened at 2007-05-19 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=1721862&group_id=5470

Please note that this message will contain a full 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
Private: No
Submitted By: Sye van der Veen (syeberman)
Assigned to: Nobody/Anonymous (nobody)
Summary: email.FeedParser.BufferedSubFile improperly handles "\r\n"

Initial Comment:
When email.FeedParser.BufferedSubFile sees "\r" at the end of the pushed-in data, it assumes that it is a Macintosh-style line terminator.  Instead, it should request more data, to ensure that the next character is not "\n", which would make it a Windows-style line terminator.  This affects email.message_from_file, which reads in the data in 8192 byte chunks.  The following code demonstrates this:

====================================
from StringIO import StringIO
from email.FeedParser import \
    BufferedSubFile, NeedMoreData

fp = StringIO( "1\r\n10\r\n100\r\n"
               "1000\r\n10000\r\n" )
bsf = BufferedSubFile( )
while True:
    data = fp.read( 3 )
    if not data:
        break
    bsf.push( data )
    for line in bsf:
        if line is NeedMoreData:
            break
        print repr( line )
bsf.close()
====================================

The output is:
====================================
'1\r\n'
'10\r'
'\n'
'100\r\n'
'1000\r\n'
'10000\r'
'\n'
====================================




----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721862&group_id=5470

From noreply at sourceforge.net  Sat May 19 18:09:58 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 19 May 2007 09:09:58 -0700
Subject: [ python-Bugs-1721862 ] email.FeedParser.BufferedSubFile improperly
	handles "\r\n"
Message-ID: <E1HpRVG-0008ID-Ey@sc8-sf-web21.sourceforge.net>

Bugs item #1721862, was opened at 2007-05-19 11:06
Message generated for change (Comment added) made by syeberman
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721862&group_id=5470

Please note that this message will contain a full 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
Private: No
Submitted By: Sye van der Veen (syeberman)
Assigned to: Nobody/Anonymous (nobody)
Summary: email.FeedParser.BufferedSubFile improperly handles "\r\n"

Initial Comment:
When email.FeedParser.BufferedSubFile sees "\r" at the end of the pushed-in data, it assumes that it is a Macintosh-style line terminator.  Instead, it should request more data, to ensure that the next character is not "\n", which would make it a Windows-style line terminator.  This affects email.message_from_file, which reads in the data in 8192 byte chunks.  The following code demonstrates this:

====================================
from StringIO import StringIO
from email.FeedParser import \
    BufferedSubFile, NeedMoreData

fp = StringIO( "1\r\n10\r\n100\r\n"
               "1000\r\n10000\r\n" )
bsf = BufferedSubFile( )
while True:
    data = fp.read( 3 )
    if not data:
        break
    bsf.push( data )
    for line in bsf:
        if line is NeedMoreData:
            break
        print repr( line )
bsf.close()
====================================

The output is:
====================================
'1\r\n'
'10\r'
'\n'
'100\r\n'
'1000\r\n'
'10000\r'
'\n'
====================================




----------------------------------------------------------------------

>Comment By: Sye van der Veen (syeberman)
Date: 2007-05-19 11:09

Message:
Logged In: YES 
user_id=982447
Originator: YES

File Added: BufferedSubFileBug.py

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721862&group_id=5470

From noreply at sourceforge.net  Sat May 19 18:11:12 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 19 May 2007 09:11:12 -0700
Subject: [ python-Bugs-1721812 ] A subclass of set doesn't always have
	__init__ called.
Message-ID: <E1HpRWS-0002MU-BQ@sc8-sf-web22.sourceforge.net>

Bugs item #1721812, was opened at 2007-05-19 14:03
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721812&group_id=5470

Please note that this message will contain 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
Private: No
Submitted By: David Benbennick (dbenbenn)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: A subclass of set doesn't always have __init__ called.

Initial Comment:
Consider the following code:

>>> class foo(set):
...     def __init__(self, iter):
...         print "foo.__init__"
...         set.__init__(self, iter)
... 
>>> x = foo([1,2])
foo.__init__
>>> y = foo([2,3])
foo.__init__
>>> x & y
foo([2])

As you can see, the foo.__and__ method creates a new foo object without calling foo.__init__.

The problem is in Objects/setobject.c:make_new_set().

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-19 16:11

Message:
Logged In: YES 
user_id=849994
Originator: NO

Wasn't that fixed some time ago?

@OP: what Python version do you use?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721812&group_id=5470

From noreply at sourceforge.net  Sat May 19 18:12:33 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 19 May 2007 09:12:33 -0700
Subject: [ python-Bugs-1721862 ] email.FeedParser.BufferedSubFile improperly
	handles "\r\n"
Message-ID: <E1HpRXl-0002TU-03@sc8-sf-web22.sourceforge.net>

Bugs item #1721862, was opened at 2007-05-19 16:06
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721862&group_id=5470

Please note that this message will contain a full 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
Private: No
Submitted By: Sye van der Veen (syeberman)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email.FeedParser.BufferedSubFile improperly handles "\r\n"

Initial Comment:
When email.FeedParser.BufferedSubFile sees "\r" at the end of the pushed-in data, it assumes that it is a Macintosh-style line terminator.  Instead, it should request more data, to ensure that the next character is not "\n", which would make it a Windows-style line terminator.  This affects email.message_from_file, which reads in the data in 8192 byte chunks.  The following code demonstrates this:

====================================
from StringIO import StringIO
from email.FeedParser import \
    BufferedSubFile, NeedMoreData

fp = StringIO( "1\r\n10\r\n100\r\n"
               "1000\r\n10000\r\n" )
bsf = BufferedSubFile( )
while True:
    data = fp.read( 3 )
    if not data:
        break
    bsf.push( data )
    for line in bsf:
        if line is NeedMoreData:
            break
        print repr( line )
bsf.close()
====================================

The output is:
====================================
'1\r\n'
'10\r'
'\n'
'100\r\n'
'1000\r\n'
'10000\r'
'\n'
====================================




----------------------------------------------------------------------

Comment By: Sye van der Veen (syeberman)
Date: 2007-05-19 16:09

Message:
Logged In: YES 
user_id=982447
Originator: YES

File Added: BufferedSubFileBug.py

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721862&group_id=5470

From noreply at sourceforge.net  Sat May 19 18:25:11 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 19 May 2007 09:25:11 -0700
Subject: [ python-Bugs-1721812 ] A subclass of set doesn't always have
	__init__ called.
Message-ID: <E1HpRjz-0004l9-Jn@sc8-sf-web24.sourceforge.net>

Bugs item #1721812, was opened at 2007-05-19 09:03
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721812&group_id=5470

Please note that this message will contain 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
Private: No
Submitted By: David Benbennick (dbenbenn)
Assigned to: Raymond Hettinger (rhettinger)
Summary: A subclass of set doesn't always have __init__ called.

Initial Comment:
Consider the following code:

>>> class foo(set):
...     def __init__(self, iter):
...         print "foo.__init__"
...         set.__init__(self, iter)
... 
>>> x = foo([1,2])
foo.__init__
>>> y = foo([2,3])
foo.__init__
>>> x & y
foo([2])

As you can see, the foo.__and__ method creates a new foo object without calling foo.__init__.

The problem is in Objects/setobject.c:make_new_set().

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-05-19 11:25

Message:
Logged In: YES 
user_id=80475
Originator: NO

Sorry, this is just the way Python works.  Given that the __and__
operation has no way of knowing the signature of your subclass contructor,
it will produce a new set from your two foo inputs.  This design prevades
the language (for example list and int have similar behaviors).  Recommend
closing this as not-a-bug:

>>> class foo(list):
	def __init__(self, iter):
		print 'foo.__init__'
		list.__init__(self, iter)

		
>>> x = foo([1,2])
foo.__init__
>>> y = foo([2,3])
foo.__init__
>>> x + y
[1, 2, 2, 3]
>>> type(_)
<type 'list'>
>>> 
>>> class foo(int): 
        pass

>>> foo(1) + foo(2)
3
>>> type(_)
<type 'int'>

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-19 11:11

Message:
Logged In: YES 
user_id=849994
Originator: NO

Wasn't that fixed some time ago?

@OP: what Python version do you use?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721812&group_id=5470

From noreply at sourceforge.net  Sat May 19 18:32:33 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 19 May 2007 09:32:33 -0700
Subject: [ python-Bugs-1721812 ] A subclass of set doesn't always have
	__init__ called.
Message-ID: <E1HpRr7-0005Vy-Rt@sc8-sf-web24.sourceforge.net>

Bugs item #1721812, was opened at 2007-05-19 14:03
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721812&group_id=5470

Please note that this message will contain 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
Private: No
Submitted By: David Benbennick (dbenbenn)
Assigned to: Raymond Hettinger (rhettinger)
Summary: A subclass of set doesn't always have __init__ called.

Initial Comment:
Consider the following code:

>>> class foo(set):
...     def __init__(self, iter):
...         print "foo.__init__"
...         set.__init__(self, iter)
... 
>>> x = foo([1,2])
foo.__init__
>>> y = foo([2,3])
foo.__init__
>>> x & y
foo([2])

As you can see, the foo.__and__ method creates a new foo object without calling foo.__init__.

The problem is in Objects/setobject.c:make_new_set().

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-19 16:32

Message:
Logged In: YES 
user_id=849994
Originator: NO

There is a difference: in the list and int case, the new object is of the
base type.
In the set case, the new object is of type foo.

But the constructor signature argument is a valid one.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-05-19 16:25

Message:
Logged In: YES 
user_id=80475
Originator: NO

Sorry, this is just the way Python works.  Given that the __and__
operation has no way of knowing the signature of your subclass contructor,
it will produce a new set from your two foo inputs.  This design prevades
the language (for example list and int have similar behaviors).  Recommend
closing this as not-a-bug:

>>> class foo(list):
	def __init__(self, iter):
		print 'foo.__init__'
		list.__init__(self, iter)

		
>>> x = foo([1,2])
foo.__init__
>>> y = foo([2,3])
foo.__init__
>>> x + y
[1, 2, 2, 3]
>>> type(_)
<type 'list'>
>>> 
>>> class foo(int): 
        pass

>>> foo(1) + foo(2)
3
>>> type(_)
<type 'int'>

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-19 16:11

Message:
Logged In: YES 
user_id=849994
Originator: NO

Wasn't that fixed some time ago?

@OP: what Python version do you use?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721812&group_id=5470

From noreply at sourceforge.net  Sat May 19 18:40:02 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 19 May 2007 09:40:02 -0700
Subject: [ python-Bugs-1721812 ] A subclass of set doesn't always have
	__init__ called.
Message-ID: <E1HpRyM-0005Rv-R2@sc8-sf-web22.sourceforge.net>

Bugs item #1721812, was opened at 2007-05-19 09:03
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721812&group_id=5470

Please note that this message will contain a full 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
Private: No
Submitted By: David Benbennick (dbenbenn)
Assigned to: Raymond Hettinger (rhettinger)
Summary: A subclass of set doesn't always have __init__ called.

Initial Comment:
Consider the following code:

>>> class foo(set):
...     def __init__(self, iter):
...         print "foo.__init__"
...         set.__init__(self, iter)
... 
>>> x = foo([1,2])
foo.__init__
>>> y = foo([2,3])
foo.__init__
>>> x & y
foo([2])

As you can see, the foo.__and__ method creates a new foo object without calling foo.__init__.

The problem is in Objects/setobject.c:make_new_set().

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-05-19 11:40

Message:
Logged In: YES 
user_id=80475
Originator: NO

Hmm, that's a bummer.
It is probably going to have to change.  
Will look it and fix it when I get a chance.


----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-19 11:32

Message:
Logged In: YES 
user_id=849994
Originator: NO

There is a difference: in the list and int case, the new object is of the
base type.
In the set case, the new object is of type foo.

But the constructor signature argument is a valid one.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-05-19 11:25

Message:
Logged In: YES 
user_id=80475
Originator: NO

Sorry, this is just the way Python works.  Given that the __and__
operation has no way of knowing the signature of your subclass contructor,
it will produce a new set from your two foo inputs.  This design prevades
the language (for example list and int have similar behaviors).  Recommend
closing this as not-a-bug:

>>> class foo(list):
	def __init__(self, iter):
		print 'foo.__init__'
		list.__init__(self, iter)

		
>>> x = foo([1,2])
foo.__init__
>>> y = foo([2,3])
foo.__init__
>>> x + y
[1, 2, 2, 3]
>>> type(_)
<type 'list'>
>>> 
>>> class foo(int): 
        pass

>>> foo(1) + foo(2)
3
>>> type(_)
<type 'int'>

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-19 11:11

Message:
Logged In: YES 
user_id=849994
Originator: NO

Wasn't that fixed some time ago?

@OP: what Python version do you use?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721812&group_id=5470

From noreply at sourceforge.net  Sat May 19 19:23:58 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 19 May 2007 10:23:58 -0700
Subject: [ python-Bugs-1721890 ] IDLE hangs in popup method completion
Message-ID: <E1HpSes-0008Cn-10@sc8-sf-web23.sourceforge.net>

Bugs item #1721890, was opened at 2007-05-19 12: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=1721890&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Andy Harrington (andyharrington)
Assigned to: Nobody/Anonymous (nobody)
Summary: IDLE hangs in popup method completion

Initial Comment:
import os

os.

After entering the above code in a new idle editor window, the popup method completion window appears.  If I navigate with the down-arrow key, the list starts scrolling fine all the way down to spawnv, which I can select, but if I try to use down-arrow once more and scroll the list (to what would be startfile if I could reach it), idle hangs.  

Pure pagedown works all the way to in the popup to write, but then it I use up-arrow idle hangs when I try to scroll up beyond startfile to what would be spawnv.

I am running Windows XP, service pack 2.  On May 5 I installed and am running python-2.5.1.msi.

I started idle form idle.bat while in the idlelib directory.  I also ran \Python25\Lib\idlelib\idle.pyw from other directories with the same result.

I have no such problem with modules os.path or string.  I did not think of a module to try which has a list of methods as long as os.

 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721890&group_id=5470

From noreply at sourceforge.net  Sat May 19 20:10:27 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 19 May 2007 11:10:27 -0700
Subject: [ python-Bugs-1697215 ] Docstring for site.addpackage() is incorrect
Message-ID: <E1HpTNr-0007dU-DB@sc8-sf-web24.sourceforge.net>

Bugs item #1697215, was opened at 2007-04-09 21:23
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1697215&group_id=5470

Please note that this 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
Private: No
Submitted By: cfk (carlfk)
Assigned to: Nobody/Anonymous (nobody)
Summary: Docstring for site.addpackage() is incorrect

Initial Comment:
docstring says "execute sitedir" - but that isn't what gets executed. 

suggested: 
    """Add a new path to known_paths by combining sitedir and 'name' 
or execute lines in name.pth that start with 'import'"""

site.py

def addpackage(sitedir, name, known_paths):

    """Add a new path to known_paths by combining sitedir and 'name' or execute sitedir if it starts with 'import'"""

    fullname = os.path.join(sitedir, name)
        f = open(fullname, "rU")
        for line in f:
            if line.startswith("import"):
                exec line
                                      

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-19 18:10

Message:
Logged In: YES 
user_id=849994
Originator: NO

Fixed in rev. 55455. (zseil, sorry, I didn't see your patch before
committing it...)

----------------------------------------------------------------------

Comment By: Ziga Seilnacht (zseil)
Date: 2007-04-15 17:59

Message:
Logged In: YES 
user_id=1326842
Originator: NO

Here is a patch.  addpackage() is actually responsible
for .pth file processing, so the current docstring was
entirely incorrect.


File Added: addpackage_docstring.diff

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1697215&group_id=5470

From noreply at sourceforge.net  Sat May 19 20:14:27 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 19 May 2007 11:14:27 -0700
Subject: [ python-Feature Requests-1712419 ] Cannot use dict with unicode keys
	as keyword arguments
Message-ID: <E1HpTRj-00084S-DB@sc8-sf-web24.sourceforge.net>

Feature Requests item #1712419, was opened at 2007-05-03 22:49
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1712419&group_id=5470

Please note that this 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: Wont Fix
Priority: 5
Private: No
Submitted By: Viktor Ferenczi (complex)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cannot use dict with unicode keys as keyword arguments

Initial Comment:
Unicode strings cannot be used as keys in dictionaries passed as keyword argument to a function. For example:

Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> def fn(**kw):
...     print repr(kw)
...
>>> fn(**{u'x':1})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: fn() keywords must be strings
>>>

Unicode strings should be converted to str automatically using the site specific default encoding or something similar solution.

This bug caused problems when decoding dictionaries from data formats such as XML or JSON. Usually unicode strings are returned from such modules, such as simplejson. Manual encoding from unicode to str causes performance loss if this cannot be done by Python automatically.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-19 18:14

Message:
Logged In: YES 
user_id=849994
Originator: NO

Yeah, should be uncontroversial.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-05-18 23:53

Message:
Logged In: YES 
user_id=80475
Originator: NO

Recommend closing this as not-a-bug. 

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2007-05-04 10:27

Message:
Logged In: YES 
user_id=38388
Originator: NO

Python (currently) does not allow non-ASCII identifiers, so it's not
surprising that Unicode parameter names don't work.

It's also a really bad idea to pass data from an AJAX XML or JSON request
directly to a function without doing at least some post-processing of the
data in order to prevent DOS attacks, code injection, etc.

dict((str(key), value) for key, value in kw.iteritems()) is all that's
needed for the above. 

BTW, I don't think those few micro-seconds really matter in the face of
XML or JSON decoding, network latency, etc. ;-)


----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-04 04:10

Message:
Logged In: YES 
user_id=849994
Originator: NO

In any case, this is a feature request.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1712419&group_id=5470

From noreply at sourceforge.net  Sat May 19 20:47:21 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 19 May 2007 11:47:21 -0700
Subject: [ python-Bugs-1583862 ] yield+break stops tracing
Message-ID: <E1HpTxZ-0000Po-0w@sc8-sf-web21.sourceforge.net>

Bugs item #1583862, was opened at 2006-10-24 17:55
Message generated for change (Settings changed) made by luks
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583862&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Lukas Lalinsky (luks)
Assigned to: Nobody/Anonymous (nobody)
Summary: yield+break stops tracing

Initial Comment:
Here is an example script:

def myiter():
    for i in range(10):
        yield i
for i in myiter():
    break
print "foo"

Now, if I try to trace it:

$ python -m trace --trace --count test.py
 --- modulename: threading, funcname: settrace
threading.py(70):     _trace_hook = func
 --- modulename: test, funcname: <module>
test.py(1): def myiter():
test.py(5): for i in myiter():
 --- modulename: test, funcname: myiter
test.py(2):     for i in range(10):
test.py(3):         yield i
test.py(6):     break
c:\python25\lib\ntpath.py:190: RuntimeWarning:
tp_compare didn't return -1 or -2 for exception
  if i<=max(p.rfind('/'), p.rfind('\\')):
foo

It stops tracing after the `break` statement. The line
after, `print "foo"`, is not traced nor included in the
coverage output.

I'm not sure RuntimeWarning from ntpath.py is relevant
here, because if I use the trace module in some other
situation it doesn't print it. IMO, it's just a side
effect of some different problem.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-04-11 18:52

Message:
Logged In: YES 
user_id=80475
Originator: NO

Using Py2.5.1, the problem seems to have gone away.
Lukas, can you please verify that it is solved and then close.


=======================================================================
rhettinger at localhost ~ $ py25/python -m trace --trace --count test.py
 --- modulename: threading, funcname: settrace
threading.py(70):     _trace_hook = func
 --- modulename: trace, funcname: <module>
<string>(1):   --- modulename: trace, funcname: <module>
test.py(1): def myiter():
test.py(6): for i in myiter():
 --- modulename: trace, funcname: myiter
test.py(2):     for i in range(10):
test.py(3):         yield i
test.py(7):     break
 --- modulename: trace, funcname: myiter
test.py(9): print 'foo'
foo


----------------------------------------------------------------------

Comment By: Lukas Lalinsky (luks)
Date: 2006-10-24 18:05

Message:
Logged In: YES 
user_id=587716

Oh, I forgot. This bug is specific to Python 2.5. It works
fine in 2.4.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583862&group_id=5470

From noreply at sourceforge.net  Sat May 19 23:29:48 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 19 May 2007 14:29:48 -0700
Subject: [ python-Bugs-1721372 ] emphasize iteration volatility for set
Message-ID: <E1HpWUm-0002zY-9i@sc8-sf-web22.sourceforge.net>

Bugs item #1721372, was opened at 2007-05-18 17:10
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721372&group_id=5470

Please note that this 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: Rejected
Priority: 5
Private: No
Submitted By: Alan (aisaac0)
Assigned to: Nobody/Anonymous (nobody)
Summary: emphasize iteration volatility for set

Initial Comment:
For <URL:http://docs.python.org/lib/types-set.html>, append the following new sentence to the 2nd paragraph.

    Iteration over a set returns elements in an indeterminate order, which generally depends on factors outside the scope of the containing program.

*Justification:* users should not be expected to understand without being told that iteration order depends on factors outside the scope of the containing program. (Additionally, unlike the documentation for dictionaries, the documentation for sets fails to give a serious warning not to rely on iteration order.)


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2007-05-19 23:29

Message:
Logged In: YES 
user_id=21627
Originator: NO

aisaac0, thanks for elaborating. Your remark now convinces me that it was
the right thing to reject this change.

Ite seems that you suggest that experienced users
a) are aware that some objects compare and hash by their id(), and
b) that the id() is the address in memory, and
c) that the id() will influence the order in which objects are iterated,
and
d) fail to see that the id() may differ across runs

Such users are *not* experienced. There are many more reasons why the id
of an object may vary across runs. E.g. Linux 2.6 deliberately randomizes
memory management, so that identical processes get their objects allocated
at different addresses, to defeat security exploits that rely on
deterministic address of things in main memory (there is a system call to
disable this randomization)

Looking at the entire thread, I agree with Carsten Haese's posting: That
even experienced users couldn't diagnose this correctly is because they
a) did not receive the source code, and
b) were talked into believing that this has to do something with the
random module.

The library reference is a specification, not a tutorial.


----------------------------------------------------------------------

Comment By: Alan (aisaac0)
Date: 2007-05-19 15:09

Message:
Logged In: YES 
user_id=1025672
Originator: YES

The previous comment completely misses the point.  Again, please see the
discussion on c.l.python.  Not one of the participants expected sets to be
"ordered". What was suprising to them was the order can *change* across
sequential executions of an **unchanged** source.   This is of course
*quite* different than expecting that sets are ordered; I am perplexed that
anyone would conflate the two.  One cannot credibly argue that anyone who
understands that sets are not ordered will not be surprised, since even
sophisticated users were as a matter of fact surprised in the c.l.python
discussion.  (Until it was explained by Peter of course.)  A natural
conclusion is that the docs should offer better protection against such
surprise, since we have concrete evidence that even sophisticated users can
be surprised by this.

In sum, the previous comment conflates two distinct issues and so fails to
address the reasons for the proposed docs patch.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-19 08:38

Message:
Logged In: YES 
user_id=21627
Originator: NO

The documentation already says "Being an unordered collection, sets do not
record element position or order of insertion."

If users read this and fail to understand the notion of an unordered
collection, I see no way of "fixing" this.

----------------------------------------------------------------------

Comment By: Alan (aisaac0)
Date: 2007-05-19 04:28

Message:
Logged In: YES 
user_id=1025672
Originator: YES

While I do not mind my language being rejected, *something* should be
added to warn users.  What the previous comment fails to mention is the
number of people on c.l.python, some of whom are quite sophisticated users,
who failed to discover the source of indeterminacy.  Users should not have
to "rediscover" this because of a documentation failure.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-05-19 01:08

Message:
Logged In: YES 
user_id=80475
Originator: NO

While the OP knows what he means here, the suggested text does not add
clarity, it only makes the subject harder to understand and implies that
some mysterious, dark force is in place.  Further, the suggested text is
simply incorrect.  Given deterministic assignment of hash values and a
consistent insertion order, the order of keys in a set or dictionary is
fully determined.

I've read the source of this suggestion on comp.lang.python and commented
there.  The underlying issue had nothing to do with either sets or dicts. 
The code in question "re-discovered" that the location of objects in memory
 would vary between runs if the user deleted a pyc file for a module.  The
OP's script used object ids as hash values, hence the set/dict ordering
could vary between runs.  This was at odds with his expectation that that
the ordering would be deterministic.  The moral is that non-deterministic
hash values lead to non-deterministic set/dict ordering.

The docs for sets and dicts should not be muddled with tangential
discussions about implementation specific details regarding what governs
where objects are placed in memory.


----------------------------------------------------------------------

Comment By: Alan (aisaac0)
Date: 2007-05-18 20:00

Message:
Logged In: YES 
user_id=1025672
Originator: YES

Location in memory.
See Peter Otten's discussion at
http://www.thescripts.com/forum/post2552380-16.html

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-18 19:05

Message:
Logged In: YES 
user_id=21627
Originator: NO

What factors outside the containing program influence iteration order?
Iteration is completely deterministic, and only depends on the items
inserted, and the order in which they were inserted, neither of which is
outside the scope of the containing program. It's just that the order is
not easily predictable.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721372&group_id=5470

From noreply at sourceforge.net  Sun May 20 04:18:15 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 19 May 2007 19:18:15 -0700
Subject: [ python-Bugs-1721309 ] make testall shows many glibc detected malloc
	corruptions
Message-ID: <E1Hpazv-0000yU-G3@sc8-sf-web24.sourceforge.net>

Bugs item #1721309, was opened at 2007-05-18 06:42
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721309&group_id=5470

Please note that this 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: Fixed
Priority: 5
Private: No
Submitted By: David Favor (dfavor)
Assigned to: Neal Norwitz (nnorwitz)
Summary: make testall shows many glibc detected malloc corruptions

Initial Comment:
export _MALLOC_CHECK_=1
make testall

test_bsddb3
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***

followed by deadlock errors.

malloc: using debugging hooks
blattest test_tempfile failed -- Traceback (most recent call last):
  File "/build/work/Python-2.5.1/Lib/test/test_tempfile.py", line 310, in test_noinherit
    self.failIf(retval > 0, "child process reports failure %d"%retval)
AssertionError: child process reports failure 1

test_timeout
test test_timeout failed -- Traceback (most recent call last):
  File "/build/work/Python-2.5.1/Lib/test/test_timeout.py", line 128, in testConnectTimeout
    %(_delta, self.fuzz, _timeout))
AssertionError: timeout (8.20631) is more than 2 seconds more than expected (0.001)


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-19 19:18

Message:
Logged In: YES 
user_id=33168
Originator: NO

Sigh, 4.4.20 and 4.5.20 behave differently.  I tested on both, but botched
it. :-(

It seemed like a good idea to have at least one of the buildbots to use
4.5.20.  I upgraded the g4 bot to 4.5.20, since that didn't have any
version of bsddb on it.  I also installed 4.4.20 on the amd64 buildbot. 
The x86 gentoo bot probably has 4.1, but it's down right now.  Martin's
machine has 4.2.

Both versions (4.4 and 4.5) require the flag DB_DBT_MALLOC (get() returns
an error 22 otherwise).  However only 4.4 actually allocates memory.  4.5
doesn't.  I checked in revs 55457 (2.5) which should handle this better. 
Could someone please test and verify I really fixed the problem this time. 
If it's really fixed, close this bug report.

The real change is to conditionally free data if it is a different pointer
than we pass in (orig_data).  Don't free if they are the same pointer.

Tested 4.5 memory leaks with the leaks program and 4.4 with valgrind.
File Added: db.c

----------------------------------------------------------------------

Comment By: David Favor (dfavor)
Date: 2007-05-19 08:05

Message:
Logged In: YES 
user_id=370230
Originator: YES

Just built with latest
http://svn.python.org/projects/python/branches/release25-maint
pull and problem still remains.

----------------------------------------------------------------------

Comment By: David Favor (dfavor)
Date: 2007-05-19 08:04

Message:
Logged In: YES 
user_id=370230
Originator: YES

My test was done with latest BerkeleyDB 4.5.20 plain (no patches).

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-19 03:31

Message:
Logged In: YES 
user_id=849994
Originator: NO

I can confirm that the checkin didn't change anything for me.

I use bsddb version 4.5.20_p2 from Gentoo.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-19 00:08

Message:
Logged In: YES 
user_id=21627
Originator: NO

(I'm not convinced that Neal's patch could actually fix anything)

Can people who were able to reproduce this please report their bdb version
also; I was using 4.4.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-19 00:04

Message:
Logged In: YES 
user_id=21627
Originator: NO

dfavor: I see. It is MALLOC_CHECK_, not _MALLOC_CHECK (as I used it), and
not _MALLOC_CHECK_ (as you wrote). I now see that debug hooks are used, but
I still cannot reproduce the problem...

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-18 21:38

Message:
Logged In: YES 
user_id=33168
Originator: NO

I screwed up the first checkin.  The CLEAR_DBT was in the wrong place. 
The fixes are in:

Committed revision 55452. 
Committed revision 55454. (2.5)


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-18 20:54

Message:
Logged In: YES 
user_id=33168
Originator: NO

Thanks for the report David.  It would be great if you could test the
change.  I couldn't find any other places that had a similar problem, but
you never know.  You will need to pull out of SVN.  It's a one line change
if you want to apply manually.

Committed revision 55450.
Committed revision 55451. (2.5)


----------------------------------------------------------------------

Comment By: David Favor (dfavor)
Date: 2007-05-18 14:26

Message:
Logged In: YES 
user_id=370230
Originator: YES

The os I'm running is Fedora 6 with latest patches.

gcc is 4.1.1

glibc is 2.5

I had to set MALLOC_CHECK_=1 just to get the suite to run as normal
MALLOC_CHECK_ defaults to die when something evil occurs.

I'll build gcc 4.2, rebuild and see what occurs.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-18 14:02

Message:
Logged In: YES 
user_id=849994
Originator: NO

I don't even need to set an environment variable to get

~/devel/python> ./python Lib/test/regrtest.py -uall test_bsddb3
test_bsddb3
*** glibc detected *** ./python: free(): invalid pointer: 0x0827874c ***
[1]    17141 abort      ./python Lib/test/regrtest.py -uall test_bsddb3

(HEAD, linux x86, gcc 4.1.2, glibc 2.5)

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-18 10:43

Message:
Logged In: YES 
user_id=21627
Originator: NO

Unfortunately, I cannot reproduce this problem on Debian unstable (x86,
gcc 4.1.3, glibc 2.5) - 
the test passes just fine with _MALLOC_CHECK set.

Can you provide a few more details: glibc version, compiler version, Linux
distribution, processor architecture, precise Python version being test,
does the error happen on the first or a subsequent cycle of all tests?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721309&group_id=5470

From noreply at sourceforge.net  Sun May 20 04:19:30 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 19 May 2007 19:19:30 -0700
Subject: [ python-Bugs-1721309 ] make testall shows many glibc detected malloc
	corruptions
Message-ID: <E1Hpb18-0003Or-Ma@sc8-sf-web23.sourceforge.net>

Bugs item #1721309, was opened at 2007-05-18 06:42
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721309&group_id=5470

Please note that this 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: Fixed
Priority: 5
Private: No
Submitted By: David Favor (dfavor)
Assigned to: Neal Norwitz (nnorwitz)
Summary: make testall shows many glibc detected malloc corruptions

Initial Comment:
export _MALLOC_CHECK_=1
make testall

test_bsddb3
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***
*** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 ***

followed by deadlock errors.

malloc: using debugging hooks
blattest test_tempfile failed -- Traceback (most recent call last):
  File "/build/work/Python-2.5.1/Lib/test/test_tempfile.py", line 310, in test_noinherit
    self.failIf(retval > 0, "child process reports failure %d"%retval)
AssertionError: child process reports failure 1

test_timeout
test test_timeout failed -- Traceback (most recent call last):
  File "/build/work/Python-2.5.1/Lib/test/test_timeout.py", line 128, in testConnectTimeout
    %(_delta, self.fuzz, _timeout))
AssertionError: timeout (8.20631) is more than 2 seconds more than expected (0.001)


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-19 19:19

Message:
Logged In: YES 
user_id=33168
Originator: NO

File Added: test_get_both.py

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-19 19:18

Message:
Logged In: YES 
user_id=33168
Originator: NO

Sigh, 4.4.20 and 4.5.20 behave differently.  I tested on both, but botched
it. :-(

It seemed like a good idea to have at least one of the buildbots to use
4.5.20.  I upgraded the g4 bot to 4.5.20, since that didn't have any
version of bsddb on it.  I also installed 4.4.20 on the amd64 buildbot. 
The x86 gentoo bot probably has 4.1, but it's down right now.  Martin's
machine has 4.2.

Both versions (4.4 and 4.5) require the flag DB_DBT_MALLOC (get() returns
an error 22 otherwise).  However only 4.4 actually allocates memory.  4.5
doesn't.  I checked in revs 55457 (2.5) which should handle this better. 
Could someone please test and verify I really fixed the problem this time. 
If it's really fixed, close this bug report.

The real change is to conditionally free data if it is a different pointer
than we pass in (orig_data).  Don't free if they are the same pointer.

Tested 4.5 memory leaks with the leaks program and 4.4 with valgrind.
File Added: db.c

----------------------------------------------------------------------

Comment By: David Favor (dfavor)
Date: 2007-05-19 08:05

Message:
Logged In: YES 
user_id=370230
Originator: YES

Just built with latest
http://svn.python.org/projects/python/branches/release25-maint
pull and problem still remains.

----------------------------------------------------------------------

Comment By: David Favor (dfavor)
Date: 2007-05-19 08:04

Message:
Logged In: YES 
user_id=370230
Originator: YES

My test was done with latest BerkeleyDB 4.5.20 plain (no patches).

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-19 03:31

Message:
Logged In: YES 
user_id=849994
Originator: NO

I can confirm that the checkin didn't change anything for me.

I use bsddb version 4.5.20_p2 from Gentoo.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-19 00:08

Message:
Logged In: YES 
user_id=21627
Originator: NO

(I'm not convinced that Neal's patch could actually fix anything)

Can people who were able to reproduce this please report their bdb version
also; I was using 4.4.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-19 00:04

Message:
Logged In: YES 
user_id=21627
Originator: NO

dfavor: I see. It is MALLOC_CHECK_, not _MALLOC_CHECK (as I used it), and
not _MALLOC_CHECK_ (as you wrote). I now see that debug hooks are used, but
I still cannot reproduce the problem...

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-18 21:38

Message:
Logged In: YES 
user_id=33168
Originator: NO

I screwed up the first checkin.  The CLEAR_DBT was in the wrong place. 
The fixes are in:

Committed revision 55452. 
Committed revision 55454. (2.5)


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-18 20:54

Message:
Logged In: YES 
user_id=33168
Originator: NO

Thanks for the report David.  It would be great if you could test the
change.  I couldn't find any other places that had a similar problem, but
you never know.  You will need to pull out of SVN.  It's a one line change
if you want to apply manually.

Committed revision 55450.
Committed revision 55451. (2.5)


----------------------------------------------------------------------

Comment By: David Favor (dfavor)
Date: 2007-05-18 14:26

Message:
Logged In: YES 
user_id=370230
Originator: YES

The os I'm running is Fedora 6 with latest patches.

gcc is 4.1.1

glibc is 2.5

I had to set MALLOC_CHECK_=1 just to get the suite to run as normal
MALLOC_CHECK_ defaults to die when something evil occurs.

I'll build gcc 4.2, rebuild and see what occurs.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-18 14:02

Message:
Logged In: YES 
user_id=849994
Originator: NO

I don't even need to set an environment variable to get

~/devel/python> ./python Lib/test/regrtest.py -uall test_bsddb3
test_bsddb3
*** glibc detected *** ./python: free(): invalid pointer: 0x0827874c ***
[1]    17141 abort      ./python Lib/test/regrtest.py -uall test_bsddb3

(HEAD, linux x86, gcc 4.1.2, glibc 2.5)

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-18 10:43

Message:
Logged In: YES 
user_id=21627
Originator: NO

Unfortunately, I cannot reproduce this problem on Debian unstable (x86,
gcc 4.1.3, glibc 2.5) - 
the test passes just fine with _MALLOC_CHECK set.

Can you provide a few more details: glibc version, compiler version, Linux
distribution, processor architecture, precise Python version being test,
does the error happen on the first or a subsequent cycle of all tests?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721309&group_id=5470

From noreply at sourceforge.net  Sun May 20 18:26:13 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 20 May 2007 09:26:13 -0700
Subject: [ python-Bugs-1720959 ] Please make sqlite3.Row iterable
Message-ID: <E1HpoEX-0002Ix-NV@sc8-sf-web22.sourceforge.net>

Bugs item #1720959, was opened at 2007-05-17 22:23
Message generated for change (Comment added) made by ghaering
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1720959&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: phil (philipdumont)
Assigned to: Gerhard H?ring (ghaering)
Summary: Please make sqlite3.Row iterable

Initial Comment:
Sometimes I'd like to get row values with columnname
indexes, sometimes by iterating over the row.

The default (not setting the connection's row_factory)
is to return a tuple, which gives the latter, but not
the former.

Setting row_factory to sqlite3.Row gives the former,
but (surprisingly) not the latter.

It's a surprise because back when pysqlite was not part
of the Python distrib (I don't recall what version), its
Row type was iterable.  Any chance that bit of
functionality could be put back?

----------------------------------------------------------------------

>Comment By: Gerhard H?ring (ghaering)
Date: 2007-05-20 18:26

Message:
Logged In: YES 
user_id=163326
Originator: NO

This functionality is already in the Python 2.6 branch. I was told not to
backport it to 2.5.x. So, I'll close this issue.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-17 23:14

Message:
Logged In: YES 
user_id=33168
Originator: NO

Gerhard, could you take a look?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1720959&group_id=5470

From noreply at sourceforge.net  Sun May 20 20:00:35 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 20 May 2007 11:00:35 -0700
Subject: [ python-Bugs-1722239 ] NamedTuple security issue
Message-ID: <E1Hpphr-00046T-U9@sc8-sf-web22.sourceforge.net>

Bugs item #1722239, was opened at 2007-05-20 20: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=1722239&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Christian Heimes (tiran)
Assigned to: Nobody/Anonymous (nobody)
Summary: NamedTuple security issue

Initial Comment:
collections.NamedTuple is using an assert to prevent exec attacks:

assert ''.join(field_names).replace('_', '').isalpha()     
# protect against exec attack
s

asserts are ignored when Python code is run with the -O or -OO flag. I suggest to replace them.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1722239&group_id=5470

From noreply at sourceforge.net  Sun May 20 21:23:10 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 20 May 2007 12:23:10 -0700
Subject: [ python-Bugs-1722239 ] NamedTuple security issue
Message-ID: <E1Hpqzm-0004VN-3b@sc8-sf-web23.sourceforge.net>

Bugs item #1722239, was opened at 2007-05-20 11:00
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1722239&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Christian Heimes (tiran)
Assigned to: Nobody/Anonymous (nobody)
Summary: NamedTuple security issue

Initial Comment:
collections.NamedTuple is using an assert to prevent exec attacks:

assert ''.join(field_names).replace('_', '').isalpha()     
# protect against exec attack
s

asserts are ignored when Python code is run with the -O or -OO flag. I suggest to replace them.



----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2007-05-20 12:23

Message:
Logged In: YES 
user_id=357491
Originator: NO

Or you could just not have the security protection in there.  I am sure
there are a ton of other places that are not protected against malicious
use of exec.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1722239&group_id=5470

From noreply at sourceforge.net  Sun May 20 22:40:52 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 20 May 2007 13:40:52 -0700
Subject: [ python-Bugs-1722239 ] NamedTuple security issue
Message-ID: <E1HpsCy-0006Wr-IP@sc8-sf-web24.sourceforge.net>

Bugs item #1722239, was opened at 2007-05-20 20:00
Message generated for change (Comment added) made by tiran
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1722239&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Christian Heimes (tiran)
Assigned to: Nobody/Anonymous (nobody)
Summary: NamedTuple security issue

Initial Comment:
collections.NamedTuple is using an assert to prevent exec attacks:

assert ''.join(field_names).replace('_', '').isalpha()     
# protect against exec attack
s

asserts are ignored when Python code is run with the -O or -OO flag. I suggest to replace them.



----------------------------------------------------------------------

>Comment By: Christian Heimes (tiran)
Date: 2007-05-20 22:40

Message:
Logged In: YES 
user_id=560817
Originator: YES

It's less than a ton (how do I weight source code? *g*) but it's used in
some modules. Personally I don't like the usage of exec/execfile and I'm
always worried when I see code that utilizes it. I've created a patch that
checks typename and field_names for non alphanumeric characters.

Bastion.py:    exec testcode
bdb.py:                exec cmd in globals, locals
cgi.py:            exec "testing print_exception() -- <I>italics?</I>"
code.py:            exec code in self.locals
collections.py:    exec template in m
cProfile.py:            exec cmd in globals, locals
doctest.py:                exec compile(example.source, filename,
"single",
hashlib.py:            exec funcName + ' = f'
hashlib.py:                exec funcName + ' =
__get_builtin_constructor(funcName)'
ihooks.py:            exec code in m.__dict__
imputil.py:                exec code in module.__dict__
pdb.py:            exec code in globals, locals
profile.py:            exec cmd in globals, locals
rexec.py:        exec TEMPLATE % (m, m)
rexec.py:        exec code in m.__dict__
runpy.py:    exec code in run_globals
site.py:                exec line
socket.py:        exec _s % (_m, _m, _m, _m)
timeit.py:            exec code in globals(), ns
timeit.py:                    exec _setup in globals(), ns
trace.py:            exec cmd in dict, dict
trace.py:            exec cmd in globals, locals


File Added: NamedTuple_55472.diff

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2007-05-20 21:23

Message:
Logged In: YES 
user_id=357491
Originator: NO

Or you could just not have the security protection in there.  I am sure
there are a ton of other places that are not protected against malicious
use of exec.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1722239&group_id=5470

From noreply at sourceforge.net  Mon May 21 00:24:37 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 20 May 2007 15:24:37 -0700
Subject: [ python-Bugs-1722344 ] Thread shutdown exception in Thread.notify()
Message-ID: <E1HptpN-0000sa-IL@sc8-sf-web24.sourceforge.net>

Bugs item #1722344, was opened at 2007-05-20 15:24
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1722344&group_id=5470

Please note that this message 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
Private: No
Submitted By: Yang Zhang (yangzhang)
Assigned to: Nobody/Anonymous (nobody)
Summary: Thread shutdown exception in Thread.notify()

Initial Comment:
Hi, I sometimes see the following exceptions when shutting down my app (using Python 2.5.1):

  Unhandled exception in thread started by
  Error in sys.excepthook:
  
  Original exception was:
  Exception in thread Thread-3 (most likely raised during interpreter shutdown):
  Traceback (most recent call last):
    File "/usr/local/lib/python2.5/threading.py", line 460, in __bootstrap
    File "/usr/local/lib/python2.5/threading.py", line 440, in run
    File "/home/yang/local/armed/lib/python2.5/site-packages/afx/threads.py", line 71, in worker
    File "/usr/local/lib/python2.5/Queue.py", line 176, in get
    File "/usr/local/lib/python2.5/threading.py", line 248, in notify
  <type 'exceptions.TypeError'>: exceptions must be classes, instances, or strings (deprecated), not NoneType
  Unhandled exception in thread started by
  Error in sys.excepthook:
  
  Original exception was:
  Exception in thread Thread-6 (most likely raised during interpreter shutdown):
  Traceback (most recent call last):
    File "/usr/local/lib/python2.5/threading.py", line 460, in __bootstrap
    File "/usr/local/lib/python2.5/threading.py", line 440, in run
    File "/home/yang/local/armed/lib/python2.5/site-packages/afx/threads.py", line 71, in worker
    File "/usr/local/lib/python2.5/Queue.py", line 176, in get
    File "/usr/local/lib/python2.5/threading.py", line 248, in notify
  <type 'exceptions.TypeError'>: exceptions must be classes, instances, or strings (deprecated), not NoneType
  Unhandled exception in thread started by
  Error in sys.excepthook:
  
  Original exception was:

Here is the code from my application:

        def worker():
            debug( 'starting worker' )
            while True:
                msg = i.get() # <-- THIS IS LINE 71
                if msg is stop_msg: break
                resultbuf, func, args, kwargs = msg
                result, exc = None, None
                try:
                    result = func( *args, **kwargs )
                except:
                    t, v, tb = exc_info()
                    exc = t, v, tb.tb_next
                o.put( ( resultbuf, result, exc ) )
                s.send( 'x' ) # assuming socket.send is thread-safe
            debug( 'stopping worker' )

Here is the origin of the exception (in threading.py):

    def notify(self, n=1):
        assert self._is_owned(), "notify() of un-acquire()d lock" # <-- THIS IS LINE 248
        __waiters = self.__waiters
        waiters = __waiters[:n]
        if not waiters:
            if __debug__:
                self._note("%s.notify(): no waiters", self)
            return
        self._note("%s.notify(): notifying %d waiter%s", self, n,
                   n!=1 and "s" or "")
        for waiter in waiters:
            waiter.release()
            try:
                __waiters.remove(waiter)
            except ValueError:
                pass

I'm not sure why this is happening. The threads are not daemon threads; I terminate them cleanly. When I get a SIGINT (I usu. shut down my app with ctrl-C), I enqueue n stop_msg's to the 'i' Queue so that the n workers can all exit.

Note I usually launch 5 workers, so I'm not consistently getting an exception per worker. Also, I've been unable to reproduce this at will.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1722344&group_id=5470

From noreply at sourceforge.net  Mon May 21 00:35:20 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 20 May 2007 15:35:20 -0700
Subject: [ python-Bugs-1722348 ] urlparse.urlunparse forms file urls
	incorrectly
Message-ID: <E1Hptzk-00065v-8r@sc8-sf-web22.sourceforge.net>

Bugs item #1722348, was opened at 2007-05-20 18:35
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1722348&group_id=5470

Please note that this message will contain 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
Private: No
Submitted By: Thomas Folz-Donahue (eigenlambda)
Assigned to: Nobody/Anonymous (nobody)
Summary: urlparse.urlunparse forms file urls incorrectly

Initial Comment:
This is a conversation with the current Python interpreter.

>>> import urlparse
>>> urlparse.urlparse(urlparse.urlunparse(urlparse.urlparse("file:////usr/bin/python")))
('file', 'usr', '/bin/python', '', '', '')

As you can see, the results are incorrect.  The problem is in the urlunsplit function:

def urlunsplit((scheme, netloc, url, query, fragment)):
    if netloc or (scheme and scheme in uses_netloc and url[:2] != '//'):
        if url and url[:1] != '/': url = '/' + url
        url = '//' + (netloc or '') + url
    if scheme:
        url = scheme + ':' + url
    if query:
        url = url + '?' + query
    if fragment:
        url = url + '#' + fragment
    return url

RFC 1808 (see http://www.ietf.org/rfc/rfc1808.txt ) specifies that a URL shall have the following syntax:
<scheme>://<net_loc>/<path>;<params>?<query>#<fragment>

The problem with the current version of urlunsplit is that it tests if there are already two slashes before the 'url' section before outputting a URL.  This is incorrect because (1) RFC 1808 clearly specifies at least three slashes between the end of the scheme portion and the beginning of the path portion and (2) this method will strip the first few slashes from an arbitrary path portion, which may require those slashes.  Removing that url[:2] != '//' causes urlunsplit to behave correctly when dealing with urls like file:////usr/bin/python .


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1722348&group_id=5470

From noreply at sourceforge.net  Mon May 21 01:12:09 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 20 May 2007 16:12:09 -0700
Subject: [ python-Bugs-1722348 ] urlparse.urlunparse forms file urls
	incorrectly
Message-ID: <E1HpuZN-0001cc-DT@sc8-sf-web22.sourceforge.net>

Bugs item #1722348, was opened at 2007-05-20 18:35
Message generated for change (Comment added) made by eigenlambda
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1722348&group_id=5470

Please note that this message will contain 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
Private: No
Submitted By: Thomas Folz-Donahue (eigenlambda)
Assigned to: Nobody/Anonymous (nobody)
Summary: urlparse.urlunparse forms file urls incorrectly

Initial Comment:
This is a conversation with the current Python interpreter.

>>> import urlparse
>>> urlparse.urlparse(urlparse.urlunparse(urlparse.urlparse("file:////usr/bin/python")))
('file', 'usr', '/bin/python', '', '', '')

As you can see, the results are incorrect.  The problem is in the urlunsplit function:

def urlunsplit((scheme, netloc, url, query, fragment)):
    if netloc or (scheme and scheme in uses_netloc and url[:2] != '//'):
        if url and url[:1] != '/': url = '/' + url
        url = '//' + (netloc or '') + url
    if scheme:
        url = scheme + ':' + url
    if query:
        url = url + '?' + query
    if fragment:
        url = url + '#' + fragment
    return url

RFC 1808 (see http://www.ietf.org/rfc/rfc1808.txt ) specifies that a URL shall have the following syntax:
<scheme>://<net_loc>/<path>;<params>?<query>#<fragment>

The problem with the current version of urlunsplit is that it tests if there are already two slashes before the 'url' section before outputting a URL.  This is incorrect because (1) RFC 1808 clearly specifies at least three slashes between the end of the scheme portion and the beginning of the path portion and (2) this method will strip the first few slashes from an arbitrary path portion, which may require those slashes.  Removing that url[:2] != '//' causes urlunsplit to behave correctly when dealing with urls like file:////usr/bin/python .


----------------------------------------------------------------------

>Comment By: Thomas Folz-Donahue (eigenlambda)
Date: 2007-05-20 19:12

Message:
Logged In: YES 
user_id=1797315
Originator: YES

Some other issues with the urlparse module.  Several constant lists
defined at the beginning of the module should be sets because they are only
used for testing if certain strings are in them.  Also, urlunsplit() uses
the + operator way too much, creating strings that are immediately thrown
away.  IMO, the alternative is actually more readable.  Attaching a patch
(diff -u urlparse.py urlparse.py.new > urlparse.diff).
File Added: urlparse.diff

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1722348&group_id=5470

From noreply at sourceforge.net  Mon May 21 07:39:32 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 20 May 2007 22:39:32 -0700
Subject: [ python-Bugs-1722239 ] NamedTuple security issue
Message-ID: <E1Hq0cG-0007Lv-GO@sc8-sf-web24.sourceforge.net>

Bugs item #1722239, was opened at 2007-05-20 13:00
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1722239&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Christian Heimes (tiran)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: NamedTuple security issue

Initial Comment:
collections.NamedTuple is using an assert to prevent exec attacks:

assert ''.join(field_names).replace('_', '').isalpha()     
# protect against exec attack
s

asserts are ignored when Python code is run with the -O or -OO flag. I suggest to replace them.



----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-05-21 00:39

Message:
Logged In: YES 
user_id=80475
Originator: NO

Will replace the assertion with something that always executes.


----------------------------------------------------------------------

Comment By: Christian Heimes (tiran)
Date: 2007-05-20 15:40

Message:
Logged In: YES 
user_id=560817
Originator: YES

It's less than a ton (how do I weight source code? *g*) but it's used in
some modules. Personally I don't like the usage of exec/execfile and I'm
always worried when I see code that utilizes it. I've created a patch that
checks typename and field_names for non alphanumeric characters.

Bastion.py:    exec testcode
bdb.py:                exec cmd in globals, locals
cgi.py:            exec "testing print_exception() -- <I>italics?</I>"
code.py:            exec code in self.locals
collections.py:    exec template in m
cProfile.py:            exec cmd in globals, locals
doctest.py:                exec compile(example.source, filename,
"single",
hashlib.py:            exec funcName + ' = f'
hashlib.py:                exec funcName + ' =
__get_builtin_constructor(funcName)'
ihooks.py:            exec code in m.__dict__
imputil.py:                exec code in module.__dict__
pdb.py:            exec code in globals, locals
profile.py:            exec cmd in globals, locals
rexec.py:        exec TEMPLATE % (m, m)
rexec.py:        exec code in m.__dict__
runpy.py:    exec code in run_globals
site.py:                exec line
socket.py:        exec _s % (_m, _m, _m, _m)
timeit.py:            exec code in globals(), ns
timeit.py:                    exec _setup in globals(), ns
trace.py:            exec cmd in dict, dict
trace.py:            exec cmd in globals, locals


File Added: NamedTuple_55472.diff

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2007-05-20 14:23

Message:
Logged In: YES 
user_id=357491
Originator: NO

Or you could just not have the security protection in there.  I am sure
there are a ton of other places that are not protected against malicious
use of exec.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1722239&group_id=5470

From noreply at sourceforge.net  Mon May 21 10:18:18 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 21 May 2007 01:18:18 -0700
Subject: [ python-Bugs-1722485 ] Option -OO doesn't remove docstrings
Message-ID: <E1Hq35u-0000CN-Ag@sc8-sf-web22.sourceforge.net>

Bugs item #1722485, was opened at 2007-05-21 10: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=1722485&group_id=5470

Please note that this 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
Private: No
Submitted By: Grzegorz Adam Hankiewicz (gradha)
Assigned to: Nobody/Anonymous (nobody)
Summary: Option -OO doesn't remove docstrings

Initial Comment:
I'm using Python 2.5.1 as said by the -V switch under Windows XP. I run one of my programs with -OO, which generates a good amount of .pyo files in the directory. According to -h the -OO parameter removes docstrings. However, when I open the .pyo files with vim I can see all the docstrings in plain text.

Conclusion, docstrings are not being removed. I noticed this in 2.5, which prompted me to upgrade after this thread: http://sourceforge.net/mailarchive/forum.php?thread_name=464D5A57.2060809%40rastertech.es&forum_name=py2exe-users

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1722485&group_id=5470

From noreply at sourceforge.net  Mon May 21 10:25:51 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 21 May 2007 01:25:51 -0700
Subject: [ python-Bugs-1722239 ] NamedTuple security issue
Message-ID: <E1Hq3DD-0007xH-VP@sc8-sf-web21.sourceforge.net>

Bugs item #1722239, was opened at 2007-05-20 13:00
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1722239&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.6
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Christian Heimes (tiran)
Assigned to: Raymond Hettinger (rhettinger)
Summary: NamedTuple security issue

Initial Comment:
collections.NamedTuple is using an assert to prevent exec attacks:

assert ''.join(field_names).replace('_', '').isalpha()     
# protect against exec attack
s

asserts are ignored when Python code is run with the -O or -OO flag. I suggest to replace them.



----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-05-21 03:25

Message:
Logged In: YES 
user_id=80475
Originator: NO

Fixed.  See revision:   55487


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-05-21 00:39

Message:
Logged In: YES 
user_id=80475
Originator: NO

Will replace the assertion with something that always executes.


----------------------------------------------------------------------

Comment By: Christian Heimes (tiran)
Date: 2007-05-20 15:40

Message:
Logged In: YES 
user_id=560817
Originator: YES

It's less than a ton (how do I weight source code? *g*) but it's used in
some modules. Personally I don't like the usage of exec/execfile and I'm
always worried when I see code that utilizes it. I've created a patch that
checks typename and field_names for non alphanumeric characters.

Bastion.py:    exec testcode
bdb.py:                exec cmd in globals, locals
cgi.py:            exec "testing print_exception() -- <I>italics?</I>"
code.py:            exec code in self.locals
collections.py:    exec template in m
cProfile.py:            exec cmd in globals, locals
doctest.py:                exec compile(example.source, filename,
"single",
hashlib.py:            exec funcName + ' = f'
hashlib.py:                exec funcName + ' =
__get_builtin_constructor(funcName)'
ihooks.py:            exec code in m.__dict__
imputil.py:                exec code in module.__dict__
pdb.py:            exec code in globals, locals
profile.py:            exec cmd in globals, locals
rexec.py:        exec TEMPLATE % (m, m)
rexec.py:        exec code in m.__dict__
runpy.py:    exec code in run_globals
site.py:                exec line
socket.py:        exec _s % (_m, _m, _m, _m)
timeit.py:            exec code in globals(), ns
timeit.py:                    exec _setup in globals(), ns
trace.py:            exec cmd in dict, dict
trace.py:            exec cmd in globals, locals


File Added: NamedTuple_55472.diff

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2007-05-20 14:23

Message:
Logged In: YES 
user_id=357491
Originator: NO

Or you could just not have the security protection in there.  I am sure
there are a ton of other places that are not protected against malicious
use of exec.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1722239&group_id=5470

From noreply at sourceforge.net  Mon May 21 11:25:13 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 21 May 2007 02:25:13 -0700
Subject: [ python-Bugs-1722239 ] NamedTuple security issue
Message-ID: <E1Hq48f-0005DM-Ln@sc8-sf-web21.sourceforge.net>

Bugs item #1722239, was opened at 2007-05-20 20:00
Message generated for change (Comment added) made by tiran
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1722239&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.6
>Status: Open
>Resolution: Remind
Priority: 5
Private: No
Submitted By: Christian Heimes (tiran)
Assigned to: Raymond Hettinger (rhettinger)
Summary: NamedTuple security issue

Initial Comment:
collections.NamedTuple is using an assert to prevent exec attacks:

assert ''.join(field_names).replace('_', '').isalpha()     
# protect against exec attack
s

asserts are ignored when Python code is run with the -O or -OO flag. I suggest to replace them.



----------------------------------------------------------------------

>Comment By: Christian Heimes (tiran)
Date: 2007-05-21 11:25

Message:
Logged In: YES 
user_id=560817
Originator: YES

You forgot two things:

 * check for isalnum() instead of isalpha() to allow numbers in type and
field names. The current check disallows Point = NamedTuple('Point3', 'x1
x2 x3')
 * add unit tests to verify that a value error is raised

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-05-21 10:25

Message:
Logged In: YES 
user_id=80475
Originator: NO

Fixed.  See revision:   55487


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-05-21 07:39

Message:
Logged In: YES 
user_id=80475
Originator: NO

Will replace the assertion with something that always executes.


----------------------------------------------------------------------

Comment By: Christian Heimes (tiran)
Date: 2007-05-20 22:40

Message:
Logged In: YES 
user_id=560817
Originator: YES

It's less than a ton (how do I weight source code? *g*) but it's used in
some modules. Personally I don't like the usage of exec/execfile and I'm
always worried when I see code that utilizes it. I've created a patch that
checks typename and field_names for non alphanumeric characters.

Bastion.py:    exec testcode
bdb.py:                exec cmd in globals, locals
cgi.py:            exec "testing print_exception() -- <I>italics?</I>"
code.py:            exec code in self.locals
collections.py:    exec template in m
cProfile.py:            exec cmd in globals, locals
doctest.py:                exec compile(example.source, filename,
"single",
hashlib.py:            exec funcName + ' = f'
hashlib.py:                exec funcName + ' =
__get_builtin_constructor(funcName)'
ihooks.py:            exec code in m.__dict__
imputil.py:                exec code in module.__dict__
pdb.py:            exec code in globals, locals
profile.py:            exec cmd in globals, locals
rexec.py:        exec TEMPLATE % (m, m)
rexec.py:        exec code in m.__dict__
runpy.py:    exec code in run_globals
site.py:                exec line
socket.py:        exec _s % (_m, _m, _m, _m)
timeit.py:            exec code in globals(), ns
timeit.py:                    exec _setup in globals(), ns
trace.py:            exec cmd in dict, dict
trace.py:            exec cmd in globals, locals


File Added: NamedTuple_55472.diff

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2007-05-20 21:23

Message:
Logged In: YES 
user_id=357491
Originator: NO

Or you could just not have the security protection in there.  I am sure
there are a ton of other places that are not protected against malicious
use of exec.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1722239&group_id=5470

From noreply at sourceforge.net  Mon May 21 14:01:32 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 21 May 2007 05:01:32 -0700
Subject: [ python-Bugs-1722344 ] Thread shutdown exception in Thread.notify()
Message-ID: <E1Hq6Zw-0003kS-RK@sc8-sf-web22.sourceforge.net>

Bugs item #1722344, was opened at 2007-05-20 19:24
Message generated for change (Comment added) made by gagenellina
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1722344&group_id=5470

Please note that this message 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
Private: No
Submitted By: Yang Zhang (yangzhang)
Assigned to: Nobody/Anonymous (nobody)
Summary: Thread shutdown exception in Thread.notify()

Initial Comment:
Hi, I sometimes see the following exceptions when shutting down my app (using Python 2.5.1):

  Unhandled exception in thread started by
  Error in sys.excepthook:
  
  Original exception was:
  Exception in thread Thread-3 (most likely raised during interpreter shutdown):
  Traceback (most recent call last):
    File "/usr/local/lib/python2.5/threading.py", line 460, in __bootstrap
    File "/usr/local/lib/python2.5/threading.py", line 440, in run
    File "/home/yang/local/armed/lib/python2.5/site-packages/afx/threads.py", line 71, in worker
    File "/usr/local/lib/python2.5/Queue.py", line 176, in get
    File "/usr/local/lib/python2.5/threading.py", line 248, in notify
  <type 'exceptions.TypeError'>: exceptions must be classes, instances, or strings (deprecated), not NoneType
  Unhandled exception in thread started by
  Error in sys.excepthook:
  
  Original exception was:
  Exception in thread Thread-6 (most likely raised during interpreter shutdown):
  Traceback (most recent call last):
    File "/usr/local/lib/python2.5/threading.py", line 460, in __bootstrap
    File "/usr/local/lib/python2.5/threading.py", line 440, in run
    File "/home/yang/local/armed/lib/python2.5/site-packages/afx/threads.py", line 71, in worker
    File "/usr/local/lib/python2.5/Queue.py", line 176, in get
    File "/usr/local/lib/python2.5/threading.py", line 248, in notify
  <type 'exceptions.TypeError'>: exceptions must be classes, instances, or strings (deprecated), not NoneType
  Unhandled exception in thread started by
  Error in sys.excepthook:
  
  Original exception was:

Here is the code from my application:

        def worker():
            debug( 'starting worker' )
            while True:
                msg = i.get() # <-- THIS IS LINE 71
                if msg is stop_msg: break
                resultbuf, func, args, kwargs = msg
                result, exc = None, None
                try:
                    result = func( *args, **kwargs )
                except:
                    t, v, tb = exc_info()
                    exc = t, v, tb.tb_next
                o.put( ( resultbuf, result, exc ) )
                s.send( 'x' ) # assuming socket.send is thread-safe
            debug( 'stopping worker' )

Here is the origin of the exception (in threading.py):

    def notify(self, n=1):
        assert self._is_owned(), "notify() of un-acquire()d lock" # <-- THIS IS LINE 248
        __waiters = self.__waiters
        waiters = __waiters[:n]
        if not waiters:
            if __debug__:
                self._note("%s.notify(): no waiters", self)
            return
        self._note("%s.notify(): notifying %d waiter%s", self, n,
                   n!=1 and "s" or "")
        for waiter in waiters:
            waiter.release()
            try:
                __waiters.remove(waiter)
            except ValueError:
                pass

I'm not sure why this is happening. The threads are not daemon threads; I terminate them cleanly. When I get a SIGINT (I usu. shut down my app with ctrl-C), I enqueue n stop_msg's to the 'i' Queue so that the n workers can all exit.

Note I usually launch 5 workers, so I'm not consistently getting an exception per worker. Also, I've been unable to reproduce this at will.

----------------------------------------------------------------------

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-21 09:01

Message:
Logged In: YES 
user_id=479790
Originator: NO

Do you join() the worker threads, waiting until they finish, before
exiting the main thread?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1722344&group_id=5470

From noreply at sourceforge.net  Mon May 21 16:47:19 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 21 May 2007 07:47:19 -0700
Subject: [ python-Bugs-1722344 ] Thread shutdown exception in Thread.notify()
Message-ID: <E1Hq9AN-0001O4-5F@sc8-sf-web23.sourceforge.net>

Bugs item #1722344, was opened at 2007-05-20 15:24
Message generated for change (Comment added) made by yangzhang
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1722344&group_id=5470

Please note that this message 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
Private: No
Submitted By: Yang Zhang (yangzhang)
Assigned to: Nobody/Anonymous (nobody)
Summary: Thread shutdown exception in Thread.notify()

Initial Comment:
Hi, I sometimes see the following exceptions when shutting down my app (using Python 2.5.1):

  Unhandled exception in thread started by
  Error in sys.excepthook:
  
  Original exception was:
  Exception in thread Thread-3 (most likely raised during interpreter shutdown):
  Traceback (most recent call last):
    File "/usr/local/lib/python2.5/threading.py", line 460, in __bootstrap
    File "/usr/local/lib/python2.5/threading.py", line 440, in run
    File "/home/yang/local/armed/lib/python2.5/site-packages/afx/threads.py", line 71, in worker
    File "/usr/local/lib/python2.5/Queue.py", line 176, in get
    File "/usr/local/lib/python2.5/threading.py", line 248, in notify
  <type 'exceptions.TypeError'>: exceptions must be classes, instances, or strings (deprecated), not NoneType
  Unhandled exception in thread started by
  Error in sys.excepthook:
  
  Original exception was:
  Exception in thread Thread-6 (most likely raised during interpreter shutdown):
  Traceback (most recent call last):
    File "/usr/local/lib/python2.5/threading.py", line 460, in __bootstrap
    File "/usr/local/lib/python2.5/threading.py", line 440, in run
    File "/home/yang/local/armed/lib/python2.5/site-packages/afx/threads.py", line 71, in worker
    File "/usr/local/lib/python2.5/Queue.py", line 176, in get
    File "/usr/local/lib/python2.5/threading.py", line 248, in notify
  <type 'exceptions.TypeError'>: exceptions must be classes, instances, or strings (deprecated), not NoneType
  Unhandled exception in thread started by
  Error in sys.excepthook:
  
  Original exception was:

Here is the code from my application:

        def worker():
            debug( 'starting worker' )
            while True:
                msg = i.get() # <-- THIS IS LINE 71
                if msg is stop_msg: break
                resultbuf, func, args, kwargs = msg
                result, exc = None, None
                try:
                    result = func( *args, **kwargs )
                except:
                    t, v, tb = exc_info()
                    exc = t, v, tb.tb_next
                o.put( ( resultbuf, result, exc ) )
                s.send( 'x' ) # assuming socket.send is thread-safe
            debug( 'stopping worker' )

Here is the origin of the exception (in threading.py):

    def notify(self, n=1):
        assert self._is_owned(), "notify() of un-acquire()d lock" # <-- THIS IS LINE 248
        __waiters = self.__waiters
        waiters = __waiters[:n]
        if not waiters:
            if __debug__:
                self._note("%s.notify(): no waiters", self)
            return
        self._note("%s.notify(): notifying %d waiter%s", self, n,
                   n!=1 and "s" or "")
        for waiter in waiters:
            waiter.release()
            try:
                __waiters.remove(waiter)
            except ValueError:
                pass

I'm not sure why this is happening. The threads are not daemon threads; I terminate them cleanly. When I get a SIGINT (I usu. shut down my app with ctrl-C), I enqueue n stop_msg's to the 'i' Queue so that the n workers can all exit.

Note I usually launch 5 workers, so I'm not consistently getting an exception per worker. Also, I've been unable to reproduce this at will.

----------------------------------------------------------------------

>Comment By: Yang Zhang (yangzhang)
Date: 2007-05-21 07:47

Message:
Logged In: YES 
user_id=1207658
Originator: YES

No, as they are not daemon threads.

----------------------------------------------------------------------

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-21 05:01

Message:
Logged In: YES 
user_id=479790
Originator: NO

Do you join() the worker threads, waiting until they finish, before
exiting the main thread?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1722344&group_id=5470

From noreply at sourceforge.net  Mon May 21 18:49:13 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 21 May 2007 09:49:13 -0700
Subject: [ python-Bugs-1722239 ] NamedTuple security issue
Message-ID: <E1HqB4L-00067E-2a@sc8-sf-web21.sourceforge.net>

Bugs item #1722239, was opened at 2007-05-20 13:00
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1722239&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.6
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Christian Heimes (tiran)
Assigned to: Raymond Hettinger (rhettinger)
Summary: NamedTuple security issue

Initial Comment:
collections.NamedTuple is using an assert to prevent exec attacks:

assert ''.join(field_names).replace('_', '').isalpha()     
# protect against exec attack
s

asserts are ignored when Python code is run with the -O or -OO flag. I suggest to replace them.



----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-05-21 11:49

Message:
Logged In: YES 
user_id=80475
Originator: NO

Fixed.

----------------------------------------------------------------------

Comment By: Christian Heimes (tiran)
Date: 2007-05-21 04:25

Message:
Logged In: YES 
user_id=560817
Originator: YES

You forgot two things:

 * check for isalnum() instead of isalpha() to allow numbers in type and
field names. The current check disallows Point = NamedTuple('Point3', 'x1
x2 x3')
 * add unit tests to verify that a value error is raised

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-05-21 03:25

Message:
Logged In: YES 
user_id=80475
Originator: NO

Fixed.  See revision:   55487


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-05-21 00:39

Message:
Logged In: YES 
user_id=80475
Originator: NO

Will replace the assertion with something that always executes.


----------------------------------------------------------------------

Comment By: Christian Heimes (tiran)
Date: 2007-05-20 15:40

Message:
Logged In: YES 
user_id=560817
Originator: YES

It's less than a ton (how do I weight source code? *g*) but it's used in
some modules. Personally I don't like the usage of exec/execfile and I'm
always worried when I see code that utilizes it. I've created a patch that
checks typename and field_names for non alphanumeric characters.

Bastion.py:    exec testcode
bdb.py:                exec cmd in globals, locals
cgi.py:            exec "testing print_exception() -- <I>italics?</I>"
code.py:            exec code in self.locals
collections.py:    exec template in m
cProfile.py:            exec cmd in globals, locals
doctest.py:                exec compile(example.source, filename,
"single",
hashlib.py:            exec funcName + ' = f'
hashlib.py:                exec funcName + ' =
__get_builtin_constructor(funcName)'
ihooks.py:            exec code in m.__dict__
imputil.py:                exec code in module.__dict__
pdb.py:            exec code in globals, locals
profile.py:            exec cmd in globals, locals
rexec.py:        exec TEMPLATE % (m, m)
rexec.py:        exec code in m.__dict__
runpy.py:    exec code in run_globals
site.py:                exec line
socket.py:        exec _s % (_m, _m, _m, _m)
timeit.py:            exec code in globals(), ns
timeit.py:                    exec _setup in globals(), ns
trace.py:            exec cmd in dict, dict
trace.py:            exec cmd in globals, locals


File Added: NamedTuple_55472.diff

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2007-05-20 14:23

Message:
Logged In: YES 
user_id=357491
Originator: NO

Or you could just not have the security protection in there.  I am sure
there are a ton of other places that are not protected against malicious
use of exec.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1722239&group_id=5470

From noreply at sourceforge.net  Mon May 21 19:14:25 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 21 May 2007 10:14:25 -0700
Subject: [ python-Bugs-1441530 ] socket read() can cause MemoryError in Windows
Message-ID: <E1HqBSj-000297-MZ@sc8-sf-web21.sourceforge.net>

Bugs item #1441530, was opened at 2006-03-02 09:27
Message generated for change (Comment added) made by mcicogni
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
Private: No
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()





----------------------------------------------------------------------

Comment By: Mauro Cicognini (mcicogni)
Date: 2007-05-21 19:14

Message:
Logged In: YES 
user_id=134511
Originator: NO

Consistently reproducible using Python 2.5.1 on Windows XP.

Another bug on the same subject was closed WONTFIX since it all appears to
be Microsoft's fault (although asking a socket directly for more than 10MB
of data at once is arguably unreasonable).

Since it appears that it's just Imaplib implementation to be somewhat
broken, we could possibly patch *that* to work around this problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1441530&group_id=5470

From noreply at sourceforge.net  Mon May 21 21:21:55 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 21 May 2007 12:21:55 -0700
Subject: [ python-Bugs-1722956 ] x = [[]]*2;  x[0].append doesn't work
Message-ID: <E1HqDS7-00038W-TN@sc8-sf-web24.sourceforge.net>

Bugs item #1722956, was opened at 2007-05-21 12: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=1722956&group_id=5470

Please note that this 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
Private: No
Submitted By: Jeff Britton (metal_one)
Assigned to: Nobody/Anonymous (nobody)
Summary: x = [[]]*2;  x[0].append doesn't work

Initial Comment:
This bug is hard to explain in words.  It is easiest to just look at the Interactive Python commands issued below.

<x> is assigned a list of two empty lists, however there is something wrong with <x>.
<y> is assigned a list of two empty lists using list comprehension.  <y> is ok.
A check of x == y, shows them equal.
However, when trying to append [1,2] to x[0] both x[0] and x[1] are appended to. 
The same operation on <y> works correctly.


>>> x = [[]]*2
>>> y = [[] for i in range(2)]
>>> x == y
True
>>> x[0].append([1,2])
>>> x
[[[1, 2]], [[1, 2]]]
>>> y[0].append([1,2])
>>> y
[[[1, 2]], []]


I have tested with Python 2.5 and 2.4.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1722956&group_id=5470

From noreply at sourceforge.net  Mon May 21 22:03:46 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 21 May 2007 13:03:46 -0700
Subject: [ python-Bugs-1722956 ] x = [[]]*2;  x[0].append doesn't work
Message-ID: <E1HqE6c-0007l5-K4@sc8-sf-web24.sourceforge.net>

Bugs item #1722956, was opened at 2007-05-21 19:21
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1722956&group_id=5470

Please note that this 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: Invalid
Priority: 5
Private: No
Submitted By: Jeff Britton (metal_one)
Assigned to: Nobody/Anonymous (nobody)
Summary: x = [[]]*2;  x[0].append doesn't work

Initial Comment:
This bug is hard to explain in words.  It is easiest to just look at the Interactive Python commands issued below.

<x> is assigned a list of two empty lists, however there is something wrong with <x>.
<y> is assigned a list of two empty lists using list comprehension.  <y> is ok.
A check of x == y, shows them equal.
However, when trying to append [1,2] to x[0] both x[0] and x[1] are appended to. 
The same operation on <y> works correctly.


>>> x = [[]]*2
>>> y = [[] for i in range(2)]
>>> x == y
True
>>> x[0].append([1,2])
>>> x
[[[1, 2]], [[1, 2]]]
>>> y[0].append([1,2])
>>> y
[[[1, 2]], []]


I have tested with Python 2.5 and 2.4.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-21 20:03

Message:
Logged In: YES 
user_id=849994
Originator: NO

This is not a bug. "x" is a list containing two references to the same
list object, while "y" is a list containing references to two distinct list
objects.

The "==" operator doesn't test for identity, but compares list contents,
which is why it yields True above.

(Please ask any further questions about this behavior on the python-list
mailing list.)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1722956&group_id=5470

From noreply at sourceforge.net  Tue May 22 05:27:48 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 21 May 2007 20:27:48 -0700
Subject: [ python-Bugs-1721372 ] emphasize iteration volatility for set
Message-ID: <E1HqL2K-0006Ih-GN@sc8-sf-web22.sourceforge.net>

Bugs item #1721372, was opened at 2007-05-18 10:10
Message generated for change (Comment added) made by aisaac0
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721372&group_id=5470

Please note that this 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: Rejected
Priority: 5
Private: No
Submitted By: Alan (aisaac0)
Assigned to: Nobody/Anonymous (nobody)
Summary: emphasize iteration volatility for set

Initial Comment:
For <URL:http://docs.python.org/lib/types-set.html>, append the following new sentence to the 2nd paragraph.

    Iteration over a set returns elements in an indeterminate order, which generally depends on factors outside the scope of the containing program.

*Justification:* users should not be expected to understand without being told that iteration order depends on factors outside the scope of the containing program. (Additionally, unlike the documentation for dictionaries, the documentation for sets fails to give a serious warning not to rely on iteration order.)


----------------------------------------------------------------------

>Comment By: Alan (aisaac0)
Date: 2007-05-21 22:27

Message:
Logged In: YES 
user_id=1025672
Originator: YES

Note that on c.l.python, Raymond Hettinger justifies this rejection as
follows:

  "the docs are sufficient when they say that set ordering is arbitrary"

Where exactly do the docs say this? I do not see it.
I am looking here: <URL:http://docs.python.org/lib/types-set.html>

I also take this as a concession that the docs *should* say something like
this,
which is about half of the language I proposed
(unless there is some reason why 'arbitrary' is superior to
'indeterminate').

Btw, I did provide the source code to several people before Peter.
This was clear in the thread on c.l.python.
I do not think they would appreciate being called "not experienced".


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-19 16:29

Message:
Logged In: YES 
user_id=21627
Originator: NO

aisaac0, thanks for elaborating. Your remark now convinces me that it was
the right thing to reject this change.

Ite seems that you suggest that experienced users
a) are aware that some objects compare and hash by their id(), and
b) that the id() is the address in memory, and
c) that the id() will influence the order in which objects are iterated,
and
d) fail to see that the id() may differ across runs

Such users are *not* experienced. There are many more reasons why the id
of an object may vary across runs. E.g. Linux 2.6 deliberately randomizes
memory management, so that identical processes get their objects allocated
at different addresses, to defeat security exploits that rely on
deterministic address of things in main memory (there is a system call to
disable this randomization)

Looking at the entire thread, I agree with Carsten Haese's posting: That
even experienced users couldn't diagnose this correctly is because they
a) did not receive the source code, and
b) were talked into believing that this has to do something with the
random module.

The library reference is a specification, not a tutorial.


----------------------------------------------------------------------

Comment By: Alan (aisaac0)
Date: 2007-05-19 08:09

Message:
Logged In: YES 
user_id=1025672
Originator: YES

The previous comment completely misses the point.  Again, please see the
discussion on c.l.python.  Not one of the participants expected sets to be
"ordered". What was suprising to them was the order can *change* across
sequential executions of an **unchanged** source.   This is of course
*quite* different than expecting that sets are ordered; I am perplexed that
anyone would conflate the two.  One cannot credibly argue that anyone who
understands that sets are not ordered will not be surprised, since even
sophisticated users were as a matter of fact surprised in the c.l.python
discussion.  (Until it was explained by Peter of course.)  A natural
conclusion is that the docs should offer better protection against such
surprise, since we have concrete evidence that even sophisticated users can
be surprised by this.

In sum, the previous comment conflates two distinct issues and so fails to
address the reasons for the proposed docs patch.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-19 01:38

Message:
Logged In: YES 
user_id=21627
Originator: NO

The documentation already says "Being an unordered collection, sets do not
record element position or order of insertion."

If users read this and fail to understand the notion of an unordered
collection, I see no way of "fixing" this.

----------------------------------------------------------------------

Comment By: Alan (aisaac0)
Date: 2007-05-18 21:28

Message:
Logged In: YES 
user_id=1025672
Originator: YES

While I do not mind my language being rejected, *something* should be
added to warn users.  What the previous comment fails to mention is the
number of people on c.l.python, some of whom are quite sophisticated users,
who failed to discover the source of indeterminacy.  Users should not have
to "rediscover" this because of a documentation failure.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-05-18 18:08

Message:
Logged In: YES 
user_id=80475
Originator: NO

While the OP knows what he means here, the suggested text does not add
clarity, it only makes the subject harder to understand and implies that
some mysterious, dark force is in place.  Further, the suggested text is
simply incorrect.  Given deterministic assignment of hash values and a
consistent insertion order, the order of keys in a set or dictionary is
fully determined.

I've read the source of this suggestion on comp.lang.python and commented
there.  The underlying issue had nothing to do with either sets or dicts. 
The code in question "re-discovered" that the location of objects in memory
 would vary between runs if the user deleted a pyc file for a module.  The
OP's script used object ids as hash values, hence the set/dict ordering
could vary between runs.  This was at odds with his expectation that that
the ordering would be deterministic.  The moral is that non-deterministic
hash values lead to non-deterministic set/dict ordering.

The docs for sets and dicts should not be muddled with tangential
discussions about implementation specific details regarding what governs
where objects are placed in memory.


----------------------------------------------------------------------

Comment By: Alan (aisaac0)
Date: 2007-05-18 13:00

Message:
Logged In: YES 
user_id=1025672
Originator: YES

Location in memory.
See Peter Otten's discussion at
http://www.thescripts.com/forum/post2552380-16.html

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-18 12:05

Message:
Logged In: YES 
user_id=21627
Originator: NO

What factors outside the containing program influence iteration order?
Iteration is completely deterministic, and only depends on the items
inserted, and the order in which they were inserted, neither of which is
outside the scope of the containing program. It's just that the order is
not easily predictable.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721372&group_id=5470

From noreply at sourceforge.net  Tue May 22 07:22:53 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 21 May 2007 22:22:53 -0700
Subject: [ python-Bugs-1721372 ] emphasize iteration volatility for set
Message-ID: <E1HqMph-0007EV-Qw@sc8-sf-web21.sourceforge.net>

Bugs item #1721372, was opened at 2007-05-18 17:10
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721372&group_id=5470

Please note that this 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: Rejected
Priority: 5
Private: No
Submitted By: Alan (aisaac0)
Assigned to: Nobody/Anonymous (nobody)
Summary: emphasize iteration volatility for set

Initial Comment:
For <URL:http://docs.python.org/lib/types-set.html>, append the following new sentence to the 2nd paragraph.

    Iteration over a set returns elements in an indeterminate order, which generally depends on factors outside the scope of the containing program.

*Justification:* users should not be expected to understand without being told that iteration order depends on factors outside the scope of the containing program. (Additionally, unlike the documentation for dictionaries, the documentation for sets fails to give a serious warning not to rely on iteration order.)


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2007-05-22 07:22

Message:
Logged In: YES 
user_id=21627
Originator: NO

aisaac0: The first sentence of types-set says "A set object is an
unordered collection of immutable values."

How else could you interpret "unordered collection" but as "having
arbitrary order"?

----------------------------------------------------------------------

Comment By: Alan (aisaac0)
Date: 2007-05-22 05:27

Message:
Logged In: YES 
user_id=1025672
Originator: YES

Note that on c.l.python, Raymond Hettinger justifies this rejection as
follows:

  "the docs are sufficient when they say that set ordering is arbitrary"

Where exactly do the docs say this? I do not see it.
I am looking here: <URL:http://docs.python.org/lib/types-set.html>

I also take this as a concession that the docs *should* say something like
this,
which is about half of the language I proposed
(unless there is some reason why 'arbitrary' is superior to
'indeterminate').

Btw, I did provide the source code to several people before Peter.
This was clear in the thread on c.l.python.
I do not think they would appreciate being called "not experienced".


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-19 23:29

Message:
Logged In: YES 
user_id=21627
Originator: NO

aisaac0, thanks for elaborating. Your remark now convinces me that it was
the right thing to reject this change.

Ite seems that you suggest that experienced users
a) are aware that some objects compare and hash by their id(), and
b) that the id() is the address in memory, and
c) that the id() will influence the order in which objects are iterated,
and
d) fail to see that the id() may differ across runs

Such users are *not* experienced. There are many more reasons why the id
of an object may vary across runs. E.g. Linux 2.6 deliberately randomizes
memory management, so that identical processes get their objects allocated
at different addresses, to defeat security exploits that rely on
deterministic address of things in main memory (there is a system call to
disable this randomization)

Looking at the entire thread, I agree with Carsten Haese's posting: That
even experienced users couldn't diagnose this correctly is because they
a) did not receive the source code, and
b) were talked into believing that this has to do something with the
random module.

The library reference is a specification, not a tutorial.


----------------------------------------------------------------------

Comment By: Alan (aisaac0)
Date: 2007-05-19 15:09

Message:
Logged In: YES 
user_id=1025672
Originator: YES

The previous comment completely misses the point.  Again, please see the
discussion on c.l.python.  Not one of the participants expected sets to be
"ordered". What was suprising to them was the order can *change* across
sequential executions of an **unchanged** source.   This is of course
*quite* different than expecting that sets are ordered; I am perplexed that
anyone would conflate the two.  One cannot credibly argue that anyone who
understands that sets are not ordered will not be surprised, since even
sophisticated users were as a matter of fact surprised in the c.l.python
discussion.  (Until it was explained by Peter of course.)  A natural
conclusion is that the docs should offer better protection against such
surprise, since we have concrete evidence that even sophisticated users can
be surprised by this.

In sum, the previous comment conflates two distinct issues and so fails to
address the reasons for the proposed docs patch.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-19 08:38

Message:
Logged In: YES 
user_id=21627
Originator: NO

The documentation already says "Being an unordered collection, sets do not
record element position or order of insertion."

If users read this and fail to understand the notion of an unordered
collection, I see no way of "fixing" this.

----------------------------------------------------------------------

Comment By: Alan (aisaac0)
Date: 2007-05-19 04:28

Message:
Logged In: YES 
user_id=1025672
Originator: YES

While I do not mind my language being rejected, *something* should be
added to warn users.  What the previous comment fails to mention is the
number of people on c.l.python, some of whom are quite sophisticated users,
who failed to discover the source of indeterminacy.  Users should not have
to "rediscover" this because of a documentation failure.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-05-19 01:08

Message:
Logged In: YES 
user_id=80475
Originator: NO

While the OP knows what he means here, the suggested text does not add
clarity, it only makes the subject harder to understand and implies that
some mysterious, dark force is in place.  Further, the suggested text is
simply incorrect.  Given deterministic assignment of hash values and a
consistent insertion order, the order of keys in a set or dictionary is
fully determined.

I've read the source of this suggestion on comp.lang.python and commented
there.  The underlying issue had nothing to do with either sets or dicts. 
The code in question "re-discovered" that the location of objects in memory
 would vary between runs if the user deleted a pyc file for a module.  The
OP's script used object ids as hash values, hence the set/dict ordering
could vary between runs.  This was at odds with his expectation that that
the ordering would be deterministic.  The moral is that non-deterministic
hash values lead to non-deterministic set/dict ordering.

The docs for sets and dicts should not be muddled with tangential
discussions about implementation specific details regarding what governs
where objects are placed in memory.


----------------------------------------------------------------------

Comment By: Alan (aisaac0)
Date: 2007-05-18 20:00

Message:
Logged In: YES 
user_id=1025672
Originator: YES

Location in memory.
See Peter Otten's discussion at
http://www.thescripts.com/forum/post2552380-16.html

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-18 19:05

Message:
Logged In: YES 
user_id=21627
Originator: NO

What factors outside the containing program influence iteration order?
Iteration is completely deterministic, and only depends on the items
inserted, and the order in which they were inserted, neither of which is
outside the scope of the containing program. It's just that the order is
not easily predictable.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721372&group_id=5470

From noreply at sourceforge.net  Tue May 22 12:43:09 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 22 May 2007 03:43:09 -0700
Subject: [ python-Bugs-1723338 ] Crash in ctypes callproc function with
	unicode string arg
Message-ID: <E1HqRpd-0005u5-Jd@sc8-sf-web22.sourceforge.net>

Bugs item #1723338, was opened at 2007-05-22 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=105470&aid=1723338&group_id=5470

Please note that this 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
Private: No
Submitted By: Colin Laplace (claplace)
Assigned to: Nobody/Anonymous (nobody)
Summary: Crash in ctypes callproc function with unicode string arg

Initial Comment:
I've recently came to a bug using ctypes.
I was using ctypes to call a syscall and and passing it
a string argument, which was in fact in unicode.
This resulted in a python crash in the callproc function.

You can easily reproduce the crash by launching the attached python file (or at this link: https://core.fluendo.com/elisa/trac/browser/branches/rewrite-1/elisa/extern/inotify.py 
)

tested with python 2.5

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1723338&group_id=5470

From noreply at sourceforge.net  Tue May 22 19:18:13 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 22 May 2007 10:18:13 -0700
Subject: [ python-Bugs-832159 ] C++ extensions using SWIG and MinGW
Message-ID: <E1HqXzx-00027E-Rp@sc8-sf-web23.sourceforge.net>

Bugs item #832159, was opened at 2003-10-29 04:27
Message generated for change (Comment added) made by dobesv
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832159&group_id=5470

Please note that this 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.3
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Allen Chan (alydar)
Assigned to: Nobody/Anonymous (nobody)
Summary: C++ extensions using SWIG and MinGW

Initial Comment:
Using the following three files:

-- begin files -----
/* hello.cpp */
#include &lt;stdio.h&gt;
void hello()
{
    printf(&quot;hello world\n&quot;);
}
------------------
/* hello.i */
%module hello
extern void hello();
------------------
# setup.py
import distutils
from distutils.core import setup, Extension

setup(name = &quot;Hello World&quot;,
        version = &quot;1.0&quot;,
        ext_modules = [Extension(&quot;_hello&quot;,
            [&quot;hello.i&quot;,&quot;hello.cpp&quot;])])
-- end files -------


executing the command:
 &quot;python setup.py build_ext -cmingw32 --swig-cpp -f&quot;
creates the following output:

-- begin output --
running build_ext
building '_hello' extension
swigging hello.i to hello_wrap.cpp
...
[ snipped ]
...
cc -mno-cygwin -shared -s build\temp.win32-2.3
\Release\hello_wrap.o build\temp.w
in32-2.3\Release\hello.o build\temp.win32-2.3
\Release\_hello.def -LC:\p\Python23
\libs -LC:\p\Python23\PCBuild -lpython23 -o 
build\lib.win32-2.3\_hello.pyd
error: command 'cc' failed: No such file or directory
-- end output --

It appears that unixccompiler.py defaults compiler_cxx 
to use &quot;cc&quot; and then uses it for the linking, and 
cygwinccompiler.py does not override the compiler_cxx 
entry.  If the self.set_executable() call in the __init__*( 
function of the Mingw32Compiler class also sets 
compiler_cxx to use &quot;g++&quot;, then the extension build will 
work.



----------------------------------------------------------------------

Comment By: Dobes V (dobesv)
Date: 2007-05-22 17:18

Message:
Logged In: YES 
user_id=400635
Originator: NO

Here's a workaround I used to fix the linker:

# Force g++ for linking
import distutils.sysconfig
old_customize_compiler = distutils.sysconfig.customize_compiler
def customize_compiler(compiler):
    old_customize_compiler(compiler)
    if compiler.compiler_type == 'mingw':
       compiler.set_executables(linker_so='g++ -mno-cygwin -shared')
distutils.sysconfig.customize_compiler = customize_compiler


You could also override the compiler, too.


----------------------------------------------------------------------

Comment By: Kef X-Schecter (furrykef)
Date: 2004-08-20 17:26

Message:
Logged In: YES 
user_id=536129

ARGH! This bug is still in Python 2.3.4 and should have been
fixed A LONG TIME AGO! What am I supposed to do, have my
users fix their distutils by hand?

Sorry to be so gripy, but jeez. It tells you how to freaking
fix it...


----------------------------------------------------------------------

Comment By: David S. Rushby (woodsplitter)
Date: 2004-02-11 23:18

Message:
Logged In: YES 
user_id=414645

I also encountered this bug while trying to build a C++
extension with no SWIG involved.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832159&group_id=5470

From noreply at sourceforge.net  Tue May 22 21:30:21 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 22 May 2007 12:30:21 -0700
Subject: [ python-Bugs-1028697 ] Problem linking on windows using mingw32 and
	C++
Message-ID: <E1Hqa3p-0002h9-Ef@sc8-sf-web24.sourceforge.net>

Bugs item #1028697, was opened at 2004-09-15 17:28
Message generated for change (Comment added) made by dobesv
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1028697&group_id=5470

Please note that this 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.3
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Steve Menard (devilwolf)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem linking on windows using mingw32 and C++

Initial Comment:
When create a python extension in C++ and using ming32
to compile it, distutil will try to use 'cc' as the linker.

The problem is that the CCompiler.link() method will
substitude the linker it has found in linker_exe or
linker_so with the first part of compiler_cxx. (lines
175-176)

So adding the following line to Mingw32Compiler, near
line 296

compiler_cxx='g++ -mno-cygwin -O -Wall',

Fixes it for me. 

Quickly looking at the CygwinCompiler indicates it
would suffer from he same problem.

----------------------------------------------------------------------

Comment By: Dobes V (dobesv)
Date: 2007-05-22 19:30

Message:
Logged In: YES 
user_id=400635
Originator: NO

This is a duplicate of 832159.  See the comments in that one for a
workaround that doesn't require patching your distutils sources.

Note that for cygwin, you can set some environment variables to change the
compiler/linker.  This doesn't work in mingw32 due to a bug in distutils.

----------------------------------------------------------------------

Comment By: Steve Menard (devilwolf)
Date: 2004-09-18 17:54

Message:
Logged In: YES 
user_id=423569

Indeed it does seem identical to
http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=877165

thanks.

----------------------------------------------------------------------

Comment By: David S. Rushby (woodsplitter)
Date: 2004-09-17 16:15

Message:
Logged In: YES 
user_id=414645

Is this a duplicate of the following two bug reports?
http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=877165
http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=832159

The first of those two was closed with a notice that the
patch is in CVS; the second is still open.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1028697&group_id=5470

From noreply at sourceforge.net  Wed May 23 01:10:47 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 22 May 2007 16:10:47 -0700
Subject: [ python-Bugs-1721890 ] IDLE hangs in popup method completion
Message-ID: <E1HqdV9-0000ij-Cx@sc8-sf-web23.sourceforge.net>

Bugs item #1721890, was opened at 2007-05-19 13:23
Message generated for change (Settings changed) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721890&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.5
Status: Open
Resolution: None
>Priority: 6
Private: No
Submitted By: Andy Harrington (andyharrington)
>Assigned to: Kurt B. Kaiser (kbk)
Summary: IDLE hangs in popup method completion

Initial Comment:
import os

os.

After entering the above code in a new idle editor window, the popup method completion window appears.  If I navigate with the down-arrow key, the list starts scrolling fine all the way down to spawnv, which I can select, but if I try to use down-arrow once more and scroll the list (to what would be startfile if I could reach it), idle hangs.  

Pure pagedown works all the way to in the popup to write, but then it I use up-arrow idle hangs when I try to scroll up beyond startfile to what would be spawnv.

I am running Windows XP, service pack 2.  On May 5 I installed and am running python-2.5.1.msi.

I started idle form idle.bat while in the idlelib directory.  I also ran \Python25\Lib\idlelib\idle.pyw from other directories with the same result.

I have no such problem with modules os.path or string.  I did not think of a module to try which has a list of methods as long as os.

 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721890&group_id=5470

From noreply at sourceforge.net  Wed May 23 01:18:51 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 22 May 2007 16:18:51 -0700
Subject: [ python-Feature Requests-1721083 ] Add File - Reload
Message-ID: <E1Hqdcx-0000FM-Ci@sc8-sf-web22.sourceforge.net>

Feature Requests item #1721083, was opened at 2007-05-17 22:15
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1721083&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Kurt B. Kaiser (kbk)
Summary: Add File - Reload

Initial Comment:
When using CVS or SVN, it is common to revert or merge a file that is open in the editor.  It would be great to have a reload/refresh option on the menu to bring in the changed file.  Without that option, the only approach is to close without saving, fire-up the editor again, and reload the file manually.

----------------------------------------------------------------------

>Comment By: Kurt B. Kaiser (kbk)
Date: 2007-05-22 19:18

Message:
Logged In: YES 
user_id=149084
Originator: NO

But isn't this an example of a bell/whistle which is outside IDLE's design
policies?  It would add a menu item which would be rather rarely used,
especially by beginners, it seems to me.  Why not just close the edit
window (not IDLE) and re-open using the Files / Recent Files feature?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1721083&group_id=5470

From noreply at sourceforge.net  Wed May 23 02:46:24 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 22 May 2007 17:46:24 -0700
Subject: [ python-Bugs-1723875 ] inspect.formatargspec last argument ignored
Message-ID: <E1Hqezg-0007qj-Tp@sc8-sf-web21.sourceforge.net>

Bugs item #1723875, was opened at 2007-05-23 00: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=1723875&group_id=5470

Please note that this message will contain a full 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
Private: No
Submitted By: Patrick Dobbs (patrickcd)
Assigned to: Nobody/Anonymous (nobody)
Summary: inspect.formatargspec last argument ignored

Initial Comment:
from: patrick at laculine.com

The last argument of inspect.formatargspect() is a function to control the way the entire returned string is formatted:

 ...join=joinseq):

joinseq being a function at line 757 in inspect.py

However, this argument is ignored and joinseq is not called.

The line in question is inspect.py 794 it was:

    return '(' + string.join(specs, ', ') + ')'

The function seems to work as advertised if this line is replaced by: 

    return join(specs)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1723875&group_id=5470

From noreply at sourceforge.net  Wed May 23 05:01:47 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 22 May 2007 20:01:47 -0700
Subject: [ python-Bugs-1721372 ] emphasize iteration volatility for set
Message-ID: <E1Hqh6h-00035K-8K@sc8-sf-web23.sourceforge.net>

Bugs item #1721372, was opened at 2007-05-18 10:10
Message generated for change (Comment added) made by aisaac0
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721372&group_id=5470

Please note that this 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: Rejected
Priority: 5
Private: No
Submitted By: Alan (aisaac0)
Assigned to: Nobody/Anonymous (nobody)
Summary: emphasize iteration volatility for set

Initial Comment:
For <URL:http://docs.python.org/lib/types-set.html>, append the following new sentence to the 2nd paragraph.

    Iteration over a set returns elements in an indeterminate order, which generally depends on factors outside the scope of the containing program.

*Justification:* users should not be expected to understand without being told that iteration order depends on factors outside the scope of the containing program. (Additionally, unlike the documentation for dictionaries, the documentation for sets fails to give a serious warning not to rely on iteration order.)


----------------------------------------------------------------------

>Comment By: Alan (aisaac0)
Date: 2007-05-22 22:01

Message:
Logged In: YES 
user_id=1025672
Originator: YES

Martin's preceding comment asks:
  "How else could you interpret 'unordered collection' but as 'having
arbitrary order'?"

This question seems to me to read into the docs much that is not there.
There are so many possibilities ...

Keep in mind that I proposed a docs patch believing that the docs should
communicate to users that a particular iteration on a set may produce a
different order of elements on *sequential* runs of an *unchanged* source. 
Martin been claiming that the docs do communicate this (although he has
been somewhat vague about the target audience).

Here is a simple description of a class whose instances are plausibly
considered an "unordered collection" that would not have that "volatility"
property. (The question here should not whether this is a silly class but
whether Martin is actually drawing a valid inference from the existing docs
rather than just reading his experience into them.)

Call the class ``Silly``. Initialize a Silly instance with an empty list
and a deterministically seeded instance of random.Random. A Silly instance
has an ``add`` method that computes the length of its list N and picks an
insertion point for the new item using randrange(N+1).  (If you want a
Silly instance to behave more like a set, we can insert an element only if
it's not in the list.) Iteration on this object is to be iteration on its
list, but no indexing or slicing is to be provided.

A ``Silly`` instance is plausibly an 'unordered collection' that is
iterable but does NOT have the "volatility" property under discussion.


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-22 00:22

Message:
Logged In: YES 
user_id=21627
Originator: NO

aisaac0: The first sentence of types-set says "A set object is an
unordered collection of immutable values."

How else could you interpret "unordered collection" but as "having
arbitrary order"?

----------------------------------------------------------------------

Comment By: Alan (aisaac0)
Date: 2007-05-21 22:27

Message:
Logged In: YES 
user_id=1025672
Originator: YES

Note that on c.l.python, Raymond Hettinger justifies this rejection as
follows:

  "the docs are sufficient when they say that set ordering is arbitrary"

Where exactly do the docs say this? I do not see it.
I am looking here: <URL:http://docs.python.org/lib/types-set.html>

I also take this as a concession that the docs *should* say something like
this,
which is about half of the language I proposed
(unless there is some reason why 'arbitrary' is superior to
'indeterminate').

Btw, I did provide the source code to several people before Peter.
This was clear in the thread on c.l.python.
I do not think they would appreciate being called "not experienced".


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-19 16:29

Message:
Logged In: YES 
user_id=21627
Originator: NO

aisaac0, thanks for elaborating. Your remark now convinces me that it was
the right thing to reject this change.

Ite seems that you suggest that experienced users
a) are aware that some objects compare and hash by their id(), and
b) that the id() is the address in memory, and
c) that the id() will influence the order in which objects are iterated,
and
d) fail to see that the id() may differ across runs

Such users are *not* experienced. There are many more reasons why the id
of an object may vary across runs. E.g. Linux 2.6 deliberately randomizes
memory management, so that identical processes get their objects allocated
at different addresses, to defeat security exploits that rely on
deterministic address of things in main memory (there is a system call to
disable this randomization)

Looking at the entire thread, I agree with Carsten Haese's posting: That
even experienced users couldn't diagnose this correctly is because they
a) did not receive the source code, and
b) were talked into believing that this has to do something with the
random module.

The library reference is a specification, not a tutorial.


----------------------------------------------------------------------

Comment By: Alan (aisaac0)
Date: 2007-05-19 08:09

Message:
Logged In: YES 
user_id=1025672
Originator: YES

The previous comment completely misses the point.  Again, please see the
discussion on c.l.python.  Not one of the participants expected sets to be
"ordered". What was suprising to them was the order can *change* across
sequential executions of an **unchanged** source.   This is of course
*quite* different than expecting that sets are ordered; I am perplexed that
anyone would conflate the two.  One cannot credibly argue that anyone who
understands that sets are not ordered will not be surprised, since even
sophisticated users were as a matter of fact surprised in the c.l.python
discussion.  (Until it was explained by Peter of course.)  A natural
conclusion is that the docs should offer better protection against such
surprise, since we have concrete evidence that even sophisticated users can
be surprised by this.

In sum, the previous comment conflates two distinct issues and so fails to
address the reasons for the proposed docs patch.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-19 01:38

Message:
Logged In: YES 
user_id=21627
Originator: NO

The documentation already says "Being an unordered collection, sets do not
record element position or order of insertion."

If users read this and fail to understand the notion of an unordered
collection, I see no way of "fixing" this.

----------------------------------------------------------------------

Comment By: Alan (aisaac0)
Date: 2007-05-18 21:28

Message:
Logged In: YES 
user_id=1025672
Originator: YES

While I do not mind my language being rejected, *something* should be
added to warn users.  What the previous comment fails to mention is the
number of people on c.l.python, some of whom are quite sophisticated users,
who failed to discover the source of indeterminacy.  Users should not have
to "rediscover" this because of a documentation failure.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-05-18 18:08

Message:
Logged In: YES 
user_id=80475
Originator: NO

While the OP knows what he means here, the suggested text does not add
clarity, it only makes the subject harder to understand and implies that
some mysterious, dark force is in place.  Further, the suggested text is
simply incorrect.  Given deterministic assignment of hash values and a
consistent insertion order, the order of keys in a set or dictionary is
fully determined.

I've read the source of this suggestion on comp.lang.python and commented
there.  The underlying issue had nothing to do with either sets or dicts. 
The code in question "re-discovered" that the location of objects in memory
 would vary between runs if the user deleted a pyc file for a module.  The
OP's script used object ids as hash values, hence the set/dict ordering
could vary between runs.  This was at odds with his expectation that that
the ordering would be deterministic.  The moral is that non-deterministic
hash values lead to non-deterministic set/dict ordering.

The docs for sets and dicts should not be muddled with tangential
discussions about implementation specific details regarding what governs
where objects are placed in memory.


----------------------------------------------------------------------

Comment By: Alan (aisaac0)
Date: 2007-05-18 13:00

Message:
Logged In: YES 
user_id=1025672
Originator: YES

Location in memory.
See Peter Otten's discussion at
http://www.thescripts.com/forum/post2552380-16.html

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-18 12:05

Message:
Logged In: YES 
user_id=21627
Originator: NO

What factors outside the containing program influence iteration order?
Iteration is completely deterministic, and only depends on the items
inserted, and the order in which they were inserted, neither of which is
outside the scope of the containing program. It's just that the order is
not easily predictable.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721372&group_id=5470

From noreply at sourceforge.net  Wed May 23 06:06:36 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 22 May 2007 21:06:36 -0700
Subject: [ python-Bugs-1723338 ] Crash in ctypes callproc function with
	unicode string arg
Message-ID: <E1Hqi7Q-0000c3-KQ@sc8-sf-web22.sourceforge.net>

Bugs item #1723338, was opened at 2007-05-22 03:43
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1723338&group_id=5470

Please note that this 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
Private: No
Submitted By: Colin Laplace (claplace)
>Assigned to: Thomas Heller (theller)
Summary: Crash in ctypes callproc function with unicode string arg

Initial Comment:
I've recently came to a bug using ctypes.
I was using ctypes to call a syscall and and passing it
a string argument, which was in fact in unicode.
This resulted in a python crash in the callproc function.

You can easily reproduce the crash by launching the attached python file (or at this link: https://core.fluendo.com/elisa/trac/browser/branches/rewrite-1/elisa/extern/inotify.py 
)

tested with python 2.5

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-22 21:06

Message:
Logged In: YES 
user_id=33168
Originator: NO

Thomas, could you take a look?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1723338&group_id=5470

From noreply at sourceforge.net  Wed May 23 13:29:57 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 23 May 2007 04:29:57 -0700
Subject: [ python-Bugs-1724099 ] Grammar error in Python Tutorial 2.5 section
	8.3
Message-ID: <E1Hqp2T-0007vX-D0@sc8-sf-web22.sourceforge.net>

Bugs item #1724099, was opened at 2007-05-23 11: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=1724099&group_id=5470

Please note that this 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
Private: No
Submitted By: sampson (sampson_uk)
Assigned to: Nobody/Anonymous (nobody)
Summary: Grammar error in Python Tutorial 2.5 section 8.3

Initial Comment:
In section 8.3 of the Python Tutorial (2.5) sentance reads:- 

"One my also instantiate an exception first before raising it and add any attributes to it as desired."

Suggest this is supposed to be "One may......"


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1724099&group_id=5470

From noreply at sourceforge.net  Wed May 23 15:26:06 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 23 May 2007 06:26:06 -0700
Subject: [ python-Bugs-1724099 ] Grammar error in Python Tutorial 2.5 section
	8.3
Message-ID: <E1Hqqqs-0006xS-Jg@sc8-sf-web23.sourceforge.net>

Bugs item #1724099, was opened at 2007-05-23 11:29
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1724099&group_id=5470

Please note that this 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: Out of Date
Priority: 5
Private: No
Submitted By: sampson (sampson_uk)
Assigned to: Nobody/Anonymous (nobody)
Summary: Grammar error in Python Tutorial 2.5 section 8.3

Initial Comment:
In section 8.3 of the Python Tutorial (2.5) sentance reads:- 

"One my also instantiate an exception first before raising it and add any attributes to it as desired."

Suggest this is supposed to be "One may......"


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-23 13:26

Message:
Logged In: YES 
user_id=849994
Originator: NO

Thanks, this is already fixed in SVN.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1724099&group_id=5470

From noreply at sourceforge.net  Wed May 23 18:42:24 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 23 May 2007 09:42:24 -0700
Subject: [ python-Bugs-1724366 ] cPickle module doesn't work with universal
	line endings
Message-ID: <E1Hqtuq-0005UV-Ey@sc8-sf-web24.sourceforge.net>

Bugs item #1724366, was opened at 2007-05-23 18: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=1724366&group_id=5470

Please note that this message will contain a full 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
Private: No
Submitted By: Geoffrey Bache (gjb1002)
Assigned to: Nobody/Anonymous (nobody)
Summary: cPickle module doesn't work with universal line endings

Initial Comment:
On UNIX, I cannot read pickle files created on Windows using the cPickle module, even if I open the file with universal line endings.

It works fine with the pickle module but is of course slower (and I have to read lots of them)

I attach a test case that pickles and unpickles an smptlib.SMTP object, converting the file to DOS format in between. There is nothing special about SMTP, you can use any object at all in a different module. 

On my system (RHEL4 with Python 2.4.3) I get the following output:

portmoller : pickletest.py cPickle
unix2dos: converting file dump to DOS format ...
Traceback (most recent call last):
  File "pickletest.py", line 14, in ?
    print load(readFile)
ImportError: No module named smtplib
portmoller : pickletest.py pickle
unix2dos: converting file dump to DOS format ...
<smtplib.SMTP instance at 0xb7ea350c>


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1724366&group_id=5470

From noreply at sourceforge.net  Wed May 23 20:26:39 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 23 May 2007 11:26:39 -0700
Subject: [ python-Bugs-1722485 ] Option -OO doesn't remove docstrings
Message-ID: <E1HqvXj-0006Kz-Aj@sc8-sf-web22.sourceforge.net>

Bugs item #1722485, was opened at 2007-05-21 10:18
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1722485&group_id=5470

Please note that this 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
Private: No
Submitted By: Grzegorz Adam Hankiewicz (gradha)
Assigned to: Nobody/Anonymous (nobody)
Summary: Option -OO doesn't remove docstrings

Initial Comment:
I'm using Python 2.5.1 as said by the -V switch under Windows XP. I run one of my programs with -OO, which generates a good amount of .pyo files in the directory. According to -h the -OO parameter removes docstrings. However, when I open the .pyo files with vim I can see all the docstrings in plain text.

Conclusion, docstrings are not being removed. I noticed this in 2.5, which prompted me to upgrade after this thread: http://sourceforge.net/mailarchive/forum.php?thread_name=464D5A57.2060809%40rastertech.es&forum_name=py2exe-users

----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2007-05-23 20:26

Message:
Logged In: YES 
user_id=11105
Originator: NO

I can confirm this bug (but have no time to work on a patch).
This simple script prints 'the docs' when run with 'python2.5 -OO',
but prints 'None' when run with Python2.4 (for example).

IMO this should be fixed in the next maintainance release, so raising the
priority.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1722485&group_id=5470

From noreply at sourceforge.net  Wed May 23 20:35:51 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 23 May 2007 11:35:51 -0700
Subject: [ python-Bugs-1723338 ] Crash in ctypes callproc function with
	unicode string arg
Message-ID: <E1Hqvgd-0008UO-8n@sc8-sf-web21.sourceforge.net>

Bugs item #1723338, was opened at 2007-05-22 12:43
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1723338&group_id=5470

Please note that this 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: Works For Me
Priority: 5
Private: No
Submitted By: Colin Laplace (claplace)
Assigned to: Thomas Heller (theller)
Summary: Crash in ctypes callproc function with unicode string arg

Initial Comment:
I've recently came to a bug using ctypes.
I was using ctypes to call a syscall and and passing it
a string argument, which was in fact in unicode.
This resulted in a python crash in the callproc function.

You can easily reproduce the crash by launching the attached python file (or at this link: https://core.fluendo.com/elisa/trac/browser/branches/rewrite-1/elisa/extern/inotify.py 
)

tested with python 2.5

----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2007-05-23 20:35

Message:
Logged In: YES 
user_id=11105
Originator: NO

Unfortunately your test script does not run for me (I don't have twisted
installed on Linux).

I fear this is not a bug.  When the .argtypes attribute for a foreign
function is not set, you can pass (among others) Python strings *and*
Python unicode strings to the function.  The foreign function will receive
a 'char *' in the former case, and a 'wchar_t *' in the latter case - the
unicode string will *not* be converted.

If this is your problem, and the foreign function expects a 'char *', you
have several choices:

1. You can convert the unicode string to an ascii string in the Python
code yourself.
2. You can wrap the unicode string in a c_char_p instance, and ctypes will
do the conversion for you.
3. You can set the correct .argtypes attribute on the function, and ctypes
will do the conversion for you.

If this is not your problem, please provide a self-contained test case.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-23 06:06

Message:
Logged In: YES 
user_id=33168
Originator: NO

Thomas, could you take a look?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1723338&group_id=5470

From noreply at sourceforge.net  Wed May 23 23:27:27 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 23 May 2007 14:27:27 -0700
Subject: [ python-Bugs-1722348 ] urlparse.urlunparse forms file urls
	incorrectly
Message-ID: <E1HqyMh-00070H-GJ@sc8-sf-web24.sourceforge.net>

Bugs item #1722348, was opened at 2007-05-21 04:05
Message generated for change (Comment added) made by orsenthil
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1722348&group_id=5470

Please note that this message will contain 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
Private: No
Submitted By: Thomas Folz-Donahue (eigenlambda)
Assigned to: Nobody/Anonymous (nobody)
Summary: urlparse.urlunparse forms file urls incorrectly

Initial Comment:
This is a conversation with the current Python interpreter.

>>> import urlparse
>>> urlparse.urlparse(urlparse.urlunparse(urlparse.urlparse("file:////usr/bin/python")))
('file', 'usr', '/bin/python', '', '', '')

As you can see, the results are incorrect.  The problem is in the urlunsplit function:

def urlunsplit((scheme, netloc, url, query, fragment)):
    if netloc or (scheme and scheme in uses_netloc and url[:2] != '//'):
        if url and url[:1] != '/': url = '/' + url
        url = '//' + (netloc or '') + url
    if scheme:
        url = scheme + ':' + url
    if query:
        url = url + '?' + query
    if fragment:
        url = url + '#' + fragment
    return url

RFC 1808 (see http://www.ietf.org/rfc/rfc1808.txt ) specifies that a URL shall have the following syntax:
<scheme>://<net_loc>/<path>;<params>?<query>#<fragment>

The problem with the current version of urlunsplit is that it tests if there are already two slashes before the 'url' section before outputting a URL.  This is incorrect because (1) RFC 1808 clearly specifies at least three slashes between the end of the scheme portion and the beginning of the path portion and (2) this method will strip the first few slashes from an arbitrary path portion, which may require those slashes.  Removing that url[:2] != '//' causes urlunsplit to behave correctly when dealing with urls like file:////usr/bin/python .


----------------------------------------------------------------------

Comment By: O.R.Senthil Kumaran (orsenthil)
Date: 2007-05-24 02:57

Message:
Logged In: YES 
user_id=942711
Originator: NO

Hi Thomas,
Verified the Bug with Python 2.5 and verified the fix as well. Works
fine.

>>> urlparse(urlunparse(urlparse('file:////home/ors')))
('file', '', '//home/ors', '', '', '')
>>> urlparse(urlunparse(urlparse('file://///home/ors')))
('file', '', '///home/ors', '', '', '')
>>> urlparse(urlunparse(urlparse('file://////home/ors')))
('file', '', '////home/ors', '', '', '')
>>>
urlparse(urlunparse(urlparse(urlunparse(urlparse('file://////home/ors')))))
('file', '', '////home/ors', '', '', '')
>>>



----------------------------------------------------------------------

Comment By: Thomas Folz-Donahue (eigenlambda)
Date: 2007-05-21 04:42

Message:
Logged In: YES 
user_id=1797315
Originator: YES

Some other issues with the urlparse module.  Several constant lists
defined at the beginning of the module should be sets because they are only
used for testing if certain strings are in them.  Also, urlunsplit() uses
the + operator way too much, creating strings that are immediately thrown
away.  IMO, the alternative is actually more readable.  Attaching a patch
(diff -u urlparse.py urlparse.py.new > urlparse.diff).
File Added: urlparse.diff

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1722348&group_id=5470

From noreply at sourceforge.net  Thu May 24 14:56:34 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 24 May 2007 05:56:34 -0700
Subject: [ python-Bugs-1724822 ] shlex.split problems on Windows
Message-ID: <E1HrCrq-0006lp-Ev@sc8-sf-web21.sourceforge.net>

Bugs item #1724822, was opened at 2007-05-24 14:56
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1724822&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Geoffrey Bache (gjb1002)
Assigned to: Nobody/Anonymous (nobody)
Summary: shlex.split problems on Windows

Initial Comment:
What is shlex.split supposed to do on Windows? It seems to be present but it can't handle basic Windows pathnames : shlex.split("C:\\directory\\file") returns C:directoryfile (whereas os.system happily accepts the same string).

Also, it runs in POSIX mode and there is no way to override it! Why isn't POSIX mode the default on POSIX systems and not on non-POSIX systems? Or for it to at least be possible to says shlex.split(s, posix=False)?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1724822&group_id=5470

From noreply at sourceforge.net  Thu May 24 15:09:11 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 24 May 2007 06:09:11 -0700
Subject: [ python-Bugs-1724822 ] shlex.split problems on Windows
Message-ID: <E1HrD43-0003Tc-Kf@sc8-sf-web23.sourceforge.net>

Bugs item #1724822, was opened at 2007-05-24 12:56
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1724822&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.5
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Geoffrey Bache (gjb1002)
Assigned to: Nobody/Anonymous (nobody)
Summary: shlex.split problems on Windows

Initial Comment:
What is shlex.split supposed to do on Windows? It seems to be present but it can't handle basic Windows pathnames : shlex.split("C:\\directory\\file") returns C:directoryfile (whereas os.system happily accepts the same string).

Also, it runs in POSIX mode and there is no way to override it! Why isn't POSIX mode the default on POSIX systems and not on non-POSIX systems? Or for it to at least be possible to says shlex.split(s, posix=False)?


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-24 13:09

Message:
Logged In: YES 
user_id=849994
Originator: NO

The docs to shlex say: "The shlex class makes it easy to write lexical
analyzers for simple syntaxes resembling that of the Unix shell."

It is not meant to be a cross-platform shell quoting handler, but an
implementation of Unix shell behavior.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1724822&group_id=5470

From noreply at sourceforge.net  Thu May 24 16:19:16 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 24 May 2007 07:19:16 -0700
Subject: [ python-Bugs-1724822 ] shlex.split problems on Windows
Message-ID: <E1HrE9s-0002qv-Qn@sc8-sf-web23.sourceforge.net>

Bugs item #1724822, was opened at 2007-05-24 14:56
Message generated for change (Comment added) made by gjb1002
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1724822&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.5
Status: Closed
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Geoffrey Bache (gjb1002)
Assigned to: Nobody/Anonymous (nobody)
Summary: shlex.split problems on Windows

Initial Comment:
What is shlex.split supposed to do on Windows? It seems to be present but it can't handle basic Windows pathnames : shlex.split("C:\\directory\\file") returns C:directoryfile (whereas os.system happily accepts the same string).

Also, it runs in POSIX mode and there is no way to override it! Why isn't POSIX mode the default on POSIX systems and not on non-POSIX systems? Or for it to at least be possible to says shlex.split(s, posix=False)?


----------------------------------------------------------------------

>Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-24 16:19

Message:
Logged In: YES 
user_id=769182
Originator: YES

Then what is "non-POSIX mode" if it's only supposed to work on UNIX?

I noted the initial comment but it seemed to be out of date. Especially as
it
seems to work fine to copy shlex.split and correct the default value for
"posix".
Seemed a very simple change that had little chance of being wrong.

If Windows behaviour is really unsupported then surely the function should
not
be available there.


----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-24 15:09

Message:
Logged In: YES 
user_id=849994
Originator: NO

The docs to shlex say: "The shlex class makes it easy to write lexical
analyzers for simple syntaxes resembling that of the Unix shell."

It is not meant to be a cross-platform shell quoting handler, but an
implementation of Unix shell behavior.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1724822&group_id=5470

From noreply at sourceforge.net  Thu May 24 16:26:54 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 24 May 2007 07:26:54 -0700
Subject: [ python-Bugs-1724822 ] shlex.split problems on Windows
Message-ID: <E1HrEHG-0003dz-68@sc8-sf-web23.sourceforge.net>

Bugs item #1724822, was opened at 2007-05-24 12:56
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1724822&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.5
Status: Closed
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Geoffrey Bache (gjb1002)
Assigned to: Nobody/Anonymous (nobody)
Summary: shlex.split problems on Windows

Initial Comment:
What is shlex.split supposed to do on Windows? It seems to be present but it can't handle basic Windows pathnames : shlex.split("C:\\directory\\file") returns C:directoryfile (whereas os.system happily accepts the same string).

Also, it runs in POSIX mode and there is no way to override it! Why isn't POSIX mode the default on POSIX systems and not on non-POSIX systems? Or for it to at least be possible to says shlex.split(s, posix=False)?


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-24 14:26

Message:
Logged In: YES 
user_id=849994
Originator: NO

Further quote: "This will often be useful for writing minilanguages, (for
example, in run control files for Python applications) or for parsing
quoted strings."

Why shouldn't that feature not be available under Windows?
Again, shlex is *not supposed* to handle Windows command lines.

Also, http://docs.python.org/lib/shlex-parsing-rules.html clearly says
what the difference between
"posix=True" and "posix=False" is.

That non-posix mode works on Windows filenames is because it does not
handle backslash escapes.

----------------------------------------------------------------------

Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-24 14:19

Message:
Logged In: YES 
user_id=769182
Originator: YES

Then what is "non-POSIX mode" if it's only supposed to work on UNIX?

I noted the initial comment but it seemed to be out of date. Especially as
it
seems to work fine to copy shlex.split and correct the default value for
"posix".
Seemed a very simple change that had little chance of being wrong.

If Windows behaviour is really unsupported then surely the function should
not
be available there.


----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-24 13:09

Message:
Logged In: YES 
user_id=849994
Originator: NO

The docs to shlex say: "The shlex class makes it easy to write lexical
analyzers for simple syntaxes resembling that of the Unix shell."

It is not meant to be a cross-platform shell quoting handler, but an
implementation of Unix shell behavior.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1724822&group_id=5470

From noreply at sourceforge.net  Thu May 24 16:52:45 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 24 May 2007 07:52:45 -0700
Subject: [ python-Bugs-1724822 ] shlex.split problems on Windows
Message-ID: <E1HrEgH-0003uI-Kn@sc8-sf-web24.sourceforge.net>

Bugs item #1724822, was opened at 2007-05-24 14:56
Message generated for change (Comment added) made by gjb1002
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1724822&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.5
Status: Closed
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Geoffrey Bache (gjb1002)
Assigned to: Nobody/Anonymous (nobody)
Summary: shlex.split problems on Windows

Initial Comment:
What is shlex.split supposed to do on Windows? It seems to be present but it can't handle basic Windows pathnames : shlex.split("C:\\directory\\file") returns C:directoryfile (whereas os.system happily accepts the same string).

Also, it runs in POSIX mode and there is no way to override it! Why isn't POSIX mode the default on POSIX systems and not on non-POSIX systems? Or for it to at least be possible to says shlex.split(s, posix=False)?


----------------------------------------------------------------------

>Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-24 16:52

Message:
Logged In: YES 
user_id=769182
Originator: YES

But surely it's not named "POSIX mode" for no reason. It's because those
rules resemble those of the UNIX shell. While "non-POSIX mode" resemble
those of non-POSIX shells, such as DOS.

shlex.split seemed to be a shortcut for those wanting to simply parse a
generic quoted string who weren't interested in creating a minilanguage.
Surely it should be possible to avoid POSIX rules when doing this on
Windows?

You haven't suggested any other way to do this. The fact is, I do want to
parse a Windows command line. The only way I have found is by copying
shlex.split and hacking it. Didn't seem very nice, especially it seems a
fix would be totally trivial, but it's obviously better than starting from
scratch.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-24 16:26

Message:
Logged In: YES 
user_id=849994
Originator: NO

Further quote: "This will often be useful for writing minilanguages, (for
example, in run control files for Python applications) or for parsing
quoted strings."

Why shouldn't that feature not be available under Windows?
Again, shlex is *not supposed* to handle Windows command lines.

Also, http://docs.python.org/lib/shlex-parsing-rules.html clearly says
what the difference between
"posix=True" and "posix=False" is.

That non-posix mode works on Windows filenames is because it does not
handle backslash escapes.

----------------------------------------------------------------------

Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-24 16:19

Message:
Logged In: YES 
user_id=769182
Originator: YES

Then what is "non-POSIX mode" if it's only supposed to work on UNIX?

I noted the initial comment but it seemed to be out of date. Especially as
it
seems to work fine to copy shlex.split and correct the default value for
"posix".
Seemed a very simple change that had little chance of being wrong.

If Windows behaviour is really unsupported then surely the function should
not
be available there.


----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-24 15:09

Message:
Logged In: YES 
user_id=849994
Originator: NO

The docs to shlex say: "The shlex class makes it easy to write lexical
analyzers for simple syntaxes resembling that of the Unix shell."

It is not meant to be a cross-platform shell quoting handler, but an
implementation of Unix shell behavior.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1724822&group_id=5470

From noreply at sourceforge.net  Thu May 24 16:59:57 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 24 May 2007 07:59:57 -0700
Subject: [ python-Bugs-1724822 ] shlex.split problems on Windows
Message-ID: <E1HrEnF-0003wx-LJ@sc8-sf-web22.sourceforge.net>

Bugs item #1724822, was opened at 2007-05-24 12:56
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1724822&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.5
Status: Closed
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Geoffrey Bache (gjb1002)
Assigned to: Nobody/Anonymous (nobody)
Summary: shlex.split problems on Windows

Initial Comment:
What is shlex.split supposed to do on Windows? It seems to be present but it can't handle basic Windows pathnames : shlex.split("C:\\directory\\file") returns C:directoryfile (whereas os.system happily accepts the same string).

Also, it runs in POSIX mode and there is no way to override it! Why isn't POSIX mode the default on POSIX systems and not on non-POSIX systems? Or for it to at least be possible to says shlex.split(s, posix=False)?


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-24 14:59

Message:
Logged In: YES 
user_id=849994
Originator: NO

The fact remains that shlex is not meant to switch modes automatically
depending on the platform.

If you want to contribute a third mode that completely resembles
Windows-style parsing,
you're most welcome, just submit a patch and I'll look at it.

----------------------------------------------------------------------

Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-24 14:52

Message:
Logged In: YES 
user_id=769182
Originator: YES

But surely it's not named "POSIX mode" for no reason. It's because those
rules resemble those of the UNIX shell. While "non-POSIX mode" resemble
those of non-POSIX shells, such as DOS.

shlex.split seemed to be a shortcut for those wanting to simply parse a
generic quoted string who weren't interested in creating a minilanguage.
Surely it should be possible to avoid POSIX rules when doing this on
Windows?

You haven't suggested any other way to do this. The fact is, I do want to
parse a Windows command line. The only way I have found is by copying
shlex.split and hacking it. Didn't seem very nice, especially it seems a
fix would be totally trivial, but it's obviously better than starting from
scratch.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-24 14:26

Message:
Logged In: YES 
user_id=849994
Originator: NO

Further quote: "This will often be useful for writing minilanguages, (for
example, in run control files for Python applications) or for parsing
quoted strings."

Why shouldn't that feature not be available under Windows?
Again, shlex is *not supposed* to handle Windows command lines.

Also, http://docs.python.org/lib/shlex-parsing-rules.html clearly says
what the difference between
"posix=True" and "posix=False" is.

That non-posix mode works on Windows filenames is because it does not
handle backslash escapes.

----------------------------------------------------------------------

Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-24 14:19

Message:
Logged In: YES 
user_id=769182
Originator: YES

Then what is "non-POSIX mode" if it's only supposed to work on UNIX?

I noted the initial comment but it seemed to be out of date. Especially as
it
seems to work fine to copy shlex.split and correct the default value for
"posix".
Seemed a very simple change that had little chance of being wrong.

If Windows behaviour is really unsupported then surely the function should
not
be available there.


----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-24 13:09

Message:
Logged In: YES 
user_id=849994
Originator: NO

The docs to shlex say: "The shlex class makes it easy to write lexical
analyzers for simple syntaxes resembling that of the Unix shell."

It is not meant to be a cross-platform shell quoting handler, but an
implementation of Unix shell behavior.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1724822&group_id=5470

From noreply at sourceforge.net  Thu May 24 17:17:48 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 24 May 2007 08:17:48 -0700
Subject: [ python-Bugs-1724822 ] shlex.split problems on Windows
Message-ID: <E1HrF4W-0006fA-7u@sc8-sf-web24.sourceforge.net>

Bugs item #1724822, was opened at 2007-05-24 14:56
Message generated for change (Comment added) made by gjb1002
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1724822&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.5
Status: Closed
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Geoffrey Bache (gjb1002)
Assigned to: Nobody/Anonymous (nobody)
Summary: shlex.split problems on Windows

Initial Comment:
What is shlex.split supposed to do on Windows? It seems to be present but it can't handle basic Windows pathnames : shlex.split("C:\\directory\\file") returns C:directoryfile (whereas os.system happily accepts the same string).

Also, it runs in POSIX mode and there is no way to override it! Why isn't POSIX mode the default on POSIX systems and not on non-POSIX systems? Or for it to at least be possible to says shlex.split(s, posix=False)?


----------------------------------------------------------------------

>Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-24 17:17

Message:
Logged In: YES 
user_id=769182
Originator: YES

OK, but surely providing the possibility to override the POSIX flag isn't
difficult. That doesn't require any change in default behaviour. 

It also seems it should be possible to request enhancements without having
to do the work myself. Can we agree that parsing Windows command lines is a
generally useful thing to do? We already have a module that can parse UNIX
command lines which isn't unrelated. Perhaps this should be changed to
"enhancement" rather than "invalid". 

Whether or not the original author of shlex cared about Windows seems to
be beside the point.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-24 16:59

Message:
Logged In: YES 
user_id=849994
Originator: NO

The fact remains that shlex is not meant to switch modes automatically
depending on the platform.

If you want to contribute a third mode that completely resembles
Windows-style parsing,
you're most welcome, just submit a patch and I'll look at it.

----------------------------------------------------------------------

Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-24 16:52

Message:
Logged In: YES 
user_id=769182
Originator: YES

But surely it's not named "POSIX mode" for no reason. It's because those
rules resemble those of the UNIX shell. While "non-POSIX mode" resemble
those of non-POSIX shells, such as DOS.

shlex.split seemed to be a shortcut for those wanting to simply parse a
generic quoted string who weren't interested in creating a minilanguage.
Surely it should be possible to avoid POSIX rules when doing this on
Windows?

You haven't suggested any other way to do this. The fact is, I do want to
parse a Windows command line. The only way I have found is by copying
shlex.split and hacking it. Didn't seem very nice, especially it seems a
fix would be totally trivial, but it's obviously better than starting from
scratch.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-24 16:26

Message:
Logged In: YES 
user_id=849994
Originator: NO

Further quote: "This will often be useful for writing minilanguages, (for
example, in run control files for Python applications) or for parsing
quoted strings."

Why shouldn't that feature not be available under Windows?
Again, shlex is *not supposed* to handle Windows command lines.

Also, http://docs.python.org/lib/shlex-parsing-rules.html clearly says
what the difference between
"posix=True" and "posix=False" is.

That non-posix mode works on Windows filenames is because it does not
handle backslash escapes.

----------------------------------------------------------------------

Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-24 16:19

Message:
Logged In: YES 
user_id=769182
Originator: YES

Then what is "non-POSIX mode" if it's only supposed to work on UNIX?

I noted the initial comment but it seemed to be out of date. Especially as
it
seems to work fine to copy shlex.split and correct the default value for
"posix".
Seemed a very simple change that had little chance of being wrong.

If Windows behaviour is really unsupported then surely the function should
not
be available there.


----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-24 15:09

Message:
Logged In: YES 
user_id=849994
Originator: NO

The docs to shlex say: "The shlex class makes it easy to write lexical
analyzers for simple syntaxes resembling that of the Unix shell."

It is not meant to be a cross-platform shell quoting handler, but an
implementation of Unix shell behavior.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1724822&group_id=5470

From noreply at sourceforge.net  Thu May 24 17:28:36 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 24 May 2007 08:28:36 -0700
Subject: [ python-Feature Requests-1724822 ] provide a shlex.split alternative
	for Windows shell syntax
Message-ID: <E1HrFEy-0003ip-HS@sc8-sf-web23.sourceforge.net>

Feature Requests item #1724822, was opened at 2007-05-24 12:56
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1724822&group_id=5470

Please note that this 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
Private: No
Submitted By: Geoffrey Bache (gjb1002)
Assigned to: Nobody/Anonymous (nobody)
>Summary: provide a shlex.split alternative for Windows shell syntax

Initial Comment:
What is shlex.split supposed to do on Windows? It seems to be present but it can't handle basic Windows pathnames : shlex.split("C:\\directory\\file") returns C:directoryfile (whereas os.system happily accepts the same string).

Also, it runs in POSIX mode and there is no way to override it! Why isn't POSIX mode the default on POSIX systems and not on non-POSIX systems? Or for it to at least be possible to says shlex.split(s, posix=False)?


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-24 15:28

Message:
Logged In: YES 
user_id=849994
Originator: NO

Okay, I'll turn this into a feature request.

BTW, what do you mean with "override the POSIX flag"?

----------------------------------------------------------------------

Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-24 15:17

Message:
Logged In: YES 
user_id=769182
Originator: YES

OK, but surely providing the possibility to override the POSIX flag isn't
difficult. That doesn't require any change in default behaviour. 

It also seems it should be possible to request enhancements without having
to do the work myself. Can we agree that parsing Windows command lines is a
generally useful thing to do? We already have a module that can parse UNIX
command lines which isn't unrelated. Perhaps this should be changed to
"enhancement" rather than "invalid". 

Whether or not the original author of shlex cared about Windows seems to
be beside the point.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-24 14:59

Message:
Logged In: YES 
user_id=849994
Originator: NO

The fact remains that shlex is not meant to switch modes automatically
depending on the platform.

If you want to contribute a third mode that completely resembles
Windows-style parsing,
you're most welcome, just submit a patch and I'll look at it.

----------------------------------------------------------------------

Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-24 14:52

Message:
Logged In: YES 
user_id=769182
Originator: YES

But surely it's not named "POSIX mode" for no reason. It's because those
rules resemble those of the UNIX shell. While "non-POSIX mode" resemble
those of non-POSIX shells, such as DOS.

shlex.split seemed to be a shortcut for those wanting to simply parse a
generic quoted string who weren't interested in creating a minilanguage.
Surely it should be possible to avoid POSIX rules when doing this on
Windows?

You haven't suggested any other way to do this. The fact is, I do want to
parse a Windows command line. The only way I have found is by copying
shlex.split and hacking it. Didn't seem very nice, especially it seems a
fix would be totally trivial, but it's obviously better than starting from
scratch.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-24 14:26

Message:
Logged In: YES 
user_id=849994
Originator: NO

Further quote: "This will often be useful for writing minilanguages, (for
example, in run control files for Python applications) or for parsing
quoted strings."

Why shouldn't that feature not be available under Windows?
Again, shlex is *not supposed* to handle Windows command lines.

Also, http://docs.python.org/lib/shlex-parsing-rules.html clearly says
what the difference between
"posix=True" and "posix=False" is.

That non-posix mode works on Windows filenames is because it does not
handle backslash escapes.

----------------------------------------------------------------------

Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-24 14:19

Message:
Logged In: YES 
user_id=769182
Originator: YES

Then what is "non-POSIX mode" if it's only supposed to work on UNIX?

I noted the initial comment but it seemed to be out of date. Especially as
it
seems to work fine to copy shlex.split and correct the default value for
"posix".
Seemed a very simple change that had little chance of being wrong.

If Windows behaviour is really unsupported then surely the function should
not
be available there.


----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-24 13:09

Message:
Logged In: YES 
user_id=849994
Originator: NO

The docs to shlex say: "The shlex class makes it easy to write lexical
analyzers for simple syntaxes resembling that of the Unix shell."

It is not meant to be a cross-platform shell quoting handler, but an
implementation of Unix shell behavior.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1724822&group_id=5470

From noreply at sourceforge.net  Thu May 24 17:31:43 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 24 May 2007 08:31:43 -0700
Subject: [ python-Feature Requests-1724822 ] provide a shlex.split alternative
	for Windows shell syntax
Message-ID: <E1HrFHz-00043u-97@sc8-sf-web23.sourceforge.net>

Feature Requests item #1724822, was opened at 2007-05-24 14:56
Message generated for change (Comment added) made by gjb1002
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1724822&group_id=5470

Please note that this 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
Private: No
Submitted By: Geoffrey Bache (gjb1002)
Assigned to: Nobody/Anonymous (nobody)
Summary: provide a shlex.split alternative for Windows shell syntax

Initial Comment:
What is shlex.split supposed to do on Windows? It seems to be present but it can't handle basic Windows pathnames : shlex.split("C:\\directory\\file") returns C:directoryfile (whereas os.system happily accepts the same string).

Also, it runs in POSIX mode and there is no way to override it! Why isn't POSIX mode the default on POSIX systems and not on non-POSIX systems? Or for it to at least be possible to says shlex.split(s, posix=False)?


----------------------------------------------------------------------

>Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-24 17:31

Message:
Logged In: YES 
user_id=769182
Originator: YES

I mean changing shlex.split to accept an optional parameter "posix":

def split(s, comments=False, posix=True):
    lex = shlex(s, posix)
    lex.whitespace_split = True
    if not comments:
        lex.commenters = ''
    return list(lex)


----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-24 17:28

Message:
Logged In: YES 
user_id=849994
Originator: NO

Okay, I'll turn this into a feature request.

BTW, what do you mean with "override the POSIX flag"?

----------------------------------------------------------------------

Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-24 17:17

Message:
Logged In: YES 
user_id=769182
Originator: YES

OK, but surely providing the possibility to override the POSIX flag isn't
difficult. That doesn't require any change in default behaviour. 

It also seems it should be possible to request enhancements without having
to do the work myself. Can we agree that parsing Windows command lines is a
generally useful thing to do? We already have a module that can parse UNIX
command lines which isn't unrelated. Perhaps this should be changed to
"enhancement" rather than "invalid". 

Whether or not the original author of shlex cared about Windows seems to
be beside the point.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-24 16:59

Message:
Logged In: YES 
user_id=849994
Originator: NO

The fact remains that shlex is not meant to switch modes automatically
depending on the platform.

If you want to contribute a third mode that completely resembles
Windows-style parsing,
you're most welcome, just submit a patch and I'll look at it.

----------------------------------------------------------------------

Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-24 16:52

Message:
Logged In: YES 
user_id=769182
Originator: YES

But surely it's not named "POSIX mode" for no reason. It's because those
rules resemble those of the UNIX shell. While "non-POSIX mode" resemble
those of non-POSIX shells, such as DOS.

shlex.split seemed to be a shortcut for those wanting to simply parse a
generic quoted string who weren't interested in creating a minilanguage.
Surely it should be possible to avoid POSIX rules when doing this on
Windows?

You haven't suggested any other way to do this. The fact is, I do want to
parse a Windows command line. The only way I have found is by copying
shlex.split and hacking it. Didn't seem very nice, especially it seems a
fix would be totally trivial, but it's obviously better than starting from
scratch.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-24 16:26

Message:
Logged In: YES 
user_id=849994
Originator: NO

Further quote: "This will often be useful for writing minilanguages, (for
example, in run control files for Python applications) or for parsing
quoted strings."

Why shouldn't that feature not be available under Windows?
Again, shlex is *not supposed* to handle Windows command lines.

Also, http://docs.python.org/lib/shlex-parsing-rules.html clearly says
what the difference between
"posix=True" and "posix=False" is.

That non-posix mode works on Windows filenames is because it does not
handle backslash escapes.

----------------------------------------------------------------------

Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-24 16:19

Message:
Logged In: YES 
user_id=769182
Originator: YES

Then what is "non-POSIX mode" if it's only supposed to work on UNIX?

I noted the initial comment but it seemed to be out of date. Especially as
it
seems to work fine to copy shlex.split and correct the default value for
"posix".
Seemed a very simple change that had little chance of being wrong.

If Windows behaviour is really unsupported then surely the function should
not
be available there.


----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-24 15:09

Message:
Logged In: YES 
user_id=849994
Originator: NO

The docs to shlex say: "The shlex class makes it easy to write lexical
analyzers for simple syntaxes resembling that of the Unix shell."

It is not meant to be a cross-platform shell quoting handler, but an
implementation of Unix shell behavior.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1724822&group_id=5470

From noreply at sourceforge.net  Thu May 24 18:50:40 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 24 May 2007 09:50:40 -0700
Subject: [ python-Feature Requests-1724822 ] provide a shlex.split alternative
	for Windows shell syntax
Message-ID: <E1HrGWO-0006G7-1Q@sc8-sf-web23.sourceforge.net>

Feature Requests item #1724822, was opened at 2007-05-24 12:56
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1724822&group_id=5470

Please note that this 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
Private: No
Submitted By: Geoffrey Bache (gjb1002)
Assigned to: Nobody/Anonymous (nobody)
Summary: provide a shlex.split alternative for Windows shell syntax

Initial Comment:
What is shlex.split supposed to do on Windows? It seems to be present but it can't handle basic Windows pathnames : shlex.split("C:\\directory\\file") returns C:directoryfile (whereas os.system happily accepts the same string).

Also, it runs in POSIX mode and there is no way to override it! Why isn't POSIX mode the default on POSIX systems and not on non-POSIX systems? Or for it to at least be possible to says shlex.split(s, posix=False)?


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-24 16:50

Message:
Logged In: YES 
user_id=849994
Originator: NO

Ah, that is reasonable. I added that parameter in rev. 55549.

----------------------------------------------------------------------

Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-24 15:31

Message:
Logged In: YES 
user_id=769182
Originator: YES

I mean changing shlex.split to accept an optional parameter "posix":

def split(s, comments=False, posix=True):
    lex = shlex(s, posix)
    lex.whitespace_split = True
    if not comments:
        lex.commenters = ''
    return list(lex)


----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-24 15:28

Message:
Logged In: YES 
user_id=849994
Originator: NO

Okay, I'll turn this into a feature request.

BTW, what do you mean with "override the POSIX flag"?

----------------------------------------------------------------------

Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-24 15:17

Message:
Logged In: YES 
user_id=769182
Originator: YES

OK, but surely providing the possibility to override the POSIX flag isn't
difficult. That doesn't require any change in default behaviour. 

It also seems it should be possible to request enhancements without having
to do the work myself. Can we agree that parsing Windows command lines is a
generally useful thing to do? We already have a module that can parse UNIX
command lines which isn't unrelated. Perhaps this should be changed to
"enhancement" rather than "invalid". 

Whether or not the original author of shlex cared about Windows seems to
be beside the point.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-24 14:59

Message:
Logged In: YES 
user_id=849994
Originator: NO

The fact remains that shlex is not meant to switch modes automatically
depending on the platform.

If you want to contribute a third mode that completely resembles
Windows-style parsing,
you're most welcome, just submit a patch and I'll look at it.

----------------------------------------------------------------------

Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-24 14:52

Message:
Logged In: YES 
user_id=769182
Originator: YES

But surely it's not named "POSIX mode" for no reason. It's because those
rules resemble those of the UNIX shell. While "non-POSIX mode" resemble
those of non-POSIX shells, such as DOS.

shlex.split seemed to be a shortcut for those wanting to simply parse a
generic quoted string who weren't interested in creating a minilanguage.
Surely it should be possible to avoid POSIX rules when doing this on
Windows?

You haven't suggested any other way to do this. The fact is, I do want to
parse a Windows command line. The only way I have found is by copying
shlex.split and hacking it. Didn't seem very nice, especially it seems a
fix would be totally trivial, but it's obviously better than starting from
scratch.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-24 14:26

Message:
Logged In: YES 
user_id=849994
Originator: NO

Further quote: "This will often be useful for writing minilanguages, (for
example, in run control files for Python applications) or for parsing
quoted strings."

Why shouldn't that feature not be available under Windows?
Again, shlex is *not supposed* to handle Windows command lines.

Also, http://docs.python.org/lib/shlex-parsing-rules.html clearly says
what the difference between
"posix=True" and "posix=False" is.

That non-posix mode works on Windows filenames is because it does not
handle backslash escapes.

----------------------------------------------------------------------

Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-24 14:19

Message:
Logged In: YES 
user_id=769182
Originator: YES

Then what is "non-POSIX mode" if it's only supposed to work on UNIX?

I noted the initial comment but it seemed to be out of date. Especially as
it
seems to work fine to copy shlex.split and correct the default value for
"posix".
Seemed a very simple change that had little chance of being wrong.

If Windows behaviour is really unsupported then surely the function should
not
be available there.


----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-24 13:09

Message:
Logged In: YES 
user_id=849994
Originator: NO

The docs to shlex say: "The shlex class makes it easy to write lexical
analyzers for simple syntaxes resembling that of the Unix shell."

It is not meant to be a cross-platform shell quoting handler, but an
implementation of Unix shell behavior.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1724822&group_id=5470

From noreply at sourceforge.net  Thu May 24 19:54:17 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 24 May 2007 10:54:17 -0700
Subject: [ python-Feature Requests-1724822 ] provide a shlex.split alternative
	for Windows shell syntax
Message-ID: <E1HrHVx-0004p5-Ej@sc8-sf-web23.sourceforge.net>

Feature Requests item #1724822, was opened at 2007-05-24 14:56
Message generated for change (Comment added) made by gjb1002
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1724822&group_id=5470

Please note that this 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
Private: No
Submitted By: Geoffrey Bache (gjb1002)
Assigned to: Nobody/Anonymous (nobody)
Summary: provide a shlex.split alternative for Windows shell syntax

Initial Comment:
What is shlex.split supposed to do on Windows? It seems to be present but it can't handle basic Windows pathnames : shlex.split("C:\\directory\\file") returns C:directoryfile (whereas os.system happily accepts the same string).

Also, it runs in POSIX mode and there is no way to override it! Why isn't POSIX mode the default on POSIX systems and not on non-POSIX systems? Or for it to at least be possible to says shlex.split(s, posix=False)?


----------------------------------------------------------------------

>Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-24 19:54

Message:
Logged In: YES 
user_id=769182
Originator: YES

Thanks.

On reflection, I think the docs could do with expanding, particularly on
the subject of what non-posix mode actually does and what it's useful for
(it's becoming increaingly clear to me that it's nothing like a DOS shell,
having used it a bit). The list of rules is all very well but doesn't mean
much unless you know why it's like that. There is a cryptic comment about
posix=False implying "compatibility mode"  but this concept is not
explained.

The fact is that in today's world (now that the Mac is UNIX) "posix=False"
more or less means "windows=True". At least unless you document very
carefully what it's intended to mean. As you've probably noticed, it
confused me thoroughly because I couldn't see what else it could be for,
and I still haven't really grasped it.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-24 18:50

Message:
Logged In: YES 
user_id=849994
Originator: NO

Ah, that is reasonable. I added that parameter in rev. 55549.

----------------------------------------------------------------------

Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-24 17:31

Message:
Logged In: YES 
user_id=769182
Originator: YES

I mean changing shlex.split to accept an optional parameter "posix":

def split(s, comments=False, posix=True):
    lex = shlex(s, posix)
    lex.whitespace_split = True
    if not comments:
        lex.commenters = ''
    return list(lex)


----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-24 17:28

Message:
Logged In: YES 
user_id=849994
Originator: NO

Okay, I'll turn this into a feature request.

BTW, what do you mean with "override the POSIX flag"?

----------------------------------------------------------------------

Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-24 17:17

Message:
Logged In: YES 
user_id=769182
Originator: YES

OK, but surely providing the possibility to override the POSIX flag isn't
difficult. That doesn't require any change in default behaviour. 

It also seems it should be possible to request enhancements without having
to do the work myself. Can we agree that parsing Windows command lines is a
generally useful thing to do? We already have a module that can parse UNIX
command lines which isn't unrelated. Perhaps this should be changed to
"enhancement" rather than "invalid". 

Whether or not the original author of shlex cared about Windows seems to
be beside the point.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-24 16:59

Message:
Logged In: YES 
user_id=849994
Originator: NO

The fact remains that shlex is not meant to switch modes automatically
depending on the platform.

If you want to contribute a third mode that completely resembles
Windows-style parsing,
you're most welcome, just submit a patch and I'll look at it.

----------------------------------------------------------------------

Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-24 16:52

Message:
Logged In: YES 
user_id=769182
Originator: YES

But surely it's not named "POSIX mode" for no reason. It's because those
rules resemble those of the UNIX shell. While "non-POSIX mode" resemble
those of non-POSIX shells, such as DOS.

shlex.split seemed to be a shortcut for those wanting to simply parse a
generic quoted string who weren't interested in creating a minilanguage.
Surely it should be possible to avoid POSIX rules when doing this on
Windows?

You haven't suggested any other way to do this. The fact is, I do want to
parse a Windows command line. The only way I have found is by copying
shlex.split and hacking it. Didn't seem very nice, especially it seems a
fix would be totally trivial, but it's obviously better than starting from
scratch.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-24 16:26

Message:
Logged In: YES 
user_id=849994
Originator: NO

Further quote: "This will often be useful for writing minilanguages, (for
example, in run control files for Python applications) or for parsing
quoted strings."

Why shouldn't that feature not be available under Windows?
Again, shlex is *not supposed* to handle Windows command lines.

Also, http://docs.python.org/lib/shlex-parsing-rules.html clearly says
what the difference between
"posix=True" and "posix=False" is.

That non-posix mode works on Windows filenames is because it does not
handle backslash escapes.

----------------------------------------------------------------------

Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-24 16:19

Message:
Logged In: YES 
user_id=769182
Originator: YES

Then what is "non-POSIX mode" if it's only supposed to work on UNIX?

I noted the initial comment but it seemed to be out of date. Especially as
it
seems to work fine to copy shlex.split and correct the default value for
"posix".
Seemed a very simple change that had little chance of being wrong.

If Windows behaviour is really unsupported then surely the function should
not
be available there.


----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-24 15:09

Message:
Logged In: YES 
user_id=849994
Originator: NO

The docs to shlex say: "The shlex class makes it easy to write lexical
analyzers for simple syntaxes resembling that of the Unix shell."

It is not meant to be a cross-platform shell quoting handler, but an
implementation of Unix shell behavior.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1724822&group_id=5470

From noreply at sourceforge.net  Thu May 24 21:06:12 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 24 May 2007 12:06:12 -0700
Subject: [ python-Bugs-1721890 ] IDLE hangs in popup method completion
Message-ID: <E1HrIdY-0001QB-3S@sc8-sf-web21.sourceforge.net>

Bugs item #1721890, was opened at 2007-05-19 20:23
Message generated for change (Comment added) made by taleinat
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721890&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.5
Status: Open
Resolution: None
Priority: 6
Private: No
Submitted By: Andy Harrington (andyharrington)
Assigned to: Kurt B. Kaiser (kbk)
Summary: IDLE hangs in popup method completion

Initial Comment:
import os

os.

After entering the above code in a new idle editor window, the popup method completion window appears.  If I navigate with the down-arrow key, the list starts scrolling fine all the way down to spawnv, which I can select, but if I try to use down-arrow once more and scroll the list (to what would be startfile if I could reach it), idle hangs.  

Pure pagedown works all the way to in the popup to write, but then it I use up-arrow idle hangs when I try to scroll up beyond startfile to what would be spawnv.

I am running Windows XP, service pack 2.  On May 5 I installed and am running python-2.5.1.msi.

I started idle form idle.bat while in the idlelib directory.  I also ran \Python25\Lib\idlelib\idle.pyw from other directories with the same result.

I have no such problem with modules os.path or string.  I did not think of a module to try which has a list of methods as long as os.

 

----------------------------------------------------------------------

Comment By: Tal Einat (taleinat)
Date: 2007-05-24 22:06

Message:
Logged In: YES 
user_id=1330769
Originator: NO

This has already been resolved: see SourceForge bug 1571112 "simple moves
freeze IDLE"

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721890&group_id=5470

From noreply at sourceforge.net  Thu May 24 21:15:14 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 24 May 2007 12:15:14 -0700
Subject: [ python-Bugs-1710718 ] Ctrl+Shift block marking by words
Message-ID: <E1HrImI-0006Mk-Ar@sc8-sf-web22.sourceforge.net>

Bugs item #1710718, was opened at 2007-05-01 20:26
Message generated for change (Comment added) made by taleinat
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1710718&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: zorkin (zorkin)
Assigned to: Kurt B. Kaiser (kbk)
Summary: Ctrl+Shift block marking by words

Initial Comment:
When I mark a block with ctrl+shift pressed, pressing the right arrow with cursor before the last word on the line marks this word plus whitespace till the first word on next line.

I think this behaviour is wrong - it should stop at the end of line.

----------------------------------------------------------------------

Comment By: Tal Einat (taleinat)
Date: 2007-05-24 22:15

Message:
Logged In: YES 
user_id=1330769
Originator: NO

It shouldn't stop at the end of the line - for that, press Shift+End. But
I'm guessing you meant that you think it should stop at the end of the
word.

Both phenomena you describe are the result of the same behavior. Pressing
Ctrl+Right or Ctrl+Left jumps to the beginning of the next word in the
relevant direction. This is the default behavior of the Tk Text widget,
which I am liking less and less as time goes by. (issues with selections,
'end-1c', ...)

What you ask has already been suggested to me: that it might be useful,
and perhaps more intuitive, to have Ctrl+Right jump to the end of words
instead of beginnings.

I'll bring this up on the IDLE-dev mailing list as a possible feature.

----------------------------------------------------------------------

Comment By: zorkin (zorkin)
Date: 2007-05-01 20:39

Message:
Logged In: YES 
user_id=1741501
Originator: YES

And another thing: if the cursor is at the start of line and I press ctrl
+ right, it moves to the start of the second word, not the first one, like
it should.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1710718&group_id=5470

From noreply at sourceforge.net  Thu May 24 21:21:27 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 24 May 2007 12:21:27 -0700
Subject: [ python-Feature Requests-1705362 ] cannot change cursor color in
	IDLE 
Message-ID: <E1HrIsJ-00071o-5A@sc8-sf-web22.sourceforge.net>

Feature Requests item #1705362, was opened at 2007-04-22 22:14
Message generated for change (Comment added) made by taleinat
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1705362&group_id=5470

Please note that this 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
Private: No
Submitted By: zorkin (zorkin)
Assigned to: Nobody/Anonymous (nobody)
Summary: cannot change cursor color in IDLE 

Initial Comment:
Python 2.5.1 for windows
When I change the cursor color to another color, it still stays black, so I can't really make black background.

----------------------------------------------------------------------

Comment By: Tal Einat (taleinat)
Date: 2007-05-24 22:21

Message:
Logged In: YES 
user_id=1330769
Originator: NO

AFAIK you can - you simply have to restart IDLE after changing the color
and saving the changes.

This is a known issue with Tk's Text widget, which IDLE uses.

----------------------------------------------------------------------

Comment By: zorkin (zorkin)
Date: 2007-04-23 10:33

Message:
Logged In: YES 
user_id=1741501
Originator: YES

The page on the link says you can invert it. As I understand, the caret
color is either black or background color. You could force it to be
black/white.

Also you should hide this option in selector - it's misleading, because I
thought i does something.

----------------------------------------------------------------------

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-04-23 08:48

Message:
Logged In: YES 
user_id=479790
Originator: NO

IDLE on Windows appears to be using an always-black caret (cursor) - not
the standard caret behavior, which does its "blinking" by inverting the
background color.
So something might be improved here, but I doubt you can reliably set the
caret color on Windows; see http://support.microsoft.com/kb/84054/en-us


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1705362&group_id=5470

From noreply at sourceforge.net  Fri May 25 01:16:44 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 24 May 2007 16:16:44 -0700
Subject: [ python-Bugs-1621111 ] IDLE crashes on OS X 10.4 when "Preferences"
	selected
Message-ID: <E1HrMY0-0003mK-IJ@sc8-sf-web24.sourceforge.net>

Bugs item #1621111, was opened at 2006-12-23 05:03
Message generated for change (Comment added) made by f_scholder
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1621111&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: Python 2.5
Status: Open
Resolution: None
Priority: 6
Private: No
Submitted By: Mick L (mehum)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: IDLE crashes on OS X 10.4 when "Preferences" selected

Initial Comment:
When I select 'preferences' (on IDLE 1.2, Python 2.5)  or 'Configure IDLE' (IDLE 1.1.4, Python 2.4.4 and IDLE 1.0, Python 2.3.3), Python crashes as soon as the dialog box appears.

Terminal reports a "Segmentation fault" upon the crash.

My system is an iMac G5 with 1 GB ram running OS X v 10.4.8, Tcl/Tk 8.4.10, and seems otherwise stable.  

IDLE also appears stable until I select this option.

The Python crash log is attached.

Please, can anyone suggest what may be causing this problem?  Thank you.



----------------------------------------------------------------------

Comment By: Fran?ois Scholder (f_scholder)
Date: 2007-05-25 01:16

Message:
Logged In: YES 
user_id=1609867
Originator: NO

FYI, I managed to solve the issue (under WinXP) by clearing the
.idlerc\config-main.cfg configuration file...

Cheers!

----------------------------------------------------------------------

Comment By: Mick L (mehum)
Date: 2007-04-12 10:27

Message:
Logged In: YES 
user_id=1674554
Originator: YES

OK... I followed your advice Ronald (moved the Tcl and Tk frameworks out
of Library), and it worked!  IDLE no longer crashes! Thank you so much!

With the frameworks moved, it apparently reverts to Tcl/Tk 8.4.7

The only oddity is that there is a _very_ long delay (beachball) when
opening preferences / configure IDLE; but now that the font is legibly
large, I doubt I shall need to go back there.

Thank you again,
Kind regards, Mick L

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2007-04-11 22:24

Message:
Logged In: YES 
user_id=580910
Originator: NO

It seems to be caused by Tcl/Tk, I cannot reproduce this with the system
version of Tk

This is on 10.4.8/intel, with python 2.5.1rc1. I don't think the change in
python version fixes this issue.

Mick: could you please test what happens when you temporarily move
/Library/Frameworks/Tcl.framework and /Library/Frameworks/Tk.framework to
another folder.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-04-11 19:12

Message:
Logged In: YES 
user_id=80475
Originator: NO

Bumping up the priority so this doesn't get lost.  My guess is that IDLE
is tickling some problem with the TkInter bindings.

----------------------------------------------------------------------

Comment By: Fran?ois Scholder (f_scholder)
Date: 2007-02-02 22:55

Message:
Logged In: YES 
user_id=1609867
Originator: NO

Erratum:

A similar problem arises with WinXP when trying to configure IDLE via the
"Options>Configure IDLE..." menu.

Clicking on the 'Ok' or 'Apply' buttons of the dialog seemingly has no
effect. However when closing the window by clicking on either the window
close button (top right 'X') or the 'Cancel' button, several bahaviors
are
observed depending on how many times one has clicked on the 'Ok' and/or
---->'Apply'<---- buttons before:
- 0 clicks => expected behavior (dialog is closed, IDLE session is
resumed
and working fine)
- 1 or 2 clicks => dialog is closed but the IDLE shell behaves as a text
editor instead of an interpreter
- 3 or more clicks => IDLE crashes...

Note: I'm running Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC
v.1310 32 bit (Intel)] on win32 -> WinXP SP2

----------------------------------------------------------------------

Comment By: Fran?ois Scholder (f_scholder)
Date: 2007-02-02 22:48

Message:
Logged In: YES 
user_id=1609867
Originator: NO

A similar problem arises with WinXP when trying to configure IDLE via the
"Options>Configure IDLE..." menu.

Clicking on the 'Ok' or 'Apply' buttons of the dialog seemingly has no
effect. However when closing the window by clicking on either the window
close button (top right 'X') or the 'Cancel' button, several bahaviors are
observed depending on how many times one has clicked on the 'Ok' and/or
'Cancel' buttons before:
- 0 clicks => expected behavior (dialog is closed, IDLE session is resumed
and working fine)
- 1 or 2 clicks => dialog is closed but the IDLE shell behaves as a text
editor instead of an interpreter
- 3 or more clicks => IDLE crashes...

Note: I'm running Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC
v.1310 32 bit (Intel)] on win32 -> WinXP SP2

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1621111&group_id=5470

From noreply at sourceforge.net  Fri May 25 05:47:21 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 24 May 2007 20:47:21 -0700
Subject: [ python-Feature Requests-1705362 ] cannot change cursor color in
	IDLE 
Message-ID: <E1HrQlt-0007ie-SQ@sc8-sf-web23.sourceforge.net>

Feature Requests item #1705362, was opened at 2007-04-22 19:14
Message generated for change (Comment added) made by zorkin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1705362&group_id=5470

Please note that this 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
Private: No
Submitted By: zorkin (zorkin)
Assigned to: Nobody/Anonymous (nobody)
Summary: cannot change cursor color in IDLE 

Initial Comment:
Python 2.5.1 for windows
When I change the cursor color to another color, it still stays black, so I can't really make black background.

----------------------------------------------------------------------

>Comment By: zorkin (zorkin)
Date: 2007-05-25 03:47

Message:
Logged In: YES 
user_id=1741501
Originator: YES

> AFAIK you can - you simply have to restart IDLE after changing the
color
and saving the changes.

Thanks, I found that out already. Maybe then after I change that option
(and perhaps some others) IDLE should say "Please restart IDLE for some
changes to take effect" ?

----------------------------------------------------------------------

Comment By: Tal Einat (taleinat)
Date: 2007-05-24 19:21

Message:
Logged In: YES 
user_id=1330769
Originator: NO

AFAIK you can - you simply have to restart IDLE after changing the color
and saving the changes.

This is a known issue with Tk's Text widget, which IDLE uses.

----------------------------------------------------------------------

Comment By: zorkin (zorkin)
Date: 2007-04-23 07:33

Message:
Logged In: YES 
user_id=1741501
Originator: YES

The page on the link says you can invert it. As I understand, the caret
color is either black or background color. You could force it to be
black/white.

Also you should hide this option in selector - it's misleading, because I
thought i does something.

----------------------------------------------------------------------

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-04-23 05:48

Message:
Logged In: YES 
user_id=479790
Originator: NO

IDLE on Windows appears to be using an always-black caret (cursor) - not
the standard caret behavior, which does its "blinking" by inverting the
background color.
So something might be improved here, but I doubt you can reliably set the
caret color on Windows; see http://support.microsoft.com/kb/84054/en-us


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1705362&group_id=5470

From noreply at sourceforge.net  Fri May 25 09:28:51 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 25 May 2007 00:28:51 -0700
Subject: [ python-Bugs-1720726 ] docu enhancement for
	logging.handlers.SysLogHandler
Message-ID: <E1HrUEF-00067m-Vn@sc8-sf-web23.sourceforge.net>

Bugs item #1720726, was opened at 2007-05-17 13:20
Message generated for change (Comment added) made by vsajip
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1720726&group_id=5470

Please note that this 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
Private: No
Submitted By: rhunger (rhunger)
Assigned to: Vinay Sajip (vsajip)
Summary: docu enhancement for logging.handlers.SysLogHandler

Initial Comment:
The documentation for "logging.handlers.SysLogHandler" is somewhat incomplete. This class can be used to communicate to a local syslogd too (not only to log to a remote syslogd, or a local syslogd with enabled remote logging capabilities ("-r" option)).

The documentation on:

http://docs.python.org/lib/node417.html

for SysLogHandler([address[, facility]]) should be expanded with something like the following:

"""
If address is specified as a string, a UNIX socket is used. To log to a local syslogd "SysLogHandler(address="/dev/log")" can be used.
"""

The docstring "import logging.handlers;help(logging.handlers.SysLogHandler.__init__)" is rather short and could be replaced with above documentation.




----------------------------------------------------------------------

>Comment By: Vinay Sajip (vsajip)
Date: 2007-05-25 07:28

Message:
Logged In: YES 
user_id=308438
Originator: NO

Updated docstring and documentation checked into trunk, release24-maint,
release25-maint.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-17 21:30

Message:
Logged In: YES 
user_id=33168
Originator: NO

Vinay, any comment?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1720726&group_id=5470

From noreply at sourceforge.net  Fri May 25 11:00:37 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 25 May 2007 02:00:37 -0700
Subject: [ python-Bugs-1724366 ] cPickle module doesn't work with universal
	line endings
Message-ID: <E1HrVf3-0007bF-5s@sc8-sf-web23.sourceforge.net>

Bugs item #1724366, was opened at 2007-05-23 13:42
Message generated for change (Comment added) made by gagenellina
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1724366&group_id=5470

Please note that this message will contain a full 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
Private: No
Submitted By: Geoffrey Bache (gjb1002)
Assigned to: Nobody/Anonymous (nobody)
Summary: cPickle module doesn't work with universal line endings

Initial Comment:
On UNIX, I cannot read pickle files created on Windows using the cPickle module, even if I open the file with universal line endings.

It works fine with the pickle module but is of course slower (and I have to read lots of them)

I attach a test case that pickles and unpickles an smptlib.SMTP object, converting the file to DOS format in between. There is nothing special about SMTP, you can use any object at all in a different module. 

On my system (RHEL4 with Python 2.4.3) I get the following output:

portmoller : pickletest.py cPickle
unix2dos: converting file dump to DOS format ...
Traceback (most recent call last):
  File "pickletest.py", line 14, in ?
    print load(readFile)
ImportError: No module named smtplib
portmoller : pickletest.py pickle
unix2dos: converting file dump to DOS format ...
<smtplib.SMTP instance at 0xb7ea350c>


----------------------------------------------------------------------

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-25 06:00

Message:
Logged In: YES 
user_id=479790
Originator: NO

Please try again with this modified version. I think you will see that
Python is trying to import "smtplib\r"
On Windows, trying to read a pickle file with MAC line endings gives a
different error:
cPickle.UnpicklingError: pickle data was truncated

It seems that cPickle support for protocol 0 is broken. If you can, try to
use the higher, binary, protocols, they don't have this problem. Even if
you must use protocol 0, opening the file always in binary mode should not
have this problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1724366&group_id=5470

From noreply at sourceforge.net  Fri May 25 11:04:14 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 25 May 2007 02:04:14 -0700
Subject: [ python-Bugs-1724366 ] cPickle module doesn't work with universal
	line endings
Message-ID: <E1HrViY-000824-Nu@sc8-sf-web23.sourceforge.net>

Bugs item #1724366, was opened at 2007-05-23 13:42
Message generated for change (Comment added) made by gagenellina
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1724366&group_id=5470

Please note that this message will contain a full 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
Private: No
Submitted By: Geoffrey Bache (gjb1002)
Assigned to: Nobody/Anonymous (nobody)
Summary: cPickle module doesn't work with universal line endings

Initial Comment:
On UNIX, I cannot read pickle files created on Windows using the cPickle module, even if I open the file with universal line endings.

It works fine with the pickle module but is of course slower (and I have to read lots of them)

I attach a test case that pickles and unpickles an smptlib.SMTP object, converting the file to DOS format in between. There is nothing special about SMTP, you can use any object at all in a different module. 

On my system (RHEL4 with Python 2.4.3) I get the following output:

portmoller : pickletest.py cPickle
unix2dos: converting file dump to DOS format ...
Traceback (most recent call last):
  File "pickletest.py", line 14, in ?
    print load(readFile)
ImportError: No module named smtplib
portmoller : pickletest.py pickle
unix2dos: converting file dump to DOS format ...
<smtplib.SMTP instance at 0xb7ea350c>


----------------------------------------------------------------------

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-25 06:04

Message:
Logged In: YES 
user_id=479790
Originator: NO

I don't see any "Attach" button...
Just add these lines near the top of the test script:

original__import = __import__
def myimport(name, *args):
  print "import",repr(name)
  return original__import(name,*args)
  #end myimport
__builtins__.__import__ = myimport


----------------------------------------------------------------------

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-25 06:00

Message:
Logged In: YES 
user_id=479790
Originator: NO

Please try again with this modified version. I think you will see that
Python is trying to import "smtplib\r"
On Windows, trying to read a pickle file with MAC line endings gives a
different error:
cPickle.UnpicklingError: pickle data was truncated

It seems that cPickle support for protocol 0 is broken. If you can, try to
use the higher, binary, protocols, they don't have this problem. Even if
you must use protocol 0, opening the file always in binary mode should not
have this problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1724366&group_id=5470

From noreply at sourceforge.net  Fri May 25 11:57:33 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 25 May 2007 02:57:33 -0700
Subject: [ python-Feature Requests-1705362 ] cannot change cursor color in
	IDLE 
Message-ID: <E1HrWY9-0000Ae-LQ@sc8-sf-web24.sourceforge.net>

Feature Requests item #1705362, was opened at 2007-04-22 22:14
Message generated for change (Comment added) made by taleinat
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1705362&group_id=5470

Please note that this 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
Private: No
Submitted By: zorkin (zorkin)
Assigned to: Nobody/Anonymous (nobody)
Summary: cannot change cursor color in IDLE 

Initial Comment:
Python 2.5.1 for windows
When I change the cursor color to another color, it still stays black, so I can't really make black background.

----------------------------------------------------------------------

Comment By: Tal Einat (taleinat)
Date: 2007-05-25 12:57

Message:
Logged In: YES 
user_id=1330769
Originator: NO

I just found out that this has nothing to do with Tk's Text widget, which
is fine.

I'll be submitting a patch to fix this issue in a short while.

----------------------------------------------------------------------

Comment By: zorkin (zorkin)
Date: 2007-05-25 06:47

Message:
Logged In: YES 
user_id=1741501
Originator: YES

> AFAIK you can - you simply have to restart IDLE after changing the
color
and saving the changes.

Thanks, I found that out already. Maybe then after I change that option
(and perhaps some others) IDLE should say "Please restart IDLE for some
changes to take effect" ?

----------------------------------------------------------------------

Comment By: Tal Einat (taleinat)
Date: 2007-05-24 22:21

Message:
Logged In: YES 
user_id=1330769
Originator: NO

AFAIK you can - you simply have to restart IDLE after changing the color
and saving the changes.

This is a known issue with Tk's Text widget, which IDLE uses.

----------------------------------------------------------------------

Comment By: zorkin (zorkin)
Date: 2007-04-23 10:33

Message:
Logged In: YES 
user_id=1741501
Originator: YES

The page on the link says you can invert it. As I understand, the caret
color is either black or background color. You could force it to be
black/white.

Also you should hide this option in selector - it's misleading, because I
thought i does something.

----------------------------------------------------------------------

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-04-23 08:48

Message:
Logged In: YES 
user_id=479790
Originator: NO

IDLE on Windows appears to be using an always-black caret (cursor) - not
the standard caret behavior, which does its "blinking" by inverting the
background color.
So something might be improved here, but I doubt you can reliably set the
caret color on Windows; see http://support.microsoft.com/kb/84054/en-us


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1705362&group_id=5470

From noreply at sourceforge.net  Fri May 25 12:29:02 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 25 May 2007 03:29:02 -0700
Subject: [ python-Bugs-1724366 ] cPickle module doesn't work with universal
	line endings
Message-ID: <E1HrX2c-0007n0-1g@sc8-sf-web21.sourceforge.net>

Bugs item #1724366, was opened at 2007-05-23 13:42
Message generated for change (Comment added) made by gagenellina
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1724366&group_id=5470

Please note that this message will contain a full 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
Private: No
Submitted By: Geoffrey Bache (gjb1002)
Assigned to: Nobody/Anonymous (nobody)
Summary: cPickle module doesn't work with universal line endings

Initial Comment:
On UNIX, I cannot read pickle files created on Windows using the cPickle module, even if I open the file with universal line endings.

It works fine with the pickle module but is of course slower (and I have to read lots of them)

I attach a test case that pickles and unpickles an smptlib.SMTP object, converting the file to DOS format in between. There is nothing special about SMTP, you can use any object at all in a different module. 

On my system (RHEL4 with Python 2.4.3) I get the following output:

portmoller : pickletest.py cPickle
unix2dos: converting file dump to DOS format ...
Traceback (most recent call last):
  File "pickletest.py", line 14, in ?
    print load(readFile)
ImportError: No module named smtplib
portmoller : pickletest.py pickle
unix2dos: converting file dump to DOS format ...
<smtplib.SMTP instance at 0xb7ea350c>


----------------------------------------------------------------------

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-25 07:29

Message:
Logged In: YES 
user_id=479790
Originator: NO

The culprit is cPickle.c; it takes certain shortcuts for read() and
readline() depending on which type of file you pass in.
For a true file object, it uses its own implementation for those two
methods, ignoring the file mode.

But it appears that there is NO WAY universal line endings could work if
the pickle contains any unicode object. The pickle format for Unicode
quotes any \n but *not* \r so the unpickler cannot determine, when it sees
a "\r", if it is a MAC end-of-line or an embedded "\r".
So, the only safe end-of-line character for a pickle using protocol 0 is
"\n", and that means that the file must be written in binary mode.
(This may also indicate that you cannot read unicode objects with embedded
\r in a MAC using protocol 0, but I don't have a MAC to test it).

So, until this is fixed (either the module or the documentation), one
should forget about universal line endings and write all pickle files as
binary. (This way ALL lines end in \n and it should work fine on all
platforms)


----------------------------------------------------------------------

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-25 06:04

Message:
Logged In: YES 
user_id=479790
Originator: NO

I don't see any "Attach" button...
Just add these lines near the top of the test script:

original__import = __import__
def myimport(name, *args):
  print "import",repr(name)
  return original__import(name,*args)
  #end myimport
__builtins__.__import__ = myimport


----------------------------------------------------------------------

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-25 06:00

Message:
Logged In: YES 
user_id=479790
Originator: NO

Please try again with this modified version. I think you will see that
Python is trying to import "smtplib\r"
On Windows, trying to read a pickle file with MAC line endings gives a
different error:
cPickle.UnpicklingError: pickle data was truncated

It seems that cPickle support for protocol 0 is broken. If you can, try to
use the higher, binary, protocols, they don't have this problem. Even if
you must use protocol 0, opening the file always in binary mode should not
have this problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1724366&group_id=5470

From noreply at sourceforge.net  Fri May 25 13:15:40 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 25 May 2007 04:15:40 -0700
Subject: [ python-Bugs-1719898 ] tarfile stops expanding with long filenames
Message-ID: <E1HrXlk-0000FN-9J@sc8-sf-web24.sourceforge.net>

Bugs item #1719898, was opened at 2007-05-16 09:32
Message generated for change (Comment added) made by zagy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1719898&group_id=5470

Please note that this message will contain a full 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
Private: No
Submitted By: Christian Zagrodnick (zagy)
Assigned to: Lars Gust?bel (gustaebel)
Summary: tarfile stops expanding with long filenames

Initial Comment:
The tarfile module fixes an issue with "Some old tar programs represent a directory as a regular file with a trailing slash.":

    if tarinfo.isreg() and tarinfo.name.endswith("/"):
        tarinfo.type = DIRTYPE

*After* that the full filename is composed. The chars >100 are stored in "prefix":

    if tarinfo.type != GNUTYPE_SPARSE:
        tarinfo.name normpath(os.path.join(nts(tarinfo.prefix), tarinfo.name))


So guess what happens if you filename has a / at the 100th character. Right, its considered a directory. Since directories have no data, the next metadata block is read from your file data which fails in various ways.

Patch attached.

----------------------------------------------------------------------

>Comment By: Christian Zagrodnick (zagy)
Date: 2007-05-25 11:15

Message:
Logged In: YES 
user_id=24696
Originator: YES

Ok, from looking at the code it should work in Python 2.5. I shipped
around the  Python 2.4 bug by creating a zip release instead of tar. 

Pity that Python 2.4 is no longer maintained though. I guess we need to
bump Zope 3 pretty soon then :)

----------------------------------------------------------------------

Comment By: Lars Gust?bel (gustaebel)
Date: 2007-05-16 13:32

Message:
Logged In: YES 
user_id=642936
Originator: NO

Did you also test Python 2.5? If this error occurs with that version too
(which it should not), please attach a small test tar archive to this
tracker item.

Python 2.4 is no longer maintained, sorry.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1719898&group_id=5470

From noreply at sourceforge.net  Fri May 25 19:24:55 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 25 May 2007 10:24:55 -0700
Subject: [ python-Bugs-1724366 ] cPickle module doesn't work with universal
	line endings
Message-ID: <E1HrdX5-0000en-3M@sc8-sf-web23.sourceforge.net>

Bugs item #1724366, was opened at 2007-05-23 18:42
Message generated for change (Comment added) made by gjb1002
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1724366&group_id=5470

Please note that this message will contain a full 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
Private: No
Submitted By: Geoffrey Bache (gjb1002)
Assigned to: Nobody/Anonymous (nobody)
Summary: cPickle module doesn't work with universal line endings

Initial Comment:
On UNIX, I cannot read pickle files created on Windows using the cPickle module, even if I open the file with universal line endings.

It works fine with the pickle module but is of course slower (and I have to read lots of them)

I attach a test case that pickles and unpickles an smptlib.SMTP object, converting the file to DOS format in between. There is nothing special about SMTP, you can use any object at all in a different module. 

On my system (RHEL4 with Python 2.4.3) I get the following output:

portmoller : pickletest.py cPickle
unix2dos: converting file dump to DOS format ...
Traceback (most recent call last):
  File "pickletest.py", line 14, in ?
    print load(readFile)
ImportError: No module named smtplib
portmoller : pickletest.py pickle
unix2dos: converting file dump to DOS format ...
<smtplib.SMTP instance at 0xb7ea350c>


----------------------------------------------------------------------

>Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-25 19:24

Message:
Logged In: YES 
user_id=769182
Originator: YES

Yes, I'm sure Python is trying to import "smtplib\r".

For various reasons I need to use protocol 0: not least because I use the
pickle files as test data and it's much easier to administer a load of text
files than a load of binary files.

I will experiment with reading the files in binary mode on Monday and get
back to you. My current workaround is to do loads(file.read()) instead of
load(file) which I guess is a performance penalty. Any idea whether this is
likely to be slower than just using the pickle module? (I haven't tested
this)


----------------------------------------------------------------------

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-25 12:29

Message:
Logged In: YES 
user_id=479790
Originator: NO

The culprit is cPickle.c; it takes certain shortcuts for read() and
readline() depending on which type of file you pass in.
For a true file object, it uses its own implementation for those two
methods, ignoring the file mode.

But it appears that there is NO WAY universal line endings could work if
the pickle contains any unicode object. The pickle format for Unicode
quotes any \n but *not* \r so the unpickler cannot determine, when it sees
a "\r", if it is a MAC end-of-line or an embedded "\r".
So, the only safe end-of-line character for a pickle using protocol 0 is
"\n", and that means that the file must be written in binary mode.
(This may also indicate that you cannot read unicode objects with embedded
\r in a MAC using protocol 0, but I don't have a MAC to test it).

So, until this is fixed (either the module or the documentation), one
should forget about universal line endings and write all pickle files as
binary. (This way ALL lines end in \n and it should work fine on all
platforms)


----------------------------------------------------------------------

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-25 11:04

Message:
Logged In: YES 
user_id=479790
Originator: NO

I don't see any "Attach" button...
Just add these lines near the top of the test script:

original__import = __import__
def myimport(name, *args):
  print "import",repr(name)
  return original__import(name,*args)
  #end myimport
__builtins__.__import__ = myimport


----------------------------------------------------------------------

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-25 11:00

Message:
Logged In: YES 
user_id=479790
Originator: NO

Please try again with this modified version. I think you will see that
Python is trying to import "smtplib\r"
On Windows, trying to read a pickle file with MAC line endings gives a
different error:
cPickle.UnpicklingError: pickle data was truncated

It seems that cPickle support for protocol 0 is broken. If you can, try to
use the higher, binary, protocols, they don't have this problem. Even if
you must use protocol 0, opening the file always in binary mode should not
have this problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1724366&group_id=5470

From noreply at sourceforge.net  Fri May 25 23:25:30 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 25 May 2007 14:25:30 -0700
Subject: [ python-Bugs-1725856 ] bsddb.btopen . del of record doesn't update
	index
Message-ID: <E1HrhHu-0003cz-JQ@sc8-sf-web21.sourceforge.net>

Bugs item #1725856, was opened at 2007-05-25 21:25
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1725856&group_id=5470

Please note that this message will contain 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
Private: No
Submitted By: Charles Hixson (quixo)
Assigned to: Nobody/Anonymous (nobody)
Summary: bsddb.btopen . del of record doesn't update index

Initial Comment:
A ram -resident database is creaed with btopen

10 records are added, keyed by sequence, value is sequence + 1 (both converted to strings).

I check to ensure that all of the records have been added.

I delete the first record, check the keys again, and it still works.

I delete the first record, check the keys again, and it fails, thusly:

python testbtopen.py
['0', '1', '2', '3', '4', '5', '6', '7', '8', '9']
['0', '1', '2', '3', '4', '5', '6', '7', '8', '9']
0
1
2
3
4
5
6
7
8
9
0 1
['1', '2', '3', '4', '5', '6', '7', '8', '9']
1
2
3
4
5
6
7
8
9
Traceback (most recent call last):
  File "testbtopen.py", line 13, in ?
    i   =       db.first()[0]
  File "/usr/lib/python2.4/site-packages/PIL/__init__.py", line 269, in first

  File "/usr/lib/python2.4/site-packages/PIL/__init__.py", line 183, in _checkCursor

_bsddb.DBNotFoundError: (-30989, 'DB_NOTFOUND: No matching key/data pair found')
charles at mandala1:~/projects/Python/bsddb$ python testbtopen.py
['0', '1', '2', '3', '4', '5', '6', '7', '8', '9']
['0', '1', '2', '3', '4', '5', '6', '7', '8', '9']
0
1
2
3
4
5
6
7
8
9
0 1
['1', '2', '3', '4', '5', '6', '7', '8', '9']
1
2
3
4
5
6
7
8
9
Traceback (most recent call last):
  File "testbtopen.py", line 13, in ?
    i   =       db.first()[0]
  File "/usr/lib/python2.4/site-packages/PIL/__init__.py", line 269, in first

  File "/usr/lib/python2.4/site-packages/PIL/__init__.py", line 183, in _checkCursor

_bsddb.DBNotFoundError: (-30989, 'DB_NOTFOUND: No matching key/data pair found')


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1725856&group_id=5470

From noreply at sourceforge.net  Fri May 25 23:36:27 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 25 May 2007 14:36:27 -0700
Subject: [ python-Bugs-1725862 ] bsddb.btopen . del of record doesn't update
	index
Message-ID: <E1HrhSV-0004pp-Ea@sc8-sf-web21.sourceforge.net>

Bugs item #1725862, was opened at 2007-05-25 21: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=1725862&group_id=5470

Please note that this message will contain 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
Private: No
Submitted By: Charles Hixson (quixo)
Assigned to: Nobody/Anonymous (nobody)
Summary: bsddb.btopen . del of record doesn't update index

Initial Comment:
A ram -resident database is creaed with btopen

10 records are added, keyed by sequence, value is sequence + 1 (both converted to strings).

I check to ensure that all of the records have been added.

I delete the first record, check the keys again, and it still works.

I delete the first record, check the keys again, and it fails, thusly:

python testbtopen.py
['0', '1', '2', '3', '4', '5', '6', '7', '8', '9']
['0', '1', '2', '3', '4', '5', '6', '7', '8', '9']
0
1
2
3
4
5
6
7
8
9
0 1
['1', '2', '3', '4', '5', '6', '7', '8', '9']
1
2
3
4
5
6
7
8
9
Traceback (most recent call last):
  File "testbtopen.py", line 13, in ?
    i   =       db.first()[0]
  File "/usr/lib/python2.4/site-packages/PIL/__init__.py", line 269, in first

  File "/usr/lib/python2.4/site-packages/PIL/__init__.py", line 183, in _checkCursor

_bsddb.DBNotFoundError: (-30989, 'DB_NOTFOUND: No matching key/data pair found')
charles at mandala1:~/projects/Python/bsddb$ python testbtopen.py
['0', '1', '2', '3', '4', '5', '6', '7', '8', '9']
['0', '1', '2', '3', '4', '5', '6', '7', '8', '9']
0
1
2
3
4
5
6
7
8
9
0 1
['1', '2', '3', '4', '5', '6', '7', '8', '9']
1
2
3
4
5
6
7
8
9
Traceback (most recent call last):
  File "testbtopen.py", line 13, in ?
    i   =       db.first()[0]
  File "/usr/lib/python2.4/site-packages/PIL/__init__.py", line 269, in first

  File "/usr/lib/python2.4/site-packages/PIL/__init__.py", line 183, in _checkCursor

_bsddb.DBNotFoundError: (-30989, 'DB_NOTFOUND: No matching key/data pair found')


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1725862&group_id=5470

From noreply at sourceforge.net  Sat May 26 00:52:08 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 25 May 2007 15:52:08 -0700
Subject: [ python-Bugs-1725899 ] decimal sqrt method doesn't use
	round-half-even
Message-ID: <E1Hridk-0004kH-3o@sc8-sf-web21.sourceforge.net>

Bugs item #1725899, was opened at 2007-05-25 22:52
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1725899&group_id=5470

Please note that this message will contain a full 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
Private: No
Submitted By: Mark Dickinson (marketdickinson)
Assigned to: Nobody/Anonymous (nobody)
Summary: decimal sqrt method doesn't use round-half-even

Initial Comment:
According to version 1.66 of Cowlishaw's `General Decimal Arithmetic
Specification' the square-root operation in the decimal module should
round using the round-half-even algorithm (regardless of the rounding
setting in the current context).  It doesn't appear to do so:

>>> from decimal import *
>>> getcontext().prec = 6
>>> Decimal(9123455**2).sqrt()
Decimal("9.12345E+6")

The exact value of this square root is exactly halfway between two
representable Decimals, so using round-half-even with 6 digits I'd
expect the answer to be rounded to the neighboring representable
Decimal with *even* last digit---that is,

Decimal("9.12346E+6")

This bug only seems to occur when the number of significant digits in
the argument exceeds the current precision (indeed, if the number of
sig. digits in the argument is less than or equal to the current
precision then it's impossible for the square root to be halfway
between two representable floats).

It seems to me that this is a minor bug that will occur rarely and is
unlikely to have any serious effect even when it does occur; however,
it does seem to be a deviation from the specification.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1725899&group_id=5470

From noreply at sourceforge.net  Sat May 26 01:24:37 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 25 May 2007 16:24:37 -0700
Subject: [ python-Bugs-1725899 ] decimal sqrt method doesn't use
	round-half-even
Message-ID: <E1Hrj9B-0007Kz-9g@sc8-sf-web23.sourceforge.net>

Bugs item #1725899, was opened at 2007-05-25 18:52
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1725899&group_id=5470

Please note that this message will contain a full 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
Private: No
Submitted By: Mark Dickinson (marketdickinson)
Assigned to: Nobody/Anonymous (nobody)
Summary: decimal sqrt method doesn't use round-half-even

Initial Comment:
According to version 1.66 of Cowlishaw's `General Decimal Arithmetic
Specification' the square-root operation in the decimal module should
round using the round-half-even algorithm (regardless of the rounding
setting in the current context).  It doesn't appear to do so:

>>> from decimal import *
>>> getcontext().prec = 6
>>> Decimal(9123455**2).sqrt()
Decimal("9.12345E+6")

The exact value of this square root is exactly halfway between two
representable Decimals, so using round-half-even with 6 digits I'd
expect the answer to be rounded to the neighboring representable
Decimal with *even* last digit---that is,

Decimal("9.12346E+6")

This bug only seems to occur when the number of significant digits in
the argument exceeds the current precision (indeed, if the number of
sig. digits in the argument is less than or equal to the current
precision then it's impossible for the square root to be halfway
between two representable floats).

It seems to me that this is a minor bug that will occur rarely and is
unlikely to have any serious effect even when it does occur; however,
it does seem to be a deviation from the specification.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2007-05-25 19:24

Message:
Logged In: YES 
user_id=31435
Originator: NO

Doesn't the spec also require that /inputs/ get rounded to working
precision /before/ operations are performed?  If so, the exact square
83237431137025 is rounded down to 83237400000000, and sqrt(83237400000000)
is 9.12345E+6 rounded to 6 digits.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1725899&group_id=5470

From noreply at sourceforge.net  Sat May 26 01:30:33 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 25 May 2007 16:30:33 -0700
Subject: [ python-Bugs-1725899 ] decimal sqrt method doesn't use
	round-half-even
Message-ID: <E1HrjEv-0003uP-HQ@sc8-sf-web22.sourceforge.net>

Bugs item #1725899, was opened at 2007-05-25 22:52
Message generated for change (Comment added) made by marketdickinson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1725899&group_id=5470

Please note that this message will contain a full 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
Private: No
Submitted By: Mark Dickinson (marketdickinson)
Assigned to: Nobody/Anonymous (nobody)
Summary: decimal sqrt method doesn't use round-half-even

Initial Comment:
According to version 1.66 of Cowlishaw's `General Decimal Arithmetic
Specification' the square-root operation in the decimal module should
round using the round-half-even algorithm (regardless of the rounding
setting in the current context).  It doesn't appear to do so:

>>> from decimal import *
>>> getcontext().prec = 6
>>> Decimal(9123455**2).sqrt()
Decimal("9.12345E+6")

The exact value of this square root is exactly halfway between two
representable Decimals, so using round-half-even with 6 digits I'd
expect the answer to be rounded to the neighboring representable
Decimal with *even* last digit---that is,

Decimal("9.12346E+6")

This bug only seems to occur when the number of significant digits in
the argument exceeds the current precision (indeed, if the number of
sig. digits in the argument is less than or equal to the current
precision then it's impossible for the square root to be halfway
between two representable floats).

It seems to me that this is a minor bug that will occur rarely and is
unlikely to have any serious effect even when it does occur; however,
it does seem to be a deviation from the specification.


----------------------------------------------------------------------

>Comment By: Mark Dickinson (marketdickinson)
Date: 2007-05-25 23:30

Message:
Logged In: YES 
user_id=703403
Originator: YES

I don't think inputs should be rounded; note 1 near the start of the
`Arithmetic Operations' section of the specification says:

"Operands may have more than precision digits and are not rounded before
use."


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2007-05-25 23:24

Message:
Logged In: YES 
user_id=31435
Originator: NO

Doesn't the spec also require that /inputs/ get rounded to working
precision /before/ operations are performed?  If so, the exact square
83237431137025 is rounded down to 83237400000000, and sqrt(83237400000000)
is 9.12345E+6 rounded to 6 digits.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1725899&group_id=5470

From noreply at sourceforge.net  Sat May 26 04:39:17 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 25 May 2007 19:39:17 -0700
Subject: [ python-Bugs-1725862 ] bsddb.btopen . del of record doesn't update
	index
Message-ID: <E1HrmBZ-0002md-7o@sc8-sf-web23.sourceforge.net>

Bugs item #1725862, was opened at 2007-05-25 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=1725862&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
>Status: Closed
>Resolution: Duplicate
Priority: 5
Private: No
Submitted By: Charles Hixson (quixo)
Assigned to: Nobody/Anonymous (nobody)
Summary: bsddb.btopen . del of record doesn't update index

Initial Comment:
A ram -resident database is creaed with btopen

10 records are added, keyed by sequence, value is sequence + 1 (both converted to strings).

I check to ensure that all of the records have been added.

I delete the first record, check the keys again, and it still works.

I delete the first record, check the keys again, and it fails, thusly:

python testbtopen.py
['0', '1', '2', '3', '4', '5', '6', '7', '8', '9']
['0', '1', '2', '3', '4', '5', '6', '7', '8', '9']
0
1
2
3
4
5
6
7
8
9
0 1
['1', '2', '3', '4', '5', '6', '7', '8', '9']
1
2
3
4
5
6
7
8
9
Traceback (most recent call last):
  File "testbtopen.py", line 13, in ?
    i   =       db.first()[0]
  File "/usr/lib/python2.4/site-packages/PIL/__init__.py", line 269, in first

  File "/usr/lib/python2.4/site-packages/PIL/__init__.py", line 183, in _checkCursor

_bsddb.DBNotFoundError: (-30989, 'DB_NOTFOUND: No matching key/data pair found')
charles at mandala1:~/projects/Python/bsddb$ python testbtopen.py
['0', '1', '2', '3', '4', '5', '6', '7', '8', '9']
['0', '1', '2', '3', '4', '5', '6', '7', '8', '9']
0
1
2
3
4
5
6
7
8
9
0 1
['1', '2', '3', '4', '5', '6', '7', '8', '9']
1
2
3
4
5
6
7
8
9
Traceback (most recent call last):
  File "testbtopen.py", line 13, in ?
    i   =       db.first()[0]
  File "/usr/lib/python2.4/site-packages/PIL/__init__.py", line 269, in first

  File "/usr/lib/python2.4/site-packages/PIL/__init__.py", line 183, in _checkCursor

_bsddb.DBNotFoundError: (-30989, 'DB_NOTFOUND: No matching key/data pair found')


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-25 19:39

Message:
Logged In: YES 
user_id=33168
Originator: NO

Duplicate of 1725856.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1725862&group_id=5470

From noreply at sourceforge.net  Sat May 26 04:39:49 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 25 May 2007 19:39:49 -0700
Subject: [ python-Bugs-1725856 ] bsddb.btopen . del of record doesn't update
	index
Message-ID: <E1HrmC5-0002n7-38@sc8-sf-web23.sourceforge.net>

Bugs item #1725856, was opened at 2007-05-25 14:25
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1725856&group_id=5470

Please note that this 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
Private: No
Submitted By: Charles Hixson (quixo)
Assigned to: Nobody/Anonymous (nobody)
Summary: bsddb.btopen . del of record doesn't update index

Initial Comment:
A ram -resident database is creaed with btopen

10 records are added, keyed by sequence, value is sequence + 1 (both converted to strings).

I check to ensure that all of the records have been added.

I delete the first record, check the keys again, and it still works.

I delete the first record, check the keys again, and it fails, thusly:

python testbtopen.py
['0', '1', '2', '3', '4', '5', '6', '7', '8', '9']
['0', '1', '2', '3', '4', '5', '6', '7', '8', '9']
0
1
2
3
4
5
6
7
8
9
0 1
['1', '2', '3', '4', '5', '6', '7', '8', '9']
1
2
3
4
5
6
7
8
9
Traceback (most recent call last):
  File "testbtopen.py", line 13, in ?
    i   =       db.first()[0]
  File "/usr/lib/python2.4/site-packages/PIL/__init__.py", line 269, in first

  File "/usr/lib/python2.4/site-packages/PIL/__init__.py", line 183, in _checkCursor

_bsddb.DBNotFoundError: (-30989, 'DB_NOTFOUND: No matching key/data pair found')
charles at mandala1:~/projects/Python/bsddb$ python testbtopen.py
['0', '1', '2', '3', '4', '5', '6', '7', '8', '9']
['0', '1', '2', '3', '4', '5', '6', '7', '8', '9']
0
1
2
3
4
5
6
7
8
9
0 1
['1', '2', '3', '4', '5', '6', '7', '8', '9']
1
2
3
4
5
6
7
8
9
Traceback (most recent call last):
  File "testbtopen.py", line 13, in ?
    i   =       db.first()[0]
  File "/usr/lib/python2.4/site-packages/PIL/__init__.py", line 269, in first

  File "/usr/lib/python2.4/site-packages/PIL/__init__.py", line 183, in _checkCursor

_bsddb.DBNotFoundError: (-30989, 'DB_NOTFOUND: No matching key/data pair found')


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1725856&group_id=5470

From noreply at sourceforge.net  Sat May 26 10:08:39 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 26 May 2007 01:08:39 -0700
Subject: [ python-Bugs-1719898 ] tarfile stops expanding with long filenames
Message-ID: <E1HrrKJ-00067y-A8@sc8-sf-web21.sourceforge.net>

Bugs item #1719898, was opened at 2007-05-16 11:32
Message generated for change (Comment added) made by gustaebel
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1719898&group_id=5470

Please note that this message will contain a full 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
Private: No
Submitted By: Christian Zagrodnick (zagy)
Assigned to: Lars Gust?bel (gustaebel)
Summary: tarfile stops expanding with long filenames

Initial Comment:
The tarfile module fixes an issue with "Some old tar programs represent a directory as a regular file with a trailing slash.":

    if tarinfo.isreg() and tarinfo.name.endswith("/"):
        tarinfo.type = DIRTYPE

*After* that the full filename is composed. The chars >100 are stored in "prefix":

    if tarinfo.type != GNUTYPE_SPARSE:
        tarinfo.name normpath(os.path.join(nts(tarinfo.prefix), tarinfo.name))


So guess what happens if you filename has a / at the 100th character. Right, its considered a directory. Since directories have no data, the next metadata block is read from your file data which fails in various ways.

Patch attached.

----------------------------------------------------------------------

>Comment By: Lars Gust?bel (gustaebel)
Date: 2007-05-26 10:08

Message:
Logged In: YES 
user_id=642936
Originator: NO

Okay, I close this bug then.

----------------------------------------------------------------------

Comment By: Christian Zagrodnick (zagy)
Date: 2007-05-25 13:15

Message:
Logged In: YES 
user_id=24696
Originator: YES

Ok, from looking at the code it should work in Python 2.5. I shipped
around the  Python 2.4 bug by creating a zip release instead of tar. 

Pity that Python 2.4 is no longer maintained though. I guess we need to
bump Zope 3 pretty soon then :)

----------------------------------------------------------------------

Comment By: Lars Gust?bel (gustaebel)
Date: 2007-05-16 15:32

Message:
Logged In: YES 
user_id=642936
Originator: NO

Did you also test Python 2.5? If this error occurs with that version too
(which it should not), please attach a small test tar archive to this
tracker item.

Python 2.4 is no longer maintained, sorry.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1719898&group_id=5470

From noreply at sourceforge.net  Sat May 26 11:38:37 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 26 May 2007 02:38:37 -0700
Subject: [ python-Bugs-1726026 ] Typo in ctypes.wintypes definition of
	WIN32_FIND_DATA field
Message-ID: <E1HrsjN-0002UF-AR@sc8-sf-web22.sourceforge.net>

Bugs item #1726026, was opened at 2007-05-26 12: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=1726026&group_id=5470

Please note that this 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
Private: No
Submitted By: Koby Kahane (kobyk)
Assigned to: Nobody/Anonymous (nobody)
Summary: Typo in ctypes.wintypes definition of WIN32_FIND_DATA field

Initial Comment:
In ctypes/wintypes.py, the ANSI and Unicode versions of the Win32 WIN32_FIND_DATA structure are defined.
Both definitions share a typo in the definition of the last field. It is incorrectly spelled as "cAlternameFileName" when it should be "cAlternateFileName" as per the Windows SDK definition of the structure.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1726026&group_id=5470

From noreply at sourceforge.net  Sun May 27 07:15:37 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 26 May 2007 22:15:37 -0700
Subject: [ python-Bugs-1726299 ] bsddb.btopen . del of record doesn't update
	index
Message-ID: <E1HsB6P-0006dV-Nh@sc8-sf-web21.sourceforge.net>

Bugs item #1726299, was opened at 2007-05-27 05: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=1726299&group_id=5470

Please note that this message will contain 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
Private: No
Submitted By: Charles Hixson (quixo)
Assigned to: Nobody/Anonymous (nobody)
Summary: bsddb.btopen . del of record doesn't update index

Initial Comment:
A ram -resident database is creaed with btopen

10 records are added, keyed by sequence, value is sequence + 1 (both converted to strings).

I check to ensure that all of the records have been added.

I delete the first record, check the keys again, and it still works.

I delete the first record, check the keys again, and it fails, thusly:

python testbtopen.py
['0', '1', '2', '3', '4', '5', '6', '7', '8', '9']
['0', '1', '2', '3', '4', '5', '6', '7', '8', '9']
0
1
2
3
4
5
6
7
8
9
0 1
['1', '2', '3', '4', '5', '6', '7', '8', '9']
1
2
3
4
5
6
7
8
9
Traceback (most recent call last):
  File "testbtopen.py", line 13, in ?
    i   =       db.first()[0]
  File "/usr/lib/python2.4/site-packages/PIL/__init__.py", line 269, in first

  File "/usr/lib/python2.4/site-packages/PIL/__init__.py", line 183, in _checkCursor

_bsddb.DBNotFoundError: (-30989, 'DB_NOTFOUND: No matching key/data pair found')
charles at mandala1:~/projects/Python/bsddb$ python testbtopen.py
['0', '1', '2', '3', '4', '5', '6', '7', '8', '9']
['0', '1', '2', '3', '4', '5', '6', '7', '8', '9']
0
1
2
3
4
5
6
7
8
9
0 1
['1', '2', '3', '4', '5', '6', '7', '8', '9']
1
2
3
4
5
6
7
8
9
Traceback (most recent call last):
  File "testbtopen.py", line 13, in ?
    i   =       db.first()[0]
  File "/usr/lib/python2.4/site-packages/PIL/__init__.py", line 269, in first

  File "/usr/lib/python2.4/site-packages/PIL/__init__.py", line 183, in _checkCursor

_bsddb.DBNotFoundError: (-30989, 'DB_NOTFOUND: No matching key/data pair found')


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1726299&group_id=5470

From noreply at sourceforge.net  Sun May 27 13:17:49 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 27 May 2007 04:17:49 -0700
Subject: [ python-Bugs-1725856 ] bsddb.btopen . del of record doesn't update
	index
Message-ID: <E1HsGkv-00089r-4N@sc8-sf-web23.sourceforge.net>

Bugs item #1725856, was opened at 2007-05-25 18:25
Message generated for change (Comment added) made by gagenellina
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1725856&group_id=5470

Please note that this 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
Private: No
Submitted By: Charles Hixson (quixo)
Assigned to: Nobody/Anonymous (nobody)
Summary: bsddb.btopen . del of record doesn't update index

Initial Comment:
A ram -resident database is creaed with btopen

10 records are added, keyed by sequence, value is sequence + 1 (both converted to strings).

I check to ensure that all of the records have been added.

I delete the first record, check the keys again, and it still works.

I delete the first record, check the keys again, and it fails, thusly:

python testbtopen.py
['0', '1', '2', '3', '4', '5', '6', '7', '8', '9']
['0', '1', '2', '3', '4', '5', '6', '7', '8', '9']
0
1
2
3
4
5
6
7
8
9
0 1
['1', '2', '3', '4', '5', '6', '7', '8', '9']
1
2
3
4
5
6
7
8
9
Traceback (most recent call last):
  File "testbtopen.py", line 13, in ?
    i   =       db.first()[0]
  File "/usr/lib/python2.4/site-packages/PIL/__init__.py", line 269, in first

  File "/usr/lib/python2.4/site-packages/PIL/__init__.py", line 183, in _checkCursor

_bsddb.DBNotFoundError: (-30989, 'DB_NOTFOUND: No matching key/data pair found')
charles at mandala1:~/projects/Python/bsddb$ python testbtopen.py
['0', '1', '2', '3', '4', '5', '6', '7', '8', '9']
['0', '1', '2', '3', '4', '5', '6', '7', '8', '9']
0
1
2
3
4
5
6
7
8
9
0 1
['1', '2', '3', '4', '5', '6', '7', '8', '9']
1
2
3
4
5
6
7
8
9
Traceback (most recent call last):
  File "testbtopen.py", line 13, in ?
    i   =       db.first()[0]
  File "/usr/lib/python2.4/site-packages/PIL/__init__.py", line 269, in first

  File "/usr/lib/python2.4/site-packages/PIL/__init__.py", line 183, in _checkCursor

_bsddb.DBNotFoundError: (-30989, 'DB_NOTFOUND: No matching key/data pair found')


----------------------------------------------------------------------

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-27 08:17

Message:
Logged In: YES 
user_id=479790
Originator: NO

FWIW, the same thing happens on 2.5.1 on Windows. With the funny stack
trace too (PIL is not remotely related, PIL/__init__.py being almost
empty).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1725856&group_id=5470

From noreply at sourceforge.net  Mon May 28 02:51:00 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 27 May 2007 17:51:00 -0700
Subject: [ python-Bugs-1726299 ] bsddb.btopen . del of record doesn't update
	index
Message-ID: <E1HsTRs-0006IG-71@sc8-sf-web21.sourceforge.net>

Bugs item #1726299, was opened at 2007-05-26 22:15
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1726299&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
>Status: Closed
>Resolution: Duplicate
Priority: 5
Private: No
Submitted By: Charles Hixson (quixo)
Assigned to: Nobody/Anonymous (nobody)
Summary: bsddb.btopen . del of record doesn't update index

Initial Comment:
A ram -resident database is creaed with btopen

10 records are added, keyed by sequence, value is sequence + 1 (both converted to strings).

I check to ensure that all of the records have been added.

I delete the first record, check the keys again, and it still works.

I delete the first record, check the keys again, and it fails, thusly:

python testbtopen.py
['0', '1', '2', '3', '4', '5', '6', '7', '8', '9']
['0', '1', '2', '3', '4', '5', '6', '7', '8', '9']
0
1
2
3
4
5
6
7
8
9
0 1
['1', '2', '3', '4', '5', '6', '7', '8', '9']
1
2
3
4
5
6
7
8
9
Traceback (most recent call last):
  File "testbtopen.py", line 13, in ?
    i   =       db.first()[0]
  File "/usr/lib/python2.4/site-packages/PIL/__init__.py", line 269, in first

  File "/usr/lib/python2.4/site-packages/PIL/__init__.py", line 183, in _checkCursor

_bsddb.DBNotFoundError: (-30989, 'DB_NOTFOUND: No matching key/data pair found')
charles at mandala1:~/projects/Python/bsddb$ python testbtopen.py
['0', '1', '2', '3', '4', '5', '6', '7', '8', '9']
['0', '1', '2', '3', '4', '5', '6', '7', '8', '9']
0
1
2
3
4
5
6
7
8
9
0 1
['1', '2', '3', '4', '5', '6', '7', '8', '9']
1
2
3
4
5
6
7
8
9
Traceback (most recent call last):
  File "testbtopen.py", line 13, in ?
    i   =       db.first()[0]
  File "/usr/lib/python2.4/site-packages/PIL/__init__.py", line 269, in first

  File "/usr/lib/python2.4/site-packages/PIL/__init__.py", line 183, in _checkCursor

_bsddb.DBNotFoundError: (-30989, 'DB_NOTFOUND: No matching key/data pair found')


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-27 17:51

Message:
Logged In: YES 
user_id=33168
Originator: NO

Duplicate of 1725856.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1726299&group_id=5470

From noreply at sourceforge.net  Mon May 28 03:23:43 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 27 May 2007 18:23:43 -0700
Subject: [ python-Bugs-1726668 ] platform.system() returns incorrect value in
	Vista
Message-ID: <E1HsTxX-0001T4-UZ@sc8-sf-web21.sourceforge.net>

Bugs item #1726668, was opened at 2007-05-27 21: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=1726668&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Benjamin Leppard (bleppard)
Assigned to: Nobody/Anonymous (nobody)
Summary: platform.system() returns incorrect value in Vista

Initial Comment:


On Microsoft Vista platform.system() returns 'Microsoft' and platform.release() returns 'Windows'

Under Microsoft Windows XP SP2 platform.system() returns 'Windows' and platform.release() returns 'XP'.

This is problem was caused by a change in the output of the "ver" command. In Windows XP SP2 "ver" outputted 'Microsoft Windows XP [Version 5.1.2600]'  In Microsoft Vista "ver" outputted 'Microsoft Windows [Version 6.0.6000]'. The lack of the 3rd word before version causes _syscmd_ver(...) in platform.py to return 'Microsoft' for system instead of 'Microsoft Windows'. This causes uname() to return the incorrect values. Both system() and release() call uname().

This problem occurs in the trunk.

I have attached a patch against the trunk svn that fixes the symptom of the problem in uname()

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1726668&group_id=5470

From noreply at sourceforge.net  Mon May 28 04:27:51 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 27 May 2007 19:27:51 -0700
Subject: [ python-Bugs-1726687 ] Bug found in datetime for Epoch time = -1
Message-ID: <E1HsUxb-0006Tu-Cj@sc8-sf-web24.sourceforge.net>

Bugs item #1726687, was opened at 2007-05-28 02:27
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1726687&group_id=5470

Please note that this 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
Private: No
Submitted By: Martin Blais (blais)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bug found in datetime for Epoch time = -1

Initial Comment:
There is a bug in datetime.fromtimestamp(), whereby if it is called with -1, it fails with "mktime argument out of range" when it should not (see attached test program to reproduce the problem).

The bug is that the way that mktime() signals an error code is subtle and error-prone: you need to set a sentinel in the tm's wday or yday and not only check the return value of mktime, but also check if those values have been modified; it figures: -1 is a valid value in the return domain of mktime() and is not a sufficient condition for signaling an error.

Here is the relevant excerpt from the Linux man page:


       The mktime() function converts a broken-down time structure,  expressed
       as  local  time, to calendar time representation.  The function ignores
       the specified contents of the structure members tm_wday and tm_yday and
       recomputes  them  from  the  other  information in the broken-down time
       structure.  If structure members are outside their legal interval, they
       will  be normalized (so that, e.g., 40 October is changed into 9 Novem-
       ber).  Calling mktime() also sets the  external  variable  tzname  with
       information  about the current time zone.  If the specified broken-down
       time cannot be represented as calendar time (seconds since the  epoch),
       mktime() returns a value of (time_t)(-1) and does not alter the tm_wday
       and tm_yday members of the broken-down time structure.


This was found under Linux, I do not know if this bug also occurs on Windows or the Mac.

I attached a couple of files:

- timebug.py: reproduce the bug
- timebug.c: tests that mktime()'s behaviour is as wicked as expected
- timebug.patch: the fix to the datetime module.



P.S. I hit this bug in a graphics application while zooming in/out of a viewer rendering time-based data. Sheer luck.




----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1726687&group_id=5470

From noreply at sourceforge.net  Mon May 28 04:28:31 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 27 May 2007 19:28:31 -0700
Subject: [ python-Bugs-1726687 ] Bug found in datetime for Epoch time = -1
Message-ID: <E1HsUyF-0006aD-1h@sc8-sf-web24.sourceforge.net>

Bugs item #1726687, was opened at 2007-05-28 02:27
Message generated for change (Comment added) made by blais
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1726687&group_id=5470

Please note that this 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
Private: No
Submitted By: Martin Blais (blais)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bug found in datetime for Epoch time = -1

Initial Comment:
There is a bug in datetime.fromtimestamp(), whereby if it is called with -1, it fails with "mktime argument out of range" when it should not (see attached test program to reproduce the problem).

The bug is that the way that mktime() signals an error code is subtle and error-prone: you need to set a sentinel in the tm's wday or yday and not only check the return value of mktime, but also check if those values have been modified; it figures: -1 is a valid value in the return domain of mktime() and is not a sufficient condition for signaling an error.

Here is the relevant excerpt from the Linux man page:


       The mktime() function converts a broken-down time structure,  expressed
       as  local  time, to calendar time representation.  The function ignores
       the specified contents of the structure members tm_wday and tm_yday and
       recomputes  them  from  the  other  information in the broken-down time
       structure.  If structure members are outside their legal interval, they
       will  be normalized (so that, e.g., 40 October is changed into 9 Novem-
       ber).  Calling mktime() also sets the  external  variable  tzname  with
       information  about the current time zone.  If the specified broken-down
       time cannot be represented as calendar time (seconds since the  epoch),
       mktime() returns a value of (time_t)(-1) and does not alter the tm_wday
       and tm_yday members of the broken-down time structure.


This was found under Linux, I do not know if this bug also occurs on Windows or the Mac.

I attached a couple of files:

- timebug.py: reproduce the bug
- timebug.c: tests that mktime()'s behaviour is as wicked as expected
- timebug.patch: the fix to the datetime module.



P.S. I hit this bug in a graphics application while zooming in/out of a viewer rendering time-based data. Sheer luck.




----------------------------------------------------------------------

>Comment By: Martin Blais (blais)
Date: 2007-05-28 02:28

Message:
Logged In: YES 
user_id=10996
Originator: YES

File Added: timebug.py

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1726687&group_id=5470

From noreply at sourceforge.net  Mon May 28 04:29:05 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 27 May 2007 19:29:05 -0700
Subject: [ python-Bugs-1726687 ] Bug found in datetime for Epoch time = -1
Message-ID: <E1HsUyn-0007tU-9t@sc8-sf-web22.sourceforge.net>

Bugs item #1726687, was opened at 2007-05-28 02:27
Message generated for change (Comment added) made by blais
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1726687&group_id=5470

Please note that this 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
Private: No
Submitted By: Martin Blais (blais)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bug found in datetime for Epoch time = -1

Initial Comment:
There is a bug in datetime.fromtimestamp(), whereby if it is called with -1, it fails with "mktime argument out of range" when it should not (see attached test program to reproduce the problem).

The bug is that the way that mktime() signals an error code is subtle and error-prone: you need to set a sentinel in the tm's wday or yday and not only check the return value of mktime, but also check if those values have been modified; it figures: -1 is a valid value in the return domain of mktime() and is not a sufficient condition for signaling an error.

Here is the relevant excerpt from the Linux man page:


       The mktime() function converts a broken-down time structure,  expressed
       as  local  time, to calendar time representation.  The function ignores
       the specified contents of the structure members tm_wday and tm_yday and
       recomputes  them  from  the  other  information in the broken-down time
       structure.  If structure members are outside their legal interval, they
       will  be normalized (so that, e.g., 40 October is changed into 9 Novem-
       ber).  Calling mktime() also sets the  external  variable  tzname  with
       information  about the current time zone.  If the specified broken-down
       time cannot be represented as calendar time (seconds since the  epoch),
       mktime() returns a value of (time_t)(-1) and does not alter the tm_wday
       and tm_yday members of the broken-down time structure.


This was found under Linux, I do not know if this bug also occurs on Windows or the Mac.

I attached a couple of files:

- timebug.py: reproduce the bug
- timebug.c: tests that mktime()'s behaviour is as wicked as expected
- timebug.patch: the fix to the datetime module.



P.S. I hit this bug in a graphics application while zooming in/out of a viewer rendering time-based data. Sheer luck.




----------------------------------------------------------------------

>Comment By: Martin Blais (blais)
Date: 2007-05-28 02:29

Message:
Logged In: YES 
user_id=10996
Originator: YES

File Added: timebug.c

----------------------------------------------------------------------

Comment By: Martin Blais (blais)
Date: 2007-05-28 02:28

Message:
Logged In: YES 
user_id=10996
Originator: YES

File Added: timebug.py

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1726687&group_id=5470

From noreply at sourceforge.net  Mon May 28 04:30:13 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 27 May 2007 19:30:13 -0700
Subject: [ python-Bugs-1726687 ] Bug found in datetime for Epoch time = -1
Message-ID: <E1HsUzt-0001IW-Ef@sc8-sf-web21.sourceforge.net>

Bugs item #1726687, was opened at 2007-05-28 02:27
Message generated for change (Comment added) made by blais
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1726687&group_id=5470

Please note that this 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
Private: No
Submitted By: Martin Blais (blais)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bug found in datetime for Epoch time = -1

Initial Comment:
There is a bug in datetime.fromtimestamp(), whereby if it is called with -1, it fails with "mktime argument out of range" when it should not (see attached test program to reproduce the problem).

The bug is that the way that mktime() signals an error code is subtle and error-prone: you need to set a sentinel in the tm's wday or yday and not only check the return value of mktime, but also check if those values have been modified; it figures: -1 is a valid value in the return domain of mktime() and is not a sufficient condition for signaling an error.

Here is the relevant excerpt from the Linux man page:


       The mktime() function converts a broken-down time structure,  expressed
       as  local  time, to calendar time representation.  The function ignores
       the specified contents of the structure members tm_wday and tm_yday and
       recomputes  them  from  the  other  information in the broken-down time
       structure.  If structure members are outside their legal interval, they
       will  be normalized (so that, e.g., 40 October is changed into 9 Novem-
       ber).  Calling mktime() also sets the  external  variable  tzname  with
       information  about the current time zone.  If the specified broken-down
       time cannot be represented as calendar time (seconds since the  epoch),
       mktime() returns a value of (time_t)(-1) and does not alter the tm_wday
       and tm_yday members of the broken-down time structure.


This was found under Linux, I do not know if this bug also occurs on Windows or the Mac.

I attached a couple of files:

- timebug.py: reproduce the bug
- timebug.c: tests that mktime()'s behaviour is as wicked as expected
- timebug.patch: the fix to the datetime module.



P.S. I hit this bug in a graphics application while zooming in/out of a viewer rendering time-based data. Sheer luck.




----------------------------------------------------------------------

>Comment By: Martin Blais (blais)
Date: 2007-05-28 02:30

Message:
Logged In: YES 
user_id=10996
Originator: YES

File Added: timebug.patch

----------------------------------------------------------------------

Comment By: Martin Blais (blais)
Date: 2007-05-28 02:29

Message:
Logged In: YES 
user_id=10996
Originator: YES

File Added: timebug.c

----------------------------------------------------------------------

Comment By: Martin Blais (blais)
Date: 2007-05-28 02:28

Message:
Logged In: YES 
user_id=10996
Originator: YES

File Added: timebug.py

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1726687&group_id=5470

From noreply at sourceforge.net  Mon May 28 04:33:04 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 27 May 2007 19:33:04 -0700
Subject: [ python-Bugs-697989 ] Clarify mktime semantics
Message-ID: <E1HsV2e-0008C4-5C@sc8-sf-web23.sourceforge.net>

Bugs item #697989, was opened at 2003-03-05 13:46
Message generated for change (Comment added) made by blais
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697989&group_id=5470

Please note that this 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
Private: No
Submitted By: Erland Lewin (erl)
Assigned to: Jeremy Hylton (jhylton)
Summary: Clarify mktime semantics

Initial Comment:
Python Library Reference, Chapter 6.9

mktime: I believe the C mktime calls ignore the weekday
and Julian day values in the tuple. I therefor assume
that the Python function also does so, which should be
documented.


----------------------------------------------------------------------

Comment By: Martin Blais (blais)
Date: 2007-05-28 02:33

Message:
Logged In: YES 
user_id=10996
Originator: NO

This is somewhat related to this bug/patch:
http://sourceforge.net/tracker/index.php?func=detail&aid=1726687&group_id=5470&atid=105470

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-03-06 19:01

Message:
Logged In: YES 
user_id=31435

Yup, I agree the spec is clear on this specific point.  I'd rather 
the docs refer users to the platform C docs, though, as many 
other aspects of mktime can and do vary across 
implementations (for example, C is silent on the origin of the 
epoch, while POSIX defines it; C and POSIX are both clear as 
mud about how out-of-range struct tm members are to be 
treated; etc -- google for mktime man pages to see what a 
mess this function really is across platforms).

----------------------------------------------------------------------

Comment By: Erland Lewin (erl)
Date: 2003-03-06 15:44

Message:
Logged In: YES 
user_id=116933

I have a draft of the C99 standard, which in paragraph
7.23.2.3 describes mktime, and says:

&quot;The original values of the tm_wday and tm_yday components
of the structure are ignored...&quot;

So, I would say that mktime() is *not* underspecified by ISO C.

In order to write correct programs, it is neccessary to know
the semantics of the functions, and IMHO the manual should
specify what can be expected of them.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-03-05 19:05

Message:
Logged In: YES 
user_id=31435

Python does (for the most part) inherit mktime semantics 
from the platform C, but mktime() is &quot;underspecified&quot; by 
ANSI C and there's little that can be said about oddball 
cases across platforms.  Sometimes it even depends on 
the preprocessor symbols defined when the platform C 
library was compiled.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697989&group_id=5470

From noreply at sourceforge.net  Mon May 28 04:38:16 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 27 May 2007 19:38:16 -0700
Subject: [ python-Bugs-1726687 ] Bug found in datetime for Epoch time = -1
Message-ID: <E1HsV7g-0002Ao-CY@sc8-sf-web21.sourceforge.net>

Bugs item #1726687, was opened at 2007-05-28 02:27
Message generated for change (Comment added) made by blais
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1726687&group_id=5470

Please note that this 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
Private: No
Submitted By: Martin Blais (blais)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bug found in datetime for Epoch time = -1

Initial Comment:
There is a bug in datetime.fromtimestamp(), whereby if it is called with -1, it fails with "mktime argument out of range" when it should not (see attached test program to reproduce the problem).

The bug is that the way that mktime() signals an error code is subtle and error-prone: you need to set a sentinel in the tm's wday or yday and not only check the return value of mktime, but also check if those values have been modified; it figures: -1 is a valid value in the return domain of mktime() and is not a sufficient condition for signaling an error.

Here is the relevant excerpt from the Linux man page:


       The mktime() function converts a broken-down time structure,  expressed
       as  local  time, to calendar time representation.  The function ignores
       the specified contents of the structure members tm_wday and tm_yday and
       recomputes  them  from  the  other  information in the broken-down time
       structure.  If structure members are outside their legal interval, they
       will  be normalized (so that, e.g., 40 October is changed into 9 Novem-
       ber).  Calling mktime() also sets the  external  variable  tzname  with
       information  about the current time zone.  If the specified broken-down
       time cannot be represented as calendar time (seconds since the  epoch),
       mktime() returns a value of (time_t)(-1) and does not alter the tm_wday
       and tm_yday members of the broken-down time structure.


This was found under Linux, I do not know if this bug also occurs on Windows or the Mac.

I attached a couple of files:

- timebug.py: reproduce the bug
- timebug.c: tests that mktime()'s behaviour is as wicked as expected
- timebug.patch: the fix to the datetime module.



P.S. I hit this bug in a graphics application while zooming in/out of a viewer rendering time-based data. Sheer luck.




----------------------------------------------------------------------

>Comment By: Martin Blais (blais)
Date: 2007-05-28 02:38

Message:
Logged In: YES 
user_id=10996
Originator: YES

(Additional note: this bug was found and fixed with Peter Wang from
Enthought.)

----------------------------------------------------------------------

Comment By: Martin Blais (blais)
Date: 2007-05-28 02:30

Message:
Logged In: YES 
user_id=10996
Originator: YES

File Added: timebug.patch

----------------------------------------------------------------------

Comment By: Martin Blais (blais)
Date: 2007-05-28 02:29

Message:
Logged In: YES 
user_id=10996
Originator: YES

File Added: timebug.c

----------------------------------------------------------------------

Comment By: Martin Blais (blais)
Date: 2007-05-28 02:28

Message:
Logged In: YES 
user_id=10996
Originator: YES

File Added: timebug.py

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1726687&group_id=5470

From noreply at sourceforge.net  Mon May 28 05:49:31 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 27 May 2007 20:49:31 -0700
Subject: [ python-Feature Requests-1726697 ] add operator.fst and snd functions
Message-ID: <E1HsWEd-0001Qt-FW@sc8-sf-web21.sourceforge.net>

Feature Requests item #1726697, was opened at 2007-05-28 03:49
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=1726697&group_id=5470

Please note that this 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
Private: No
Submitted By: paul rubin (phr)
Assigned to: Nobody/Anonymous (nobody)
Summary: add operator.fst and snd functions

Initial Comment:
operator.itemgetter is a general but clumsy abstraction.  Almost all the time when I use it, it's either to get the first or the second item of a tuple.  I think that use case is common enough that it's worth including them in the operator module:

   fst = itemgetter(0)
   snd = itemgetter(1)

I end up putting the above definitions in my programs very frequently and it would be nice if I could stop ;)

fst and snd are mathematical names abbreviating "first" and "second" in some areas of math, like sin and cos abbreviate "sine" and "cosine".  The names fst and snd are also used in Haskell and *ML.  However, calling them "first" and "second" might be stylistically preferable to some Python users and would also be ok.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1726697&group_id=5470

From noreply at sourceforge.net  Mon May 28 06:49:18 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 27 May 2007 21:49:18 -0700
Subject: [ python-Feature Requests-1726697 ] add operator.fst and snd functions
Message-ID: <E1HsXAU-0005uW-9e@sc8-sf-web22.sourceforge.net>

Feature Requests item #1726697, was opened at 2007-05-27 22:49
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1726697&group_id=5470

Please note that this 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
Private: No
Submitted By: paul rubin (phr)
Assigned to: Nobody/Anonymous (nobody)
Summary: add operator.fst and snd functions

Initial Comment:
operator.itemgetter is a general but clumsy abstraction.  Almost all the time when I use it, it's either to get the first or the second item of a tuple.  I think that use case is common enough that it's worth including them in the operator module:

   fst = itemgetter(0)
   snd = itemgetter(1)

I end up putting the above definitions in my programs very frequently and it would be nice if I could stop ;)

fst and snd are mathematical names abbreviating "first" and "second" in some areas of math, like sin and cos abbreviate "sine" and "cosine".  The names fst and snd are also used in Haskell and *ML.  However, calling them "first" and "second" might be stylistically preferable to some Python users and would also be ok.


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-05-27 23:49

Message:
Logged In: YES 
user_id=80475
Originator: NO

-1

That would provide too many ways to do it.  
It is more important to learn how to use one way correctly.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1726697&group_id=5470

From noreply at sourceforge.net  Mon May 28 06:51:12 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 27 May 2007 21:51:12 -0700
Subject: [ python-Feature Requests-1726707 ] add itertools.ichain function and
	count.getvalue
Message-ID: <E1HsXCK-0004uz-Hx@sc8-sf-web24.sourceforge.net>

Feature Requests item #1726707, was opened at 2007-05-28 04:51
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=1726707&group_id=5470

Please note that this 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
Private: No
Submitted By: paul rubin (phr)
Assigned to: Nobody/Anonymous (nobody)
Summary: add itertools.ichain function and count.getvalue

Initial Comment:
def ichain(seq):
  for s in seq:
     for t in s: yield t

This is like itertools.chain except seq is lazy-evaluated element-by-element.  Obvious use cases:

# equivalent of perl's "while (<>) { ... } "
for line in ichain(all_lines_of(f) for f in list_of_filenames):
   do_something_with(line)

# generate infinite sequence 1,1,1,2,2,2...
seq = ichain(repeat(i,3) for i in count(1))

Also requested: it would be nice to be able to get the current counter value from a count() instance without incrementing it, e.g.
   c = count()
   ...
   i = c.getvalue()

This is clearly useful since repr(c) does something like that internally.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1726707&group_id=5470

From noreply at sourceforge.net  Mon May 28 06:51:19 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 27 May 2007 21:51:19 -0700
Subject: [ python-Feature Requests-1719222 ] new functool: "defaults" decorator
Message-ID: <E1HsXCR-00067u-9b@sc8-sf-web22.sourceforge.net>

Feature Requests item #1719222, was opened at 2007-05-15 06:42
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1719222&group_id=5470

Please note that this message will contain 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: Rejected
Priority: 5
Private: No
Submitted By: Aaron Brady (ascription)
Assigned to: Nobody/Anonymous (nobody)
Summary: new functool: "defaults" decorator

Initial Comment:
Python feature

Functools gains a new decorator.

`Defaults' allows its caller to placehold non-None defaults; it becomes unnecessary to know the value a place defaults to.

It might be useful in cases where you want the calling signature to look alike for a group of dispatched functions and the added overhead the decorator adds isn't a problem.  But you probably wouldn't want that overhead all the time, so having it as an optional decorator would be good. -Ron Adam


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-05-27 23:51

Message:
Logged In: YES 
user_id=80475
Originator: NO

Rejecting due to lack of support.



----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-15 09:47

Message:
Logged In: YES 
user_id=849994
Originator: NO

Moving to Feature Requests, adapting summary.

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2007-05-15 09:25

Message:
Logged In: YES 
user_id=341410
Originator: NO

This is not a bug.  Should move to Feature Requests at minimum, patches if
the text file is an actual patch.

Generally the poster desires that a catch-all default argument be allowed
to be passed to any function with default arguments to signal that the
original defaults should be used; like foo(123, default, 456) rather than
foo(123, arg3=456).

This proposal received no support in python-ideas.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1719222&group_id=5470

From noreply at sourceforge.net  Mon May 28 06:52:02 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 27 May 2007 21:52:02 -0700
Subject: [ python-Feature Requests-1719222 ] new functool: "defaults" decorator
Message-ID: <E1HsXD8-0006Cj-Nt@sc8-sf-web22.sourceforge.net>

Feature Requests item #1719222, was opened at 2007-05-15 06:42
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1719222&group_id=5470

Please note that this message will contain 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: Rejected
Priority: 5
Private: No
Submitted By: Aaron Brady (ascription)
Assigned to: Nobody/Anonymous (nobody)
Summary: new functool: "defaults" decorator

Initial Comment:
Python feature

Functools gains a new decorator.

`Defaults' allows its caller to placehold non-None defaults; it becomes unnecessary to know the value a place defaults to.

It might be useful in cases where you want the calling signature to look alike for a group of dispatched functions and the added overhead the decorator adds isn't a problem.  But you probably wouldn't want that overhead all the time, so having it as an optional decorator would be good. -Ron Adam


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-05-27 23:51

Message:
Logged In: YES 
user_id=80475
Originator: NO

Rejecting due to lack of support.



----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-15 09:47

Message:
Logged In: YES 
user_id=849994
Originator: NO

Moving to Feature Requests, adapting summary.

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2007-05-15 09:25

Message:
Logged In: YES 
user_id=341410
Originator: NO

This is not a bug.  Should move to Feature Requests at minimum, patches if
the text file is an actual patch.

Generally the poster desires that a catch-all default argument be allowed
to be passed to any function with default arguments to signal that the
original defaults should be used; like foo(123, default, 456) rather than
foo(123, arg3=456).

This proposal received no support in python-ideas.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1719222&group_id=5470

From noreply at sourceforge.net  Mon May 28 07:15:31 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 27 May 2007 22:15:31 -0700
Subject: [ python-Feature Requests-1726707 ] add itertools.ichain function and
	count.getvalue
Message-ID: <E1HsXZr-0000DK-Hj@sc8-sf-web22.sourceforge.net>

Feature Requests item #1726707, was opened at 2007-05-27 23:51
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1726707&group_id=5470

Please note that this 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
Private: No
Submitted By: paul rubin (phr)
Assigned to: Nobody/Anonymous (nobody)
Summary: add itertools.ichain function and count.getvalue

Initial Comment:
def ichain(seq):
  for s in seq:
     for t in s: yield t

This is like itertools.chain except seq is lazy-evaluated element-by-element.  Obvious use cases:

# equivalent of perl's "while (<>) { ... } "
for line in ichain(all_lines_of(f) for f in list_of_filenames):
   do_something_with(line)

# generate infinite sequence 1,1,1,2,2,2...
seq = ichain(repeat(i,3) for i in count(1))

Also requested: it would be nice to be able to get the current counter value from a count() instance without incrementing it, e.g.
   c = count()
   ...
   i = c.getvalue()

This is clearly useful since repr(c) does something like that internally.


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-05-28 00:15

Message:
Logged In: YES 
user_id=80475
Originator: NO

Am rejecting ichain() because it adds too little in the way of
functionality to be worth the confusion associated with having two like
named functions and two ways to handle most problems.

Also, I think that some the use cases for lazy-evaluated inputs are better
served by using explicit for-loops and not itertools (too much magic
underneath the hood).  I do see some value in having lazy-evaluated inputs
but do not think it is worth complexifying the module any further.

FWIW, the first example has no need for lazy evaluation.  I would write it
as:

   for line in chain(*map(open, list_of_filenames)):
        do_something_with(line)

Or, just use plain vanilla Python:

   for filename in list_of_filenames:
       for line in open(filename):
            do_something_with(line)

Please submit a separate feature request for count.getvalue().  I'm
thinking it should be a read-only attribute instead of a method.  The only
downside is that it complicates the explanation of an otherwise trivially
simple tool.  


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1726707&group_id=5470

From noreply at sourceforge.net  Mon May 28 07:32:52 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 27 May 2007 22:32:52 -0700
Subject: [ python-Feature Requests-1726707 ] add itertools.ichain function and
	count.getvalue
Message-ID: <E1HsXqe-0004Bg-Hs@sc8-sf-web21.sourceforge.net>

Feature Requests item #1726707, was opened at 2007-05-28 04:51
Message generated for change (Comment added) made by phr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1726707&group_id=5470

Please note that this 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
Private: No
Submitted By: paul rubin (phr)
Assigned to: Nobody/Anonymous (nobody)
Summary: add itertools.ichain function and count.getvalue

Initial Comment:
def ichain(seq):
  for s in seq:
     for t in s: yield t

This is like itertools.chain except seq is lazy-evaluated element-by-element.  Obvious use cases:

# equivalent of perl's "while (<>) { ... } "
for line in ichain(all_lines_of(f) for f in list_of_filenames):
   do_something_with(line)

# generate infinite sequence 1,1,1,2,2,2...
seq = ichain(repeat(i,3) for i in count(1))

Also requested: it would be nice to be able to get the current counter value from a count() instance without incrementing it, e.g.
   c = count()
   ...
   i = c.getvalue()

This is clearly useful since repr(c) does something like that internally.


----------------------------------------------------------------------

>Comment By: paul rubin (phr)
Date: 2007-05-28 05:32

Message:
Logged In: YES 
user_id=72053
Originator: YES

Well, I use ichain all the time in my own code, and the difference doesn't
seem hard to explain.  The chain(*map(open, list_of_filenames)) substitute
is no good because it opens all the files simultaneously, and there might
be millions of them, so you run out of file descriptors.  Not having ichain
in the module leads to users writing such inferior substitutes, which can
work for small examples and end up breaking or performing poorly with large
examples.  Also, using nested for-loops isn't so nice if you want to pass
the resulting generator to some other function (maybe islice or groupby or
something).  It means you've got to wrap the statements in a named
function, which I suppose is doable, but ends up with unnecessary Java-like
code bloat.

A read-only attribute is fine for count.getvalue.  I guess it could be
count.value instead of getvalue.  I'll submit a separate RFE as suggested.



----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-05-28 05:15

Message:
Logged In: YES 
user_id=80475
Originator: NO

Am rejecting ichain() because it adds too little in the way of
functionality to be worth the confusion associated with having two like
named functions and two ways to handle most problems.

Also, I think that some the use cases for lazy-evaluated inputs are better
served by using explicit for-loops and not itertools (too much magic
underneath the hood).  I do see some value in having lazy-evaluated inputs
but do not think it is worth complexifying the module any further.

FWIW, the first example has no need for lazy evaluation.  I would write it
as:

   for line in chain(*map(open, list_of_filenames)):
        do_something_with(line)

Or, just use plain vanilla Python:

   for filename in list_of_filenames:
       for line in open(filename):
            do_something_with(line)

Please submit a separate feature request for count.getvalue().  I'm
thinking it should be a read-only attribute instead of a method.  The only
downside is that it complicates the explanation of an otherwise trivially
simple tool.  


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1726707&group_id=5470

From noreply at sourceforge.net  Mon May 28 11:58:05 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 28 May 2007 02:58:05 -0700
Subject: [ python-Bugs-1723338 ] Crash in ctypes callproc function with
	unicode string arg
Message-ID: <E1HsbzJ-00043u-Sz@sc8-sf-web21.sourceforge.net>

Bugs item #1723338, was opened at 2007-05-22 10:43
Message generated for change (Comment added) made by claplace
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1723338&group_id=5470

Please note that this 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: Works For Me
Priority: 5
Private: No
Submitted By: Colin Laplace (claplace)
Assigned to: Thomas Heller (theller)
Summary: Crash in ctypes callproc function with unicode string arg

Initial Comment:
I've recently came to a bug using ctypes.
I was using ctypes to call a syscall and and passing it
a string argument, which was in fact in unicode.
This resulted in a python crash in the callproc function.

You can easily reproduce the crash by launching the attached python file (or at this link: https://core.fluendo.com/elisa/trac/browser/branches/rewrite-1/elisa/extern/inotify.py 
)

tested with python 2.5

----------------------------------------------------------------------

>Comment By: Colin Laplace (claplace)
Date: 2007-05-28 09:58

Message:
Logged In: YES 
user_id=25510
Originator: YES

The argtypes thing fixed my problem, thank you.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2007-05-23 18:35

Message:
Logged In: YES 
user_id=11105
Originator: NO

Unfortunately your test script does not run for me (I don't have twisted
installed on Linux).

I fear this is not a bug.  When the .argtypes attribute for a foreign
function is not set, you can pass (among others) Python strings *and*
Python unicode strings to the function.  The foreign function will receive
a 'char *' in the former case, and a 'wchar_t *' in the latter case - the
unicode string will *not* be converted.

If this is your problem, and the foreign function expects a 'char *', you
have several choices:

1. You can convert the unicode string to an ascii string in the Python
code yourself.
2. You can wrap the unicode string in a c_char_p instance, and ctypes will
do the conversion for you.
3. You can set the correct .argtypes attribute on the function, and ctypes
will do the conversion for you.

If this is not your problem, please provide a self-contained test case.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-23 04:06

Message:
Logged In: YES 
user_id=33168
Originator: NO

Thomas, could you take a look?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1723338&group_id=5470

From noreply at sourceforge.net  Mon May 28 17:39:17 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 28 May 2007 08:39:17 -0700
Subject: [ python-Bugs-1723338 ] Crash in ctypes callproc function with
	unicode string arg
Message-ID: <E1HshJV-0006B1-Ty@sc8-sf-web24.sourceforge.net>

Bugs item #1723338, was opened at 2007-05-22 12:43
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1723338&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.5
>Status: Closed
Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Colin Laplace (claplace)
Assigned to: Thomas Heller (theller)
Summary: Crash in ctypes callproc function with unicode string arg

Initial Comment:
I've recently came to a bug using ctypes.
I was using ctypes to call a syscall and and passing it
a string argument, which was in fact in unicode.
This resulted in a python crash in the callproc function.

You can easily reproduce the crash by launching the attached python file (or at this link: https://core.fluendo.com/elisa/trac/browser/branches/rewrite-1/elisa/extern/inotify.py 
)

tested with python 2.5

----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2007-05-28 17:39

Message:
Logged In: YES 
user_id=11105
Originator: NO

Thanks, closing then.

----------------------------------------------------------------------

Comment By: Colin Laplace (claplace)
Date: 2007-05-28 11:58

Message:
Logged In: YES 
user_id=25510
Originator: YES

The argtypes thing fixed my problem, thank you.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2007-05-23 20:35

Message:
Logged In: YES 
user_id=11105
Originator: NO

Unfortunately your test script does not run for me (I don't have twisted
installed on Linux).

I fear this is not a bug.  When the .argtypes attribute for a foreign
function is not set, you can pass (among others) Python strings *and*
Python unicode strings to the function.  The foreign function will receive
a 'char *' in the former case, and a 'wchar_t *' in the latter case - the
unicode string will *not* be converted.

If this is your problem, and the foreign function expects a 'char *', you
have several choices:

1. You can convert the unicode string to an ascii string in the Python
code yourself.
2. You can wrap the unicode string in a c_char_p instance, and ctypes will
do the conversion for you.
3. You can set the correct .argtypes attribute on the function, and ctypes
will do the conversion for you.

If this is not your problem, please provide a self-contained test case.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-23 06:06

Message:
Logged In: YES 
user_id=33168
Originator: NO

Thomas, could you take a look?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1723338&group_id=5470

From noreply at sourceforge.net  Mon May 28 19:41:22 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 28 May 2007 10:41:22 -0700
Subject: [ python-Bugs-1727024 ] subprocess: unreliability of returncode not
	clear from docs
Message-ID: <E1HsjDe-0000Yd-K0@sc8-sf-web21.sourceforge.net>

Bugs item #1727024, was opened at 2007-05-28 17: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=1727024&group_id=5470

Please note that this 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
Private: No
Submitted By: Dan O'Huiginn (ohuiginn)
Assigned to: Nobody/Anonymous (nobody)
Summary: subprocess: unreliability of returncode not clear from docs

Initial Comment:
The docs for the subprocess module (http://docs.python.org/lib/node533.html) give the impression that you can reliably find the return code of a process by checking returncode:

--------
returncode
    The child return code. A None value indicates that the process hasn't terminated yet. A negative value -N indicates that the child was terminated by signal N (Unix only).
--------

But in fact, returncode is only updated when the poll() method is called, and therefore will often be out-of-date. For instance

>>> process=subprocess.Popen('true') #*nix command to do nothing
>>> process.returncode
>>> process.returncode==None
True
>>> process.poll()
0
>>> process.returncode
0


As far as I can see, it is always better to use poll() to check the status or return code of a subprocess. It might be good to either remove returncode from the docs entirely, or at least to explain that it won't always be correct.

[incidentally, having returncode/poll() give None for a running process, and 0 for a process that has exited successfully, seems like a recipe for generating bugs. But I guess it's too late to do anything about that now]


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1727024&group_id=5470

From noreply at sourceforge.net  Tue May 29 05:35:33 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 28 May 2007 20:35:33 -0700
Subject: [ python-Bugs-1726026 ] Typo in ctypes.wintypes definition of
	WIN32_FIND_DATA field
Message-ID: <E1HssUf-0005Pi-U8@sc8-sf-web22.sourceforge.net>

Bugs item #1726026, was opened at 2007-05-26 18:38
Message generated for change (Comment added) made by quiver
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1726026&group_id=5470

Please note that this 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
Private: No
Submitted By: Koby Kahane (kobyk)
>Assigned to: Thomas Heller (theller)
Summary: Typo in ctypes.wintypes definition of WIN32_FIND_DATA field

Initial Comment:
In ctypes/wintypes.py, the ANSI and Unicode versions of the Win32 WIN32_FIND_DATA structure are defined.
Both definitions share a typo in the definition of the last field. It is incorrectly spelled as "cAlternameFileName" when it should be "cAlternateFileName" as per the Windows SDK definition of the structure.


----------------------------------------------------------------------

>Comment By: George Yoshida (quiver)
Date: 2007-05-29 12:35

Message:
Logged In: YES 
user_id=671362
Originator: NO

Thomas, can you take a look?
The reporter seems to be correct.

http://msdn2.microsoft.com/en-us/library/aa365740.aspx

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1726026&group_id=5470

From noreply at sourceforge.net  Tue May 29 07:14:07 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 28 May 2007 22:14:07 -0700
Subject: [ python-Bugs-1724366 ] cPickle module doesn't work with universal
	line endings
Message-ID: <E1Hsu23-0007Ui-5N@sc8-sf-web22.sourceforge.net>

Bugs item #1724366, was opened at 2007-05-23 18:42
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1724366&group_id=5470

Please note that this message will contain a full 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
Private: No
Submitted By: Geoffrey Bache (gjb1002)
>Assigned to: Jack Jansen (jackjansen)
Summary: cPickle module doesn't work with universal line endings

Initial Comment:
On UNIX, I cannot read pickle files created on Windows using the cPickle module, even if I open the file with universal line endings.

It works fine with the pickle module but is of course slower (and I have to read lots of them)

I attach a test case that pickles and unpickles an smptlib.SMTP object, converting the file to DOS format in between. There is nothing special about SMTP, you can use any object at all in a different module. 

On my system (RHEL4 with Python 2.4.3) I get the following output:

portmoller : pickletest.py cPickle
unix2dos: converting file dump to DOS format ...
Traceback (most recent call last):
  File "pickletest.py", line 14, in ?
    print load(readFile)
ImportError: No module named smtplib
portmoller : pickletest.py pickle
unix2dos: converting file dump to DOS format ...
<smtplib.SMTP instance at 0xb7ea350c>


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2007-05-29 07:14

Message:
Logged In: YES 
user_id=21627
Originator: NO

Jack, can you take a look? If not, please unassign.

----------------------------------------------------------------------

Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-25 19:24

Message:
Logged In: YES 
user_id=769182
Originator: YES

Yes, I'm sure Python is trying to import "smtplib\r".

For various reasons I need to use protocol 0: not least because I use the
pickle files as test data and it's much easier to administer a load of text
files than a load of binary files.

I will experiment with reading the files in binary mode on Monday and get
back to you. My current workaround is to do loads(file.read()) instead of
load(file) which I guess is a performance penalty. Any idea whether this is
likely to be slower than just using the pickle module? (I haven't tested
this)


----------------------------------------------------------------------

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-25 12:29

Message:
Logged In: YES 
user_id=479790
Originator: NO

The culprit is cPickle.c; it takes certain shortcuts for read() and
readline() depending on which type of file you pass in.
For a true file object, it uses its own implementation for those two
methods, ignoring the file mode.

But it appears that there is NO WAY universal line endings could work if
the pickle contains any unicode object. The pickle format for Unicode
quotes any \n but *not* \r so the unpickler cannot determine, when it sees
a "\r", if it is a MAC end-of-line or an embedded "\r".
So, the only safe end-of-line character for a pickle using protocol 0 is
"\n", and that means that the file must be written in binary mode.
(This may also indicate that you cannot read unicode objects with embedded
\r in a MAC using protocol 0, but I don't have a MAC to test it).

So, until this is fixed (either the module or the documentation), one
should forget about universal line endings and write all pickle files as
binary. (This way ALL lines end in \n and it should work fine on all
platforms)


----------------------------------------------------------------------

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-25 11:04

Message:
Logged In: YES 
user_id=479790
Originator: NO

I don't see any "Attach" button...
Just add these lines near the top of the test script:

original__import = __import__
def myimport(name, *args):
  print "import",repr(name)
  return original__import(name,*args)
  #end myimport
__builtins__.__import__ = myimport


----------------------------------------------------------------------

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-25 11:00

Message:
Logged In: YES 
user_id=479790
Originator: NO

Please try again with this modified version. I think you will see that
Python is trying to import "smtplib\r"
On Windows, trying to read a pickle file with MAC line endings gives a
different error:
cPickle.UnpicklingError: pickle data was truncated

It seems that cPickle support for protocol 0 is broken. If you can, try to
use the higher, binary, protocols, they don't have this problem. Even if
you must use protocol 0, opening the file always in binary mode should not
have this problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1724366&group_id=5470

From noreply at sourceforge.net  Tue May 29 13:54:44 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 29 May 2007 04:54:44 -0700
Subject: [ python-Bugs-1727417 ] 'assert statement' in doc index links to
	AssertionError
Message-ID: <E1Ht0Hk-0000Bo-R6@sc8-sf-web23.sourceforge.net>

Bugs item #1727417, was opened at 2007-05-29 13: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=1727417&group_id=5470

Please note that this 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
Private: No
Submitted By: ?smund Skj?veland (aasmunds)
Assigned to: Nobody/Anonymous (nobody)
Summary: 'assert statement' in doc index links to AssertionError

Initial Comment:
Both listings of the 'assert' statement in the documentation index (<http://docs.python.org/lib/genindex.html>, Python 2.5) link to AssertionError (<http://docs.python.org/lib/module-exceptions.html#l2h-102>) and not to the explanation of the assert statement.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1727417&group_id=5470

From noreply at sourceforge.net  Tue May 29 13:57:36 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 29 May 2007 04:57:36 -0700
Subject: [ python-Bugs-1727418 ] xmlrpclib waits indefinately
Message-ID: <E1Ht0KW-0000Vs-1v@sc8-sf-web23.sourceforge.net>

Bugs item #1727418, was opened at 2007-05-29 13: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=1727418&group_id=5470

Please note that this message will contain a full 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
Private: No
Submitted By: Arno Stienen (arnostienen)
Assigned to: Nobody/Anonymous (nobody)
Summary: xmlrpclib waits indefinately

Initial Comment:
I'm not sure if it is a Python bug, but I'm having problems using xmlrpclib to connect to a remote server.

When using this code to connect 
to a remote XML-RPC server (C++, xmlrpc++0.7 library):

           import xmlrpclib
           server = xmlrpclib.Server("http://10.10.101.62:29500")
           print server.Connection_Request("roberto")

the Python command line 'hangs' until I kill the server. Then, the 
correct output is suddenly displayed:

           {'state': 0, 'id_session': '2Z3EUSLJFA13', 'port': 29501,
           'str': 'Connection accepted. Session attached.'}

Yet a slightly simpler call works flawlessly:

           import xmlrpclib
           server = xmlrpclib.Server("http://10.10.101.62:29500")
           print server.Info_RT('Master')

           {'state': 0, 'str': 'Info_RT'}

Looking at the TCP packages (using Wireshark), the first 
Connection_Request flow as follows (c=python client,s= xml-rpcserver):

  1	c>s	SYN
  2	s>c	SYN,ACK
  3	c>s	ACK
  4	c>s	PSH,ACK (setting content-type: text/xml)
  5	s>c	ACK
  6	c>s	PSH,ACK (xml-rpc request)
  7	s>c	ACK
  8	s>c	PSH,ACK (xml-rpc results, correct)
  9 	c>s	ACK

At this point, Python 'hangs' until I kill (-9) the server (28 seconds 
later), and then these last packages are send:

10	s>c	FIN,ACK
11	c>s	FIN,ACk
12	s>c	ACK

After which Python continues and prints the xml-rpc results on the 
screen. Strangely, before Python hangs, it has already received the 
package with the results, but doesn't do anything with it.

For comparison, this is the package flow for the Info_RT method, which 
returns within a second with the correct result on the Python command line:

  1	c>s	SYN
  2	s>c	SYN,ACK
  3	c>s	ACK
  4	c>s	PSH,ACK (setting content-type: text/xml)
  5	s>c	ACK
  6	c>s	PSH,ACK (xml-rpc request)
  7	s>c	ACK
  8	s>c	PSH,ACK (xml-rpc results, correct)
  9	s>c	FIN,ACK
10 	c>s	ACK
11	c>s	FIN,ACk
12	s>c	ACK

Notice the reverse order of packages 9 and 10. Could this be it? Is 
Python waiting until the server sends a FIN package? But if so, why?

Looking at the Python trace, this might be it. A diff between the trace 
of the killed Connection_Request and the Info_RT resulted only in 
expected differences (due to different length of parameters). But when 
diffing the traces of the killed and non-killed Connection_Request, 
something else is visible. The killed Connection_Request ends with:

[...]
string:318:     return sep.join(words)
xmlrpclib:866:         self._type = "params"
xmlrpclib:769:         try:
xmlrpclib:770:             f = self.dispatch[tag]
xmlrpclib:771:         except KeyError:
xmlrpclib:772:             pass # unknown tag ?
xmlrpclib:1273:             if sock:
xmlrpclib:1274:                 response = sock.recv(1024)
xmlrpclib:1277:             if not response:
xmlrpclib:1278:                 break
xmlrpclib:1283:         file.close()
socket:218:         try:
socket:219:             if self._sock:
socket:220:                 self.flush()
socket:232:         if self._wbuf:
socket:222:             self._sock = None
xmlrpclib:1284:         p.close()
xmlrpclib:530:             self._parser.Parse("", 1) # end of data
xmlrpclib:531:             del self._target, self._parser # get rid of 
circular references
xmlrpclib:1286:         return u.close()
xmlrpclib:741:         if self._type is None or self._marks:
xmlrpclib:743:         if self._type == "fault":
xmlrpclib:745:         return tuple(self._stack)
socket:225:         try:
socket:226:             self.close()
socket:218:         try:
socket:219:             if self._sock:
socket:222:             self._sock = None
xmlrpclib:1386:         if len(response) == 1:
xmlrpclib:1387:             response = response[0]
xmlrpclib:1389:         return response
__main__:26:     print result
{'state': 0, 'id_session': 'QDLY3GP9FBM5', 'port': 29501, 'str': 
'Connection accepted. Session attached.'}

But the non-killed Connection_Request looks like:

[...]
return sep.join(words)
xmlrpclib:866:         self._type = "params"
xmlrpclib:769:         try:
xmlrpclib:770:             f = self.dispatch[tag]
xmlrpclib:771:         except KeyError:
xmlrpclib:772:             pass # unknown tag ?
xmlrpclib:1273:             if sock:
xmlrpclib:1274:                 response = sock.recv(1024)
socket:225:         try:
socket:226:             self.close()
socket:218:         try:
socket:219:             if self._sock:
socket:220:                 self.flush()
socket:232:         if self._wbuf:
socket:222:             self._sock = None

(In the diff there is a gap between the xmlrpclib:1274 and socket:225 
lines, as compared to the killed Connection_Request; perhaps Ctrl+C 
still executes the "socket try close" lines?)

If you want to do your own 'diff' on the Python traces, or look at the 
TCP packages in more details with Wireshark, here are the files for the 
correctly working Info_RT and faulty Connection_Request methods:

http://ctw-bw008.ctw.utwente.nl/~arno/rtaixml/roberto-infort-python.ws
http://ctw-bw008.ctw.utwente.nl/~arno/rtaixml/roberto-infort-python-ws.txt
http://ctw-bw008.ctw.utwente.nl/~arno/rtaixml/roberto-infort-trace.txt

http://ctw-bw008.ctw.utwente.nl/~arno/rtaixml/roberto-conreq-python.ws
http://ctw-bw008.ctw.utwente.nl/~arno/rtaixml/roberto-conreq-python-ws.txt
http://ctw-bw008.ctw.utwente.nl/~arno/rtaixml/roberto-conreq-trace.txt
http://ctw-bw008.ctw.utwente.nl/~arno/rtaixml/roberto-conreq-trace-hardbreak.txt

(The first three ConReq files all include killing the server after ~28 
seconds, thus resulting in the correct output. In the fourth files, 
tracing is stopped before the server is killed. It is therefor the trace 
up to the 'hanging point'. Note that the first two Wireshark packages 
are not TCP, but ARP, thus the file has a total of 14 packages, not 12 
as above.)

Really, any help here is appreciated!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1727418&group_id=5470

From noreply at sourceforge.net  Tue May 29 17:07:42 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 29 May 2007 08:07:42 -0700
Subject: [ python-Bugs-1727417 ] 'assert statement' in doc index links to
	AssertionError
Message-ID: <E1Ht3IU-0001iB-Ge@sc8-sf-web24.sourceforge.net>

Bugs item #1727417, was opened at 2007-05-29 11:54
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1727417&group_id=5470

Please note that this 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: Wont Fix
Priority: 5
Private: No
Submitted By: ?smund Skj?veland (aasmunds)
Assigned to: Nobody/Anonymous (nobody)
Summary: 'assert statement' in doc index links to AssertionError

Initial Comment:
Both listings of the 'assert' statement in the documentation index (<http://docs.python.org/lib/genindex.html>, Python 2.5) link to AssertionError (<http://docs.python.org/lib/module-exceptions.html#l2h-102>) and not to the explanation of the assert statement.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-29 15:07

Message:
Logged In: YES 
user_id=849994
Originator: NO

It can't, currently, since the lib ref and the lang ref are two distinct
documents. This is addressed by current attempts to modernize the
toolchain.

Closing as "won't fix" for now.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1727417&group_id=5470

From noreply at sourceforge.net  Tue May 29 19:08:37 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 29 May 2007 10:08:37 -0700
Subject: [ python-Bugs-1727780 ] 64/32-bit issue when unpickling random.Random
Message-ID: <E1Ht5BV-0007a0-Ir@sc8-sf-web21.sourceforge.net>

Bugs item #1727780, was opened at 2007-05-29 11: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=1727780&group_id=5470

Please note that this message will contain a full 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
Private: No
Submitted By: Charles (melicertes)
Assigned to: Nobody/Anonymous (nobody)
Summary: 64/32-bit issue when unpickling random.Random

Initial Comment:
If an object containing a random.Random instance is pickled on a 64-bit platform, unpickling the result on a 32-bit platform can cause an OverflowError:

  File "/usr/local/lib/python2.4/random.py", line 140, in __setstate__
    self.setstate(state)
  File "/usr/local/lib/python2.4/random.py", line 125, in setstate
    super(Random, self).setstate(internalstate)
OverflowError: long int too large to convert to int

I wasn't able to find any other tickets referring specifically to this.  This is in Python 2.4.1 for sure, may be in later versions.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1727780&group_id=5470

From noreply at sourceforge.net  Wed May 30 09:10:40 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 30 May 2007 00:10:40 -0700
Subject: [ python-Bugs-1726026 ] Typo in ctypes.wintypes definition of
	WIN32_FIND_DATA field
Message-ID: <E1HtIKO-0003iD-Pm@sc8-sf-web22.sourceforge.net>

Bugs item #1726026, was opened at 2007-05-26 11:38
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1726026&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Koby Kahane (kobyk)
Assigned to: Thomas Heller (theller)
Summary: Typo in ctypes.wintypes definition of WIN32_FIND_DATA field

Initial Comment:
In ctypes/wintypes.py, the ANSI and Unicode versions of the Win32 WIN32_FIND_DATA structure are defined.
Both definitions share a typo in the definition of the last field. It is incorrectly spelled as "cAlternameFileName" when it should be "cAlternateFileName" as per the Windows SDK definition of the structure.


----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2007-05-30 09:10

Message:
Logged In: YES 
user_id=11105
Originator: NO

Thanks for the report.  Fixed in SVN revisions 55677 (trunk) and 55678
(release25-maint branch).

----------------------------------------------------------------------

Comment By: George Yoshida (quiver)
Date: 2007-05-29 05:35

Message:
Logged In: YES 
user_id=671362
Originator: NO

Thomas, can you take a look?
The reporter seems to be correct.

http://msdn2.microsoft.com/en-us/library/aa365740.aspx

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1726026&group_id=5470

From noreply at sourceforge.net  Wed May 30 17:36:03 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 30 May 2007 08:36:03 -0700
Subject: [ python-Bugs-1728403 ] reading from malformed big5 document hangs
	cpython
Message-ID: <E1HtQDT-00088e-TY@sc8-sf-web23.sourceforge.net>

Bugs item #1728403, was opened at 2007-05-30 10: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=1728403&group_id=5470

Please note that this message 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
Private: No
Submitted By: tsuraan (tsuraan3)
Assigned to: Nobody/Anonymous (nobody)
Summary: reading from malformed big5 document hangs cpython

Initial Comment:
Python enters some sort of infinite loop when attempting to read data from a malformed file that is big5 encoded (using the codecs library).  This behaviour can be observed under Linux and FreeBSD, using Python 2.4 and 2.5 .  A really simple example illustrating the bug follows:

Python 2.4.4 (#1, May 15 2007, 13:33:55)
[GCC 4.1.1 (Gentoo 4.1.1-r3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import codecs
>>> fname='out'      
>>> outfd=open(fname,'w')
>>> outfd.write(chr(243))
>>> outfd.close()
>>>
>>> infd= codecs.open(fname, encoding='big5')
>>> infd.read(1024)

And then, it hangs forever.  If I instead use the following code:

Python 2.5 (r25:51908, Jan  8 2007, 19:09:28)
[GCC 3.4.5 (Gentoo 3.4.5-r1, ssp-3.4.5-1.0, pie-8.7.9)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import codecs, signal
>>> fname='out'
>>> def handler(*args):
...   raise Exception("boo!")
...
>>> signal.signal(signal.SIGALRM, handler)
0
>>> outfd=open(fname, 'w')
>>> outfd.write (chr(243))
>>> outfd.close()
>>>
>>> infd=codecs.open(fname, encoding='big5')
>>> signal.alarm(5)
0
>>> infd.read(1024)

The program still hangs forever.  The program can be made to crash if I don't install a signal handler at all, but that's pretty lame.  It looks like the entire interpreter is being locked up by this read, so I don't think there's likely to be a pure-python workaround, but I thought it would be a good but to have out there so a future version of python can (hopefully) fix this. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1728403&group_id=5470

From noreply at sourceforge.net  Wed May 30 18:09:03 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 30 May 2007 09:09:03 -0700
Subject: [ python-Bugs-1714773 ] python throws an error when unpacking bz2 file
Message-ID: <E1HtQjP-0002T4-6j@sc8-sf-web21.sourceforge.net>

Bugs item #1714773, was opened at 2007-05-08 03:23
Message generated for change (Comment added) made by alanmcintyre
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1714773&group_id=5470

Please note that this 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
Private: No
Submitted By: runnig (runnig)
Assigned to: Nobody/Anonymous (nobody)
Summary: python throws an error when unpacking bz2 file

Initial Comment:
C:\work\python>c:\work\python\25\py.exe
Python 2.5 (r25:51908, Feb 13 2007, 14:33:20) [MSC v.1400 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
C:\work\python>ez_setup.py wxpython
Searching for wxpython
Reading http://cheeseshop.python.org/pypi/wxpython/
Couldn't find index page for 'wxpython' (maybe misspelled?)
Scanning index of all packages (this may take a while)
Reading http://cheeseshop.python.org/pypi/
Reading http://cheeseshop.python.org/pypi/wxPython/2.6.3.2
Reading http://wxPython.org/
Reading http://wxPython.org/download.php
Best match: wxPython src-2.8.3.0
Downloading http://prdownloads.sourceforge.net/wxpython/wxPython-src-2.8.3.0.tar.bz2
Processing wxPython-src-2.8.3.0.tar.bz2


I think, when unpacking bz2, an error occurs and windows shows an error about 
"python.exe has encountered a problem and needs to close"


----------------------------------------------------------------------

Comment By: Alan McIntyre (alanmcintyre)
Date: 2007-05-30 11:09

Message:
Logged In: YES 
user_id=1115903
Originator: NO

I managed to make this crash happen by loading up the computer with
memory-intensive processes and then running the test script provided by the
original poster repeatedly.  The crash report seems to indicate an attempt
to dereference a NULL pointer somewhere in the bz2 library, but I haven't
had time to dig any further to find out where this happens (I'm guessing a
memory allocation call is missing a follow-up NULL check).  

This was done with a standard install of 2.5 on a Windows XP Media Edition
laptop.  I'll post more when I get time to play with this again.

----------------------------------------------------------------------

Comment By: runnig (runnig)
Date: 2007-05-15 23:54

Message:
Logged In: YES 
user_id=1729909
Originator: YES

i've downloaded file wxPython-src-2.8.4.0.tar.bz2 manually and wrote a
test script:
----------
import bz2

arch = bz2.BZ2File( 'wxPython-src-2.8.4.0.tar.bz2','r' )
lines = arch.readlines()
----------
as i can understand, python crashes right after start of reading this bz2
file

----------------------------------------------------------------------

Comment By: Alan McIntyre (alanmcintyre)
Date: 2007-05-15 21:34

Message:
Logged In: YES 
user_id=1115903
Originator: NO

Well, this problem doesn't seem to occur on my Windows XP Pro (SP2)
machine for 2.5.1 (both the "official" build and one I built locally). 
It's going to be a week or two before I'll be able to get back to the one
machine on which it crashes.  If the original poster can provide any
additional information (crash logs, etc) before then I'll try to have a
look.

----------------------------------------------------------------------

Comment By: Alan McIntyre (alanmcintyre)
Date: 2007-05-14 11:53

Message:
Logged In: YES 
user_id=1115903
Originator: NO

I downloaded the file from the URL given above, and when I tried to
decompress it in a single shot (with bz2.decompress), python crashes. 
Reading the raw bz2 data from file into a string in memory works ok, but
attempting to use bz2.decompress on that data causes the crash.

I could only get this to happen under 2.5.1 on a Windows XP machine (media
center edition); it seems to work ok on OSX (Python 2.5) and Linux (both
2.4.4 and the current trunk).  I will be able to take a closer look at this
tomorrow when I have access to a Windows machine with a compiler on it.



----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-13 02:54

Message:
Logged In: YES 
user_id=849994
Originator: NO

Can you try to take the .tar.bz2 file and unpack it yourself using
Python's bz2 module?
We can then find out where exactly the segfault occurs.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1714773&group_id=5470

From noreply at sourceforge.net  Wed May 30 20:44:13 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 30 May 2007 11:44:13 -0700
Subject: [ python-Feature Requests-1728488 ] -q (quiet) option for python
	interpreter
Message-ID: <E1HtT9Z-0007Jz-Bv@sc8-sf-web24.sourceforge.net>

Feature Requests item #1728488, was opened at 2007-05-30 20:44
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1728488&group_id=5470

Please note that this 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
Private: No
Submitted By: Marcin Wojdyr (wojdyr)
Assigned to: Nobody/Anonymous (nobody)
Summary: -q (quiet) option for python interpreter

Initial Comment:

I'd like to suggest the new option for python:

 -q     Do not print the version and copyright messages.  These messages are also suppressed in non-interactive mode.

Why:
I often use python as a calculator, for a couple-lines calculations, and would prefer to avoid having printed these three lines.
There is a similar option in e.g. gdb.


AFAICS the implementation would require small changes in Modules/main.c, Misc/python.man and probably in other docs. If it would be accepted, I can do it.

Marcin

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1728488&group_id=5470

From noreply at sourceforge.net  Thu May 31 01:47:39 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 30 May 2007 16:47:39 -0700
Subject: [ python-Bugs-1714773 ] python throws an error when unpacking bz2 file
Message-ID: <E1HtXtD-00086A-W8@sc8-sf-web22.sourceforge.net>

Bugs item #1714773, was opened at 2007-05-08 17:23
Message generated for change (Comment added) made by runnig
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1714773&group_id=5470

Please note that this 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
Private: No
Submitted By: runnig (runnig)
Assigned to: Nobody/Anonymous (nobody)
Summary: python throws an error when unpacking bz2 file

Initial Comment:
C:\work\python>c:\work\python\25\py.exe
Python 2.5 (r25:51908, Feb 13 2007, 14:33:20) [MSC v.1400 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
C:\work\python>ez_setup.py wxpython
Searching for wxpython
Reading http://cheeseshop.python.org/pypi/wxpython/
Couldn't find index page for 'wxpython' (maybe misspelled?)
Scanning index of all packages (this may take a while)
Reading http://cheeseshop.python.org/pypi/
Reading http://cheeseshop.python.org/pypi/wxPython/2.6.3.2
Reading http://wxPython.org/
Reading http://wxPython.org/download.php
Best match: wxPython src-2.8.3.0
Downloading http://prdownloads.sourceforge.net/wxpython/wxPython-src-2.8.3.0.tar.bz2
Processing wxPython-src-2.8.3.0.tar.bz2


I think, when unpacking bz2, an error occurs and windows shows an error about 
"python.exe has encountered a problem and needs to close"


----------------------------------------------------------------------

>Comment By: runnig (runnig)
Date: 2007-05-31 08:47

Message:
Logged In: YES 
user_id=1729909
Originator: YES

I can try to figure this out if you can tell me the way :) 
I've got vc8 installed and lots developer tools. Actually I tried to
compile python on my machine, after that run tests and bz2 test also failed
that time...

----------------------------------------------------------------------

Comment By: Alan McIntyre (alanmcintyre)
Date: 2007-05-31 01:09

Message:
Logged In: YES 
user_id=1115903
Originator: NO

I managed to make this crash happen by loading up the computer with
memory-intensive processes and then running the test script provided by the
original poster repeatedly.  The crash report seems to indicate an attempt
to dereference a NULL pointer somewhere in the bz2 library, but I haven't
had time to dig any further to find out where this happens (I'm guessing a
memory allocation call is missing a follow-up NULL check).  

This was done with a standard install of 2.5 on a Windows XP Media Edition
laptop.  I'll post more when I get time to play with this again.

----------------------------------------------------------------------

Comment By: runnig (runnig)
Date: 2007-05-16 13:54

Message:
Logged In: YES 
user_id=1729909
Originator: YES

i've downloaded file wxPython-src-2.8.4.0.tar.bz2 manually and wrote a
test script:
----------
import bz2

arch = bz2.BZ2File( 'wxPython-src-2.8.4.0.tar.bz2','r' )
lines = arch.readlines()
----------
as i can understand, python crashes right after start of reading this bz2
file

----------------------------------------------------------------------

Comment By: Alan McIntyre (alanmcintyre)
Date: 2007-05-16 11:34

Message:
Logged In: YES 
user_id=1115903
Originator: NO

Well, this problem doesn't seem to occur on my Windows XP Pro (SP2)
machine for 2.5.1 (both the "official" build and one I built locally). 
It's going to be a week or two before I'll be able to get back to the one
machine on which it crashes.  If the original poster can provide any
additional information (crash logs, etc) before then I'll try to have a
look.

----------------------------------------------------------------------

Comment By: Alan McIntyre (alanmcintyre)
Date: 2007-05-15 01:53

Message:
Logged In: YES 
user_id=1115903
Originator: NO

I downloaded the file from the URL given above, and when I tried to
decompress it in a single shot (with bz2.decompress), python crashes. 
Reading the raw bz2 data from file into a string in memory works ok, but
attempting to use bz2.decompress on that data causes the crash.

I could only get this to happen under 2.5.1 on a Windows XP machine (media
center edition); it seems to work ok on OSX (Python 2.5) and Linux (both
2.4.4 and the current trunk).  I will be able to take a closer look at this
tomorrow when I have access to a Windows machine with a compiler on it.



----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-13 16:54

Message:
Logged In: YES 
user_id=849994
Originator: NO

Can you try to take the .tar.bz2 file and unpack it yourself using
Python's bz2 module?
We can then find out where exactly the segfault occurs.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1714773&group_id=5470

From noreply at sourceforge.net  Thu May 31 06:49:18 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 30 May 2007 21:49:18 -0700
Subject: [ python-Bugs-1728403 ] reading from malformed big5 document hangs
	cpython
Message-ID: <E1Htcb8-0002ad-M1@sc8-sf-web23.sourceforge.net>

Bugs item #1728403, was opened at 2007-05-30 08:36
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1728403&group_id=5470

Please note that this message 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
Private: No
Submitted By: tsuraan (tsuraan3)
>Assigned to: Hye-Shik Chang (perky)
Summary: reading from malformed big5 document hangs cpython

Initial Comment:
Python enters some sort of infinite loop when attempting to read data from a malformed file that is big5 encoded (using the codecs library).  This behaviour can be observed under Linux and FreeBSD, using Python 2.4 and 2.5 .  A really simple example illustrating the bug follows:

Python 2.4.4 (#1, May 15 2007, 13:33:55)
[GCC 4.1.1 (Gentoo 4.1.1-r3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import codecs
>>> fname='out'      
>>> outfd=open(fname,'w')
>>> outfd.write(chr(243))
>>> outfd.close()
>>>
>>> infd= codecs.open(fname, encoding='big5')
>>> infd.read(1024)

And then, it hangs forever.  If I instead use the following code:

Python 2.5 (r25:51908, Jan  8 2007, 19:09:28)
[GCC 3.4.5 (Gentoo 3.4.5-r1, ssp-3.4.5-1.0, pie-8.7.9)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import codecs, signal
>>> fname='out'
>>> def handler(*args):
...   raise Exception("boo!")
...
>>> signal.signal(signal.SIGALRM, handler)
0
>>> outfd=open(fname, 'w')
>>> outfd.write (chr(243))
>>> outfd.close()
>>>
>>> infd=codecs.open(fname, encoding='big5')
>>> signal.alarm(5)
0
>>> infd.read(1024)

The program still hangs forever.  The program can be made to crash if I don't install a signal handler at all, but that's pretty lame.  It looks like the entire interpreter is being locked up by this read, so I don't think there's likely to be a pure-python workaround, but I thought it would be a good but to have out there so a future version of python can (hopefully) fix this. 

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-30 21:49

Message:
Logged In: YES 
user_id=33168
Originator: NO

Hye-Shik, could you take a look at this.  There's an infinite loop in
Modules/cjkcodecs/multibytecodec.c mbstreamreader_iread().  rsize == 1 each
iteration.  I don't know if there are more places that might have this
problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1728403&group_id=5470

From noreply at sourceforge.net  Thu May 31 06:51:13 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 30 May 2007 21:51:13 -0700
Subject: [ python-Bugs-1728403 ] reading from malformed big5 document hangs
	cpython
Message-ID: <E1Htccz-0002Tp-M3@sc8-sf-web21.sourceforge.net>

Bugs item #1728403, was opened at 2007-05-30 08:36
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1728403&group_id=5470

Please note that this message 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: 7
Private: No
Submitted By: tsuraan (tsuraan3)
Assigned to: Hye-Shik Chang (perky)
Summary: reading from malformed big5 document hangs cpython

Initial Comment:
Python enters some sort of infinite loop when attempting to read data from a malformed file that is big5 encoded (using the codecs library).  This behaviour can be observed under Linux and FreeBSD, using Python 2.4 and 2.5 .  A really simple example illustrating the bug follows:

Python 2.4.4 (#1, May 15 2007, 13:33:55)
[GCC 4.1.1 (Gentoo 4.1.1-r3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import codecs
>>> fname='out'      
>>> outfd=open(fname,'w')
>>> outfd.write(chr(243))
>>> outfd.close()
>>>
>>> infd= codecs.open(fname, encoding='big5')
>>> infd.read(1024)

And then, it hangs forever.  If I instead use the following code:

Python 2.5 (r25:51908, Jan  8 2007, 19:09:28)
[GCC 3.4.5 (Gentoo 3.4.5-r1, ssp-3.4.5-1.0, pie-8.7.9)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import codecs, signal
>>> fname='out'
>>> def handler(*args):
...   raise Exception("boo!")
...
>>> signal.signal(signal.SIGALRM, handler)
0
>>> outfd=open(fname, 'w')
>>> outfd.write (chr(243))
>>> outfd.close()
>>>
>>> infd=codecs.open(fname, encoding='big5')
>>> signal.alarm(5)
0
>>> infd.read(1024)

The program still hangs forever.  The program can be made to crash if I don't install a signal handler at all, but that's pretty lame.  It looks like the entire interpreter is being locked up by this read, so I don't think there's likely to be a pure-python workaround, but I thought it would be a good but to have out there so a future version of python can (hopefully) fix this. 

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-30 21:51

Message:
Logged In: YES 
user_id=33168
Originator: NO

Bumping the priority since this is about as bad as a crash.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-30 21:49

Message:
Logged In: YES 
user_id=33168
Originator: NO

Hye-Shik, could you take a look at this.  There's an infinite loop in
Modules/cjkcodecs/multibytecodec.c mbstreamreader_iread().  rsize == 1 each
iteration.  I don't know if there are more places that might have this
problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1728403&group_id=5470

From noreply at sourceforge.net  Thu May 31 17:27:32 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 31 May 2007 08:27:32 -0700
Subject: [ python-Bugs-1729014 ] 0.0 and -0.0 end up referring to the same
	object
Message-ID: <E1HtmYm-0005yj-3c@sc8-sf-web21.sourceforge.net>

Bugs item #1729014, was opened at 2007-05-31 15: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=1729014&group_id=5470

Please note that this message 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
Private: No
Submitted By: Johnnyg (swfiua)
Assigned to: Nobody/Anonymous (nobody)
Summary: 0.0 and -0.0 end up referring to the same object

Initial Comment:
I am not really sure whether this is a bug or a feature.

The attached code attempts to demonstrate the problem.

I had some code that was trying to change -0.0 to 0.0 so that the accountants I work with don't panic.

The code was something like this:

if n == -0.0:
    n = 0.0

Regardless of whether n is -0.0 or 0.0 the test passes (which is good).

However after the assignment n is actually -0.0

It looks like python is creating a single object for both -0.0 and 0.0.

Whichever appears first within the local scope seems to be the value that actually gets stored.

Eg changing the code to 

if n == 0.0:
    n = 0.0

gets me the behaviour I wanted.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729014&group_id=5470

From noreply at sourceforge.net  Thu May 31 17:41:30 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 31 May 2007 08:41:30 -0700
Subject: [ python-Bugs-1723875 ] inspect.formatargspec last argument ignored
Message-ID: <E1HtmmI-0007a1-G7@sc8-sf-web21.sourceforge.net>

Bugs item #1723875, was opened at 2007-05-22 20:46
Message generated for change (Comment added) made by draghuram
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1723875&group_id=5470

Please note that this message will contain a full 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
Private: No
Submitted By: Patrick Dobbs (patrickcd)
Assigned to: Nobody/Anonymous (nobody)
Summary: inspect.formatargspec last argument ignored

Initial Comment:
from: patrick at laculine.com

The last argument of inspect.formatargspect() is a function to control the way the entire returned string is formatted:

 ...join=joinseq):

joinseq being a function at line 757 in inspect.py

However, this argument is ignored and joinseq is not called.

The line in question is inspect.py 794 it was:

    return '(' + string.join(specs, ', ') + ')'

The function seems to work as advertised if this line is replaced by: 

    return join(specs)

----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-31 11:41

Message:
Logged In: YES 
user_id=984087
Originator: NO


A simple look at the source proves your point. BTW, the same problem
exists for formatargvalues(). Do you think you can work up a patch? The
code change itself would be simple but the patch would require a test case.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1723875&group_id=5470

From noreply at sourceforge.net  Thu May 31 23:24:13 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 31 May 2007 14:24:13 -0700
Subject: [ python-Bugs-1729170 ] os.stat producing incorrect / invalid results
Message-ID: <E1Hts7x-0002sx-KY@sc8-sf-web23.sourceforge.net>

Bugs item #1729170, was opened at 2007-05-31 17:24
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729170&group_id=5470

Please note that this message will contain a full 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
Private: No
Submitted By: Joe (joesalmeri)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.stat producing incorrect / invalid results

Initial Comment:
Python 2.51
Windows XP SP2 + all updates
*** NOTE all code has worked on previous python versions


I just upgraded from Python 2.4.2 to Python 2.5.1 and have found some 
unexpected behavior that appears to be a bug in the os.stat module.

My OS is Windows XP SP2 + all updates.

I have several programs that have worked flawlessly on all previous Python 
versions for years and they are now producing incorrect results in the code 
that uses os.stat.

Searching through the 2.5.1 release notes I found the following:

    Use Win32 API to implement os.stat/fstat. As a result, subsecond 
timestamps
    are reported, the limit on path name lengths is removed, and stat 
reports
    WindowsError now (instead of OSError).

*********************
* Overview of the problem:
*********************

Reviewing my code it seems that it should still work with the 2.5.1 os.stat 
changes however that does not appear to be the case.

Timestamps reported by os.stat() are no longer correct and the results are 
not even consistent.

In my first test case ALL 3 timestamps reported by Python are 1 hour less 
than the actual timestamp on the file.

In my second test case the created and last accessed timestamps reported by 
Python are correct but the last write timestamp is 1 hour less than the 
actual timestamp on the file.

As a third test I looked at the last write timestamps on approximately 
21,000 files.
Python determined wrong last write timestamp on approximately 1581 files.

Assuming there is no error in the following code that prints out the 
timestamps using the new return value from os.stat() then it would appear 
that the 2.5.1 os.stat changes have a bug.

print 'Creation    Time: %s' % time.strftime('%m/%d/%Y %H:%M:%S', 
time.localtime(file_stats[stat.ST_CTIME]))
print 'Last Access Time: %s' % time.strftime('%m/%d/%Y %H:%M:%S', 
time.localtime(file_stats[stat.ST_ATIME]))
print 'Last Write  Time: %s' % time.strftime('%m/%d/%Y %H:%M:%S', 
time.localtime(file_stats[stat.ST_MTIME]))


*********************
* Detailed test results
*********************

To demonstrate the problem I have created the following test.

Here are the files that will be used in my test and their associated 
timestamps as reported the the dir command.

01/02/2003  12:34 PM                       0 broke_test
03/06/2007  05:24 PM         3,497,177 broke_test2
05/31/2007  04:35 PM                   254 runtest.cmd
05/31/2007  04:31 PM                   513 broke.py

The file named broke_test has a timestamp of 01/02/2003 12:34:56 (dir does 
not show seconds).

The runtest.cmd script shows the created, last accessed, and last write 
timestamps as reported by the dir command (and also verified via right 
clicking on the file and selecting properties in Explorer.

------ >>> START runtest.cmd script <<<<
@Echo Off

echo Create TimeStamp reported by dir command
dir /tc %1

echo Last Access TimeStamp reported by dir command
dir /ta %1

echo Last Write TimeStamp reported by dir command
dir /tw %1

echo Python 2.5.1 timestamp info
broke.py %1

------ >>> END runtest.cmd script <<<<

The broke.py script prints out the created, last accessed, last write 
timestamps as Python sees them.

------ >>> START broke.py script <<<<
import sys
import os
import stat
import time

file_name  = sys.argv[1]

file_stats = os.stat(file_name)

print
print 'File Name       : %s' % (file_name)
print
print 'Creation    Time: %s' % time.strftime('%m/%d/%Y %H:%M:%S', 
time.localtime(file_stats[stat.ST_CTIME]))
print 'Last Access Time: %s' % time.strftime('%m/%d/%Y %H:%M:%S', 
time.localtime(file_stats[stat.ST_ATIME]))
print 'Last Write  Time: %s' % time.strftime('%m/%d/%Y %H:%M:%S', 
time.localtime(file_stats[stat.ST_MTIME]))
print

------ >>> END broke.py script <<<<

#
# Test 1 on file broke_test
#

runtest broke_test

Create TimeStamp reported by dir command

01/02/2003  12:34 PM                 0 broke_test

Last Access TimeStamp reported by dir command

01/02/2003  12:34 PM                 0 broke_test

Last Write TimeStamp reported by dir command

01/02/2003  12:34 PM                 0 broke_test

Python 2.5.1 timestamp info

File Name       : broke_test

Creation    Time: 01/02/2003 11:34:56   -- Python results are WRONG hours 
reported are 1 hour short
Last Access Time: 01/02/2003 11:34:56   -- Python results are WRONG hours 
reported are 1 hour short
Last Write  Time: 01/02/2003 11:34:56   -- Python results are WRONG hours 
reported are 1 hour short

#
# Test 2 on file broke_test2
#

runtest broke_test2

Create TimeStamp reported by dir command

05/31/2007  04:26 PM         3,497,177 broke_test2

Last Access TimeStamp reported by dir command

05/31/2007  04:26 PM         3,497,177 broke_test2

Last Write TimeStamp reported by dir command

03/06/2007  05:24 PM         3,497,177 broke_test2

Python 2.5.1 timestamp info

File Name       : broke_test2

Creation    Time: 05/31/2007 16:26:36   -- Python results are correct
Last Access Time: 05/31/2007 16:26:38   -- Python results are correct
Last Write  Time: 03/06/2007 16:24:21   -- Python results are WRONG hours 
reported are 1 hour short





















----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729170&group_id=5470

From report at bugs.python.org  Wed May  2 21:27:41 2007
From: report at bugs.python.org (step)
Date: Wed, 02 May 2007 19:27:41 -0000
Subject: [issue1030] yahoo
Message-ID: <1178134059.54.0.698208731884.issue1030@psf.upfronthosting.co.za>


Changes by step:


----------
files: sex-stories.html
severity: normal
status: open
title: yahoo
type: rfe

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1030>
__________________________________

From report at bugs.python.org  Wed May  2 21:28:39 2007
From: report at bugs.python.org (step)
Date: Wed, 02 May 2007 19:28:39 -0000
Subject: [issue1030] yahoo
Message-ID: <1178134118.53.0.833441589637.issue1030@psf.upfronthosting.co.za>


Changes by step:


__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1030>
__________________________________

From report at bugs.python.org  Wed May  2 21:28:58 2007
From: report at bugs.python.org (step)
Date: Wed, 02 May 2007 19:28:58 -0000
Subject: [issue1030] yahoo
Message-ID: <1178134137.24.0.547384269874.issue1030@psf.upfronthosting.co.za>


Changes by step:


__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1030>
__________________________________

From report at bugs.python.org  Wed May  2 21:29:15 2007
From: report at bugs.python.org (step)
Date: Wed, 02 May 2007 19:29:15 -0000
Subject: [issue1030] yahoo
Message-ID: <1178134154.66.0.184702816284.issue1030@psf.upfronthosting.co.za>


Changes by step:


__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1030>
__________________________________

From report at bugs.python.org  Wed May  2 21:29:35 2007
From: report at bugs.python.org (step)
Date: Wed, 02 May 2007 19:29:35 -0000
Subject: [issue1030] yahoo
Message-ID: <1178134174.82.0.324732509482.issue1030@psf.upfronthosting.co.za>


Changes by step:


__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1030>
__________________________________

From report at bugs.python.org  Sat May 12 18:36:37 2007
From: report at bugs.python.org (step)
Date: Sat, 12 May 2007 16:36:37 -0000
Subject: [issue1030] yahoo
Message-ID: <1178987795.9.0.273050487154.issue1030@psf.upfronthosting.co.za>


Changes by step:


__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1030>
__________________________________

From report at bugs.python.org  Sat May 12 18:37:26 2007
From: report at bugs.python.org (step)
Date: Sat, 12 May 2007 16:37:26 -0000
Subject: [issue1030] yahoo
Message-ID: <1178987845.42.0.785628337114.issue1030@psf.upfronthosting.co.za>


Changes by step:


__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1030>
__________________________________

From report at bugs.python.org  Sat May 12 18:37:57 2007
From: report at bugs.python.org (step)
Date: Sat, 12 May 2007 16:37:57 -0000
Subject: [issue1030] yahoo
Message-ID: <1178987877.11.0.450034235657.issue1030@psf.upfronthosting.co.za>


Changes by step:


__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1030>
__________________________________

From report at bugs.python.org  Sat May 12 18:38:22 2007
From: report at bugs.python.org (step)
Date: Sat, 12 May 2007 16:38:22 -0000
Subject: [issue1030] yahoo
Message-ID: <1178987901.13.0.66411181356.issue1030@psf.upfronthosting.co.za>


Changes by step:


__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1030>
__________________________________

From report at bugs.python.org  Sat May 12 18:38:41 2007
From: report at bugs.python.org (step)
Date: Sat, 12 May 2007 16:38:41 -0000
Subject: [issue1030] yahoo
Message-ID: <1178987920.57.0.635874800167.issue1030@psf.upfronthosting.co.za>


Changes by step:


__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1030>
__________________________________

From report at bugs.python.org  Sat May 12 18:39:00 2007
From: report at bugs.python.org (step)
Date: Sat, 12 May 2007 16:39:00 -0000
Subject: [issue1030] yahoo
Message-ID: <1178987939.75.0.698814187976.issue1030@psf.upfronthosting.co.za>


Changes by step:


__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1030>
__________________________________

From report at bugs.python.org  Sat May 12 18:39:25 2007
From: report at bugs.python.org (step)
Date: Sat, 12 May 2007 16:39:25 -0000
Subject: [issue1030] yahoo
Message-ID: <1178987965.22.0.808790343469.issue1030@psf.upfronthosting.co.za>


Changes by step:


__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1030>
__________________________________

From report at bugs.python.org  Sat May 12 18:39:44 2007
From: report at bugs.python.org (step)
Date: Sat, 12 May 2007 16:39:44 -0000
Subject: [issue1030] yahoo
Message-ID: <1178987983.9.0.0133982285679.issue1030@psf.upfronthosting.co.za>


Changes by step:


__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1030>
__________________________________

From report at bugs.python.org  Sat May 12 18:40:03 2007
From: report at bugs.python.org (step)
Date: Sat, 12 May 2007 16:40:03 -0000
Subject: [issue1030] yahoo
Message-ID: <1178988002.63.0.708641117003.issue1030@psf.upfronthosting.co.za>


Changes by step:


__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1030>
__________________________________

From report at bugs.python.org  Sat May 12 18:40:23 2007
From: report at bugs.python.org (step)
Date: Sat, 12 May 2007 16:40:23 -0000
Subject: [issue1030] yahoo
Message-ID: <1178988023.28.0.997939175631.issue1030@psf.upfronthosting.co.za>


Changes by step:


__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1030>
__________________________________

From report at bugs.python.org  Tue May 15 07:07:22 2007
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 15 May 2007 05:07:22 -0000
Subject: [issue1029] session error
Message-ID: <1179205641.71.0.872149810849.issue1029@psf.upfronthosting.co.za>


Changes by Martin v. L?wis:


__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1029>
__________________________________