From report at bugs.python.org  Wed Jul  1 00:05:26 2009
From: report at bugs.python.org (Pablo Torres Navarrete)
Date: Tue, 30 Jun 2009 22:05:26 +0000
Subject: [issue5801] spurious empty lines in wsgiref code
In-Reply-To: <1240243437.89.0.00300959182441.issue5801@psf.upfronthosting.co.za>
Message-ID: <1246399526.99.0.439214262807.issue5801@psf.upfronthosting.co.za>


Pablo Torres Navarrete <tn.pablo at gmail.com> added the comment:

Oops, forgot to add the .diff extension so web browsers don't get
confused.  Their contents are the same though.

----------
keywords: +patch
Added file: http://bugs.python.org/file14411/wsgiref-patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5801>
_______________________________________

From report at bugs.python.org  Wed Jul  1 00:39:46 2009
From: report at bugs.python.org (Vernon Cole)
Date: Tue, 30 Jun 2009 22:39:46 +0000
Subject: [issue1571184] Generate numeric/space/linebreak from Unicode database.
Message-ID: <1246401586.07.0.164736877971.issue1571184@psf.upfronthosting.co.za>


Vernon Cole <vernondcole at gmail.com> added the comment:

Adding Python 2.6 to the list of affected versions - as that is where I
found the bug reported in issue 6383 (now superseded by this one.)

----------
nosy: +vernondcole
versions: +Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1571184>
_______________________________________

From report at bugs.python.org  Wed Jul  1 00:59:50 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 30 Jun 2009 22:59:50 +0000
Subject: [issue6391] Incorrect description of unittest.TestCase.run
In-Reply-To: <1246390989.67.0.115182745273.issue6391@psf.upfronthosting.co.za>
Message-ID: <1246402790.47.0.344501345977.issue6391@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed in r73712.
I left "result object" because the object can also be a subclass of
TestResult. I also changed the last part to clarify that the result
object is never returned to the caller, even when it's passed to run().

Thanks!

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6391>
_______________________________________

From report at bugs.python.org  Wed Jul  1 01:01:22 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 30 Jun 2009 23:01:22 +0000
Subject: [issue1571184] Generate numeric/space/linebreak from Unicode database.
Message-ID: <1246402882.97.0.781700303323.issue1571184@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1571184>
_______________________________________

From report at bugs.python.org  Wed Jul  1 01:06:00 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 30 Jun 2009 23:06:00 +0000
Subject: [issue6312] httplib fails with HEAD requests to pages with
	"transfer-encoding: chunked"
In-Reply-To: <1245419610.47.0.800823464354.issue6312@psf.upfronthosting.co.za>
Message-ID: <1246403160.54.0.718722831089.issue6312@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6312>
_______________________________________

From report at bugs.python.org  Wed Jul  1 01:21:11 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 30 Jun 2009 23:21:11 +0000
Subject: [issue5388] Green-box doc glitch: winhelp version only
In-Reply-To: <1235763954.97.0.134032530958.issue5388@psf.upfronthosting.co.za>
Message-ID: <1246404071.94.0.783189877813.issue5388@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This is what I see here (see attached image). The only scrollbar is the
one at the bottom for the whole page. The file is under Start ->
Programs -> Python 3.1 -> Python Manuals, and the path/file is
C:\Programs\Python31\Doc\python31.chm (you can see it right-clicking on
it from start menu and selecting properties).

I'm using WinXP SP2, the versions of the HTML Help Components are:
HHCTRL.OCX 5.02.3790.2453
ITSS.DLL   5.02.3790.2453
ITIRCL.DLL 5.02.3790.2453
HHA.DLL    4.74.8702.0

Compiled with HHA Version 4.74.8702

You can find this information right-clicking on WinHelp in the
application bar (or on the small icon on the left of the title bar) and
then on "Version...". Maybe you are running an older (or newer) version
of WinHelp.

Tomorrow I'll check with some other Windows.

----------
Added file: http://bugs.python.org/file14412/py31doc.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5388>
_______________________________________

From report at bugs.python.org  Wed Jul  1 01:52:52 2009
From: report at bugs.python.org (Adam Olsen)
Date: Tue, 30 Jun 2009 23:52:52 +0000
Subject: [issue6326] Add a "swap" method to list
In-Reply-To: <1245762769.52.0.940605508616.issue6326@psf.upfronthosting.co.za>
Message-ID: <1246405972.14.0.0410717225573.issue6326@psf.upfronthosting.co.za>


Adam Olsen <rhamph at gmail.com> added the comment:

Fix it at its source: patch your database engine to use the type you
want.  Or wrap the list without subclassing (__iter__ may be the only
method you need to wrap).

Obscure performance hacks don't warrant language extensions.

----------
nosy: +Rhamphoryncus

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6326>
_______________________________________

From report at bugs.python.org  Wed Jul  1 02:03:24 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 01 Jul 2009 00:03:24 +0000
Subject: [issue6326] Add a "swap" method to list
In-Reply-To: <1245762769.52.0.940605508616.issue6326@psf.upfronthosting.co.za>
Message-ID: <1246406604.82.0.671687610096.issue6326@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

fyi, here is the thread from python-ideas:

http://mail.python.org/pipermail/python-ideas/2009-June/005042.html

The parallel to C++?s future "rvalue reference" is interesting 
(http://www.artima.com/cppsource/rvalue.html, see the "move" 
application) 

Especially, perhaps, in light of this quote from http://evanjones.ca/rvalue-references.html, criticising the concept:

"...Or add a swap member function. This is not "elegant" nor is it as 
general. However, this is what we've been using for decades. It also 
requires zero changes to C++ compilers, and requires users to learn 
nothing. It has been immortalized in books like Effective C++ (Item 25: 
Consider support for a non-throwing swap)."

This, incidentally, is where the name 'swap' comes from, me being an old 
C++ programmer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6326>
_______________________________________

From report at bugs.python.org  Wed Jul  1 02:03:32 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 01 Jul 2009 00:03:32 +0000
Subject: [issue1571184] Generate numeric/space/linebreak from Unicode database.
Message-ID: <1246406612.38.0.0754513900135.issue1571184@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Here is a refreshed version of the patch, without the generated files.
The patch combines several changes which are fairly independent from 
each other:

- Using the unicode database to generate the functions adds 143 new 
codepoints to PyUnicode_ToNumeric, and one codepoint to 
PyUnicode_IsWhitespace.

- In addition, PyUnicode_ToNumeric now contains code for all numerics; 
previously those which are also digits fell in the 'default:' case and 
were converted with PyUnicode_ToDigit(). This adds 468 new codepoints, 
but removes the need to call PyUnicode_ToDigit()

- The Unihan.txt files (two files to download, 25Mb each) are now 
parsed, and this adds 73 more codepoints to PyUnicode_ToNumeric. (There 
are now 1009 entries in this function.)
The 3.2.0 version of this file contains two huge numbers: 1e16 and 1e20, 
I had to widen the type of 'change_record.numeric_changed' from 'int' to 
'double'.  It is possible that these were removed from the Unicode 
database between versions 4.1 and 5.1.

- the database has a new flag, NUMERIC_MASK, used by 
PyUnicode_IsNumeric.  This adds ~350 lines in the arrays of numbers in 
unicodetype_db.h

If this patch is accepted, the md5 checksum in test_unicodedata.py will 
need to change.

----------
nosy: +amaury.forgeotdarc
Added file: http://bugs.python.org/file14413/unicodedata-2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1571184>
_______________________________________

From report at bugs.python.org  Wed Jul  1 02:43:58 2009
From: report at bugs.python.org (Greg Ward)
Date: Wed, 01 Jul 2009 00:43:58 +0000
Subject: [issue5555] optparse
In-Reply-To: <1237917675.54.0.817122476849.issue5555@psf.upfronthosting.co.za>
Message-ID: <1246409038.75.0.520763745593.issue5555@psf.upfronthosting.co.za>


Greg Ward <greg at gerg.ca> added the comment:

> This is an edited-down excerpt form the optparse documentation from:
> 
> http://docs.python.org/library/optparse.html
> 
> "... the traditional Unix syntax is a hyphen (?-?) followed by a 
> single letter [...] Some other option syntaxes that the world has seen
include:
>    * a hyphen followed by a few letters, e.g. "-pf" [...]

Note that the second "[...]" expands to "(this is *not* the same as
multiple options merged into a single argument)".  Which means:

1) optparse *does* implement the traditional Unix option-munging that
has been around since at least the mid-1980s
2) the proposed statement "optparse has chosen to implement a subset of
the GNU coding standard's command line interface guidelines, allowing
for both long and short options, but not the POSIX-style concatenation
of short options." is false

Offhand, I don't see a way for the documentation to be any clearer. 
Maybe an example of "-a" and "-b" munged to "-ab"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5555>
_______________________________________

From report at bugs.python.org  Wed Jul  1 02:44:53 2009
From: report at bugs.python.org (Greg Ward)
Date: Wed, 01 Jul 2009 00:44:53 +0000
Subject: [issue5555] optparse: clarify option concatenation in docs
In-Reply-To: <1237917675.54.0.817122476849.issue5555@psf.upfronthosting.co.za>
Message-ID: <1246409093.22.0.898909382263.issue5555@psf.upfronthosting.co.za>


Changes by Greg Ward <greg at gerg.ca>:


----------
title: optparse -> optparse: clarify option concatenation in docs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5555>
_______________________________________

From report at bugs.python.org  Wed Jul  1 02:58:57 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 01 Jul 2009 00:58:57 +0000
Subject: [issue5388] Green-box doc glitch: winhelp version only
In-Reply-To: <1235763954.97.0.134032530958.issue5388@psf.upfronthosting.co.za>
Message-ID: <1246409937.19.0.911171023031.issue5388@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Same path to python31.chm.
I presume color difference is due to difference selections in
Display Properties / Appearance tab.

When I left- or right-click on upper-left icon as depicted in screen
capture, choices are move, resize, ...., close, About HTML Help. No
Versions. Result of selecting last is popup window

About Microsoft HTML Help. 
Html Help Control Version 5.2.3790.4110
Copyright blah blah

Ditto for right-click on entry in task bar as bottom of screen.

Other programs use the same control.

We are obviously running different 'help' programs. WinHelp versus HTML
Help? I wonder if it has anything to do with vendor customization. My XP
Home is from HP. However, wife's machine from Dell with XP Pro uses the
same version of same control for help with various programs also.

My machine does have winhelp.exe (with pure ? icon instead of ? and
page) and winhelp32.exe (with ? on book cover icon), but they are not
listed in programs / accessories. Latter does not recognize python31.chm
as a help file. The former looks for .hlp files.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5388>
_______________________________________

From report at bugs.python.org  Wed Jul  1 05:56:12 2009
From: report at bugs.python.org (Matt)
Date: Wed, 01 Jul 2009 03:56:12 +0000
Subject: [issue6392] IDLE 3.1 will not open
In-Reply-To: <1246420572.02.0.605221544968.issue6392@psf.upfronthosting.co.za>
Message-ID: <1246420572.02.0.605221544968.issue6392@psf.upfronthosting.co.za>


New submission from Matt <matthall.oxford at gmail.com>:

IDLE will not open; it does not give an error or even appear on the 
process list.

I am using Windows XP on an IBM Thinkpad. I tried the prescribed 
solution on Issue 4049, and it returned this message:

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\Matt>cd \python31

C:\Python31>python.exe Lib\idlelib\idle.py
Traceback (most recent call last):
  File "Lib\idlelib\idle.py", line 11, in <module>
    idlelib.PyShell.main()
  File "C:\Python31\Lib\idlelib\PyShell.py", line 1374, in main
    root = Tk(className="Idle")
  File "C:\Python31\Lib\tkinter\__init__.py", line 1632, in __init__
    self.tk = _tkinter.create(screenName, baseName, className, 
interactive, want
objects, useTk, sync, use)
_tkinter.TclError: Can't find a usable init.tcl in the following 
directories:
    {C:\IBMTOOLS\Python22\tcl\tcl8.4} C:/IBMTOOLS/Python22/tcl/tcl8.5 
C:/Python3
1/lib/tcl8.5 C:/lib/tcl8.5 C:/lib/tcl8.5 C:/library C:/library 
C:/tcl8.5.2/libra
ry C:/tcl8.5.2/library

C:/IBMTOOLS/Python22/tcl/tcl8.4/init.tcl: version conflict for 
package "Tcl": ha
ve 8.5.2, need exactly 8.4
version conflict for package "Tcl": have 8.5.2, need exactly 8.4
    while executing
"package require -exact Tcl 8.4"
    (file "C:/IBMTOOLS/Python22/tcl/tcl8.4/init.tcl" line 19)
    invoked from within
"source C:/IBMTOOLS/Python22/tcl/tcl8.4/init.tcl"
    ("uplevel" body line 1)
    invoked from within
"uplevel #0 [list source $tclfile]"


This probably means that Tcl wasn't installed properly.


C:\Python31>

I am very new to Python (and programming in general), and I have no 
idea how to fix this.

By the way, I did install the program for all users.

----------
components: IDLE
messages: 89962
nosy: matthall
severity: normal
status: open
title: IDLE 3.1 will not open
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6392>
_______________________________________

From report at bugs.python.org  Wed Jul  1 17:57:14 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 01 Jul 2009 15:57:14 +0000
Subject: [issue5415] uuid module generates incorrect values for uuid3 (and
	possibly uuid5)
In-Reply-To: <1236151740.35.0.183499583743.issue5415@psf.upfronthosting.co.za>
Message-ID: <1246463834.38.0.440484606559.issue5415@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I also found several threads saying that the RFC is wrong;
the current uuid.py module returns the correct result.

----------
nosy: +amaury.forgeotdarc
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5415>
_______________________________________

From report at bugs.python.org  Wed Jul  1 16:00:43 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 01 Jul 2009 14:00:43 +0000
Subject: [issue1303673] traceback on trying to load a hotshot stats file
Message-ID: <1246456843.97.0.943871314355.issue1303673@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

It was indeed fixed with 2.4.2, but this does not correct the invalid
statistics generated with 2.4.1.
Running hotshotmain.py with a newer version should generate a correct file.

----------
dependencies:  -hotshot.stats.load fails with AssertionError
nosy: +amaury.forgeotdarc
resolution:  -> duplicate
superseder:  -> hotshot.stats.load fails with AssertionError

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1303673>
_______________________________________

From report at bugs.python.org  Wed Jul  1 17:42:05 2009
From: report at bugs.python.org (Jon Anglin)
Date: Wed, 01 Jul 2009 15:42:05 +0000
Subject: [issue6394] getppid support in os module on Windows
In-Reply-To: <1246461114.22.0.192646662001.issue6394@psf.upfronthosting.co.za>
Message-ID: <015901c9fa62$79d10410$6d730c30$@com>


Jon Anglin <janglin at fortresgrand.com> added the comment:

I didn't raise an exception because the Unix version never fails (or raises) so I thought to maintain compatibility I would always return a value.  Do you advise that I should change it?

As for the tabs...  This entire process is new to me and I am learning, it was just a mistake.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6394>
_______________________________________

From report at bugs.python.org  Wed Jul  1 17:04:20 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 01 Jul 2009 15:04:20 +0000
Subject: [issue6369] binhex buggy in py3k
In-Reply-To: <1246286179.9.0.0098379045157.issue6369@psf.upfronthosting.co.za>
Message-ID: <1246460660.74.0.415832552024.issue6369@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixed in r73747 and r73748.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6369>
_______________________________________

From report at bugs.python.org  Wed Jul  1 17:08:10 2009
From: report at bugs.python.org (Jon Anglin)
Date: Wed, 01 Jul 2009 15:08:10 +0000
Subject: [issue6394] getppid support in os module on Windows
In-Reply-To: <1246460889.83.0.840180185924.issue6394@psf.upfronthosting.co.za>
Message-ID: <1246460889.83.0.840180185924.issue6394@psf.upfronthosting.co.za>


New submission from Jon Anglin <janglin at fortresgrand.com>:

Implements getppid in the os module on Windows systems. The getppid 
function was only available on Unix like systems, this diff patch brings 
this functionality to Windows systems.  This function will return the 
parent process Id, upon error it will return -1.  This differs from the 
Unix implementation that never fails.  Due to the way Windows returns the 
parent process Id, a never fail guarantee can not be made.  It should only 
fail in low memory conditions.  This patch is on the latest svn trunk (	
http://svn.python.org/projects/python/trunk).  This implementation should 
port to any python version (older or newer).  I have personally tested it 
against Python 2.5.4, 2.6.2, 3.1, and the aforementioned svn trunk.

----------
components: Library (Lib)
files: mydiffs.diff
keywords: patch
messages: 89981
nosy: janglin
severity: normal
status: open
title: getppid support in os module on Windows
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file14419/mydiffs.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6394>
_______________________________________

From report at bugs.python.org  Wed Jul  1 17:08:11 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 01 Jul 2009 15:08:11 +0000
Subject: [issue6326] Add a "swap" method to list
In-Reply-To: <1245762769.52.0.940605508616.issue6326@psf.upfronthosting.co.za>
Message-ID: <1246460891.5.0.627674640182.issue6326@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Even if C++ decides it's an useful feature, it's not a sufficient reason
to add it to Python!
Based on previous discussion and the converging advice of others, this
bug can IMO be closed.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6326>
_______________________________________

From report at bugs.python.org  Wed Jul  1 18:02:16 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 01 Jul 2009 16:02:16 +0000
Subject: [issue6395] Add Pickle Support to the codecs Module
In-Reply-To: <1246463188.35.0.320675118154.issue6395@psf.upfronthosting.co.za>
Message-ID: <1246464136.64.0.200157318146.issue6395@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
type: crash -> feature request
versions: +Python 2.7, Python 3.2 -Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6395>
_______________________________________

From report at bugs.python.org  Wed Jul  1 18:14:07 2009
From: report at bugs.python.org (Mahmoud)
Date: Wed, 01 Jul 2009 16:14:07 +0000
Subject: [issue6396] No conversion specifier in the string,
	no __getitem__ method in the right hand value
In-Reply-To: <1246464847.52.0.736883285817.issue6396@psf.upfronthosting.co.za>
Message-ID: <1246464847.52.0.736883285817.issue6396@psf.upfronthosting.co.za>


New submission from Mahmoud <saghaei at med.mui.ac.ir>:

When using a class instance as a mapping for the right hand value in a
sting format expression without conversion specifier, it seems logical
that the class has a __getitem__ method. Therefore following format
expression should raise an exception.

>>> class AClass(object):
...   pass
... 
>>> c = AClass()
>>> "a string with no conversion specifier" % c
'a string with no conversion specifier'

----------
messages: 89987
nosy: msaghaei
severity: normal
status: open
title: No conversion specifier in the string, no __getitem__ method in the right hand value
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6396>
_______________________________________

From report at bugs.python.org  Wed Jul  1 17:46:28 2009
From: report at bugs.python.org (ThomasH)
Date: Wed, 01 Jul 2009 15:46:28 +0000
Subject: [issue6395] Add Pickle Support to the codecs Module
In-Reply-To: <1246463188.35.0.320675118154.issue6395@psf.upfronthosting.co.za>
Message-ID: <1246463188.35.0.320675118154.issue6395@psf.upfronthosting.co.za>


New submission from ThomasH <thomas.bugzilla at gmx.net>:

I recently ran into an infinite recursion trying to unpickle a
codecs.StreamWriter object (I presume the issue would be the same for a
StreamReader).

Here is the end of the stack trace:

? File "/sw/lib/python2.5/codecs.py", line 330, in __getattr__? ? 
? ? return getattr(self.stream, name)
? File "/sw/lib/python2.5/codecs.py", line 330, in __getattr__? 
? ? return getattr(self.stream, name)?
? File "/sw/lib/python2.5/codecs.py", line 330, in __getattr__?
? ? return getattr(self.stream, name)?
 RuntimeError: maximum recursion depth exceeded 

The issue is the same under Python2.6 but the error output has changed
(see http://bugs.python.org/issue5508).

The problem is that the codecs module tries to delegate member lookup to
the underlying stream. But after unpickling, "self.stream" is not
defined, so the reference to self.stream in __getattr__ itself leads to
an invocation of __getattr__ - hence the recursion loop.

Using tools from the Pickle protocol, like __getstate__/__setstate__,
could help degrade codecs objects gracefully during pickle/unpickle
cycles. E.g. it might be enough to provide a dummy self.stream through
__setstate__.

----------
components: Library (Lib)
messages: 89985
nosy: ThomasH
severity: normal
status: open
title: Add Pickle Support to the codecs Module
type: crash
versions: Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6395>
_______________________________________

From report at bugs.python.org  Wed Jul  1 12:55:21 2009
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Wed, 01 Jul 2009 10:55:21 +0000
Subject: [issue6331] Add unicode script info to the unicode database
In-Reply-To: <1245790259.44.0.08771310344.issue6331@psf.upfronthosting.co.za>
Message-ID: <1246445721.76.0.391283150968.issue6331@psf.upfronthosting.co.za>


Walter D?rwald <walter at livinglogic.de> added the comment:

Here is a new version that includes a new function scriptl() that
returns the script name in lowercase.

----------
Added file: http://bugs.python.org/file14418/unicode-script-3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6331>
_______________________________________

From report at bugs.python.org  Wed Jul  1 16:17:17 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 01 Jul 2009 14:17:17 +0000
Subject: [issue1284496] traceback module can return undecodable byte strings
Message-ID: <1246457837.56.0.488166375216.issue1284496@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Python 3.0 switched to unicode precisely for this kind of issues.
There, you get
'Traceback (most recent call last):\n  File "<stdin>", line 3, in
<module>\nValueError: Invalid value
b\'\\xff\\xfeh\\x00e\\x00l\\x00l\\x00o\\x00\'\n'

For python 2.x, it's up to the application to decide how it will convert
various tracebacks to unicode. The 'backslashreplace' encoding may help,
or you can use %r instead of %s.

----------
nosy: +amaury.forgeotdarc
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1284496>
_______________________________________

From report at bugs.python.org  Wed Jul  1 10:38:25 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 01 Jul 2009 08:38:25 +0000
Subject: [issue6353] "L" integer suffix in Python 3.1 tutorial
In-Reply-To: <1246175705.48.0.727392252197.issue6353@psf.upfronthosting.co.za>
Message-ID: <1246437505.63.0.2154959215.issue6353@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This is already fixed in r71994.
Thanks anyway.

----------
nosy: +ezio.melotti
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6353>
_______________________________________

From report at bugs.python.org  Wed Jul  1 17:11:54 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 01 Jul 2009 15:11:54 +0000
Subject: [issue6394] getppid support in os module on Windows
In-Reply-To: <1246460889.83.0.840180185924.issue6394@psf.upfronthosting.co.za>
Message-ID: <1246461114.22.0.192646662001.issue6394@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I'm not qualified to comment on Windows-specific code, but two things:
- you should raise an appropriate exception on failure, not return -1
- the file is intended with tabs, not spaces

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6394>
_______________________________________

From report at bugs.python.org  Wed Jul  1 12:51:57 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 01 Jul 2009 10:51:57 +0000
Subject: [issue6393] OS X: python3 from python-3.1.dmg crashes at startup
In-Reply-To: <1246445517.38.0.373229118664.issue6393@psf.upfronthosting.co.za>
Message-ID: <1246445517.38.0.373229118664.issue6393@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

There was a report[1] on c.l.p. that python3 from the OS X Python 3.1 
dmg download at www.python.org/download/releases/3.1/ crashes on 
startup.  I can reproduce this with the python.org download (using the 
OS X Terminal) only with a bad locale setting:

newton:~ dickinsm$ LANG=utf-8 python3
Fatal Python error: Py_Initialize: can't initialize sys standard streams
LookupError: unknown encoding: 
Abort trap (core dumped)

The core dump isn't useful:  just lots of 'No symbol table info 
available.'

This is on OS X 10.5.7/Intel.

I can't reproduce it with either the py3k branch or the release31-maint 
branch, built from scratch.

I suspect that this has to do with the behaviour of nl_langinfo(CODESET) 
on OS X: namely, after doing (in C) setlocale(LC_CTYPE, ""), the result 
of nl_langinfo(CODESET) appears to be "UTF-8" for well-defined utf-8 
locales (e.g., 'en_US.UTF-8'), "US-ASCII" for meaningless locales (e.g., 
'invalid'), but one just gets "" for locales like 'utf-8' or 'en_US'.
This in turn affects Python's locale.getpreferredencoding function. 
See also issue 2173, which may be related.

Ronald, any ideas?

[1] http://mail.python.org/pipermail/python-list/2009-June/718255.html

----------
assignee: ronaldoussoren
components: Interpreter Core, Macintosh
messages: 89972
nosy: marketdickinson, ronaldoussoren
severity: normal
status: open
title: OS X: python3 from python-3.1.dmg crashes at startup
type: crash
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6393>
_______________________________________

From report at bugs.python.org  Wed Jul  1 13:55:12 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 01 Jul 2009 11:55:12 +0000
Subject: [issue4965] Can doc index of html version be separately scrollable?
In-Reply-To: <1232148633.29.0.602528403512.issue4965@psf.upfronthosting.co.za>
Message-ID: <1246449312.16.0.847572872874.issue4965@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee: georg.brandl -> ezio.melotti
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4965>
_______________________________________

From report at bugs.python.org  Wed Jul  1 07:20:38 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 01 Jul 2009 05:20:38 +0000
Subject: [issue5388] Green-box doc glitch: winhelp version only
In-Reply-To: <1235763954.97.0.134032530958.issue5388@psf.upfronthosting.co.za>
Message-ID: <1246425638.07.0.975408911334.issue5388@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Added file: http://bugs.python.org/file14414/py31doc-vista.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5388>
_______________________________________

From report at bugs.python.org  Wed Jul  1 18:19:00 2009
From: report at bugs.python.org (Josiah Carlson)
Date: Wed, 01 Jul 2009 16:19:00 +0000
Subject: [issue1314572] Trailing slash redirection for SimpleHTTPServer
Message-ID: <1246465140.59.0.941034448246.issue1314572@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

The other patch is more correct.  Closing.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> SimpleHTTPServer directory-indexing "bug" fix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1314572>
_______________________________________

From report at bugs.python.org  Wed Jul  1 13:13:20 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 01 Jul 2009 11:13:20 +0000
Subject: [issue3154] "Quick search" box renders too wide if font size is large
In-Reply-To: <1213998453.68.0.954320877172.issue3154@psf.upfronthosting.co.za>
Message-ID: <1246446800.91.0.529027310873.issue3154@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3154>
_______________________________________

From report at bugs.python.org  Wed Jul  1 11:01:33 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 01 Jul 2009 09:01:33 +0000
Subject: [issue3143] development docs waste a lot of horizontal space on left
	nav bar
In-Reply-To: <1213894130.5.0.901866798504.issue3143@psf.upfronthosting.co.za>
Message-ID: <1246438893.17.0.285729562659.issue3143@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Using "position: fixed" was requested in #4965 too and I posted a proof
of concept. I'll try to do a proper patch in the next days.

It might also be possible to make the sidebar collapsible using
Javascript (something similar to the sidebar of Google maps).
I'll take a look at this issue too.

----------
assignee: georg.brandl -> ezio.melotti
priority:  -> low
stage:  -> needs patch
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3143>
_______________________________________

From report at bugs.python.org  Wed Jul  1 12:02:02 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 01 Jul 2009 10:02:02 +0000
Subject: [issue6267] Cumulative patcc:h to http and xmlrpc
In-Reply-To: <1244734235.6.0.17264314682.issue6267@psf.upfronthosting.co.za>
Message-ID: <1246442522.96.0.565505462042.issue6267@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

committed to py3k in revision 73742

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6267>
_______________________________________

From report at bugs.python.org  Wed Jul  1 07:41:53 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 01 Jul 2009 05:41:53 +0000
Subject: [issue5388] Green-box doc glitch: winhelp version only
In-Reply-To: <1235763954.97.0.134032530958.issue5388@psf.upfronthosting.co.za>
Message-ID: <1246426913.42.0.79587554683.issue5388@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Added file: http://bugs.python.org/file14415/py31doc-vista.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5388>
_______________________________________

From report at bugs.python.org  Wed Jul  1 10:48:55 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 01 Jul 2009 08:48:55 +0000
Subject: [issue3143] development docs waste a lot of horizontal space on left
	nav bar
In-Reply-To: <1213894130.5.0.901866798504.issue3143@psf.upfronthosting.co.za>
Message-ID: <1246438135.73.0.0404636545207.issue3143@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3143>
_______________________________________

From report at bugs.python.org  Wed Jul  1 13:04:14 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 01 Jul 2009 11:04:14 +0000
Subject: [issue4711] Wide literals in the table of contents overflow in
	documentation
In-Reply-To: <1229878552.94.0.178929851509.issue4711@psf.upfronthosting.co.za>
Message-ID: <1246446254.48.0.481072429425.issue4711@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I can see 5 possible solutions here:
1) use "overflow: auto" - an horizontal scrollbar will appear at the
bottom of the sidebar;
2) use "overflow: hidden" - no scrollbar and the content that doesn't
fit in the sidebar won't be visible;
3) allow the sidebar to change its width according to the content - this
may have other negative side-effects;
4) try to break/cut the long items - this may be quite difficult to realize;
5) try some experiment with CSS3's "text-overflow: ellipsis" - it's nice
and it should work on Opera an maybe on FF3.5 too.

Fixing #4965 will probably solve this issue using the first solution, 
"text-overflow: ellipsis" could still be used in addition (it cuts the
word and '...' at the end if the text doesn't fit in the container).

Making the sidebar collapsible (as suggested in #3143) could make the
third option feasible.

The old link doesn't work anymore, this works:
http://docs.python.org/library/multiprocessing.html

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4711>
_______________________________________

From report at bugs.python.org  Wed Jul  1 11:03:46 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 01 Jul 2009 09:03:46 +0000
Subject: [issue4965] Can doc index of html version be separately scrollable?
In-Reply-To: <1232148633.29.0.602528403512.issue4965@psf.upfronthosting.co.za>
Message-ID: <1246439026.07.0.639594541194.issue4965@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

See also #3143.
I'll try to do a proper patch to fix this issue.

----------
assignee: georg.brandl -> ezio.melotti
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4965>
_______________________________________

From report at bugs.python.org  Wed Jul  1 18:49:15 2009
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 01 Jul 2009 16:49:15 +0000
Subject: [issue6397] Implementing Solaris "poll" in the "select" module
In-Reply-To: <1246466955.08.0.134631976531.issue6397@psf.upfronthosting.co.za>
Message-ID: <1246466955.08.0.134631976531.issue6397@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n <jcea at jcea.es>:

In Python 2.6 we added support for Linux "epoll" and *BSD "kqueue" in
the select module. I think we should add support for Solaris "poll"
interface too.

What do you think?.

I volunteer to do the work, if you agree this is a feature we want to
have. I think so.

----------
assignee: jcea
components: Library (Lib)
messages: 89989
nosy: jcea
severity: normal
stage: needs patch
status: open
title: Implementing Solaris "poll" in the "select" module
type: feature request
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6397>
_______________________________________

From report at bugs.python.org  Wed Jul  1 12:20:13 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 01 Jul 2009 10:20:13 +0000
Subject: [issue4965] Can doc index of html version be separately scrollable?
In-Reply-To: <1232148633.29.0.602528403512.issue4965@psf.upfronthosting.co.za>
Message-ID: <1246443613.78.0.171264812944.issue4965@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

"overflow: auto" should fix #4711 too (adding an horizontal scroll bar
at the bottom of the sidebar).

----------
assignee: ezio.melotti -> georg.brandl
stage: needs patch -> 
superseder:  -> Wide literals in the table of contents overflow in documentation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4965>
_______________________________________

From report at bugs.python.org  Wed Jul  1 13:05:14 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 01 Jul 2009 11:05:14 +0000
Subject: [issue4711] Wide literals in the table of contents overflow in
	documentation
In-Reply-To: <1229878552.94.0.178929851509.issue4711@psf.upfronthosting.co.za>
Message-ID: <1246446314.13.0.717868075084.issue4711@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee: georg.brandl -> ezio.melotti
priority:  -> low
stage:  -> needs patch
versions: +Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4711>
_______________________________________

From report at bugs.python.org  Wed Jul  1 16:52:43 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 01 Jul 2009 14:52:43 +0000
Subject: [issue1262856] fcntl.ioctl have a bit problem.
Message-ID: <1246459963.53.0.388500443789.issue1262856@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This was fixed in 2.5 with issue1231069.

----------
nosy: +amaury.forgeotdarc
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1262856>
_______________________________________

From report at bugs.python.org  Wed Jul  1 18:53:01 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 01 Jul 2009 16:53:01 +0000
Subject: [issue4278] optparse quirks
In-Reply-To: <1226063635.77.0.234802837689.issue4278@psf.upfronthosting.co.za>
Message-ID: <1246467181.42.0.228888116602.issue4278@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

- For the -h option, you may add "add_help_option=False" when creating
the Optparse object

- concerning the error message: every parser that tries to give
meaningful error messages has to guess what the user really meant. The
exact text is really an implementation detail.

----------
nosy: +amaury.forgeotdarc
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4278>
_______________________________________

From report at bugs.python.org  Thu Jul  2 01:30:31 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 01 Jul 2009 23:30:31 +0000
Subject: [issue6026] test_(zipfile|zipimport|gzip|distutils) fail if zlib is
	not available
In-Reply-To: <1242349106.59.0.466065396405.issue6026@psf.upfronthosting.co.za>
Message-ID: <1246491031.95.0.659601069488.issue6026@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I tried also with the final release of Python 3.1, but when zlib is
missing only test_zlib is skipped, test_zipfile, test_zipimport,
test_gzip and test_distutils fail.
These tests should check if zlib is available too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6026>
_______________________________________

From report at bugs.python.org  Wed Jul  1 22:24:09 2009
From: report at bugs.python.org (Christoph Burgmer)
Date: Wed, 01 Jul 2009 20:24:09 +0000
Subject: [issue1293741] doctest runner cannot handle non-ascii characters
Message-ID: <1246479849.58.0.934130515291.issue1293741@psf.upfronthosting.co.za>


Christoph Burgmer <cburgmer at ira.uka.de> added the comment:

My last patch only changed the encoding used in DocTestRunner.run().
This new patch will apply the same to DocTestCase.runTest().

----------
Added file: http://bugs.python.org/file14422/doctest.unicode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1293741>
_______________________________________

From report at bugs.python.org  Wed Jul  1 22:25:05 2009
From: report at bugs.python.org (Christoph Burgmer)
Date: Wed, 01 Jul 2009 20:25:05 +0000
Subject: [issue3955] maybe doctest doesn't understand unicode_literals?
In-Reply-To: <1222259902.44.0.148184723221.issue3955@psf.upfronthosting.co.za>
Message-ID: <1246479905.84.0.145282473133.issue3955@psf.upfronthosting.co.za>


Christoph Burgmer <cburgmer at ira.uka.de> added the comment:

JFTR: To yield the results of my last comment, you need to apply the
patch posted in http://bugs.python.org/issue1293741

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3955>
_______________________________________

From report at bugs.python.org  Wed Jul  1 21:15:37 2009
From: report at bugs.python.org (Erik Antelman)
Date: Wed, 01 Jul 2009 19:15:37 +0000
Subject: [issue4749] Issue with RotatingFileHandler logging handler on Windows
In-Reply-To: <1230295606.47.0.842082380856.issue4749@psf.upfronthosting.co.za>
Message-ID: <1246475737.03.0.0208427221237.issue4749@psf.upfronthosting.co.za>


Erik Antelman <eantelman at acm.org> added the comment:

The really annoying this about handle inheritance is that even if a 
subprocess is never referencing or using logging there can be an open 
file handle conflict due to the default inheratence.

Another tack from modifying Popen, 

I looked at the forking.py of multiprocessing and observed the 
techniques for changing the inheratance attribute of files handles 
using the _subprocess wrapper to the NT DuplicateHandle call.

Then by replacing the _open of the FileHandler to ensure handles are 
open non-inheritable I can ensure that log files are not inherited. 
This preserves the behavior of everything else. 

I attached the NT/Multiprocessing safe version of a RotatingFileHandler 
class

----------
nosy: +eantelman
Added file: http://bugs.python.org/file14420/NTSafeLogging.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4749>
_______________________________________

From report at bugs.python.org  Wed Jul  1 21:36:57 2009
From: report at bugs.python.org (Jon Anglin)
Date: Wed, 01 Jul 2009 19:36:57 +0000
Subject: [issue6394] getppid support in os module on Windows
In-Reply-To: <1246460889.83.0.840180185924.issue6394@psf.upfronthosting.co.za>
Message-ID: <1246477017.13.0.467200841893.issue6394@psf.upfronthosting.co.za>


Jon Anglin <janglin at fortresgrand.com> added the comment:

Implements getppid in the os module on Windows systems. The getppid 
function was only available on Unix like systems, this diff patch brings 
this functionality to Windows systems.  This function will return the 
parent process Id, upon error it raises a WindowsError. This differs 
from the Unix implementation that never fails.  Due to the way Windows 
returns the parent process Id, a never fail guarantee can not be made.  
This is a revision of a previous post.  The file Issue6394-1.diff 
contains the updated patches.

----------
Added file: http://bugs.python.org/file14421/Issue6394-1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6394>
_______________________________________

From report at bugs.python.org  Wed Jul  1 22:30:45 2009
From: report at bugs.python.org (Nathan Michaels)
Date: Wed, 01 Jul 2009 20:30:45 +0000
Subject: [issue6398] README typo
In-Reply-To: <1246480245.72.0.392053113431.issue6398@psf.upfronthosting.co.za>
Message-ID: <1246480245.72.0.392053113431.issue6398@psf.upfronthosting.co.za>


New submission from Nathan Michaels <nmichaels at gmail.com>:

There's a typo in the README in the 2.6 source root. "versio" on line
942 should be "version".

----------
assignee: georg.brandl
components: Documentation
files: fix.diff
keywords: patch
messages: 89998
nosy: georg.brandl, nmichaels
severity: normal
status: open
title: README typo
versions: Python 2.6
Added file: http://bugs.python.org/file14423/fix.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6398>
_______________________________________

From report at bugs.python.org  Wed Jul  1 15:45:29 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 01 Jul 2009 13:45:29 +0000
Subject: [issue900092] hotshot.stats.load fails with AssertionError
Message-ID: <1246455929.45.0.905836069963.issue900092@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I added some prints in the hotshot.stats.load function, this lead to
interesting things:

- first, the program seems to spawn subprocesses which trace themselves
in the same file.

- however, there is real issue when fork() is called on a traced
program: calls to _execvpe should not appear in the trace!
IMO PyOS_AfterFork should disable any trace or profile function.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue900092>
_______________________________________

From report at bugs.python.org  Wed Jul  1 07:59:40 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 01 Jul 2009 05:59:40 +0000
Subject: [issue5388] Green-box doc glitch: winhelp version only
In-Reply-To: <1235763954.97.0.134032530958.issue5388@psf.upfronthosting.co.za>
Message-ID: <1246427980.01.0.520136378284.issue5388@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Removed file: http://bugs.python.org/file14415/py31doc-vista.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5388>
_______________________________________

From report at bugs.python.org  Wed Jul  1 07:59:28 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 01 Jul 2009 05:59:28 +0000
Subject: [issue5388] Green-box doc glitch: winhelp version only
In-Reply-To: <1235763954.97.0.134032530958.issue5388@psf.upfronthosting.co.za>
Message-ID: <1246427968.99.0.944775422107.issue5388@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Added file: http://bugs.python.org/file14417/py31doc-winxpsp2.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5388>
_______________________________________

From report at bugs.python.org  Wed Jul  1 19:25:16 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 01 Jul 2009 17:25:16 +0000
Subject: [issue5383] Allow intermixing of keyword arguments and vargarg
	arguments
In-Reply-To: <1235753152.03.0.131983429775.issue5383@psf.upfronthosting.co.za>
Message-ID: <1246469116.95.0.371813678563.issue5383@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Also, the new syntax breaks the symmetry between the function definition
and the function call.

In any case, the issue tracker is the wrong place for such discussions.
This should be done on the python-ideas mailing list.

----------
nosy: +amaury.forgeotdarc
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5383>
_______________________________________

From report at bugs.python.org  Wed Jul  1 07:57:35 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 01 Jul 2009 05:57:35 +0000
Subject: [issue5388] Green-box doc glitch: winhelp version only
In-Reply-To: <1235763954.97.0.134032530958.issue5388@psf.upfronthosting.co.za>
Message-ID: <1246427855.03.0.542362847949.issue5388@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I uploaded a few more screenshots.
I was able to reproduce the issue on Vista with HTML Help Version 6.0
and on Windows 2003 Server whit HTML Help Control Version 5.2.3790.3959.
I also tried on another Windows XP SP2 machine with HTML Help Control
Version 5.2.3790.1194 but the scrollbar wasn't there, so I guess they
changed something between .1194 and .3959
The version I'm running at home is probably even older (4.74?) and the
problem seems to affect only the newer versions.

----------
Added file: http://bugs.python.org/file14416/py31doc-win2k3.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5388>
_______________________________________

From report at bugs.python.org  Wed Jul  1 12:17:46 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 01 Jul 2009 10:17:46 +0000
Subject: [issue1314572] Trailing slash redirection for SimpleHTTPServer
Message-ID: <1246443466.7.0.188257435241.issue1314572@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The same problem was fixed with issue827559.
But the patch here is different:

- it returns a code 302 instead of 301

- it uses the header "Content-Location" instead of "Location" to set the
new path with the slash

- it sets "Content-type: text/html" and returns the following content:
   '<META HTTP-EQUIV="refresh" CONTENT="0;URL=%s/">'%self.path

Some HTTP expert should conclude.

----------
assignee:  -> akuchling
nosy: +akuchling, amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1314572>
_______________________________________

From report at bugs.python.org  Wed Jul  1 13:06:57 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 01 Jul 2009 11:06:57 +0000
Subject: [issue3810] os.chdir() et al: is the path str or bytes?
In-Reply-To: <1220937677.05.0.675791850215.issue3810@psf.upfronthosting.co.za>
Message-ID: <1246446417.49.0.433444711115.issue3810@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee: georg.brandl -> ezio.melotti
nosy: +ezio.melotti
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3810>
_______________________________________

From report at bugs.python.org  Wed Jul  1 11:55:15 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 01 Jul 2009 09:55:15 +0000
Subject: [issue6392] IDLE 3.1 will not open
In-Reply-To: <1246420572.02.0.605221544968.issue6392@psf.upfronthosting.co.za>
Message-ID: <1246442115.53.0.0119764842071.issue6392@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This is a duplicate of issue5528.
The fix is to remove the TCL_LIBRARY environment variable.

----------
nosy: +amaury.forgeotdarc
resolution:  -> duplicate
status: open -> closed
superseder:  -> Unable to launch IDLE on Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6392>
_______________________________________

From report at bugs.python.org  Wed Jul  1 19:29:08 2009
From: report at bugs.python.org (Aaron Sherman)
Date: Wed, 01 Jul 2009 17:29:08 +0000
Subject: [issue5555] optparse: clarify option concatenation in docs
In-Reply-To: <1237917675.54.0.817122476849.issue5555@psf.upfronthosting.co.za>
Message-ID: <1246469348.06.0.820428045784.issue5555@psf.upfronthosting.co.za>


Aaron Sherman <ajs at ajs.com> added the comment:

I'm closing this out, as the previous poster was correct: the module
does the right thing, and I misread the documentation. Thanks!

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5555>
_______________________________________

From report at bugs.python.org  Thu Jul  2 02:11:31 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 02 Jul 2009 00:11:31 +0000
Subject: [issue6026] test_(zipfile|zipimport|gzip|distutils) fail if zlib is
	not available
In-Reply-To: <1242349106.59.0.466065396405.issue6026@psf.upfronthosting.co.za>
Message-ID: <1246493491.47.0.855554556481.issue6026@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee:  -> ezio.melotti
priority:  -> normal
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6026>
_______________________________________

From report at bugs.python.org  Wed Jul  1 12:14:43 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 01 Jul 2009 10:14:43 +0000
Subject: [issue4758] Python 3.0 internet documentation needs work
In-Reply-To: <1230383680.06.0.695552325819.issue4758@psf.upfronthosting.co.za>
Message-ID: <1246443283.91.0.431853641167.issue4758@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

David, I think that a list of notes posted here is ok, can you still
provide them?

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4758>
_______________________________________

From report at bugs.python.org  Wed Jul  1 19:24:01 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Wed, 01 Jul 2009 17:24:01 +0000
Subject: [issue6397] Implementing Solaris "poll" in the "select" module
In-Reply-To: <1246466955.08.0.134631976531.issue6397@psf.upfronthosting.co.za>
Message-ID: <1246469041.42.0.435057920983.issue6397@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Solaris 10 introduced "The Event Completion Framework".  I am not
particularly familiar with Solaris, so I couldn't say whether it would
be better to target this or the older /dev/poll.  Some documentation
suggests that "The Event Completion Framework" is somewhat preferred:

http://developers.sun.com/solaris/articles/event_completion.html

It suggests that /dev/poll is not as performant, but I'm not sure I
believe it.  One feature which it does seem to have which puts it ahead
of /dev/poll is the support of various non-fd event sources (eg, timers).

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6397>
_______________________________________

From report at bugs.python.org  Thu Jul  2 08:00:45 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 02 Jul 2009 06:00:45 +0000
Subject: [issue6396] No conversion specifier in the string,
	no __getitem__ method in the right hand value
In-Reply-To: <1246464847.52.0.736883285817.issue6396@psf.upfronthosting.co.za>
Message-ID: <1246514445.2.0.474944179112.issue6396@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

No, it's not logical that there should be an exception. The result looks
right to me.

You are incorrectly assuming that it would always invoke __getitem__ in
this case, which is not true:

py> "a string with a single placeholder: %s" % c
'a string with a single placeholder: <__main__.AClass object at 0xb7d3b1ec>'

So whether it requires c to be a dictionary depends on whether there are
any %(foo)s conversions in the string. With no conversion specifiers,
the values passed to % are irrelevant.

----------
nosy: +loewis
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6396>
_______________________________________

From report at bugs.python.org  Thu Jul  2 10:14:10 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 02 Jul 2009 08:14:10 +0000
Subject: [issue6394] getppid support in os module on Windows
In-Reply-To: <1246460889.83.0.840180185924.issue6394@psf.upfronthosting.co.za>
Message-ID: <1246522450.28.0.141806036428.issue6394@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

First, I checked that the API does exist on Window 2000. And python does
not have any "never fail guarantee", specially in low memory conditions.

Then, some remarks:

- If Process32First or Process32Next fail for any reason, "return
win32_error(...)" is called, but the GetLastError function won't find
the cause because CloseHandle will clear it.

- It would be nice to add a comment like "if the loop ends and our pid
was not found, GetLastError() will return ERROR_NO_MORE_FILES.  This is
an error anyway, so let's raise this."

- A unit test is necessary: it could use a subprocess and compare
getpid() with the child's getppid().

- The documentation should state what happens when the parent process
exits.  Is the ppid reset to zero?  Is it possible to have another new
process with the same ppid?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6394>
_______________________________________

From report at bugs.python.org  Thu Jul  2 10:27:50 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 02 Jul 2009 08:27:50 +0000
Subject: [issue6026] test_(zipfile|zipimport|gzip|distutils) fail if zlib is
	not available
In-Reply-To: <1242349106.59.0.466065396405.issue6026@psf.upfronthosting.co.za>
Message-ID: <1246523270.69.0.238630354698.issue6026@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

test_zipfile and test_zipimport should be enabled when zlib is not
available: a zip file can store data uncompressed, and does not need
zlib in this case.
Only disable tests that require compression.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6026>
_______________________________________

From report at bugs.python.org  Thu Jul  2 10:32:10 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 02 Jul 2009 08:32:10 +0000
Subject: [issue6026] test_(zipfile|zipimport|gzip|distutils) fail if zlib is
	not available
In-Reply-To: <1242349106.59.0.466065396405.issue6026@psf.upfronthosting.co.za>
Message-ID: <1246523530.53.0.07261798354.issue6026@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I'm working on a patch.
There a few more tests that need to be skipped in test_zipfile when zlib
is not available. test_gzip has to be skipped entirely if zlib is not
available. I still have to look at test_zipimport and test_distutils.

----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6026>
_______________________________________

From report at bugs.python.org  Thu Jul  2 11:12:43 2009
From: report at bugs.python.org (Colin Watson)
Date: Thu, 02 Jul 2009 09:12:43 +0000
Subject: [issue1652] subprocess should have an option to restore SIGPIPE to
	default action
In-Reply-To: <1197992466.47.0.0612439954222.issue1652@psf.upfronthosting.co.za>
Message-ID: <1246525963.25.0.482676420116.issue1652@psf.upfronthosting.co.za>


Colin Watson <cjwatson at users.sourceforge.net> added the comment:

Is there anything more I can do to move this along? Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1652>
_______________________________________

From report at bugs.python.org  Thu Jul  2 11:30:10 2009
From: report at bugs.python.org (chkneo)
Date: Thu, 02 Jul 2009 09:30:10 +0000
Subject: [issue5111] httplib: wrong Host header when connecting to IPv6
	litteral URL
In-Reply-To: <1233334139.62.0.259128767537.issue5111@psf.upfronthosting.co.za>
Message-ID: <1246527010.39.0.744889750552.issue5111@psf.upfronthosting.co.za>


chkneo <chkneo at gmail.com> added the comment:

As per the RFC 2732 host header should be wrapped with []. I am
attaching patch for this too which is applied on trunk(2.7)

----------
keywords: +patch
nosy: +chkneo
type:  -> behavior
Added file: http://bugs.python.org/file14424/5111.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5111>
_______________________________________

From report at bugs.python.org  Thu Jul  2 11:33:30 2009
From: report at bugs.python.org (chkneo)
Date: Thu, 02 Jul 2009 09:33:30 +0000
Subject: [issue5111] httplib: wrong Host header when connecting to IPv6
	litteral URL
In-Reply-To: <1233334139.62.0.259128767537.issue5111@psf.upfronthosting.co.za>
Message-ID: <1246527210.16.0.943688627599.issue5111@psf.upfronthosting.co.za>


chkneo <chkneo at gmail.com> added the comment:

RFC 2732 Section three have the following details.

      host          = hostname | IPv4address | IPv6reference
      ipv6reference = "[" IPv6address "]"

The patch contains check for : and adding the brackets

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5111>
_______________________________________

From report at bugs.python.org  Thu Jul  2 11:36:39 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 02 Jul 2009 09:36:39 +0000
Subject: [issue6398] README typo
In-Reply-To: <1246480245.72.0.392053113431.issue6398@psf.upfronthosting.co.za>
Message-ID: <1246527399.31.0.433105607236.issue6398@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee: georg.brandl -> ezio.melotti
nosy: +ezio.melotti
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6398>
_______________________________________

From report at bugs.python.org  Thu Jul  2 11:44:08 2009
From: report at bugs.python.org (chkneo)
Date: Thu, 02 Jul 2009 09:44:08 +0000
Subject: [issue5111] httplib: wrong Host header when connecting to IPv6
	litteral URL
In-Reply-To: <1233334139.62.0.259128767537.issue5111@psf.upfronthosting.co.za>
Message-ID: <1246527848.16.0.782739392768.issue5111@psf.upfronthosting.co.za>


Changes by chkneo <chkneo at gmail.com>:


Removed file: http://bugs.python.org/file14424/5111.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5111>
_______________________________________

From report at bugs.python.org  Thu Jul  2 11:44:18 2009
From: report at bugs.python.org (chkneo)
Date: Thu, 02 Jul 2009 09:44:18 +0000
Subject: [issue5111] httplib: wrong Host header when connecting to IPv6
	litteral URL
In-Reply-To: <1233334139.62.0.259128767537.issue5111@psf.upfronthosting.co.za>
Message-ID: <1246527858.71.0.0305327740297.issue5111@psf.upfronthosting.co.za>


Changes by chkneo <chkneo at gmail.com>:


Added file: http://bugs.python.org/file14425/5111.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5111>
_______________________________________

From report at bugs.python.org  Thu Jul  2 11:50:31 2009
From: report at bugs.python.org (Mike)
Date: Thu, 02 Jul 2009 09:50:31 +0000
Subject: [issue6399] Error reporting by logging.config.fileConfig()
In-Reply-To: <1246528231.33.0.0905986098741.issue6399@psf.upfronthosting.co.za>
Message-ID: <1246528231.33.0.0905986098741.issue6399@psf.upfronthosting.co.za>


New submission from Mike <python at amadron.com>:

Hi,
I had a logging.conf file with the following logger def in it:

[logger_Builder]
level=DEBUG
handlers=consoleStderr
qualname=Builder
propogate=0

And I couldn't understand why all my log messages were coming out twice.
 It took me four hours :-\ to realise I had misspelt "propagate".

Wouldn't it be better if spurious names raised parsing exceptions?

Thanks,
Mike.

P.S. Another thing that might have helped me track this down a little
quicker is if I could have printed the name of the logger that was the
source of some output. %(name)s gives the logger that *received* the log
message.  If there was another format variable for the logger that was
the source of a log message I would have seen one message from Builder
and one message from root and it would have been more obvious what was
going on.

----------
components: Extension Modules
messages: 90007
nosy: mike
severity: normal
status: open
title: Error reporting by logging.config.fileConfig()
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6399>
_______________________________________

From report at bugs.python.org  Thu Jul  2 13:43:34 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 02 Jul 2009 11:43:34 +0000
Subject: [issue6396] No conversion specifier in the string,
	no __getitem__ method in the right hand value
In-Reply-To: <1246464847.52.0.736883285817.issue6396@psf.upfronthosting.co.za>
Message-ID: <1246535014.28.0.284138563738.issue6396@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

If A is a simple class (old or new style):
   class A: pass

Why is there a difference between:
   "" % object()
and
   "" % A()
?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6396>
_______________________________________

From report at bugs.python.org  Thu Jul  2 14:20:04 2009
From: report at bugs.python.org (Andreas Kloeckner)
Date: Thu, 02 Jul 2009 12:20:04 +0000
Subject: [issue1652] subprocess should have an option to restore SIGPIPE to
	default action
In-Reply-To: <1197992466.47.0.0612439954222.issue1652@psf.upfronthosting.co.za>
Message-ID: <1246537204.77.0.247281014239.issue1652@psf.upfronthosting.co.za>


Changes by Andreas Kloeckner <inform at tiker.net>:


----------
nosy: +inducer

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1652>
_______________________________________

From report at bugs.python.org  Thu Jul  2 14:23:36 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 02 Jul 2009 12:23:36 +0000
Subject: [issue6396] No conversion specifier in the string,
	no __getitem__ method in the right hand value
In-Reply-To: <1246464847.52.0.736883285817.issue6396@psf.upfronthosting.co.za>
Message-ID: <1246537416.36.0.293289564581.issue6396@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

IMO, the *_FromFormat functions are wrong to decide whether the args
object is a mapping. the code is:
    if (Py_TYPE(args)->tp_as_mapping && !PyTuple_Check(args) &&
        !PyObject_TypeCheck(args, &PyBaseString_Type))
        dict = args;

But heap types always fill tp_as_mapping: it points to
PyHeapTypeObject.as_mapping, whose members may be NULL...
PyMapping_Check() would be more appropriate.

----------
resolution: invalid -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6396>
_______________________________________

From report at bugs.python.org  Thu Jul  2 15:09:40 2009
From: report at bugs.python.org (Alejandro)
Date: Thu, 02 Jul 2009 13:09:40 +0000
Subject: [issue6400] incorrect commands import
In-Reply-To: <1246540179.08.0.172564067781.issue6400@psf.upfronthosting.co.za>
Message-ID: <1246540179.08.0.172564067781.issue6400@psf.upfronthosting.co.za>


New submission from Alejandro <alejolp at alejolp.com>:

I'm porting a project to Py3k wich contains a "commands.py" script on
the project's module. 

Inside "a.py" there is an "import commands" statement:

/mymodule/commands.py
/mymodule/a.py

The 2to3 tool replaces the "import commands" and all the "commands"
ocurrences with the word "subprocess".

Is is possible to adapt the fix_imports fixer to detect a local import,
like the fix_import fixer (probably_a_local_import)?

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 90010
nosy: alejolp
severity: normal
status: open
title: incorrect commands import
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6400>
_______________________________________

From report at bugs.python.org  Thu Jul  2 15:56:25 2009
From: report at bugs.python.org (j_pok)
Date: Thu, 02 Jul 2009 13:56:25 +0000
Subject: [issue6401] Unexpected module garbage collection
In-Reply-To: <1246542985.56.0.681737783337.issue6401@psf.upfronthosting.co.za>
Message-ID: <1246542985.56.0.681737783337.issue6401@psf.upfronthosting.co.za>


New submission from j_pok <pystole at gmail.com>:

This code does not behave as I expected. Removing module from 
sys.modules and from local variable causes garbage collection (?) of 
module in spite of there is an instance of a class from this module. 
Instance method test() from TestClass returns global variable contained 
in module.

import sys

module = __import__("broken_module")
instance = module.TestClass()
print("a: "+str(instance.test()))
del sys.modules["broken_module"]
print("b: "+str(instance.test()))
del module
print("c: "+str(instance.test()))

Output:

a: test
b: test
c: None

----------
components: None
files: broken_module.py
messages: 90011
nosy: j_pok
severity: normal
status: open
title: Unexpected module garbage collection
type: behavior
versions: Python 2.6, Python 3.1
Added file: http://bugs.python.org/file14426/broken_module.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6401>
_______________________________________

From report at bugs.python.org  Thu Jul  2 16:23:08 2009
From: report at bugs.python.org (Jon Anglin)
Date: Thu, 02 Jul 2009 14:23:08 +0000
Subject: [issue6394] getppid support in os module on Windows
In-Reply-To: <1246460889.83.0.840180185924.issue6394@psf.upfronthosting.co.za>
Message-ID: <1246544588.05.0.797704767748.issue6394@psf.upfronthosting.co.za>


Jon Anglin <janglin at fortresgrand.com> added the comment:

I have addressed the issues brought up by Amaury Forgeot d'Arc except 
for the unit test.  I will get a unit test in tommorrow.  Thank you for 
the feedback.  I have uploaded a new diff file Issue6394-2.diff.

- Should I remove the old diff files?

I ran some test with a parent process that had exited.  The code still 
returned the correct parent process id, even though the process does 
not exist.  I am not sure if process ids get recycled, but I am looking 
in to it.

----------
Added file: http://bugs.python.org/file14427/Issue6394-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6394>
_______________________________________

From report at bugs.python.org  Thu Jul  2 16:30:53 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 02 Jul 2009 14:30:53 +0000
Subject: [issue6401] Unexpected module garbage collection
In-Reply-To: <1246542985.56.0.681737783337.issue6401@psf.upfronthosting.co.za>
Message-ID: <1246545053.27.0.822560547533.issue6401@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

The class doesn't hold any references to the module, so naturally it
will be collected if you don't.

----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6401>
_______________________________________

From report at bugs.python.org  Thu Jul  2 16:32:04 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 02 Jul 2009 14:32:04 +0000
Subject: [issue6401] Unexpected module garbage collection
In-Reply-To: <1246542985.56.0.681737783337.issue6401@psf.upfronthosting.co.za>
Message-ID: <1246545124.66.0.464388239701.issue6401@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This is a quirk of module finalization semantics. You've got to consider
the following facts:
- a class doesn't hold a reference to the module it is defined it,
because it doesn't need to (the __module__ attribute is a string)
- a function (and a method) holds a reference to the dictionary of
global variables of its defining namespace, that is, to the __dict__ of
the module, but not to the module itself
- therefore, if you remove all explicit references to the module, the
module will get garbage collected (but not its __dict__)
- when a module gets garbage collected, its attributes (members of its
__dict__) are first set to None, in an attempt to minimize circular
references issues

That's why, when you remove all explicit references to your module,
values of its __dict__ (including the "global_variable") get set to None.
(it is also why you shouldn't remove stuff from sys.modules unless you
really know what you are doing :-))

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6401>
_______________________________________

From report at bugs.python.org  Thu Jul  2 16:38:07 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 02 Jul 2009 14:38:07 +0000
Subject: [issue6400] incorrect commands import
In-Reply-To: <1246540179.08.0.172564067781.issue6400@psf.upfronthosting.co.za>
Message-ID: <1246545487.76.0.11365571541.issue6400@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

What version of 2to3 are you using?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6400>
_______________________________________

From report at bugs.python.org  Thu Jul  2 16:40:04 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 02 Jul 2009 14:40:04 +0000
Subject: [issue5111] httplib: wrong Host header when connecting to IPv6
	litteral URL
In-Reply-To: <1233334139.62.0.259128767537.issue5111@psf.upfronthosting.co.za>
Message-ID: <1246545604.15.0.724473832935.issue5111@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks for the patch. It would be better if you also added a test to
Lib/test/test_httplib.py (unless for some reason it's technically
impossible to do so).

----------
nosy: +pitrou
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5111>
_______________________________________

From report at bugs.python.org  Thu Jul  2 16:59:39 2009
From: report at bugs.python.org (Jon Anglin)
Date: Thu, 02 Jul 2009 14:59:39 +0000
Subject: [issue6394] getppid support in os module on Windows
In-Reply-To: <1246460889.83.0.840180185924.issue6394@psf.upfronthosting.co.za>
Message-ID: <1246546779.84.0.322103086459.issue6394@psf.upfronthosting.co.za>


Jon Anglin <janglin at fortresgrand.com> added the comment:

Just some information, on Windows:
- process ids are re-used.
- parent process id is set at process creation time and never updated.
(Windows Internal 4th Ed. by Russinovich and Solomon).

Thus, I would say that a long running process can not rely on the value 
of its parent process id.  The parent may not be running, or the process 
id may have been re-used and the process with that id may not be in fact 
the actual parent.  Having said that, I don't know the algorithm that 
Windows uses for process ids, so collisions may be rare (or not).

-Do these same issues exist on Unix systems?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6394>
_______________________________________

From report at bugs.python.org  Thu Jul  2 17:00:26 2009
From: report at bugs.python.org (Alejandro)
Date: Thu, 02 Jul 2009 15:00:26 +0000
Subject: [issue6400] incorrect commands import
In-Reply-To: <1246540179.08.0.172564067781.issue6400@psf.upfronthosting.co.za>
Message-ID: <1246546826.79.0.329411394987.issue6400@psf.upfronthosting.co.za>


Alejandro <alejolp at alejolp.com> added the comment:

The one included on Python 3.1-rc2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6400>
_______________________________________

From report at bugs.python.org  Thu Jul  2 17:22:04 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 02 Jul 2009 15:22:04 +0000
Subject: [issue6400] incorrect commands import
In-Reply-To: <1246540179.08.0.172564067781.issue6400@psf.upfronthosting.co.za>
Message-ID: <1246548124.07.0.257209979597.issue6400@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Oh, I see the problem. mymodule/ isn't a package. If it has __init__.py,
this should work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6400>
_______________________________________

From report at bugs.python.org  Thu Jul  2 17:24:46 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 02 Jul 2009 15:24:46 +0000
Subject: [issue6394] getppid support in os module on Windows
In-Reply-To: <1246460889.83.0.840180185924.issue6394@psf.upfronthosting.co.za>
Message-ID: <1246548286.35.0.848272834905.issue6394@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> Do these same issues exist on Unix systems?
No. When the parent exits, the child process is attached to the 'init'
process and getppid() returns 1.

And collisions are not rare at all. Actually it seems that you get the
same pid if you close and restart a program quickly.
That's why Windows apps prefer dealing with "process handles" instead of
"process ids"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6394>
_______________________________________

From report at bugs.python.org  Thu Jul  2 17:28:10 2009
From: report at bugs.python.org (Alejandro Santos)
Date: Thu, 02 Jul 2009 15:28:10 +0000
Subject: [issue6400] incorrect commands import
In-Reply-To: <1246540179.08.0.172564067781.issue6400@psf.upfronthosting.co.za>
Message-ID: <1246548490.35.0.668882577486.issue6400@psf.upfronthosting.co.za>


Alejandro Santos <alejolp at alejolp.com> added the comment:

Sorry. Yes, there is an "__init__.py" script on the same level as the
"commands.py". I forgot to mention it.

/mymodule/commands.py
/mymodule/a.py
/mymodule/__init__.py

This is the real repository:

http://selenic.com/repo/hg/file/b81baf9e4dd6/mercurial

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6400>
_______________________________________

From report at bugs.python.org  Thu Jul  2 17:59:19 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 02 Jul 2009 15:59:19 +0000
Subject: [issue6400] incorrect commands import
In-Reply-To: <1246540179.08.0.172564067781.issue6400@psf.upfronthosting.co.za>
Message-ID: <1246550359.72.0.287086648133.issue6400@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Thanks for the bug report! Fixed in r73771. Now when I run it on
mercurial/dispatch.py I get:

--- mercurial/dispatch.py (original)
+++ mercurial/dispatch.py (refactored)
@@ -5,11 +5,11 @@
 # This software may be used and distributed according to the terms of the
 # GNU General Public License version 2, incorporated herein by reference.
 
-from i18n import _
+from .i18n import _
 import os, sys, atexit, signal, pdb, socket, errno, shlex, time
-import util, commands, hg, fancyopts, extensions, hook, error
-import cmdutil, encoding
-import ui as _ui
+from . import util, commands, hg, fancyopts, extensions, hook, error
+from . import cmdutil, encoding
+from . import ui as _ui
 
 def run():
     "run the command in sys.argv"
@@ -486,7 +486,7 @@
             p.disable()
 
             if format == 'kcachegrind':
-                import lsprofcalltree
+                from . import lsprofcalltree
                 calltree = lsprofcalltree.KCacheGrind(p)
                 calltree.output(ostream)
             else:
RefactoringTool: Files that need to be modified:
RefactoringTool: mercurial/dispatch.py

Much better. :)

I'm glad to see someone is working on porting mercurial. You might want
to use the 2to3 development version, since it's always up to date wiht
bug fixes. [1] If you need any help, feel free to email the
python-porting list.

[1] http://svn.python.org/projects/sandbox/trunk/2to3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6400>
_______________________________________

From report at bugs.python.org  Thu Jul  2 17:59:46 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 02 Jul 2009 15:59:46 +0000
Subject: [issue6400] incorrect commands import
In-Reply-To: <1246540179.08.0.172564067781.issue6400@psf.upfronthosting.co.za>
Message-ID: <1246550386.61.0.0973758968606.issue6400@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6400>
_______________________________________

From report at bugs.python.org  Thu Jul  2 18:02:57 2009
From: report at bugs.python.org (Alejandro Santos)
Date: Thu, 02 Jul 2009 16:02:57 +0000
Subject: [issue6400] incorrect commands import
In-Reply-To: <1246540179.08.0.172564067781.issue6400@psf.upfronthosting.co.za>
Message-ID: <1246550577.29.0.551414532293.issue6400@psf.upfronthosting.co.za>


Alejandro Santos <alejolp at alejolp.com> added the comment:

Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6400>
_______________________________________

From report at bugs.python.org  Thu Jul  2 18:06:31 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 02 Jul 2009 16:06:31 +0000
Subject: [issue4533] 3.0 file.read dreadfully slow
In-Reply-To: <1228415420.85.0.256947820591.issue4533@psf.upfronthosting.co.za>
Message-ID: <1246550791.69.0.310592187646.issue4533@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This has been fixed as part of the big IO update in trunk. I assume
nobody really cares about making a separate patch for 2.6, please
re-open if you are interested!

----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4533>
_______________________________________

From report at bugs.python.org  Thu Jul  2 18:07:56 2009
From: report at bugs.python.org (djc)
Date: Thu, 02 Jul 2009 16:07:56 +0000
Subject: [issue6119] Confusing DeprecationWarning
In-Reply-To: <1243373041.06.0.391551220918.issue6119@psf.upfronthosting.co.za>
Message-ID: <1246550876.35.0.630237348434.issue6119@psf.upfronthosting.co.za>


Changes by djc <dirkjan at ochtman.nl>:


----------
nosy: +djc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6119>
_______________________________________

From report at bugs.python.org  Thu Jul  2 18:23:23 2009
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 02 Jul 2009 16:23:23 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1246551803.15.0.798179026917.issue4753@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Thu Jul  2 18:47:02 2009
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Jul 2009 16:47:02 +0000
Subject: [issue4601] directory permission error with make install in 3.0
In-Reply-To: <1228771673.82.0.0596697860689.issue4601@psf.upfronthosting.co.za>
Message-ID: <1246553222.31.0.773992325173.issue4601@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

ping

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4601>
_______________________________________

From report at bugs.python.org  Thu Jul  2 18:54:26 2009
From: report at bugs.python.org (Jan Lieskovsky)
Date: Thu, 02 Jul 2009 16:54:26 +0000
Subject: [issue6402] Crash after attempt to set the error indicator via
	PyErr_SetString()
In-Reply-To: <1246553666.48.0.84202001291.issue6402@psf.upfronthosting.co.za>
Message-ID: <1246553666.48.0.84202001291.issue6402@psf.upfronthosting.co.za>


New submission from Jan Lieskovsky <iankko at seznam.cz>:

Hello guys,

  i am experiencing segmentation fault, when trying to set the
error indicator via the PyErr_SetString() method called from C source.
This occurs for all Python exceptions, as documented in:

    http://docs.python.org/c-api/exceptions.html

Checked Python-2.6.2, also Python-2.4.1 - the crash is present
there (wondering what's wrong with the provided reproducer).

Scenario:
--------
tar xvzf pyexceptions-sample.tar.gz
cd pyexceptions-sample
make
./pyexceptionssample -> 
Segmentation fault (core dumped)

Note: Doesn't matter if compiled with libpython2.6.a or libpython2.4.so,
      the crash is still there.

Here is the most interesting part of the backtrace (the whole
coredump also attached).

gdb ./pyexceptions-sample core.31283

Core was generated by `./pyexceptions-sample'.
Program terminated with signal 11, Segmentation fault.
[New process 31283]
#0  PyErr_Restore (type=0x60000000000058f0, value=0x2000000000435030,
traceback=0x0) at Python/errors.c:39
39		oldtype = tstate->curexc_type;

(gdb) bt
#0  PyErr_Restore (type=0x60000000000058f0, value=0x2000000000435030,
traceback=0x0) at Python/errors.c:39
#1  0x4000000000125180 in PyErr_SetString (exception=0x60000000000058f0,
string=<value optimized out>) at Python/errors.c:57
#2  0x4000000000005eb0 in check_value ()
#3  0x4000000000006670 in main ()

(gdb) info args
type = (PyObject *) 0x60000000000058f0
value = (PyObject *) 0x2000000000435030
traceback = (PyObject *) 0x0

(gdb) info locals
tstate = (PyThreadState *) 0x0
oldtype = <value optimized out>
oldvalue = <value optimized out>
oldtraceback = <value optimized out>

(Looks like NULL ptr dereference in tstate = (PyThreadState *)).

Could you please have a look?

Thanks && regards, Jan.
--
Jan iankko Lieskovsky

----------
components: Interpreter Core
files: pyexceptions-sample.tar.gz
messages: 90026
nosy: iankko
severity: normal
status: open
title: Crash after attempt to set the error indicator via PyErr_SetString()
type: crash
versions: Python 2.4, Python 2.5, Python 2.6
Added file: http://bugs.python.org/file14428/pyexceptions-sample.tar.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6402>
_______________________________________

From report at bugs.python.org  Thu Jul  2 19:00:18 2009
From: report at bugs.python.org (Jan Lieskovsky)
Date: Thu, 02 Jul 2009 17:00:18 +0000
Subject: [issue6402] Crash after attempt to set the error indicator via
	PyErr_SetString()
In-Reply-To: <1246553666.48.0.84202001291.issue6402@psf.upfronthosting.co.za>
Message-ID: <1246554018.07.0.540160045477.issue6402@psf.upfronthosting.co.za>


Changes by Jan Lieskovsky <iankko at seznam.cz>:


Added file: http://bugs.python.org/file14429/core.31283.bz2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6402>
_______________________________________

From report at bugs.python.org  Thu Jul  2 19:04:11 2009
From: report at bugs.python.org (Jan Lieskovsky)
Date: Thu, 02 Jul 2009 17:04:11 +0000
Subject: [issue6402] Crash after attempt to set the error indicator via
	PyErr_SetString()
In-Reply-To: <1246553666.48.0.84202001291.issue6402@psf.upfronthosting.co.za>
Message-ID: <1246554251.32.0.379235131198.issue6402@psf.upfronthosting.co.za>


Changes by Jan Lieskovsky <iankko at seznam.cz>:


----------
nosy: +benjamin.peterson, gregory.p.smith, pitrou, psss

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6402>
_______________________________________

From report at bugs.python.org  Thu Jul  2 19:07:59 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 02 Jul 2009 17:07:59 +0000
Subject: [issue6119] Confusing DeprecationWarning
In-Reply-To: <1243373041.06.0.391551220918.issue6119@psf.upfronthosting.co.za>
Message-ID: <1246554479.25.0.391840106075.issue6119@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r73774.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6119>
_______________________________________

From report at bugs.python.org  Thu Jul  2 19:56:34 2009
From: report at bugs.python.org (chkneo)
Date: Thu, 02 Jul 2009 17:56:34 +0000
Subject: [issue5111] httplib: wrong Host header when connecting to IPv6
	litteral URL
In-Reply-To: <1233334139.62.0.259128767537.issue5111@psf.upfronthosting.co.za>
Message-ID: <1246557394.42.0.262752922159.issue5111@psf.upfronthosting.co.za>


chkneo <chkneo at gmail.com> added the comment:

Attaching the test patch

----------
Added file: http://bugs.python.org/file14430/5311_test.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5111>
_______________________________________

From report at bugs.python.org  Thu Jul  2 20:17:23 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 02 Jul 2009 18:17:23 +0000
Subject: [issue4618] print_function and unicode_literals don't work together
In-Reply-To: <1228915146.01.0.235938679842.issue4618@psf.upfronthosting.co.za>
Message-ID: <1246558643.77.0.499831689331.issue4618@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r73776.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4618>
_______________________________________

From report at bugs.python.org  Thu Jul  2 20:24:56 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 02 Jul 2009 18:24:56 +0000
Subject: [issue5999] compile error on HP-UX 11.22 ia64 - 'mbstate_t' is
	used	as a type, but has not been defined as a type
In-Reply-To: <1242077074.29.0.376465629361.issue5999@psf.upfronthosting.co.za>
Message-ID: <1246559096.46.0.141373607855.issue5999@psf.upfronthosting.co.za>


Changes by Sridhar Ratnakumar <sridharr at activestate.com>:


Added file: http://bugs.python.org/file14431/_mbstate_t.h

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5999>
_______________________________________

From report at bugs.python.org  Thu Jul  2 20:25:35 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 02 Jul 2009 18:25:35 +0000
Subject: [issue5999] compile error on HP-UX 11.22 ia64 - 'mbstate_t' is
	used	as a type, but has not been defined as a type
In-Reply-To: <1242077074.29.0.376465629361.issue5999@psf.upfronthosting.co.za>
Message-ID: <1246559135.42.0.557754235362.issue5999@psf.upfronthosting.co.za>


Changes by Sridhar Ratnakumar <sridharr at activestate.com>:


Added file: http://bugs.python.org/file14432/test.c.preprocessed.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5999>
_______________________________________

From report at bugs.python.org  Thu Jul  2 20:27:54 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 02 Jul 2009 18:27:54 +0000
Subject: [issue5999] compile error on HP-UX 11.22 ia64 - 'mbstate_t' is
	used	as a type, but has not been defined as a type
In-Reply-To: <1242077074.29.0.376465629361.issue5999@psf.upfronthosting.co.za>
Message-ID: <1246559274.76.0.767590353016.issue5999@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

I've attached the files you requested.

> As a wild guess, try defining _XOPEN_SOURCE to 500, 
> i.e. -D_XOPEN_SOURCE=500.

Yes, this works .. the file compiles. I tried modifying the value of 
_XOPEN_SOURCE to 500 in pyconfig.h (currently set to 600). While fixes 
the mbstate_t error .. it results in in-numerous other errors.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5999>
_______________________________________

From report at bugs.python.org  Thu Jul  2 20:28:26 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 02 Jul 2009 18:28:26 +0000
Subject: [issue6389] os.chmod() documentation refers to non-existent
	documentation in stat
In-Reply-To: <1246376943.24.0.988862914661.issue6389@psf.upfronthosting.co.za>
Message-ID: <1246559306.91.0.986083963415.issue6389@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I've added the documentation of the flags defined in the stat module in
r73778, with the os.chmod references to the hyperlinked.  The
descriptions are taken from the linux stat(2) page, so if anyone spots
any cross-platform inaccuracies let me know.  (As far as I can see the
flags are defined on Windows, they are just meaningless there, for the
most part).

----------
assignee: georg.brandl -> r.david.murray
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6389>
_______________________________________

From report at bugs.python.org  Thu Jul  2 20:29:26 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 02 Jul 2009 18:29:26 +0000
Subject: [issue5999] compile error on HP-UX 11.22 ia64 - 'mbstate_t' is
	used	as a type, but has not been defined as a type
In-Reply-To: <1242077074.29.0.376465629361.issue5999@psf.upfronthosting.co.za>
Message-ID: <1246559366.01.0.82985143933.issue5999@psf.upfronthosting.co.za>


Changes by Sridhar Ratnakumar <sridharr at activestate.com>:


Added file: http://bugs.python.org/file14433/test.c_XOPEN_SOURCE_500_preprocessed.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5999>
_______________________________________

From report at bugs.python.org  Thu Jul  2 21:09:35 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 02 Jul 2009 19:09:35 +0000
Subject: [issue6402] Crash after attempt to set the error indicator via
	PyErr_SetString()
In-Reply-To: <1246553666.48.0.84202001291.issue6402@psf.upfronthosting.co.za>
Message-ID: <1246561775.66.0.387561453308.issue6402@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This bug tracker is not a place to obtain help. If it is primarily help
that you are after (which it seems to be from your last question), I
recommend that we close the issue, and you ask for help elsewhere.

Most likely, the error happens at a point in the code where there is no
thread state. You have to find out why that is - it could be either that
there is legitimately no thread state, in which case you shouldn't call
Python API, or it might be that the thread state was lost somehow, in
which case you should find out where it got lost.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6402>
_______________________________________

From report at bugs.python.org  Thu Jul  2 21:15:32 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 02 Jul 2009 19:15:32 +0000
Subject: [issue5999] compile error on HP-UX 11.22 ia64 - 'mbstate_t' is
	used	as a type, but has not been defined as a type
In-Reply-To: <1246559274.76.0.767590353016.issue5999@psf.upfronthosting.co.za>
Message-ID: <4A4D0750.2090709@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Yes, this works .. the file compiles. I tried modifying the value of 
> _XOPEN_SOURCE to 500 in pyconfig.h (currently set to 600). 

That's an HPUX bug then, please report it to HP. They should assume
that any feature present in XPG 5 is also present in any later version.

> While fixes 
> the mbstate_t error .. it results in in-numerous other errors.

Well, we absolutely need mbstate_t, so we need to resolve all these
other errors.

Please be prepared for this becoming a many-months project. I don't
know what you need the HP-UX port for - maybe it would be best to hire
somebody who knows HP-UX, C, and Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5999>
_______________________________________

From report at bugs.python.org  Thu Jul  2 22:26:45 2009
From: report at bugs.python.org (ivank)
Date: Thu, 02 Jul 2009 20:26:45 +0000
Subject: [issue6403] distutils builds extension modules to root package
	directory
In-Reply-To: <1246566405.01.0.90148130878.issue6403@psf.upfronthosting.co.za>
Message-ID: <1246566405.01.0.90148130878.issue6403@psf.upfronthosting.co.za>


New submission from ivank <ivan at ludios.org>:

When I built Twisted, I noticed that 'python2.7 setup.py build' created
_c_urlang.so in the wrong place:

$ find . | grep _c_url
./twisted/protocols/_c_urlarg.c
./build/lib.linux-x86_64-2.7/_c_urlarg.so
./build/temp.linux-x86_64-2.7/twisted/protocols/_c_urlarg.o

I noticed the same problem when I built Mercurial 1.3, too.

This happens with svn r73778, but not svn r73145 (June 2). I don't know
which commit caused the problem. I don't know if the problem is in 3.x too.

----------
assignee: tarek
components: Distutils
messages: 90034
nosy: ivank, tarek
severity: normal
status: open
title: distutils builds extension modules to root package directory
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6403>
_______________________________________

From report at bugs.python.org  Thu Jul  2 22:35:26 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 02 Jul 2009 20:35:26 +0000
Subject: [issue6403] distutils builds extension modules to root package
	directory
In-Reply-To: <1246566405.01.0.90148130878.issue6403@psf.upfronthosting.co.za>
Message-ID: <1246566926.55.0.650238590652.issue6403@psf.upfronthosting.co.za>


Changes by Jean-Paul Calderone <exarkun at divmod.com>:


----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6403>
_______________________________________

From report at bugs.python.org  Thu Jul  2 23:01:10 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 02 Jul 2009 21:01:10 +0000
Subject: [issue6402] Crash after attempt to set the error indicator via
	PyErr_SetString()
In-Reply-To: <1246553666.48.0.84202001291.issue6402@psf.upfronthosting.co.za>
Message-ID: <1246568470.94.0.820085374819.issue6402@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6402>
_______________________________________

From report at bugs.python.org  Thu Jul  2 23:59:24 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 02 Jul 2009 21:59:24 +0000
Subject: [issue6363] __future__ statements break doctest
In-Reply-To: <1246242450.27.0.0341374672588.issue6363@psf.upfronthosting.co.za>
Message-ID: <1246571964.33.0.128934648598.issue6363@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r73782 and r73783.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6363>
_______________________________________

From report at bugs.python.org  Fri Jul  3 00:05:11 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 02 Jul 2009 22:05:11 +0000
Subject: [issue6403] distutils builds extension modules to root package
	directory
In-Reply-To: <1246566405.01.0.90148130878.issue6403@psf.upfronthosting.co.za>
Message-ID: <1246572311.35.0.364402561164.issue6403@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6403>
_______________________________________

From report at bugs.python.org  Fri Jul  3 01:10:56 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 02 Jul 2009 23:10:56 +0000
Subject: [issue6399] Error reporting by logging.config.fileConfig()
In-Reply-To: <1246528231.33.0.0905986098741.issue6399@psf.upfronthosting.co.za>
Message-ID: <1246576256.57.0.232344125388.issue6399@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Ignoring unknown options in the configuration file is analogous to
ignoring unknown tags in html: it makes it easier to use the same config
file with multiple versions of the logger, with older versions ignoring
the options they don't understand.  This is a tradeoff, and I suppose it
could be argued that the tradeoff is being made in the wrong direction
here.  I don't use configuration files for logging myself, so I'm not a
good person to render an opinion on that.

But IMO this is not a bug; changing the behavior would be a feature request.

----------
nosy: +r.david.murray, vsajip
priority:  -> low
type: behavior -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6399>
_______________________________________

From report at bugs.python.org  Fri Jul  3 01:57:33 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 02 Jul 2009 23:57:33 +0000
Subject: [issue4601] directory permission error with make install in 3.0
In-Reply-To: <1228771673.82.0.0596697860689.issue4601@psf.upfronthosting.co.za>
Message-ID: <1246579053.57.0.891446901111.issue4601@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Ok, fixed in r73788 and r73789.

----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4601>
_______________________________________

From report at bugs.python.org  Fri Jul  3 01:57:53 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 02 Jul 2009 23:57:53 +0000
Subject: [issue6404] 3.1 NEWS.txt points to alpha 2 file
In-Reply-To: <1246579072.98.0.262073120436.issue6404@psf.upfronthosting.co.za>
Message-ID: <1246579072.98.0.262073120436.issue6404@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

On Thu, 02 Jul 2009 16:43:15 -0700, <webmaster at python.org> wrote:

> On Mon, Jun 29, 2009, Sridhar Ratnakumar wrote:
>>
>> From http://www.python.org/download/releases/3.1/NEWS.txt
>>
>> (...)
>>
>> What's New in Python 3.1 alpha 2?
>> =================================
>>
>> *Release date: 2009-4-4*
>
> AFAICT, this isn't maintained by webmasters, please submit a report to
> bugs.python.org

----------
assignee: georg.brandl
components: Documentation
messages: 90038
nosy: georg.brandl, srid
severity: normal
status: open
title: 3.1 NEWS.txt points to alpha 2 file
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6404>
_______________________________________

From report at bugs.python.org  Fri Jul  3 02:02:18 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 03 Jul 2009 00:02:18 +0000
Subject: [issue6404] 3.1 NEWS.txt points to alpha 2 file
In-Reply-To: <1246579072.98.0.262073120436.issue6404@psf.upfronthosting.co.za>
Message-ID: <1246579338.82.0.876897600062.issue6404@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Already fixed...

----------
nosy: +benjamin.peterson
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6404>
_______________________________________

From report at bugs.python.org  Fri Jul  3 02:03:29 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Fri, 03 Jul 2009 00:03:29 +0000
Subject: [issue6395] Add Pickle Support to the codecs Module
In-Reply-To: <1246463188.35.0.320675118154.issue6395@psf.upfronthosting.co.za>
Message-ID: <1246579409.83.0.854888481717.issue6395@psf.upfronthosting.co.za>


Changes by Alexandre Vassalotti <alexandre at peadrop.com>:


----------
nosy: +alexandre.vassalotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6395>
_______________________________________

From report at bugs.python.org  Fri Jul  3 03:37:59 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 03 Jul 2009 01:37:59 +0000
Subject: [issue1652] subprocess should have an option to restore SIGPIPE to
	default action
In-Reply-To: <1197992466.47.0.0612439954222.issue1652@psf.upfronthosting.co.za>
Message-ID: <1246585079.61.0.710020580751.issue1652@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Find someone to review the patch and post their evaluation here.  It
doesn't have to be a committer, though that would be even better.

----------
nosy: +r.david.murray
stage:  -> patch review
versions: +Python 2.7, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1652>
_______________________________________

From report at bugs.python.org  Fri Jul  3 03:41:18 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 03 Jul 2009 01:41:18 +0000
Subject: [issue1652] subprocess should have an option to restore SIGPIPE to
	default action
In-Reply-To: <1197992466.47.0.0612439954222.issue1652@psf.upfronthosting.co.za>
Message-ID: <1246585278.24.0.668872462209.issue1652@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Hmm.  Looks like the patch is missing a unit test for the new feature.

----------
stage: patch review -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1652>
_______________________________________

From report at bugs.python.org  Fri Jul  3 04:41:51 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 03 Jul 2009 02:41:51 +0000
Subject: [issue6267] Cumulative patcc:h to http and xmlrpc
In-Reply-To: <1244734235.6.0.17264314682.issue6267@psf.upfronthosting.co.za>
Message-ID: <1246588911.34.0.724227097098.issue6267@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Before r73742, test_socketserver and test_urllib2_localnet work, after
this patchset is applied there are failures.  This is on Gentoo linux,
py3k.  See also issue 6381 and issue 6382, which are the same problems
on trunk.  (The test_urllib2_localnet failure seems to now be
consistently repeatable on my machine, for whatever reason.)

----------
components: +Library (Lib)
nosy: +r.david.murray
priority:  -> normal
stage:  -> needs patch
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6267>
_______________________________________

From report at bugs.python.org  Fri Jul  3 06:10:34 2009
From: report at bugs.python.org (Henry Precheur)
Date: Fri, 03 Jul 2009 04:10:34 +0000
Subject: [issue2775] Implement PEP 3108
In-Reply-To: <1210097469.77.0.880435072777.issue2775@psf.upfronthosting.co.za>
Message-ID: <1246594234.45.0.941565699013.issue2775@psf.upfronthosting.co.za>


Henry Precheur <henry at precheur.org> added the comment:

I found some bsddb code left in setup.py. Patch attached.

----------
nosy: +henry.precheur
Added file: http://bugs.python.org/file14434/setup.py.remove-bsddb.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2775>
_______________________________________

From report at bugs.python.org  Fri Jul  3 09:50:24 2009
From: report at bugs.python.org (Mike)
Date: Fri, 03 Jul 2009 07:50:24 +0000
Subject: [issue6399] Error reporting by logging.config.fileConfig()
In-Reply-To: <1246528231.33.0.0905986098741.issue6399@psf.upfronthosting.co.za>
Message-ID: <1246607424.07.0.546934171548.issue6399@psf.upfronthosting.co.za>


Mike <python at amadron.com> added the comment:

Fair point.  Agree that this is a feature request.  Perhaps something like:

logging.config.fileConfig(path, strict=False)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6399>
_______________________________________

From report at bugs.python.org  Fri Jul  3 09:57:04 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 03 Jul 2009 07:57:04 +0000
Subject: [issue6377] distutils compiler switch ignored
In-Reply-To: <1246299740.9.0.786372120366.issue6377@psf.upfronthosting.co.za>
Message-ID: <1246607824.91.0.350170374975.issue6377@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

yes, the problem is that this option (string) is also used as an
attribute (compiler object).

But Python itself uses as an attribute..

I have to check its type at this spot, and deprecate the usage of
"compiler" as an attribute.

----------
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6377>
_______________________________________

From report at bugs.python.org  Fri Jul  3 10:59:55 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 03 Jul 2009 08:59:55 +0000
Subject: [issue6403] distutils builds extension modules to root package
	directory
In-Reply-To: <1246566405.01.0.90148130878.issue6403@psf.upfronthosting.co.za>
Message-ID: <1246611595.13.0.795504214585.issue6403@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Related to #6365. I've added a test to make sure twisted builds with
'build' and 'build_ext -i'.

Fixed in r73790 and propagated in 2.6/3.1/3.2. 

Thanks for the feeback !

(I am also adding twisted in my buildbot to make sure trunk creates a
similar binary dist than 2.6)

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6403>
_______________________________________

From report at bugs.python.org  Fri Jul  3 13:07:23 2009
From: report at bugs.python.org (Floris Bruynooghe)
Date: Fri, 03 Jul 2009 11:07:23 +0000
Subject: [issue6405] Redundant redeclarations in descrobject.h
In-Reply-To: <1246619243.32.0.155882535989.issue6405@psf.upfronthosting.co.za>
Message-ID: <1246619243.32.0.155882535989.issue6405@psf.upfronthosting.co.za>


New submission from Floris Bruynooghe <floris.bruynooghe at gmail.com>:

There are redundant redeclarations for PyGetSetDescr_Type and
PyMemberDescr_Type in descrobject.h.  This is an issue when compiling an
extension module with the -Wredundant-decls flag:

In file included from /usr/local/include/python3.1/Python.h:98,
                 from src/util.c:27:
/usr/local/include/python3.1/descrobject.h:76: error: redundant
redeclaration of ?PyGetSetDescr_Type?
/usr/local/include/python3.1/descrobject.h:71: error: previous
declaration of ?PyGetSetDescr_Type? was here
/usr/local/include/python3.1/descrobject.h:77: error: redundant
redeclaration of ?PyMemberDescr_Type?
/usr/local/include/python3.1/descrobject.h:72: error: previous
declaration of ?PyMemberDescr_Type? was here
error: command 'gcc' failed with exit status 1

The patch is trivial.

----------
components: Extension Modules
files: descrobject.diff
keywords: patch
messages: 90047
nosy: flub
severity: normal
status: open
title: Redundant redeclarations in descrobject.h
type: compile error
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14435/descrobject.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6405>
_______________________________________

From report at bugs.python.org  Fri Jul  3 14:33:29 2009
From: report at bugs.python.org (Alejandro Santos)
Date: Fri, 03 Jul 2009 12:33:29 +0000
Subject: [issue6406] NameError on 2to3 tool
In-Reply-To: <1246624409.35.0.327265047408.issue6406@psf.upfronthosting.co.za>
Message-ID: <1246624409.35.0.327265047408.issue6406@psf.upfronthosting.co.za>


New submission from Alejandro Santos <alejolp at alejolp.com>:

Using the -j switch of the 2to3 tool shiped with Python 3.1 final i'm
getting:

Traceback (most recent call last):
  File "/home/alejo/apps/local/bin/2to3", line 6, in <module>
    sys.exit(main("lib2to3.fixes"))
  File "/home/alejo/apps/local/lib/python3.1/lib2to3/main.py", line 132,
in main
    options.processes)
  File "/home/alejo/apps/local/lib/python3.1/lib2to3/refactor.py", line
553, in refactor
    for i in xrange(num_processes)]
NameError: global name 'xrange' is not defined

Attached patch seems to work fine.

----------
components: 2to3 (2.x to 3.0 conversion tool)
files: 2to3-xrange.patch
keywords: patch
messages: 90048
nosy: alejolp, djc
severity: normal
status: open
title: NameError on 2to3 tool
type: crash
versions: Python 3.1
Added file: http://bugs.python.org/file14436/2to3-xrange.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6406>
_______________________________________

From report at bugs.python.org  Fri Jul  3 15:11:35 2009
From: report at bugs.python.org (Senthil)
Date: Fri, 03 Jul 2009 13:11:35 +0000
Subject: [issue2977] truncation of text in tables in Library Reference PDF
In-Reply-To: <1211834269.04.0.0744383580947.issue2977@psf.upfronthosting.co.za>
Message-ID: <1246626695.09.0.481088664567.issue2977@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

I verified the library reference pdf files from the trunk and I 
don't see this problem. Should we close the issue then?

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2977>
_______________________________________

From report at bugs.python.org  Fri Jul  3 15:21:45 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 03 Jul 2009 13:21:45 +0000
Subject: [issue6406] NameError on 2to3 tool
In-Reply-To: <1246624409.35.0.327265047408.issue6406@psf.upfronthosting.co.za>
Message-ID: <1246627305.96.0.996273677439.issue6406@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

And that's what we get for not having unittests for the accursed
feature... Fixed in r73805.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6406>
_______________________________________

From report at bugs.python.org  Fri Jul  3 15:23:06 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 03 Jul 2009 13:23:06 +0000
Subject: [issue2775] Implement PEP 3108
In-Reply-To: <1210097469.77.0.880435072777.issue2775@psf.upfronthosting.co.za>
Message-ID: <1246627386.65.0.338224243424.issue2775@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Thanks for the patch. Applied in r738067.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2775>
_______________________________________

From report at bugs.python.org  Fri Jul  3 15:23:18 2009
From: report at bugs.python.org (Matthew Leon Grinshpun)
Date: Fri, 03 Jul 2009 13:23:18 +0000
Subject: [issue6407] multiprocessing Pool should allow custom task queue
In-Reply-To: <1246627398.56.0.0568609724018.issue6407@psf.upfronthosting.co.za>
Message-ID: <1246627398.56.0.0568609724018.issue6407@psf.upfronthosting.co.za>


New submission from Matthew Leon Grinshpun <vertespain at gmail.com>:

Multiprocessing's Pool class __init__ method is written in a way that
makes it very difficult for a subclass to modify self._taskqueue. There
are very good reasons for wanting to do this - ie, making the taskqueue
block when it reaches a certain size. It seems to me that simply moving
the taskqueue assignment into _setup_queues() would do the trick.

The following usenet group discussion contains further details:

http://groups.google.com/group/comp.lang.python/browse_thread/thread/e6c67a09fb20cdec#

----------
components: Library (Lib)
messages: 90052
nosy: masher
severity: normal
status: open
title: multiprocessing Pool should allow custom task queue
type: feature request
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6407>
_______________________________________

From report at bugs.python.org  Fri Jul  3 15:30:53 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 03 Jul 2009 13:30:53 +0000
Subject: [issue6405] Redundant redeclarations in descrobject.h
In-Reply-To: <1246619243.32.0.155882535989.issue6405@psf.upfronthosting.co.za>
Message-ID: <1246627853.31.0.849863837628.issue6405@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r73809.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6405>
_______________________________________

From report at bugs.python.org  Fri Jul  3 15:35:58 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 03 Jul 2009 13:35:58 +0000
Subject: [issue6407] multiprocessing Pool should allow custom task queue
In-Reply-To: <1246627398.56.0.0568609724018.issue6407@psf.upfronthosting.co.za>
Message-ID: <1246628158.21.0.508405627762.issue6407@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> jnoller
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6407>
_______________________________________

From report at bugs.python.org  Fri Jul  3 15:37:00 2009
From: report at bugs.python.org (Alejandro Santos)
Date: Fri, 03 Jul 2009 13:37:00 +0000
Subject: [issue6406] NameError on 2to3 tool
In-Reply-To: <1246624409.35.0.327265047408.issue6406@psf.upfronthosting.co.za>
Message-ID: <1246628220.84.0.638951980125.issue6406@psf.upfronthosting.co.za>


Alejandro Santos <alejolp at alejolp.com> added the comment:

Thanks!!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6406>
_______________________________________

From report at bugs.python.org  Fri Jul  3 15:50:37 2009
From: report at bugs.python.org (Alejandro Santos)
Date: Fri, 03 Jul 2009 13:50:37 +0000
Subject: [issue6408] 2to3: Local package import
In-Reply-To: <1246629036.25.0.586773207888.issue6408@psf.upfronthosting.co.za>
Message-ID: <1246629036.25.0.586773207888.issue6408@psf.upfronthosting.co.za>


New submission from Alejandro Santos <alejolp at alejolp.com>:

The 2to3 tool shipped with Python 3.1 final doesn't handle correctly a
local package import (fixer fix_import). Test case:

$ find . -name '*.py'
./__init__.py
./a.py
./b/__init__.py
./b/m.py

$ 2to3 a.py
RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: set_literal
RefactoringTool: Skipping implicit fixer: ws_comma
RefactoringTool: No files need to be modified.

$ cat a.py

from b import m

m.q()


Trying to use the 2to3 tool from one level up won't work either:

$ 2to3 test2to3/a.py
RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: set_literal
RefactoringTool: Skipping implicit fixer: ws_comma
RefactoringTool: No files need to be modified.

It seems to be a bug in the fixer, which is using the os.path.pathsep
constant when it should be using the os.path.sep instead. 

The probably_a_local_import function is checking if "test2to3/b:"
exists, when it should be checking against: "test2to3/b/"

Attached patch seems to be working:

$ 2to3 test2to3/a.py
RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: set_literal
RefactoringTool: Skipping implicit fixer: ws_comma
--- test2to3/a.py (original)
+++ test2to3/a.py (refactored)
@@ -1,5 +1,5 @@
 
-from b import m
+from .b import m
 
 m.q()
 
RefactoringTool: Files that need to be modified:
RefactoringTool: test2to3/a.py

----------
components: 2to3 (2.x to 3.0 conversion tool)
files: 2to3-os.path.sep.path
messages: 90055
nosy: alejolp, djc
severity: normal
status: open
title: 2to3: Local package import
versions: Python 3.1
Added file: http://bugs.python.org/file14437/2to3-os.path.sep.path

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6408>
_______________________________________

From report at bugs.python.org  Fri Jul  3 15:51:01 2009
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 03 Jul 2009 13:51:01 +0000
Subject: [issue6407] multiprocessing Pool should allow custom task queue
In-Reply-To: <1246627398.56.0.0568609724018.issue6407@psf.upfronthosting.co.za>
Message-ID: <1246629061.0.0.941332384856.issue6407@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

I'm not against this; new features will only be committed to the 2.7 and 
3.1.x branches however. 

Something to help speed this up would be an actual patch with docs/tests 
for the module made against python trunk. That way I could review and 
simply submit.

----------
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6407>
_______________________________________

From report at bugs.python.org  Fri Jul  3 16:03:37 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 03 Jul 2009 14:03:37 +0000
Subject: [issue6408] 2to3: Local package import
In-Reply-To: <1246629036.25.0.586773207888.issue6408@psf.upfronthosting.co.za>
Message-ID: <1246629817.75.0.00940255789117.issue6408@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r73811.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6408>
_______________________________________

From report at bugs.python.org  Fri Jul  3 16:04:52 2009
From: report at bugs.python.org (Alejandro Santos)
Date: Fri, 03 Jul 2009 14:04:52 +0000
Subject: [issue6408] 2to3: Local package import
In-Reply-To: <1246629036.25.0.586773207888.issue6408@psf.upfronthosting.co.za>
Message-ID: <1246629892.13.0.326068723338.issue6408@psf.upfronthosting.co.za>


Alejandro Santos <alejolp at alejolp.com> added the comment:

Nice, Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6408>
_______________________________________

From report at bugs.python.org  Fri Jul  3 16:07:18 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 03 Jul 2009 14:07:18 +0000
Subject: [issue1172711] long long support for array module
Message-ID: <1246630038.94.0.445877941666.issue1172711@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

How about this patch? I haven't tested so intensely, but testcase seems
working.

----------
nosy: +ocean-city
Added file: http://bugs.python.org/file14438/array_long_long.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1172711>
_______________________________________

From report at bugs.python.org  Fri Jul  3 16:16:28 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 03 Jul 2009 14:16:28 +0000
Subject: [issue6267] Cumulative patcc:h to http and xmlrpc
In-Reply-To: <1244734235.6.0.17264314682.issue6267@psf.upfronthosting.co.za>
Message-ID: <1246630588.31.0.900630038668.issue6267@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The port to py3k has an error, see
http://mail.python.org/pipermail/python-checkins/2009-July/084734.html

Indexing is no more allowed on exception objects. it may be replaced
with e.args[0], or better, with e.errno.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6267>
_______________________________________

From report at bugs.python.org  Fri Jul  3 16:17:37 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 03 Jul 2009 14:17:37 +0000
Subject: [issue1172711] long long support for array module
Message-ID: <1246630657.49.0.634915959749.issue1172711@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


Added file: http://bugs.python.org/file14439/array_long_long.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1172711>
_______________________________________

From report at bugs.python.org  Fri Jul  3 16:17:46 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 03 Jul 2009 14:17:46 +0000
Subject: [issue1172711] long long support for array module
Message-ID: <1246630666.73.0.357392965087.issue1172711@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


Removed file: http://bugs.python.org/file14438/array_long_long.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1172711>
_______________________________________

From report at bugs.python.org  Fri Jul  3 16:25:31 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 03 Jul 2009 14:25:31 +0000
Subject: [issue5117] os.path.relpath problem with root directory
In-Reply-To: <1233386752.72.0.952122419494.issue5117@psf.upfronthosting.co.za>
Message-ID: <1246631131.95.0.640529908709.issue5117@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Maybe this patch should be updated because os.path functions changed
their behaviors for UNC in py3k. (#5799)

----------
dependencies: +Change ntpath functions to implicitly support UNC paths

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5117>
_______________________________________

From report at bugs.python.org  Fri Jul  3 16:28:59 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 03 Jul 2009 14:28:59 +0000
Subject: [issue5117] os.path.relpath problem with root directory
In-Reply-To: <1233386752.72.0.952122419494.issue5117@psf.upfronthosting.co.za>
Message-ID: <1246631339.75.0.745928533093.issue5117@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


----------
versions: +Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5117>
_______________________________________

From report at bugs.python.org  Fri Jul  3 16:32:58 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 03 Jul 2009 14:32:58 +0000
Subject: [issue1195571] simple callback system for Py_FatalError
Message-ID: <1246631578.2.0.610290716125.issue1195571@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Here is a refreshed patch against trunk.
Since the previous one did not provide any context, I hope I copied the
lines in the right locations.

----------
keywords: +needs review
nosy: +amaury.forgeotdarc
Added file: http://bugs.python.org/file14440/fatalhook.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1195571>
_______________________________________

From report at bugs.python.org  Fri Jul  3 17:24:24 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 03 Jul 2009 15:24:24 +0000
Subject: [issue894936] Have a split corresponding with os.path.join
Message-ID: <1246634664.65.0.92118600569.issue894936@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I still fail to see how 'splitall' would be useful.
How is it a problem that "str.split is incompatible with os.path.join" ?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue894936>
_______________________________________

From report at bugs.python.org  Fri Jul  3 17:53:47 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Fri, 03 Jul 2009 15:53:47 +0000
Subject: [issue6409] 2to3 generates malformed diffs
In-Reply-To: <1246636426.08.0.872531312657.issue6409@psf.upfronthosting.co.za>
Message-ID: <1246636426.08.0.872531312657.issue6409@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

I ran 2to3 over Twisted r27084 like this:

time ~/Projects/python/trunk/python
/home/exarkun/Projects/python/trunk/Tools/scripts/2to3 -j 4 twisted/ >
2to3.patch

Visual inspection revealed some curious defects, and attempting to apply
it failed like this:

$ patch -p0 < 2to3.patch 
patching file twisted/application/app.py
patching file twisted/conch/client/connect.py
patching file twisted/conch/client/default.py
patch: **** malformed patch at line 129: @@ -1,6 +1,6 @@

The resulting file is attached.

----------
components: Library (Lib)
files: 2to3.patch
keywords: patch
messages: 90064
nosy: exarkun
severity: normal
status: open
title: 2to3 generates malformed diffs
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file14441/2to3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6409>
_______________________________________

From report at bugs.python.org  Fri Jul  3 18:01:07 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 03 Jul 2009 16:01:07 +0000
Subject: [issue6409] 2to3 generates malformed diffs
In-Reply-To: <1246636426.08.0.872531312657.issue6409@psf.upfronthosting.co.za>
Message-ID: <1246636867.81.0.223040469821.issue6409@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

You seem to use the 'parallel' option. Some flush() or synchronization
missing?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6409>
_______________________________________

From report at bugs.python.org  Fri Jul  3 18:18:25 2009
From: report at bugs.python.org (Elvis Pranskevichus)
Date: Fri, 03 Jul 2009 16:18:25 +0000
Subject: [issue5672] Implement a way to change the python process name
In-Reply-To: <1238701084.1.0.0781987214897.issue5672@psf.upfronthosting.co.za>
Message-ID: <1246637905.24.0.725937753968.issue5672@psf.upfronthosting.co.za>


Elvis Pranskevichus <elprans at gmail.com> added the comment:

> Please don't provide a wrapper around ptrctrl

prctl is not portable. I always thought that the premise of stdlib is to
provide portable interfaces.  BSD, for example, uses setprocname instead
of prctl.  Also, prctl does not modify the process name shown in "ps
uxww". Here's how PostgreSQL does this: http://tinyurl.com/mhjuqc.

----------
nosy: +elprans

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5672>
_______________________________________

From report at bugs.python.org  Fri Jul  3 18:35:41 2009
From: report at bugs.python.org (Matthew Leon Grinshpun)
Date: Fri, 03 Jul 2009 16:35:41 +0000
Subject: [issue6407] multiprocessing Pool should allow custom task queue
In-Reply-To: <1246627398.56.0.0568609724018.issue6407@psf.upfronthosting.co.za>
Message-ID: <1246638941.62.0.598567477173.issue6407@psf.upfronthosting.co.za>


Matthew Leon Grinshpun <vertespain at gmail.com> added the comment:

I have attached a patch. All I did was shift the one line from __init__
to _setup_queues.

That's it.

You could take advantage of the change in the following way:

class BlockingPool(pool.Pool):
    def _setup_queues(self):
        pool.Pool._setup_queues(self)
        self._taskqueue = Queue(3)
        self._inqueue = Queue(3)
        self._quick_put = self._inqueue.put

Because of the design of _handle_tasks thread, you need to cap both
_taskqueue and _inqueue for blocking to work out.

I can't see any potential problems caused by this change, but I have
little experience working with this module so far.

----------
keywords: +patch
Added file: http://bugs.python.org/file14442/multiproc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6407>
_______________________________________

From report at bugs.python.org  Fri Jul  3 19:05:08 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 03 Jul 2009 17:05:08 +0000
Subject: [issue6399] Error reporting by logging.config.fileConfig()
In-Reply-To: <1246528231.33.0.0905986098741.issue6399@psf.upfronthosting.co.za>
Message-ID: <1246640708.53.0.445143741322.issue6399@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I'm not sure that this is a valid feature request. As R. David Murray
has said, it's sort of an unwritten rule of ConfigParser-based
applications that they look for specific entries, but don't care what
else is there in the file - sort of in line with Postel's Law.

The appearance of multiple messages pretty much points to multiple
handlers handling the message; knowing the way the hierarchy works,
propagation should have been one of the first things to check (as I
assume you had added handlers both at and above [logger_Builder]. I know
hindsight is wonderful, and I'm sorry it took you 4 hours to find the
problem; but I'm not convinced by this that I need to put more error
checking into the fileConfig code.

----------
resolution:  -> invalid
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6399>
_______________________________________

From report at bugs.python.org  Fri Jul  3 19:37:08 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 03 Jul 2009 17:37:08 +0000
Subject: [issue2977] truncation of text in tables in Library Reference PDF
In-Reply-To: <1211834269.04.0.0744383580947.issue2977@psf.upfronthosting.co.za>
Message-ID: <1246642628.3.0.985483862223.issue2977@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2977>
_______________________________________

From report at bugs.python.org  Fri Jul  3 20:00:06 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 03 Jul 2009 18:00:06 +0000
Subject: [issue894936] Have a split corresponding with os.path.join
Message-ID: <1246644006.59.0.506860939227.issue894936@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I think the OP meant os.path.split, not str.split, but I don't
understand what incompatibility he is referring to.  This seems to work
fine:

>>> ntpath.join(*ntpath.split("Z:/xyz"))
'Z:/xyz'

That said, I'd like to note that I was surprised the first few times I
used os.path.split to find that it did only one split.  I fully expected
it to be symetric with os.path.join and analogous to str.split and give
me a list of path components.

After thinking about this for a while, I think there are enough
subleties involved in doing this operation that it would be worth having
a cannonical function to do it the "right way" (which, IMO, is not how
the proposed patch does it!)

Here is what I think it should produce:

  D:/abc\\xyz.ext   -->    ['D:\\', 'abc', 'xyz.ext']
  D:abc/xyz.ext     -->    ['D:', 'abc', 'xyz.ext']
  
I don't think this is what the OP is expecting, but I think it is
necessary to keep the drive attached to the first path element to avoid
ambiguity and to be consistent with the rest of the os.path semantics.

The reason I think this is worth doing is that otherwise what one would
do to produce the list of path components would be something like:

  drive, rpath = splitdrive(normpath("D:/abc/def.ext"))
  pathcomponents = rpath.split(sep)

which produces the result:

   ['', 'abc', 'def.ext']

when what one really wants is:

   ['\\', 'abc', 'def.ext']

Yes, your code can treat '' as indicating an absolute path, but that
adds one more step to the mutlistep process, the omission of any one of
which leads to subtle bugs.  Better to have a function that does it right.

Now, the question is, are there enough real use cases for this function
to motivate someone to do the work to add it?  I don't have any myself.

----------
nosy: +r.david.murray
priority: normal -> low
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue894936>
_______________________________________

From report at bugs.python.org  Fri Jul  3 20:11:57 2009
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 03 Jul 2009 18:11:57 +0000
Subject: [issue6407] multiprocessing Pool should allow custom task queue
In-Reply-To: <1246627398.56.0.0568609724018.issue6407@psf.upfronthosting.co.za>
Message-ID: <1246644717.94.0.911521684981.issue6407@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Thanks Matthew - I agree, it's simple. But fixing the code is 1/3 of the 
patch. I'll need to add tests/update the ones there as well as modify the 
.rst documentation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6407>
_______________________________________

From report at bugs.python.org  Fri Jul  3 20:31:09 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Jul 2009 18:31:09 +0000
Subject: [issue6353] "L" integer suffix in Python 3.1 tutorial
In-Reply-To: <1246175705.48.0.727392252197.issue6353@psf.upfronthosting.co.za>
Message-ID: <1246645869.83.0.971340793.issue6353@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Pierre, before submitting doc issues, you can check the 'in-development'
version of the docs at
http://docs.python.org/dev/py3k/
to see if an issue has been fixed. This is currently labeled "Python
v3.2a0 documentation"

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6353>
_______________________________________

From report at bugs.python.org  Fri Jul  3 21:47:34 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 03 Jul 2009 19:47:34 +0000
Subject: [issue6353] "L" integer suffix in Python 3.1 tutorial
In-Reply-To: <1246175705.48.0.727392252197.issue6353@psf.upfronthosting.co.za>
Message-ID: <1246650454.14.0.622186039902.issue6353@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

ezio.melotti:  do you mean r73658? (which was committed after
delroth submitted the report :-).

----------
nosy: +marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6353>
_______________________________________

From report at bugs.python.org  Fri Jul  3 21:53:27 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 03 Jul 2009 19:53:27 +0000
Subject: [issue6353] "L" integer suffix in Python 3.1 tutorial
In-Reply-To: <1246175705.48.0.727392252197.issue6353@psf.upfronthosting.co.za>
Message-ID: <1246650807.72.0.0338952624561.issue6353@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Yes, I was looking at the diff between the two and I probably picked up
the wrong one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6353>
_______________________________________

From report at bugs.python.org  Fri Jul  3 22:33:59 2009
From: report at bugs.python.org (Michael W.)
Date: Fri, 03 Jul 2009 20:33:59 +0000
Subject: [issue6410] Dictionaries should support __add__
In-Reply-To: <1246653238.95.0.314927755738.issue6410@psf.upfronthosting.co.za>
Message-ID: <1246653238.95.0.314927755738.issue6410@psf.upfronthosting.co.za>


New submission from Michael W. <hotdog003 at gmail.com>:

Summary:
Dictionaries should support being added to other dictionaries instead of
using update(). This should be a relatively easy fix and would make the
language more pythonic.

How to reproduce:
$ python
Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41) 
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> {1: 2, 3: 4} + {5: 6, 7: 8}

What happens:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'dict' and 'dict'

What should happen:
{1: 2, 3: 4, 5: 6, 7: 8}

Temporary workaround:
>>> a = {1: 2, 3: 4}
>>> b = {5: 6, 7: 8}
>>> c = a.copy()
>>> c.update(b)
>>> print c
{1: 2, 3: 4, 5: 6, 7: 8}
This is undesirable because it is not very compact and hard to read. Why
should any language take five lines of code to merge only two dictionaries?

----------
components: Interpreter Core
messages: 90074
nosy: hotdog003
severity: normal
status: open
title: Dictionaries should support __add__
type: feature request
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6410>
_______________________________________

From report at bugs.python.org  Fri Jul  3 23:14:03 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 03 Jul 2009 21:14:03 +0000
Subject: [issue6410] Dictionaries should support __add__
In-Reply-To: <1246653238.95.0.314927755738.issue6410@psf.upfronthosting.co.za>
Message-ID: <1246655643.74.0.750768711653.issue6410@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

What would you do in case of duplicate keys?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6410>
_______________________________________

From report at bugs.python.org  Fri Jul  3 23:17:48 2009
From: report at bugs.python.org (corban)
Date: Fri, 03 Jul 2009 21:17:48 +0000
Subject: [issue6411] 3.1 not functional
In-Reply-To: <1246655868.68.0.634239679631.issue6411@psf.upfronthosting.co.za>
Message-ID: <1246655868.68.0.634239679631.issue6411@psf.upfronthosting.co.za>


New submission from corban <element.effect at gmail.com>:

After downloading v. 3.1, I couldnt get it to perform even the most 
simple functions. I am somewhat new to the programming so I dont know 
if there is something simple that I am missing or if it is a possible 
bug with the system.

----------
messages: 90076
nosy: element.effect
severity: normal
status: open
title: 3.1 not functional
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6411>
_______________________________________

From report at bugs.python.org  Fri Jul  3 23:22:50 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Fri, 03 Jul 2009 21:22:50 +0000
Subject: [issue6411] 3.1 not functional
In-Reply-To: <1246655868.68.0.634239679631.issue6411@psf.upfronthosting.co.za>
Message-ID: <1246656170.71.0.635214098272.issue6411@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Could you elaborate on what is problem exactly? Please include any error
message you are getting. Also, what operating system are you using?

----------
nosy: +alexandre.vassalotti
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6411>
_______________________________________

From report at bugs.python.org  Fri Jul  3 23:25:41 2009
From: report at bugs.python.org (corban)
Date: Fri, 03 Jul 2009 21:25:41 +0000
Subject: [issue6411] 3.1 not functional
In-Reply-To: <1246655868.68.0.634239679631.issue6411@psf.upfronthosting.co.za>
Message-ID: <1246656341.95.0.680141121373.issue6411@psf.upfronthosting.co.za>


corban <element.effect at gmail.com> added the comment:

I am using windows xp. I dont have the exact error message because I've 
already uninstalled in and went with v/ 2.6.2 (which seems to be 
working fine.) But it was telling me to be a syntax error and would 
always highlight the blank space after any command as if that were the 
issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6411>
_______________________________________

From report at bugs.python.org  Fri Jul  3 23:28:05 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 03 Jul 2009 21:28:05 +0000
Subject: [issue6411] 3.1 not functional
In-Reply-To: <1246655868.68.0.634239679631.issue6411@psf.upfronthosting.co.za>
Message-ID: <1246656485.06.0.454839288637.issue6411@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Maybe you used "print foo" instead of "print(foo)". In Python3 print is
a function and if you don't use the () you get this:
>>> print foo
  File "<stdin>", line 1
    print foo
            ^
SyntaxError: invalid syntax

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6411>
_______________________________________

From report at bugs.python.org  Fri Jul  3 23:31:25 2009
From: report at bugs.python.org (corban)
Date: Fri, 03 Jul 2009 21:31:25 +0000
Subject: [issue6411] 3.1 not functional
In-Reply-To: <1246655868.68.0.634239679631.issue6411@psf.upfronthosting.co.za>
Message-ID: <1246656685.09.0.304973041312.issue6411@psf.upfronthosting.co.za>


corban <element.effect at gmail.com> added the comment:

Are there many changes like this with functions because what little 
I've learned is from v. 2.6.2 and most lessons seem to be based around 
that style as well. Im trying to teach myself and need to know which 
version would be better.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6411>
_______________________________________

From report at bugs.python.org  Fri Jul  3 23:37:01 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Fri, 03 Jul 2009 21:37:01 +0000
Subject: [issue6410] Dictionaries should support __add__
In-Reply-To: <1246653238.95.0.314927755738.issue6410@psf.upfronthosting.co.za>
Message-ID: <1246657021.95.0.142460473749.issue6410@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

I am against adding __add__ to dict, since merging dictionaries is not a
commutative operation.

If a short syntax is desired for merging dictionaries, the just define a
function. For example: 

def merge_dicts(*args):
  result = {}
  for x in args:
    result.update(x)
  return result

----------
nosy: +alexandre.vassalotti
resolution:  -> rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6410>
_______________________________________

From report at bugs.python.org  Fri Jul  3 23:37:20 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 03 Jul 2009 21:37:20 +0000
Subject: [issue6411] 3.1 not functional
In-Reply-To: <1246655868.68.0.634239679631.issue6411@psf.upfronthosting.co.za>
Message-ID: <1246657040.02.0.147932952341.issue6411@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

If you want to know what changed in Python 3 you can read
http://docs.python.org/3.0/whatsnew/3.0.html
If you are learning Python and you need help you can ask on
comp.lang.python or on #python (server: irc.freenode.net).
Closing as invalid.

----------
resolution:  -> invalid
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6411>
_______________________________________

From report at bugs.python.org  Fri Jul  3 23:40:45 2009
From: report at bugs.python.org (corban)
Date: Fri, 03 Jul 2009 21:40:45 +0000
Subject: [issue6411] 3.1 not functional
In-Reply-To: <1246655868.68.0.634239679631.issue6411@psf.upfronthosting.co.za>
Message-ID: <1246657245.56.0.289302205106.issue6411@psf.upfronthosting.co.za>


corban <element.effect at gmail.com> added the comment:

>From what I can see, the older version of python may be easier to learn 
for a programming novice. It seems to be a little less complicated 
overall.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6411>
_______________________________________

From report at bugs.python.org  Sat Jul  4 01:00:00 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 03 Jul 2009 23:00:00 +0000
Subject: [issue6381] test_urllib2_localnet sporadic failures closing socket
In-Reply-To: <1246326020.83.0.77401775469.issue6381@psf.upfronthosting.co.za>
Message-ID: <1246662000.5.0.886735134837.issue6381@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Clearly some platforms automatically set the shutdown state, and we need 
to catch that error.

----------
nosy: +krisvale

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6381>
_______________________________________

From report at bugs.python.org  Sat Jul  4 01:07:36 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 03 Jul 2009 23:07:36 +0000
Subject: [issue6381] test_urllib2_localnet sporadic failures closing socket
In-Reply-To: <1246326020.83.0.77401775469.issue6381@psf.upfronthosting.co.za>
Message-ID: <1246662456.08.0.785781168788.issue6381@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Commited revision 73819
Please test on gentoo

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6381>
_______________________________________

From report at bugs.python.org  Sat Jul  4 01:14:49 2009
From: report at bugs.python.org (Christoph Burgmer)
Date: Fri, 03 Jul 2009 23:14:49 +0000
Subject: [issue6412] Titlecase as defined in Unicode Case Mappings not followed
In-Reply-To: <1246662889.32.0.498842923824.issue6412@psf.upfronthosting.co.za>
Message-ID: <1246662889.32.0.498842923824.issue6412@psf.upfronthosting.co.za>


New submission from Christoph Burgmer <cburgmer at ira.uka.de>:

Titlecase, i.e. istitle() and title(), is buggy when the string
includes combining diacritical marks.

>>> u'H\u0301ngh'.istitle()
False
>>> u'H\u0301ngh'.title()
u'H\u0301Ngh'
>>>

The string given already is in titlecase so that the following result
is expected:
>>> u'H\u0301ngh'.istitle()
True
>>> u'H\u0301ngh'.title()
u'H\u0301ngh'
>>>

UTR#21 Case Mappings defines the following algorithm for titlecase
mapping [1]:

For each character C, find the preceding character B. 
  ignore any intervening case-ignorable characters when finding B.
If B exists, and is cased 
  map C to UCD_lower(C)
Otherwise, 
  map C to UCD_title(C)

The class of 'case-ignorable' is defined under [2] and includes
Nonspacing Marks (Mn) as listed in [3]. This includes diacritcal marks
and others. These should not be handled similar to spaces which they
currently are, thus dividing words.

A patch including the above test case is attached.

[1]
http://unicode.org/reports/tr21/tr21-5.html#Case_Conversion_of_Strings
[2] http://unicode.org/reports/tr21/tr21-5.html#Definitions
[3] http://www.fileformat.info/info/unicode/category/Mn/list.htm

----------
components: Library (Lib)
files: test_unicode.titlecase.diff
keywords: patch
messages: 90086
nosy: christoph
severity: normal
status: open
title: Titlecase as defined in Unicode Case Mappings not followed
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file14443/test_unicode.titlecase.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6412>
_______________________________________

From report at bugs.python.org  Sat Jul  4 01:19:05 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 03 Jul 2009 23:19:05 +0000
Subject: [issue6412] Titlecase as defined in Unicode Case Mappings not followed
In-Reply-To: <1246662889.32.0.498842923824.issue6412@psf.upfronthosting.co.za>
Message-ID: <1246663145.21.0.1166770119.issue6412@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
priority:  -> normal
stage:  -> needs patch
type:  -> behavior
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6412>
_______________________________________

From report at bugs.python.org  Sat Jul  4 01:21:01 2009
From: report at bugs.python.org (Christoph Burgmer)
Date: Fri, 03 Jul 2009 23:21:01 +0000
Subject: [issue6412] Titlecase as defined in Unicode Case Mappings not followed
In-Reply-To: <1246662889.32.0.498842923824.issue6412@psf.upfronthosting.co.za>
Message-ID: <1246663261.95.0.923996018705.issue6412@psf.upfronthosting.co.za>


Christoph Burgmer <cburgmer at ira.uka.de> added the comment:

Adding a incomplete patch in need of a function
Py_UNICODE_ISCASEIGNORABLE defining the case-ignorable class.

I don't want to touch capitalize() as I don't fully understand the
semantics, where it is different to title(). It seems though following
UTR#21 not the first character should be uppercased, but the first
character with casing.

----------
Added file: http://bugs.python.org/file14444/unicodeobject.titlecase.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6412>
_______________________________________

From report at bugs.python.org  Sat Jul  4 01:30:08 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 03 Jul 2009 23:30:08 +0000
Subject: [issue6267] Cumulative patcc:h to http and xmlrpc
In-Reply-To: <1244734235.6.0.17264314682.issue6267@psf.upfronthosting.co.za>
Message-ID: <1246663808.82.0.863516549434.issue6267@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Fixed exception handling in 
revision 73820
and
revision 73821 and revision 73822

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6267>
_______________________________________

From report at bugs.python.org  Sat Jul  4 01:32:44 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 03 Jul 2009 23:32:44 +0000
Subject: [issue6267] Cumulative patcc:h to http and xmlrpc
In-Reply-To: <1244734235.6.0.17264314682.issue6267@psf.upfronthosting.co.za>
Message-ID: <1246663964.33.0.589996309609.issue6267@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

I've submitted a fix to 6381 in the trunk.  6382 is less clear to me, I 
must take a closer look.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6267>
_______________________________________

From report at bugs.python.org  Sat Jul  4 01:38:46 2009
From: report at bugs.python.org (Eric Devolder)
Date: Fri, 03 Jul 2009 23:38:46 +0000
Subject: [issue5960] Windows Installer Error 1722 when opting for compilation
	at install time - once again
In-Reply-To: <1241721168.05.0.823315409835.issue5960@psf.upfronthosting.co.za>
Message-ID: <1246664326.1.0.0315344775382.issue5960@psf.upfronthosting.co.za>


Eric Devolder <eric.devolder at gmail.com> added the comment:

problem fixed under final 3.1

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5960>
_______________________________________

From report at bugs.python.org  Sat Jul  4 01:43:13 2009
From: report at bugs.python.org (Adam Ginsburg)
Date: Fri, 03 Jul 2009 23:43:13 +0000
Subject: [issue4017] Tkinter cannot find Tcl/Tk on Mac OS X
In-Reply-To: <1222960590.08.0.635891151551.issue4017@psf.upfronthosting.co.za>
Message-ID: <1246664593.01.0.499824422051.issue4017@psf.upfronthosting.co.za>


Adam Ginsburg <keflavich at gmail.com> added the comment:

Although this is an old & closed error, I'm still running in to it.

I am trying to compile & install 64 bit python with Tk/Tcl support on
Mac OS X 10.5.7.

I have installed 64-bit Tcl/Tk:
$ file /Library/Frameworks/Tk.framework/Versions/8.5/Tk
/Library/Frameworks/Tk.framework/Versions/8.5/Tk: Mach-O universal
binary with 3 architectures
/Library/Frameworks/Tk.framework/Versions/8.5/Tk (for architecture
ppc7400):    Mach-O dynamically linked shared library ppc
/Library/Frameworks/Tk.framework/Versions/8.5/Tk (for architecture
i386):       Mach-O dynamically linked shared library i386
/Library/Frameworks/Tk.framework/Versions/8.5/Tk (for architecture
x86_64):     Mach-O 64-bit dynamically linked shared library x86_64
$ file /Library/Frameworks/Tcl.framework/Versions/8.5/Tcl
/Library/Frameworks/Tcl.framework/Versions/8.5/Tcl: Mach-O universal
binary with 3 architectures
/Library/Frameworks/Tcl.framework/Versions/8.5/Tcl (for architecture
ppc7400):  Mach-O dynamically linked shared library ppc
/Library/Frameworks/Tcl.framework/Versions/8.5/Tcl (for architecture
i386):     Mach-O dynamically linked shared library i386
/Library/Frameworks/Tcl.framework/Versions/8.5/Tcl (for architecture
x86_64):   Mach-O 64-bit dynamically linked shared library x86_64

Everything that _tkinter.so links to appears to be 64-bit capable:
$ otool -L
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_tkinter.so
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_tkinter.so:
        /Library/Frameworks/Tcl.framework/Versions/8.5/Tcl
(compatibility version 8.5.0, current version 8.5.7)
        /Library/Frameworks/Tk.framework/Versions/8.5/Tk (compatibility
version 8.5.0, current version 8.5.7)
        /usr/local/lib/libgcc_s.1.dylib (compatibility version 1.0.0,
current version 1.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 111.0.0)

But somehow _tkinter.so doesn't have x86_64 support:
$ file
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_tkinter.so
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_tkinter.so:
Mach-O universal binary with 2 architectures
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_tkinter.so
(for architecture i386):        Mach-O bundle i386
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_tkinter.so
(for architecture ppc7400):     Mach-O bundle ppc

How can I make tkinter work with 64 bit Tcl/Tk?

----------
nosy: +keflavich

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4017>
_______________________________________

From report at bugs.python.org  Sat Jul  4 02:58:08 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 04 Jul 2009 00:58:08 +0000
Subject: [issue3810] os.chdir() et al: is the path str or bytes?
In-Reply-To: <1220937677.05.0.675791850215.issue3810@psf.upfronthosting.co.za>
Message-ID: <1246669088.89.0.730546770727.issue3810@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

At the beginning of the page[1] there's a note that says: "All functions
accepting path or file names accept both bytes and string objects, and
result in an object of the same type, if a path or file name is returned."
This applies to os.chdir() too (both work, however it doesn't return
anything).

The doc for os.listdir[2] now says: "This function can be called with a
bytes or string argument. In the bytes case, all filenames will be
listed as returned by the underlying API. In the string case, filenames
will be decoded using the file system encoding, and skipped if a
decoding error occurs." so the second problem you mentioned seems
already fixed.

[1]: http://docs.python.org/3.0/library/os.html#module-os
[2]: http://docs.python.org/3.0/library/os.html#os.listdir

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3810>
_______________________________________

From report at bugs.python.org  Sat Jul  4 03:21:20 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 04 Jul 2009 01:21:20 +0000
Subject: [issue6398] README typo
In-Reply-To: <1246480245.72.0.392053113431.issue6398@psf.upfronthosting.co.za>
Message-ID: <1246670480.99.0.327613479181.issue6398@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed in r73823 (py3k) and r73824 (trunk).
Thanks!

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6398>
_______________________________________

From report at bugs.python.org  Sat Jul  4 03:51:59 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 04 Jul 2009 01:51:59 +0000
Subject: [issue3392] subprocess fails in select when descriptors are large
In-Reply-To: <1216293940.59.0.136491841956.issue3392@psf.upfronthosting.co.za>
Message-ID: <1246672319.25.0.073376830216.issue3392@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Your patch looks pretty good.  I cleaned up a few things in it and added
a unittest (the existing test suite is run with both select and poll).

Committed to trunk in r73825.

I am leaving the issue open until this is ported and merged into py3k as
well as backported to release26-maint and release31-maint.

----------
keywords:  -needs review
resolution:  -> accepted
stage: patch review -> commit review
versions: +Python 3.1 -Python 3.0
Added file: http://bugs.python.org/file14445/subprocess_with_poll3-gps03.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3392>
_______________________________________

From report at bugs.python.org  Sat Jul  4 04:00:37 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 04 Jul 2009 02:00:37 +0000
Subject: [issue6413] incorrect log level in distutlis.dist for announce
In-Reply-To: <1246672837.63.0.0147126592432.issue6413@psf.upfronthosting.co.za>
Message-ID: <1246672837.63.0.0147126592432.issue6413@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

The correct level should be INFO

----------
assignee: tarek
messages: 90095
nosy: tarek
priority: normal
severity: normal
status: open
title: incorrect log level in distutlis.dist for announce
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6413>
_______________________________________

From report at bugs.python.org  Sat Jul  4 04:07:32 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 04 Jul 2009 02:07:32 +0000
Subject: [issue6413] incorrect log level in distutlis.dist for announce
In-Reply-To: <1246672837.63.0.0147126592432.issue6413@psf.upfronthosting.co.za>
Message-ID: <1246673252.06.0.333902069681.issue6413@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

done in r73827, r73828 and r73830

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6413>
_______________________________________

From report at bugs.python.org  Sat Jul  4 04:11:54 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 04 Jul 2009 02:11:54 +0000
Subject: [issue1027] uudecoding (uu.py) does not supprt base64, patch attached
In-Reply-To: <1188155058.19.0.438776826235.issue1027@psf.upfronthosting.co.za>
Message-ID: <1246673514.83.0.874430206747.issue1027@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Now it's too late for 2.5 and probably for 2.6 too. If there are no news
this can probably be closed.

----------
nosy: +ezio.melotti
status: open -> pending
versions: +Python 2.7 -Python 2.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1027>
_______________________________________

From report at bugs.python.org  Sat Jul  4 04:26:50 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 04 Jul 2009 02:26:50 +0000
Subject: [issue1229646] httplib error checking.
Message-ID: <1246674410.49.0.608292323042.issue1229646@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

In Python3 the code for httplib changed:
Py3:
http://svn.python.org/view/python/branches/py3k/Lib/http/client.py?view=markup#send
Py2: http://svn.python.org/view/python/trunk/Lib/httplib.py?view=markup#send

Does this still need to be fixed on Py2.7 (and maybe on Py3 too)?

----------
nosy: +ezio.melotti
type:  -> behavior
versions: +Python 2.7 -Python 2.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1229646>
_______________________________________

From report at bugs.python.org  Sat Jul  4 04:35:15 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 04 Jul 2009 02:35:15 +0000
Subject: [issue1710703] zipfile.ZipFile behavior inconsistent.
Message-ID: <1246674915.64.0.914936502296.issue1710703@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +patch
stage:  -> test needed
type:  -> behavior
versions: +Python 2.7 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1710703>
_______________________________________

From report at bugs.python.org  Sat Jul  4 04:37:05 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 04 Jul 2009 02:37:05 +0000
Subject: [issue777884] minidom.py -- TypeError: object doesn't support slice
	assig
Message-ID: <1246675025.9.0.855881184917.issue777884@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
stage:  -> needs patch
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue777884>
_______________________________________

From report at bugs.python.org  Sat Jul  4 04:39:53 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 04 Jul 2009 02:39:53 +0000
Subject: [issue1921] Confusing Descrintro example
In-Reply-To: <1201181747.66.0.31684496906.issue1921@psf.upfronthosting.co.za>
Message-ID: <1246675193.57.0.0576306151471.issue1921@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee:  -> georg.brandl
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1921>
_______________________________________

From report at bugs.python.org  Sat Jul  4 04:42:37 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 04 Jul 2009 02:42:37 +0000
Subject: [issue1025395] email.Utils.parseaddr fails to parse valid addresses
Message-ID: <1246675357.32.0.805625185079.issue1025395@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
stage:  -> test needed
versions: +Python 2.7 -Python 2.3, Python 2.4, Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1025395>
_______________________________________

From report at bugs.python.org  Sat Jul  4 04:47:23 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 04 Jul 2009 02:47:23 +0000
Subject: [issue3392] subprocess fails in select when descriptors are large
In-Reply-To: <1216293940.59.0.136491841956.issue3392@psf.upfronthosting.co.za>
Message-ID: <1246675643.5.0.120298868959.issue3392@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Merged to py3k in r73833.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3392>
_______________________________________

From report at bugs.python.org  Sat Jul  4 04:48:58 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 04 Jul 2009 02:48:58 +0000
Subject: [issue2060] python2.6 -3 gives "warning: callable() not supported in
	3.x" on startup
In-Reply-To: <1202681730.06.0.258652347172.issue2060@psf.upfronthosting.co.za>
Message-ID: <1246675738.46.0.343356361465.issue2060@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I can't reproduce this with Python 2.6 (final) on Windows and Python
2.6.2 on Linux. I guess that this was fixed before the final release.
Closing as "fixed".

----------
nosy: +ezio.melotti
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2060>
_______________________________________

From report at bugs.python.org  Sat Jul  4 05:05:13 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 04 Jul 2009 03:05:13 +0000
Subject: [issue6409] 2to3 generates malformed diffs
In-Reply-To: <1246636426.08.0.872531312657.issue6409@psf.upfronthosting.co.za>
Message-ID: <1246676713.4.0.935836647401.issue6409@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> benjamin.peterson
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6409>
_______________________________________

From report at bugs.python.org  Sat Jul  4 05:06:30 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 04 Jul 2009 03:06:30 +0000
Subject: [issue3426] os.path.abspath with unicode argument should call
	os.getcwdu
In-Reply-To: <1216737133.71.0.70086601319.issue3426@psf.upfronthosting.co.za>
Message-ID: <1246676790.04.0.99286054242.issue3426@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This seems to work fine with Py 3.0 and 3.1 on Linux, it still fails
with Py 2.6 and 2.7.

----------
nosy: +ezio.melotti
priority:  -> normal
versions: +Python 2.6, Python 2.7 -Python 2.4, Python 2.5, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3426>
_______________________________________

From report at bugs.python.org  Sat Jul  4 05:12:15 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 04 Jul 2009 03:12:15 +0000
Subject: [issue3250] datetime.time does not support arithmetic
In-Reply-To: <1214905740.54.0.833672968887.issue3250@psf.upfronthosting.co.za>
Message-ID: <1246677135.38.0.290739942114.issue3250@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

If there's no obviously best way to handle overflow, can this be closed?

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3250>
_______________________________________

From report at bugs.python.org  Sat Jul  4 05:17:59 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 04 Jul 2009 03:17:59 +0000
Subject: [issue3077] h2py char literal doesn work
In-Reply-To: <1213172768.79.0.156029263713.issue3077@psf.upfronthosting.co.za>
Message-ID: <1246677479.44.0.00983760267686.issue3077@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
priority:  -> normal
versions: +Python 2.7 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3077>
_______________________________________

From report at bugs.python.org  Sat Jul  4 05:22:11 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 04 Jul 2009 03:22:11 +0000
Subject: [issue3151] elementtree serialization bug for weird namespace urls
In-Reply-To: <1213974981.57.0.313909578004.issue3151@psf.upfronthosting.co.za>
Message-ID: <1246677731.88.0.711967084904.issue3151@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
priority:  -> normal
stage:  -> patch review
versions: +Python 2.7 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3151>
_______________________________________

From report at bugs.python.org  Sat Jul  4 05:26:53 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 04 Jul 2009 03:26:53 +0000
Subject: [issue3056] Simplify the Integral ABC
In-Reply-To: <1212803845.73.0.399511532431.issue3056@psf.upfronthosting.co.za>
Message-ID: <1246678013.16.0.799261700496.issue3056@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Ping?

----------
nosy: +ezio.melotti
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3056>
_______________________________________

From report at bugs.python.org  Sat Jul  4 06:14:48 2009
From: report at bugs.python.org (Russ Gibson)
Date: Sat, 04 Jul 2009 04:14:48 +0000
Subject: [issue1559298] test_popen fails on Windows if installed to "Program
	Files"
Message-ID: <1246680888.8.0.815473524315.issue1559298@psf.upfronthosting.co.za>


Russ Gibson <russg at rnstech.com> added the comment:

What is needed is separate quoting for the command and the argument. 
Right now, test_popen only surrounds the entire command line with quotes:

"c:\Program Files\Python2.6\Python.exe -u c:\Documents and Settings\Russ
Gibson\cgi-bin\cgi.py"

It needs to the above as thus:

"c:\Program Files\Python2.6\Python.exe" -u "c:\Documents and
Settings\Russ Gibson\cgi-bin\cgi.py"

>From the command line, the second case works, but the first doesn't. 
Neither work from os.popen in 2.6.2.

To make sure that popen works in all cases under windows, test_popen*
need to test with separate quotes around the command and argument.  That
will show the real problem with the current os.popen* implementation(s).

(yeah, I know, shut up and provide a patch...)

----------
nosy: +squeegee

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1559298>
_______________________________________

From report at bugs.python.org  Sat Jul  4 06:19:08 2009
From: report at bugs.python.org (Russ Gibson)
Date: Sat, 04 Jul 2009 04:19:08 +0000
Subject: [issue1475] test_popen fails when the directory contains a space
In-Reply-To: <1195544172.34.0.734753003895.issue1475@psf.upfronthosting.co.za>
Message-ID: <1246681148.08.0.888988788738.issue1475@psf.upfronthosting.co.za>


Russ Gibson <russg at rnstech.com> added the comment:

(Same comment I added to 1559298:)
What is needed is separate quoting for the command and the argument. 
Right now, test_popen only surrounds the entire command line with quotes:

"c:\Program Files\Python2.6\Python.exe -u c:\Documents and Settings\Russ
Gibson\cgi-bin\cgi.py"

It needs to test the above as thus:

"c:\Program Files\Python2.6\Python.exe" -u "c:\Documents and
Settings\Russ Gibson\cgi-bin\cgi.py"

>From the command line, the second case works, but the first doesn't.
Neither work from os.popen in 2.6.2.  I have been unable to get popen*
to work with a command and an argument that both contain spaces.

To make sure that popen works in all cases under windows, test_popen*
needs to test with separate quotes around the command and argument. 
That will show the real problem with the current os.popen*
implementation(s).

(yeah, I know, shut up and provide a patch...)

----------
nosy: +squeegee

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1475>
_______________________________________

From report at bugs.python.org  Sat Jul  4 06:57:20 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 04 Jul 2009 04:57:20 +0000
Subject: [issue6381] test_urllib2_localnet sporadic failures closing socket
In-Reply-To: <1246326020.83.0.77401775469.issue6381@psf.upfronthosting.co.za>
Message-ID: <1246683440.19.0.405574835541.issue6381@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Test passes consistently now on trunk in Gentoo.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6381>
_______________________________________

From report at bugs.python.org  Sat Jul  4 09:46:30 2009
From: report at bugs.python.org (Karl Magdsick)
Date: Sat, 04 Jul 2009 07:46:30 +0000
Subject: [issue6414] struct module : processor endianness descriptions
	misleading
In-Reply-To: <1246693590.67.0.013392500744.issue6414@psf.upfronthosting.co.za>
Message-ID: <1246693590.67.0.013392500744.issue6414@psf.upfronthosting.co.za>


New submission from Karl Magdsick <kmagdsick at hotmail.com>:

In http://docs.python.org/dev/library/struct.html,

it says
"Native byte order is big-endian or little-endian, depending on the host 
system. For example, Motorola and Sun processors are big-endian; Intel 
and DEC processors are little-endian."

This is a gross over-generalization at best.  Off the top of my head, 
current Linux kernels run the Intel Itanium in big-endian mode. (Though, 
I don't recall if there's a non-privileged instruction to flip 
endianness, system headers and system calls are defined in big-endian 
order, which is what's most relevant to the struct module.)  Sun SPARC 
v9 is bi-endian. Intel Itanium and XScale processors are bi-endian.  Dec 
Alphas are bi-endian.  (Though, I'm only aware of Cray using Alphas in 
big-endian mode.)

The quoted paragraph should name specific processors which are single-
endian (Intel Core 2, Sun SPARC v8) and/or provide a Wikipedia 
reference, rather than making incorrect statements.

Intel Itanium machines running Linux are probably the most common 
systems where this statement's inaccuracy is likely to cause confusion 
among developers.

----------
assignee: georg.brandl
components: Documentation
messages: 90107
nosy: georg.brandl, kmag
severity: normal
status: open
title: struct module : processor endianness descriptions misleading
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6414>
_______________________________________

From report at bugs.python.org  Sat Jul  4 10:54:25 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 04 Jul 2009 08:54:25 +0000
Subject: [issue5463] Remove deprecated features from struct module
In-Reply-To: <1236633440.53.0.769324137007.issue5463@psf.upfronthosting.co.za>
Message-ID: <1246697665.87.0.785257447379.issue5463@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The trunk warning was squashed in r73004.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5463>
_______________________________________

From report at bugs.python.org  Sat Jul  4 11:30:48 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 04 Jul 2009 09:30:48 +0000
Subject: [issue1741130] struct.pack("I", "foo");
	struct.pack("L", "foo") should fail
Message-ID: <1246699848.74.0.0103628785671.issue1741130@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the patch, Daniel!  It certainly fixes the problem.  I was 
planning something a little more drastic, though---I think the struct 
module could do with a bit of a cleanup in this area.

At the moment it's not clear exactly what types should be accepted by
struct.pack with an integer format.  Just ints and longs (and their 
subclases)?  Anything implementing an __index__ method?  Anything 
implementing an __int__ method (e.g., Decimal instances)?

I propose doing a little bit of rewriting so that

  (1) all attempted conversions of a PyObject to a C integer
      go through PyNumber_Index; thus anything with an __index__
      method can be packed.

  (2) If PY_STRUCT_FLOAT_COERCE is defined, instances of float or
      subclasses of float (i.e., everything that passes PyFloat_Check)
      are also accepted, for backwards compatibility.

Does this seem reasonable?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1741130>
_______________________________________

From report at bugs.python.org  Sat Jul  4 11:37:01 2009
From: report at bugs.python.org (Frank Chu)
Date: Sat, 04 Jul 2009 09:37:01 +0000
Subject: [issue3392] subprocess fails in select when descriptors are large
In-Reply-To: <1246675643.5.0.120298868959.issue3392@psf.upfronthosting.co.za>
Message-ID: <7e1ece9e0907040236r17ee281fq1e314dd39acc351b@mail.gmail.com>


Frank Chu <fpmchu at gmail.com> added the comment:

Thanks!  Good to hear it's checked in finally :-).

Frank

On Fri, Jul 3, 2009 at 7:47 PM, Gregory P. Smith <report at bugs.python.org>wrote:

>
> Gregory P. Smith <greg at krypto.org> added the comment:
>
> Merged to py3k in r73833.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3392>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file14446/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3392>
_______________________________________
-------------- next part --------------
Thanks!?? Good to hear it&#39;s checked in finally :-).<br><br>Frank<br><br><div class="gmail_quote">On Fri, Jul 3, 2009 at 7:47 PM, Gregory P. Smith <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im"><br>
Gregory P. Smith &lt;<a href="mailto:greg at krypto.org">greg at krypto.org</a>&gt; added the comment:<br>
<br>
</div>Merged to py3k in r73833.<br>
<br>
----------<br>
<div><div></div><div class="h5"><br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue3392" target="_blank">http://bugs.python.org/issue3392</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br>

From report at bugs.python.org  Sat Jul  4 12:14:04 2009
From: report at bugs.python.org (wiesenth)
Date: Sat, 04 Jul 2009 10:14:04 +0000
Subject: [issue6415] warnings.warn segfaults on bad formatted string
In-Reply-To: <1246702444.15.0.967525803194.issue6415@psf.upfronthosting.co.za>
Message-ID: <1246702444.15.0.967525803194.issue6415@psf.upfronthosting.co.za>


New submission from wiesenth <d.wiesenthal at gmx.de>:

The interpreter crashes with an segmentation fault when warnings.warn
shall output a Warning instance, whose string representation is bad
formatted.

Don't know if this is fixed in a minor 2.6 release or in 2.7, I use the
Ubuntu 9.04 python2.6 package.

An easy reproducing example is given.

This is also an issue within python3.0 (python3.1 does not exist in the
repositories)

----------
files: warnsegfault.py
messages: 90111
nosy: wiesenth
severity: normal
status: open
title: warnings.warn segfaults on bad formatted string
type: crash
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file14447/warnsegfault.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6415>
_______________________________________

From report at bugs.python.org  Sat Jul  4 13:05:36 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 04 Jul 2009 11:05:36 +0000
Subject: [issue3410] platform.version() don't work as expected in Vista in
	portuguese
In-Reply-To: <1216410595.08.0.936182141358.issue3410@psf.upfronthosting.co.za>
Message-ID: <1246705536.98.0.789305583116.issue3410@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I tried platform.version() on a non-English Vista and XP and I got
'32bit' for Vista and '5.1.2600' for XP. With platform.platform() I got
'Windows-32bit-SP2' on Vista and 'Windows-XP-5.1.2600-SP2' on XP.

----------
nosy: +ezio.melotti
priority:  -> normal
versions: +Python 2.7 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3410>
_______________________________________

From report at bugs.python.org  Sat Jul  4 13:24:35 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 04 Jul 2009 11:24:35 +0000
Subject: [issue6416] Failed to compile selectmodule.c on windows (trunk)
In-Reply-To: <1246706675.4.0.617951670977.issue6416@psf.upfronthosting.co.za>
Message-ID: <1246706675.4.0.617951670977.issue6416@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

I cannot compile selectmodule.c on windows(trunk). PIPE_BUF will not be
defined if macro _POSIX_ is not defined. But if define _POSIX_ before
"#include <limits.h>" in Include/Python.h another compile error happens.

E:\python-dev\trunk\PC\msvcrtmodule.c(39) : warning C4013: ??
'_heapmin' ???????????int ?????????????????
E:\python-dev\trunk\Modules\posixmodule.c(2901) : warning C4013: ??
'_exit' ???????????int ?????????????????
E:\python-dev\trunk\Modules\posixmodule.c(2974) : warning C4013: ??
'execv' ???????????int ?????????????????
E:\python-dev\trunk\Modules\posixmodule.c(3107) : warning C4013: ??
'execve' ???????????int ?????????????????
E:\python-dev\trunk\Modules\posixmodule.c(3194) : error C2065:
'_OLD_P_OVERLAY' : ??????????????
E:\python-dev\trunk\Modules\posixmodule.c(3195) : error C2065:
'_P_OVERLAY' : ??????????????
E:\python-dev\trunk\Modules\posixmodule.c(3198) : warning C4013: ??
'_spawnv' ???????????int ?????????????????
E:\python-dev\trunk\Modules\posixmodule.c(3343) : warning C4013: ??
'_spawnve' ???????????int ?????????????????
E:\python-dev\trunk\Modules\posixmodule.c(3790) : warning C4013: ??
'getpid' ???????????int ?????????????????
E:\python-dev\trunk\Modules\posixmodule.c(4918) : warning C4013: ??
'alloca' ???????????int ?????????????????
E:\python-dev\trunk\Modules\posixmodule.c(5868) : warning C4013: ??
'_cwait' ???????????int ?????????????????
E:\python-dev\trunk\Modules\posixmodule.c(6743) : warning C4013: ??
'putenv' ???????????int ?????????????????
E:\python-dev\trunk\Modules\posixmodule.c(8941) : error C2065: '_P_WAIT'
: ??????????????
E:\python-dev\trunk\Modules\posixmodule.c(8942) : error C2065:
'_P_NOWAIT' : ??????????????
E:\python-dev\trunk\Modules\posixmodule.c(8944) : error C2065:
'_P_NOWAITO' : ??????????????
E:\python-dev\trunk\Modules\posixmodule.c(8945) : error C2065:
'_P_DETACH' : ??????????????
(snip)

Probaly it's not good define _POSIX_ on windows. Is it reasonable to put
"#ifdef PIPE_BUF" around

	PyModule_AddIntConstant(m, "PIPE_BUF", PIPE_BUF);

in selectmodule.c.

----------
components: Build, Windows
messages: 90113
nosy: ocean-city
severity: normal
status: open
title: Failed to compile selectmodule.c on windows (trunk)
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6416>
_______________________________________

From report at bugs.python.org  Sat Jul  4 13:59:46 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 04 Jul 2009 11:59:46 +0000
Subject: [issue6416] Failed to compile selectmodule.c on windows (trunk)
In-Reply-To: <1246706675.4.0.617951670977.issue6416@psf.upfronthosting.co.za>
Message-ID: <1246708786.96.0.80534994395.issue6416@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

>E:\python-dev\trunk\PC\msvcrtmodule.c(39) : warning C4013:
>??'_heapmin' ???????????int ?????????????????

This means "_heapmin is not defined".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6416>
_______________________________________

From report at bugs.python.org  Sat Jul  4 14:52:59 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sat, 04 Jul 2009 12:52:59 +0000
Subject: [issue3410] platform.version() don't work as expected in Vista
	in	portuguese
In-Reply-To: <1246705536.98.0.789305583116.issue3410@psf.upfronthosting.co.za>
Message-ID: <4A4F50A8.107@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Ezio Melotti wrote:
> Ezio Melotti <ezio.melotti at gmail.com> added the comment:
> 
> I tried platform.version() on a non-English Vista and XP and I got
> '32bit' for Vista and '5.1.2600' for XP. With platform.platform() I got
> 'Windows-32bit-SP2' on Vista and 'Windows-XP-5.1.2600-SP2' on XP.

Could you please run the platform function win32_ver() through
a debugger and check why it doesn't return "Vista". That function
does have support for Vista.

----------
title: platform.version() don't work as expected in Vista in portuguese -> platform.version() don't work as expected in Vista in	portuguese

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3410>
_______________________________________

From report at bugs.python.org  Sat Jul  4 14:59:19 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 04 Jul 2009 12:59:19 +0000
Subject: [issue6415] warnings.warn segfaults on bad formatted string
In-Reply-To: <1246702444.15.0.967525803194.issue6415@psf.upfronthosting.co.za>
Message-ID: <1246712359.8.0.808546374004.issue6415@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I hope attached patch will fix this issue.

----------
keywords: +patch
nosy: +ocean-city
Added file: http://bugs.python.org/file14448/warnings_segfault.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6415>
_______________________________________

From report at bugs.python.org  Sat Jul  4 15:22:40 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 04 Jul 2009 13:22:40 +0000
Subject: [issue3410] platform.version() don't work as expected in Vista
	in	portuguese
In-Reply-To: <1216410595.08.0.936182141358.issue3410@psf.upfronthosting.co.za>
Message-ID: <1246713760.84.0.901681559212.issue3410@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The Vista machine is running Py 2.5.2 but is not mine so I can't
test/debug the issue properly there. FWIW I tried win32_ver() on it and
I got ('', '6.0.6002', 'SP2', 'Multiprocessor Free').

Here on WinXP with 2.6 I get ('XP', '5.1.2600', 'SP2', u'Uniprocessor
Free') (why only the last is unicode?).

On Monday I'll have access to more Windows machines (including Vista)
but they are all in English. If there's something that I should try
there let me know.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3410>
_______________________________________

From report at bugs.python.org  Sat Jul  4 15:33:22 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 04 Jul 2009 13:33:22 +0000
Subject: [issue6415] warnings.warn segfaults on bad formatted string
In-Reply-To: <1246702444.15.0.967525803194.issue6415@psf.upfronthosting.co.za>
Message-ID: <1246714402.54.0.728831429696.issue6415@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> brett.cannon
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6415>
_______________________________________

From report at bugs.python.org  Sat Jul  4 16:58:45 2009
From: report at bugs.python.org (Michael Newman)
Date: Sat, 04 Jul 2009 14:58:45 +0000
Subject: [issue6417] multiprocessing Process examples: print and getppid
In-Reply-To: <1246719525.24.0.54072257834.issue6417@psf.upfronthosting.co.za>
Message-ID: <1246719525.24.0.54072257834.issue6417@psf.upfronthosting.co.za>


New submission from Michael Newman <michael.b.newman at gmail.com>:

The "16.6.1.1. The Process class" section of the multiprocessing
documentation:
http://docs.python.org/dev/py3k/library/multiprocessing.html
has errors in both examples.

The first example needs the indentation fixed on the "from" and "if"
lines (remove the leading spaces).

The second example has two issues: print syntax needs be updated from
2.0 to 3.0 syntax. Also, getppid is not available on win32 platforms.
Below is a corrected example, which I tested successfully on on win32
and linux:

# Python 3.1 (r31:73574, Jun 26 2009, 20:21:35) [MSC v.1500 32 bit
(Intel)] on win32
C:\>c:\Python31\python.exe Process_with_more_info.py
main line
module name: __main__
parent process: None
process id: 3216
function f
module name: __main__
parent process: 3216
process id: 3692
hello bob

# Python 3.0.1 (r301:69556, Jun  6 2009, 21:34:43) [GCC 4.3.2] on linux2
mike at www:~/files$ python3.0 Process_with_more_info.py
main line
module name: __main__
parent process: 19853
process id: 22544
function f
module name: __main__
parent process: 22544
process id: 22545
hello bob

# Start of corrected example:

from multiprocessing import Process, current_process
from sys import platform
import os

def info(title):
    print(title)
    print('module name:', __name__)
    if platform == 'win32':
      print('parent process:', current_process()._parent_pid)
    else:
      print('parent process:', os.getppid())
    print('process id:', os.getpid())

def f(name):
    info('function f')
    print('hello', name)

if __name__ == '__main__':
    info('main line')
    p = Process(target=f, args=('bob',))
    p.start()
    p.join()

# End of corrected example.

I also saw this online:
"os.getppid on Windows"
http://d.hatena.ne.jp/chrono-meter/20090325/p1
But the license of the code is not clear, and it would make the example
too confusing to insert in.

Another reference:
"Multiprocessing docs are not 3.0-ready"
http://bugs.python.org/issue3256
Looks like some print statements fixed back then, but not sure why the
examples mentioned here were not fixed.

----------
assignee: georg.brandl
components: Documentation
messages: 90118
nosy: georg.brandl, mnewman
severity: normal
status: open
title: multiprocessing Process examples: print and getppid
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6417>
_______________________________________

From report at bugs.python.org  Sat Jul  4 17:18:50 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sat, 04 Jul 2009 15:18:50 +0000
Subject: [issue6381] test_urllib2_localnet sporadic failures closing socket
In-Reply-To: <1246326020.83.0.77401775469.issue6381@psf.upfronthosting.co.za>
Message-ID: <1246720730.89.0.940674514926.issue6381@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

meged to py3k in revision 73845

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6381>
_______________________________________

From report at bugs.python.org  Sat Jul  4 17:22:07 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 04 Jul 2009 15:22:07 +0000
Subject: [issue6417] multiprocessing Process examples: print and getppid
In-Reply-To: <1246719525.24.0.54072257834.issue6417@psf.upfronthosting.co.za>
Message-ID: <1246720927.99.0.494520421394.issue6417@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee: georg.brandl -> jnoller
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6417>
_______________________________________

From report at bugs.python.org  Sat Jul  4 17:44:20 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sat, 04 Jul 2009 15:44:20 +0000
Subject: [issue6382] test_socketserver fails on trunk in test_ForkingTCPServer
In-Reply-To: <1246327124.37.0.772968679477.issue6382@psf.upfronthosting.co.za>
Message-ID: <1246722260.24.0.727573149082.issue6382@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

This is a "fork" problem.
socket.close must be done on the parent, while socket.shutdown and 
socket.close must be performed on the child.
I must restructure this a little bit to make it work.

----------
nosy: +krisvale

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6382>
_______________________________________

From report at bugs.python.org  Sat Jul  4 17:48:46 2009
From: report at bugs.python.org (Michael Newman)
Date: Sat, 04 Jul 2009 15:48:46 +0000
Subject: [issue6417] multiprocessing Process examples: print and getppid
In-Reply-To: <1246719525.24.0.54072257834.issue6417@psf.upfronthosting.co.za>
Message-ID: <1246722526.19.0.144079684692.issue6417@psf.upfronthosting.co.za>


Michael Newman <michael.b.newman at gmail.com> added the comment:

# Revised example that is more platform neutral (avoids sys.platform):

from multiprocessing import Process, current_process
import os

def info(title):
    print(title)
    print('module name:', __name__)
    if not hasattr(os, 'getppid'):  # win32
      print('parent process:', current_process()._parent_pid)
    else:
      print('parent process:', os.getppid())
    print('process id:', os.getpid())

def f(name):
    info('function f')
    print('hello', name)

if __name__ == '__main__':
    info('main line')
    p = Process(target=f, args=('bob',))
    p.start()
    p.join()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6417>
_______________________________________

From report at bugs.python.org  Sat Jul  4 17:51:58 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 04 Jul 2009 15:51:58 +0000
Subject: [issue3810] os.chdir() et al: is the path str or bytes?
In-Reply-To: <1220937677.05.0.675791850215.issue3810@psf.upfronthosting.co.za>
Message-ID: <1246722718.07.0.371737479714.issue3810@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> out of date
stage:  -> committed/rejected
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3810>
_______________________________________

From report at bugs.python.org  Sat Jul  4 19:23:25 2009
From: report at bugs.python.org (Jerry Chen)
Date: Sat, 04 Jul 2009 17:23:25 +0000
Subject: [issue6415] warnings.warn segfaults on bad formatted string
In-Reply-To: <1246702444.15.0.967525803194.issue6415@psf.upfronthosting.co.za>
Message-ID: <1246728205.69.0.659365082157.issue6415@psf.upfronthosting.co.za>


Jerry Chen <jerry at 3rdengine.com> added the comment:

Bug and patch confirmed on both py3k and python2.7 branches

Before:

$ ./python.exe warnsegfault.py 
this exception is caught: incomplete format
this exception is also caught: incomplete format
Bus error

After:

$ ./python.exe warnsegfault.py this exception is caught: incomplete format
this exception is also caught: incomplete format
Traceback (most recent call last):
  File "warnsegfault.py", line 21, in <module>
    warnings.warn(MyWarning())
  File "warnsegfault.py", line 10, in __str__
    return "A bad formatted string %(err)" % {"err" : "there is no %(err)s"}
ValueError: incomplete format

----------
nosy: +jcsalterego

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6415>
_______________________________________

From report at bugs.python.org  Sat Jul  4 22:27:29 2009
From: report at bugs.python.org (Jason Pellerin)
Date: Sat, 04 Jul 2009 20:27:29 +0000
Subject: [issue6418] unittest.TestProgram change breaks nose
In-Reply-To: <1246739248.73.0.754849239276.issue6418@psf.upfronthosting.co.za>
Message-ID: <1246739248.73.0.754849239276.issue6418@psf.upfronthosting.co.za>


New submission from Jason Pellerin <jpellerin at gmail.com>:

This changeset:

http://hg.python.org/cpython/rev/c3fb79d1c036

breaks nose, as it changes the behavior of unittest.TestProgram in a
non-backwards-compatible way. Previously, when called like:

TestProgram(testRunner=None)

self.testRunner would be None when runTests() was called. Now, it is 
populated with the default TextTestRunner class in TestProgram.__init__. 
nose expects self.testRunner to be None or a runner instance in 
runTests(), and thus fails immediately with 2.6.3.

If initialization of self.testRunner could be deferred to runTests() as 
in unitttest for 2.5 and earlier, that would be ideal for nose.

----------
components: Library (Lib)
messages: 90123
nosy: jpellerin
severity: normal
status: open
title: unittest.TestProgram change breaks nose
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6418>
_______________________________________

From report at bugs.python.org  Sat Jul  4 22:35:48 2009
From: report at bugs.python.org (Michael Foord)
Date: Sat, 04 Jul 2009 20:35:48 +0000
Subject: [issue6418] unittest.TestProgram change breaks nose
In-Reply-To: <1246739248.73.0.754849239276.issue6418@psf.upfronthosting.co.za>
Message-ID: <1246739748.85.0.761922165375.issue6418@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

This change was made to fix a regression in 2.6.
In 2.5 the default was None and someone (else) made the also backwards
incompatible change to make the default the TextTestRunner class. This
broke test suites (like setuptools for example) which expected to be
able to pass None in and get sensible default behaviour.

The change can't be reverted as it was a bugfix, but a different change
could be applied.

----------
nosy: +michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6418>
_______________________________________

From report at bugs.python.org  Sat Jul  4 23:07:15 2009
From: report at bugs.python.org (James William Pye)
Date: Sat, 04 Jul 2009 21:07:15 +0000
Subject: [issue2698] Extension module build fails for MinGW: missing
	vcvarsall.bat
In-Reply-To: <1209230424.66.0.154562223128.issue2698@psf.upfronthosting.co.za>
Message-ID: <1246741635.95.0.827889800456.issue2698@psf.upfronthosting.co.za>


James William Pye <x at jwp.name> added the comment:

Seeing this in 3.1 when I try to compile with mingw32 under wine:

"error: Unable to find vcvarsall.bat"


--compiler=mingw32 works in 3.0. I assume it's related to this bug?

----------
nosy: +jwp
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2698>
_______________________________________

From report at bugs.python.org  Sat Jul  4 23:14:34 2009
From: report at bugs.python.org (Henry Precheur)
Date: Sat, 04 Jul 2009 21:14:34 +0000
Subject: [issue5910] kqueue for more than one event is broken.
In-Reply-To: <1241301488.84.0.663629523973.issue5910@psf.upfronthosting.co.za>
Message-ID: <1246742074.91.0.65202439594.issue5910@psf.upfronthosting.co.za>


Henry Precheur <henry at precheur.org> added the comment:

I tested the patch with py3k on OpenBSD 4.6 beta and it worked.

But I must admit I don't fully understand what the patch does ...

----------
nosy: +henry.precheur

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5910>
_______________________________________

From report at bugs.python.org  Sat Jul  4 23:23:01 2009
From: report at bugs.python.org (Henry Precheur)
Date: Sat, 04 Jul 2009 21:23:01 +0000
Subject: [issue6419] Broken test_kqueue.py on OpenBSD
In-Reply-To: <1246742581.68.0.218952543803.issue6419@psf.upfronthosting.co.za>
Message-ID: <1246742581.68.0.218952543803.issue6419@psf.upfronthosting.co.za>


New submission from Henry Precheur <henry at precheur.org>:

A kqueue's test doesn't pass on OpenBSD 4.6-beta, 4.4, & 4.5:

FAILED (failures=1)
Traceback (most recent call last):
  File "Lib/test/test_kqueue.py", line 186, in <module>
    test_main()
  File "Lib/test/test_kqueue.py", line 183, in test_main
    support.run_unittest(TestKQueue)
  File "/home/henry/py3k/Lib/test/support.py", line 882, in run_unittest
    _run_suite(suite)
  File "/home/henry/py3k/Lib/test/support.py", line 865, in _run_suite
    raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
  File "Lib/test/test_kqueue.py", line 119, in test_queue_event
    (server.fileno(), select.KQ_FILTER_WRITE, flags)])
AssertionError: Lists differ: [(6, -2, 5), (7, -2, 5)] != [(6, -2, 0),
(7, -2, 0)]

First differing element 0:
(6, -2, 5)
(6, -2, 0)

- [(6, -2, 5), (7, -2, 5)]
?          ^           ^

+ [(6, -2, 0), (7, -2, 0)]
?          ^           ^

It looks like OpenBSD behaves like Darwin. The attached patch fixes the
test.

----------
files: patch-Lib_test_test_kqueue_py
messages: 90127
nosy: henry.precheur
severity: normal
status: open
title: Broken test_kqueue.py on OpenBSD
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14449/patch-Lib_test_test_kqueue_py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6419>
_______________________________________

From report at bugs.python.org  Sat Jul  4 23:39:27 2009
From: report at bugs.python.org (Henry Precheur)
Date: Sat, 04 Jul 2009 21:39:27 +0000
Subject: [issue6420] Fix warning in nismodule.c on OpenBSD
In-Reply-To: <1246743567.03.0.331926957573.issue6420@psf.upfronthosting.co.za>
Message-ID: <1246743567.03.0.331926957573.issue6420@psf.upfronthosting.co.za>


New submission from Henry Precheur <henry at precheur.org>:

On OpenBSD the file /usr/include/rpcsvc/ypclnt.h contains the following
declaration:

struct ypall_callback {
	/* return non-0 to stop getting called */
	int (*foreach)(unsigned long, char *, int, char *, int, void *);
	char *data;		/* opaque pointer for use of callback fn */
};

the 'foreach' function pointer's declaration in Modules/nismodule.c is
different:

gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -I. -I./Include -I/usr/local/include -IInclude
-I/home/henry/py3k -c /home/henry/py3k/Modules/nismodule.c -o
build/temp.openbsd-4.6-amd64-3.2/home/henry/py3k/Modules/nismodule.o
/home/henry/py3k/Modules/nismodule.c: In function `nis_cat':
/home/henry/py3k/Modules/nismodule.c:208: warning: assignment from
incompatible pointer type


The attached patch fixes this very important issue :)

----------
components: Build, Library (Lib)
files: patch-Modules_nismodule_c
messages: 90128
nosy: henry.precheur
severity: normal
status: open
title: Fix warning in nismodule.c on OpenBSD
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14450/patch-Modules_nismodule_c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6420>
_______________________________________

From report at bugs.python.org  Sat Jul  4 23:40:00 2009
From: report at bugs.python.org (Henry Precheur)
Date: Sat, 04 Jul 2009 21:40:00 +0000
Subject: [issue6419] Broken test_kqueue.py on OpenBSD
In-Reply-To: <1246742581.68.0.218952543803.issue6419@psf.upfronthosting.co.za>
Message-ID: <1246743600.2.0.704267227085.issue6419@psf.upfronthosting.co.za>


Changes by Henry Precheur <henry at precheur.org>:


----------
components: +Tests

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6419>
_______________________________________

From report at bugs.python.org  Sat Jul  4 23:48:13 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 04 Jul 2009 21:48:13 +0000
Subject: [issue1741130] struct.pack("I", "foo");
	struct.pack("L", "foo") should fail
Message-ID: <1246744093.58.0.960122230987.issue1741130@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a patch that does some general cleanup of the object->integer 
helper functions in the struct module;  in the process, it fixes this 
bug.  With this patch, all conversions from a PyObject to a C integer go 
through get_pylong, so they're all treated the same way.  Currently 
(i.e., without the patch) there's a lack of consistency in the way the 
various integer codes are handled---some codes emit a warning for float 
conversions and some ('q', 'Q') don't;  some codes will happily convert 
a Decimal instance, and others won't.  Some codes produce this strange 
'unsupported operand types' message and some don't, etc.

----------
versions: +Python 2.7 -Python 2.6
Added file: http://bugs.python.org/file14451/issue1741130.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1741130>
_______________________________________

From report at bugs.python.org  Sat Jul  4 23:56:14 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sat, 04 Jul 2009 21:56:14 +0000
Subject: [issue3410] platform.version() don't work as expected in Vista
	in	portuguese
In-Reply-To: <1246713760.84.0.901681559212.issue3410@psf.upfronthosting.co.za>
Message-ID: <4A4FCFFB.7000400@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Ezio Melotti wrote:
> Ezio Melotti <ezio.melotti at gmail.com> added the comment:
> 
> The Vista machine is running Py 2.5.2 but is not mine so I can't
> test/debug the issue properly there. FWIW I tried win32_ver() on it and
> I got ('', '6.0.6002', 'SP2', 'Multiprocessor Free').

Interesting. Looking at the code in win32_ver() should be getting
one of ('Vista', '2008Server', 'post2008Server'), but not '' for the
release.

> Here on WinXP with 2.6 I get ('XP', '5.1.2600', 'SP2', u'Uniprocessor
> Free') (why only the last is unicode?).

Do you have the win32 tools installed on that machine ? This could
be the reason.

> On Monday I'll have access to more Windows machines (including Vista)
> but they are all in English. If there's something that I should try
> there let me know.

Please check the results of win32_ver() on those machines. The
release part should always be set.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3410>
_______________________________________

From report at bugs.python.org  Sun Jul  5 00:11:33 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 04 Jul 2009 22:11:33 +0000
Subject: [issue3410] platform.version() don't work as expected in Vista
	in	portuguese
In-Reply-To: <1216410595.08.0.936182141358.issue3410@psf.upfronthosting.co.za>
Message-ID: <1246745493.46.0.684573695365.issue3410@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> Do you have the win32 tools installed on that machine ? This could
> be the reason.

On my XP machine I have them installed for Py 2.4 only, "import
win32api" fails on Py 2.6.
"platform.win32_ver()" returns the same with both the versions, but on
Py 2.4 they are all plain strings, on Py 2.6 the last string is Unicode
(and on Py 3 they are all Unicode).

I'll let you know about the result of win32_ver() on the other machines.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3410>
_______________________________________

From report at bugs.python.org  Sun Jul  5 00:34:11 2009
From: report at bugs.python.org (Tim Gordon)
Date: Sat, 04 Jul 2009 22:34:11 +0000
Subject: [issue6410] Dictionaries should support __add__
In-Reply-To: <1246653238.95.0.314927755738.issue6410@psf.upfronthosting.co.za>
Message-ID: <1246746851.79.0.51064419894.issue6410@psf.upfronthosting.co.za>


Tim Gordon <tim.py at aleph17.co.uk> added the comment:

__add__ is non-commutative for lists, tuples, strings etc. - perhaps 
non-commutative wasn't quite what you were looking for :p.

----------
nosy: +QuantumTim
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6410>
_______________________________________

From report at bugs.python.org  Sun Jul  5 00:39:59 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sat, 04 Jul 2009 22:39:59 +0000
Subject: [issue6410] Dictionaries should support __add__
In-Reply-To: <1246653238.95.0.314927755738.issue6410@psf.upfronthosting.co.za>
Message-ID: <1246747199.89.0.557977966584.issue6410@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Why so much opposition to the shorter spelling of .copy() & .update()? 
As Tim pointed out, lists, tuples, and strings all provide this
shortcut.  Why not dicts?

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6410>
_______________________________________

From report at bugs.python.org  Sun Jul  5 00:53:42 2009
From: report at bugs.python.org (Alex Martelli)
Date: Sat, 04 Jul 2009 22:53:42 +0000
Subject: [issue6421] errors in docs re module initialization vs self arg to
	functions
In-Reply-To: <1246748021.93.0.159427637238.issue6421@psf.upfronthosting.co.za>
Message-ID: <1246748021.93.0.159427637238.issue6421@psf.upfronthosting.co.za>


New submission from Alex Martelli <aleaxit at gmail.com>:

http://docs.python.org/3.1/c-api/structures.html#PyMethodDef

says (under METH_VARARGS):

"""The first one is the self object for methods; for module functions,
it has the value given to Py_InitModule4 (or NULL if Py_InitModule was
used)."""

Py_InitModule4 is no more, and the first argument is now in fact a 
pointer to the module object. This is quite important, since the module 
object is now crucial for the get-state function that's supposed to 
replace a module's statics!

http://docs.python.org/3.1/extending/extending.html#a-simple-example
is ever wronger, since it says, after presenting spam_system's code:

"""The self argument is only used when the C function implements a
built-in method, not a function. In the example, self will always be a
NULL pointer, since we are defining a function, not a method. """

It will never be NULL; it will point to the module.

----------
assignee: georg.brandl
components: Documentation
keywords: easy
messages: 90134
nosy: aleax, georg.brandl
priority: normal
severity: normal
status: open
title: errors in docs re module initialization vs self arg to functions
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6421>
_______________________________________

From report at bugs.python.org  Sun Jul  5 01:27:51 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 04 Jul 2009 23:27:51 +0000
Subject: [issue6410] Dictionaries should support __add__
In-Reply-To: <1246653238.95.0.314927755738.issue6410@psf.upfronthosting.co.za>
Message-ID: <1246750071.93.0.459160325517.issue6410@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Lists, tuples, and strings are all sequences. Adding two non-ordering
mappings makes much less sense in my head than two sequences.

----------
nosy: +benjamin.peterson
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6410>
_______________________________________

From report at bugs.python.org  Sun Jul  5 01:37:41 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sat, 04 Jul 2009 23:37:41 +0000
Subject: [issue6410] Dictionaries should support __add__
In-Reply-To: <1246653238.95.0.314927755738.issue6410@psf.upfronthosting.co.za>
Message-ID: <1246750661.33.0.613321389135.issue6410@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Tim Gordon wrote:
> __add__ is non-commutative for lists, tuples, strings etc. - perhaps 
> non-commutative wasn't quite what you were looking for :p.

Yeah, I was not clear in my explanation.

The thing is for lists, tuples, string and other ordered types
concatenation is a well-defined concept. Whereas for dictionaries is not
obvious what concatenation should do with duplicate keys. For example,
what would be the result of {"a": 1, "b": 2} + {"a": 2, "b": 1}? Should
it be {"a": 1, "b": 2} or {"a": 2, "b": 1}?

Also, it would be inconsistent the use of | for the union operation of sets.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6410>
_______________________________________

From report at bugs.python.org  Sun Jul  5 01:38:03 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sat, 04 Jul 2009 23:38:03 +0000
Subject: [issue6410] Dictionaries should support __add__
In-Reply-To: <1246653238.95.0.314927755738.issue6410@psf.upfronthosting.co.za>
Message-ID: <1246750683.73.0.986557706404.issue6410@psf.upfronthosting.co.za>


Changes by Alexandre Vassalotti <alexandre at peadrop.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6410>
_______________________________________

From report at bugs.python.org  Sun Jul  5 01:46:26 2009
From: report at bugs.python.org (Jesse Noller)
Date: Sat, 04 Jul 2009 23:46:26 +0000
Subject: [issue6417] multiprocessing Process examples: print and getppid
In-Reply-To: <1246719525.24.0.54072257834.issue6417@psf.upfronthosting.co.za>
Message-ID: <1246751186.09.0.845854150109.issue6417@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6417>
_______________________________________

From report at bugs.python.org  Sun Jul  5 01:51:49 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 04 Jul 2009 23:51:49 +0000
Subject: [issue6410] Dictionaries should support __add__
In-Reply-To: <1246653238.95.0.314927755738.issue6410@psf.upfronthosting.co.za>
Message-ID: <1246751509.28.0.477656045784.issue6410@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

A dict.merge() method could be added so that:

>>> a = dict(x=10, y=20)
>>> b = dict(y=30, z=40)
>>> a.merge(b)
dict(x=10, y=20, z=40)
>>> b.merge(a)
dict(y=30, z=40, x=10)

In case of duplicate keys, the items of the second dict with the same
keys will be discarded (even if dict.update() does the opposite, I think
here it make more sense in this way).

I never needed to do something like this though, so I'm +0 about it.

----------
nosy: +ezio.melotti
priority:  -> low
resolution: rejected -> 
status: closed -> open
versions: +Python 2.7, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6410>
_______________________________________

From report at bugs.python.org  Sun Jul  5 02:23:25 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 05 Jul 2009 00:23:25 +0000
Subject: [issue6410] Dictionaries should support __add__
In-Reply-To: <1246653238.95.0.314927755738.issue6410@psf.upfronthosting.co.za>
Message-ID: <1246753405.23.0.0315707811565.issue6410@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

IIRC, Guido has previously rejected this suggestion and its variants.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6410>
_______________________________________

From report at bugs.python.org  Sun Jul  5 03:27:03 2009
From: report at bugs.python.org (Jason Pellerin)
Date: Sun, 05 Jul 2009 01:27:03 +0000
Subject: [issue6418] unittest.TestProgram change breaks nose
In-Reply-To: <1246739248.73.0.754849239276.issue6418@psf.upfronthosting.co.za>
Message-ID: <1246757223.23.0.882672631649.issue6418@psf.upfronthosting.co.za>


Changes by Jason Pellerin <jpellerin at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file14452/6418.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6418>
_______________________________________

From report at bugs.python.org  Sun Jul  5 04:03:39 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 05 Jul 2009 02:03:39 +0000
Subject: [issue6151] Make PyDescr_COMMON conform to standard C
In-Reply-To: <1243725945.44.0.74609777501.issue6151@psf.upfronthosting.co.za>
Message-ID: <1246759419.92.0.0243785232829.issue6151@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

New patch with the superfluous macros stripped out. However, I still
like my original patch better, since it is a bit more consistent.

Anyway, is anyone opposed to this change?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6151>
_______________________________________

From report at bugs.python.org  Sun Jul  5 05:26:52 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sun, 05 Jul 2009 03:26:52 +0000
Subject: [issue6410] Dictionaries should support __add__
In-Reply-To: <1246653238.95.0.314927755738.issue6410@psf.upfronthosting.co.za>
Message-ID: <1246764412.57.0.994885232507.issue6410@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

> IIRC, Guido has previously rejected this suggestion and its variants.

Got a link?  It'd be nice to know what the rationale was.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6410>
_______________________________________

From report at bugs.python.org  Sun Jul  5 05:41:30 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 05 Jul 2009 03:41:30 +0000
Subject: [issue6410] Dictionaries should support __add__
In-Reply-To: <1246653238.95.0.314927755738.issue6410@psf.upfronthosting.co.za>
Message-ID: <1246765290.79.0.352063042601.issue6410@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Regardless of whether this feature will be dict.merge or __add__, it
needs to work its way through python-ideas first.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6410>
_______________________________________

From report at bugs.python.org  Sun Jul  5 06:44:11 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 05 Jul 2009 04:44:11 +0000
Subject: [issue2370] operator.{isCallable,sequenceIncludes} needs a fixer
In-Reply-To: <1205784272.93.0.866002228926.issue2370@psf.upfronthosting.co.za>
Message-ID: <1246769051.4.0.929838093648.issue2370@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Committed the warning patch in r73846 (with a minor correction in
r73847), the 2to3 fixer in r73849.

Thanks!

----------
assignee: collinwinter -> 
nosy: +alexandre.vassalotti
resolution:  -> accepted
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2370>
_______________________________________

From report at bugs.python.org  Sun Jul  5 07:13:50 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 05 Jul 2009 05:13:50 +0000
Subject: [issue6416] Failed to compile selectmodule.c on windows (trunk)
In-Reply-To: <1246706675.4.0.617951670977.issue6416@psf.upfronthosting.co.za>
Message-ID: <1246770830.13.0.212965995969.issue6416@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


----------
priority:  -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6416>
_______________________________________

From report at bugs.python.org  Sun Jul  5 07:14:23 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 05 Jul 2009 05:14:23 +0000
Subject: [issue6416] Failed to compile selectmodule.c on windows (trunk)
In-Reply-To: <1246706675.4.0.617951670977.issue6416@psf.upfronthosting.co.za>
Message-ID: <1246770863.01.0.888686086638.issue6416@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


----------
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6416>
_______________________________________

From report at bugs.python.org  Sun Jul  5 07:15:57 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 05 Jul 2009 05:15:57 +0000
Subject: [issue6416] Failed to compile selectmodule.c on windows (trunk)
In-Reply-To: <1246706675.4.0.617951670977.issue6416@psf.upfronthosting.co.za>
Message-ID: <1246770957.24.0.445902805127.issue6416@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


----------
versions: +Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6416>
_______________________________________

From report at bugs.python.org  Sun Jul  5 07:40:07 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 05 Jul 2009 05:40:07 +0000
Subject: [issue4509] bugs in array.array with exports (buffer protocol)
In-Reply-To: <1228341998.62.0.651194722962.issue4509@psf.upfronthosting.co.za>
Message-ID: <1246772407.71.0.762032072028.issue4509@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Fixed the array bug in r73850. Is there any bug left to fixed that were
reported in this issue?

----------
nosy: +alexandre.vassalotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4509>
_______________________________________

From report at bugs.python.org  Sun Jul  5 08:49:05 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 05 Jul 2009 06:49:05 +0000
Subject: [issue4005] pydoc in web server mode tails at initial request
In-Reply-To: <1222842290.34.0.581261002226.issue4005@psf.upfronthosting.co.za>
Message-ID: <1246776545.33.0.482160446313.issue4005@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Committed in r73856.

----------
nosy: +alexandre.vassalotti
resolution:  -> accepted
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4005>
_______________________________________

From report at bugs.python.org  Sun Jul  5 09:25:25 2009
From: report at bugs.python.org (Roger Binns)
Date: Sun, 05 Jul 2009 07:25:25 +0000
Subject: [issue6040] bdist_msi does not deal with pre-release version
In-Reply-To: <1242472106.67.0.523299229524.issue6040@psf.upfronthosting.co.za>
Message-ID: <1246778725.64.0.699623664139.issue6040@psf.upfronthosting.co.za>


Roger Binns <python at rogerbinns.com> added the comment:

This issue is highly annoying.  The ultimate cause is the msi code using
the StrictVersion class to get the version number.  StrictVersion is
documented to be constrained to numerical dot separated versions, and
there doesn't appear to be a way of providing that.  My extension has a
human readable version and I'm happy to also provide a different mangled
version to keep this command working.  I suspect the strictversion
doesn't actually matter than much and is only used to identify an
identical version of the installer so there is no reason why it can't be
automatically derived from the human readable version.

----------
nosy: +rogerbinns

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6040>
_______________________________________

From report at bugs.python.org  Sun Jul  5 09:46:55 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 05 Jul 2009 07:46:55 +0000
Subject: [issue2356] fixer for sys.exitfunc -> atexit
In-Reply-To: <1205782652.14.0.516090878435.issue2356@psf.upfronthosting.co.za>
Message-ID: <1246780015.58.0.381188719397.issue2356@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Here is an attempt to add a Py3K warning when sys.exitfunc is modified.

----------
nosy: +alexandre.vassalotti
Added file: http://bugs.python.org/file14453/sys_exitfunc_warning.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2356>
_______________________________________

From report at bugs.python.org  Sun Jul  5 10:27:40 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 05 Jul 2009 08:27:40 +0000
Subject: [issue2733] mmap resize fails on anonymous memory
In-Reply-To: <1209661457.64.0.989081565875.issue2733@psf.upfronthosting.co.za>
Message-ID: <1246782460.09.0.311363721599.issue2733@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I still think we should forbid to resize anonymous memory map because
this operation is really problematic. I think original poster's purpose
can be fulfilled with creation of another mmap object with same tagname.

Here is a patch for it.

----------
components:  -Windows
stage: commit review -> 
title: mmap resize fails on anonymous memory (Windows) -> mmap resize fails on anonymous memory
versions: +Python 3.2 -Python 2.6, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file14454/mmap_disable_anonymous_resize.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2733>
_______________________________________

From report at bugs.python.org  Sun Jul  5 11:32:49 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 05 Jul 2009 09:32:49 +0000
Subject: [issue6333] logging: ValueError: I/O operation on closed file
In-Reply-To: <1245807768.39.0.536701423847.issue6333@psf.upfronthosting.co.za>
Message-ID: <1246786369.35.0.749353647895.issue6333@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Can you submit a short script which demonstrates the bug? Your fix is
unfortunately not suitable to use as-is, since the StreamHandler
operates on file-like objects, and these are not guaranteed to have the
"closed" attribute.

----------
assignee:  -> vsajip
nosy: +vsajip
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6333>
_______________________________________

From report at bugs.python.org  Sun Jul  5 12:08:21 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 05 Jul 2009 10:08:21 +0000
Subject: [issue1741130] struct.pack("I", "foo");
	struct.pack("L", "foo") should fail
Message-ID: <1246788501.95.0.297404449469.issue1741130@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Strange TypeError message fixed in r73858: those pack operations now raise 
struct.error, like they do for all other integer codes.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1741130>
_______________________________________

From report at bugs.python.org  Sun Jul  5 12:09:44 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 05 Jul 2009 10:09:44 +0000
Subject: [issue1530559] struct.pack raises TypeError where it used to convert
Message-ID: <1246788584.61.0.824682578674.issue1530559@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This is now fixed in the trunk in r73858.  The failing test has been 
reenabled.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1530559>
_______________________________________

From report at bugs.python.org  Sun Jul  5 12:15:44 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 05 Jul 2009 10:15:44 +0000
Subject: [issue1523] xdrlib fails to detect overflow (struct bug?)
In-Reply-To: <1196356512.02.0.767950905039.issue1523@psf.upfronthosting.co.za>
Message-ID: <1246788944.8.0.321274501502.issue1523@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I think there's nothing we can do about this in 2.6: there's probably code 
out there that depends on the overflow behaviour.

However, 2.6 should have been issuing DeprecationWarnings for overflow 
handling, so it would be safe to remove the overflow wrapping for 2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1523>
_______________________________________

From report at bugs.python.org  Sun Jul  5 13:43:07 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 05 Jul 2009 11:43:07 +0000
Subject: [issue6343] TimedRotatingFileHandler permission denied rename failure
	on Windows
In-Reply-To: <1245949185.33.0.897995880567.issue6343@psf.upfronthosting.co.za>
Message-ID: <1246794187.34.0.871784450509.issue6343@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I'm running your test script (WinXP, Python 2.5) and am unable to
reproduce the error, after running the script for a couple of hours.

Is it possible that you have e.g. anti-virus software or backup software
or some other application (e.g. a service) running in the background
which could temporarily be locking the log files? If the failure happens
repeatably on your system, try running filemon (Microsoft sysinternals)
to see system-wide file activity which could be causing the problem.

----------
nosy: +vsajip
resolution:  -> works for me
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6343>
_______________________________________

From report at bugs.python.org  Sun Jul  5 13:53:17 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 05 Jul 2009 11:53:17 +0000
Subject: [issue6343] TimedRotatingFileHandler permission denied rename failure
	on Windows
In-Reply-To: <1245949185.33.0.897995880567.issue6343@psf.upfronthosting.co.za>
Message-ID: <1246794797.61.0.71875624706.issue6343@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

See http://img15.imageshack.us/img15/5909/screenshotcpc.png which shows
the script being run.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6343>
_______________________________________

From report at bugs.python.org  Sun Jul  5 16:14:16 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 05 Jul 2009 14:14:16 +0000
Subject: [issue6377] distutils compiler switch ignored
In-Reply-To: <1246299740.9.0.786372120366.issue6377@psf.upfronthosting.co.za>
Message-ID: <1246803256.59.0.455175793513.issue6377@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Here's the patch. There's no simple way to deprecate the usage of
"compiler" as an attribute, so I have just fixed Python setup.py.
Using it as an attribute is just wrong.

I have put Benjamin in the loop and I'll wait for his greenlight to
commit this change.

----------
nosy: +benjamin.peterson
Added file: http://bugs.python.org/file14455/compiler.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6377>
_______________________________________

From report at bugs.python.org  Sun Jul  5 16:42:00 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 05 Jul 2009 14:42:00 +0000
Subject: [issue6377] distutils compiler switch ignored
In-Reply-To: <1246299740.9.0.786372120366.issue6377@psf.upfronthosting.co.za>
Message-ID: <1246804920.1.0.905479700642.issue6377@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I think the patch is fine. (Did you try using the descriptor protocol to
add a deprecation warning?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6377>
_______________________________________

From report at bugs.python.org  Sun Jul  5 17:08:49 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 05 Jul 2009 15:08:49 +0000
Subject: [issue6377] distutils compiler switch ignored
In-Reply-To: <1246299740.9.0.786372120366.issue6377@psf.upfronthosting.co.za>
Message-ID: <1246806529.98.0.810413829388.issue6377@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Right, turning compiler into a property and adding a warning on the set
would be good enough I guess. Then turn it back into a simple string for
python 3.3 and ... 2.8 :)

I'll add that

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6377>
_______________________________________

From report at bugs.python.org  Sun Jul  5 17:15:12 2009
From: report at bugs.python.org (Scott David Daniels)
Date: Sun, 05 Jul 2009 15:15:12 +0000
Subject: [issue6422] timeit called from within Python should allow autoranging
In-Reply-To: <1246806912.2.0.722769600334.issue6422@psf.upfronthosting.co.za>
Message-ID: <1246806912.2.0.722769600334.issue6422@psf.upfronthosting.co.za>


New submission from Scott David Daniels <Scott.Daniels at Acm.Org>:

timeit.main has a _very_ handy autoranging facility to pick an
appropriate number of repetitions when not specified.  The autoranging
code should be lifted to a method on Timer instances (so non-main code
can use it).  If number is specified as 0 or None, I would like to use
the results of that autoranging code in Timer.repeat and Timer.timeit.

Patch to follow.

----------
components: Library (Lib)
messages: 90157
nosy: scott_daniels
severity: normal
status: open
title: timeit called from within Python should allow autoranging
type: feature request
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6422>
_______________________________________

From report at bugs.python.org  Sun Jul  5 17:17:31 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 05 Jul 2009 15:17:31 +0000
Subject: [issue6418] unittest.TestProgram change breaks nose
In-Reply-To: <1246739248.73.0.754849239276.issue6418@psf.upfronthosting.co.za>
Message-ID: <1246807051.75.0.418331741476.issue6418@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
nosy: +tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6418>
_______________________________________

From report at bugs.python.org  Sun Jul  5 18:05:32 2009
From: report at bugs.python.org (Christoph Zwerschke)
Date: Sun, 05 Jul 2009 16:05:32 +0000
Subject: [issue6423] The cgi docs should advertize using "in" instead of
	"has_key"
In-Reply-To: <1246809932.04.0.15312988227.issue6423@psf.upfronthosting.co.za>
Message-ID: <1246809932.04.0.15312988227.issue6423@psf.upfronthosting.co.za>


New submission from Christoph Zwerschke <cito at online.de>:

The cgi.Fieldstorage class supports the __contains__ method since Py
2.2, but the documentation of Py 2.6 still only mentions the old
fashioned has_key method. See patch.

----------
assignee: georg.brandl
components: Documentation
files: cgi.patch
keywords: patch
messages: 90158
nosy: cito, georg.brandl
severity: normal
status: open
title: The cgi docs should advertize using "in" instead of "has_key"
versions: Python 2.6
Added file: http://bugs.python.org/file14456/cgi.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6423>
_______________________________________

From report at bugs.python.org  Sun Jul  5 18:24:53 2009
From: report at bugs.python.org (Thomas Courbon)
Date: Sun, 05 Jul 2009 16:24:53 +0000
Subject: [issue6424] Idle3 crashing when using completion
In-Reply-To: <1246811092.0.0.225058940814.issue6424@psf.upfronthosting.co.za>
Message-ID: <1246811092.0.0.225058940814.issue6424@psf.upfronthosting.co.za>


New submission from Thomas Courbon <harthie at yahoo.fr>:

Configuration : fedora 11, python3.1 manually compiled and installed
along python 2.6 (provided by the distribution).

Reproducibility : seems to be happening any time

Description : When you try to use the auto-completion (ctrl + space) on
anything (tested with module and custom class), the idle crash with the
message :
Traceback (most recent call last):
  File "/usr/local/bin/idle3", line 5, in <module>
    main()
  File "/usr/local/lib/python3.1/idlelib/PyShell.py", line 1420, in main
    root.mainloop()
  File "/usr/local/lib/python3.1/tkinter/__init__.py", line 1009, in
mainloop
    self.tk.mainloop(n)
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 0-1:
illegal encoding

----------
components: IDLE
messages: 90159
nosy: tcourbon
severity: normal
status: open
title: Idle3 crashing when using completion
type: crash
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6424>
_______________________________________

From report at bugs.python.org  Sun Jul  5 21:35:08 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 05 Jul 2009 19:35:08 +0000
Subject: [issue1581182] Definition of a "character" is wrong
Message-ID: <1246822508.34.0.84533222505.issue1581182@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1581182>
_______________________________________

From report at bugs.python.org  Sun Jul  5 22:57:22 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sun, 05 Jul 2009 20:57:22 +0000
Subject: [issue6382] test_socketserver fails on trunk in test_ForkingTCPServer
In-Reply-To: <1246327124.37.0.772968679477.issue6382@psf.upfronthosting.co.za>
Message-ID: <1246827442.91.0.170448044953.issue6382@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

submitted revision 73863.  Please test for me on gentoo.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6382>
_______________________________________

From report at bugs.python.org  Mon Jul  6 00:19:50 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 05 Jul 2009 22:19:50 +0000
Subject: [issue6424] Idle3 crashing when using completion
In-Reply-To: <1246811092.0.0.225058940814.issue6424@psf.upfronthosting.co.za>
Message-ID: <1246832390.03.0.692981923073.issue6424@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Duplicate of issue6144

----------
nosy: +amaury.forgeotdarc
resolution:  -> duplicate
status: open -> closed
superseder:  -> [IDLE] UnicodeDecodeError when invoking force-open-completions

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6424>
_______________________________________

From report at bugs.python.org  Mon Jul  6 00:47:25 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 05 Jul 2009 22:47:25 +0000
Subject: [issue2389] Array pickling exposes internal memory representation of
	elements
In-Reply-To: <1205851091.96.0.575523128038.issue2389@psf.upfronthosting.co.za>
Message-ID: <1246834045.67.0.99102888468.issue2389@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

I would like to commit my patch later this week. So if you see any issue
with the patch, please speak up.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2389>
_______________________________________

From report at bugs.python.org  Mon Jul  6 00:47:43 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 05 Jul 2009 22:47:43 +0000
Subject: [issue2389] Array pickling exposes internal memory representation of
	elements
In-Reply-To: <1205851091.96.0.575523128038.issue2389@psf.upfronthosting.co.za>
Message-ID: <1246834063.87.0.819890001999.issue2389@psf.upfronthosting.co.za>


Changes by Alexandre Vassalotti <alexandre at peadrop.com>:


Removed file: http://bugs.python.org/file11096/fix_array_pickling.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2389>
_______________________________________

From report at bugs.python.org  Mon Jul  6 07:48:56 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 06 Jul 2009 05:48:56 +0000
Subject: [issue3410] platform.version() don't work as expected in Vista
	in	portuguese
In-Reply-To: <1216410595.08.0.936182141358.issue3410@psf.upfronthosting.co.za>
Message-ID: <1246859336.78.0.825608989816.issue3410@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Here are the results.
Windows Vista SP2 in English
  Python 3.0.1:
  >>> platform.platform()
  'Windows-Vista-6.0.6002-SP2'
  >>> platform.version()
  '6.0.6002'
  >>> platform.win32_ver()
  ('Vista', '6.0.6002', 'SP2', 'Multiprocessor Free')

  Python 2.6.2:
  >>> platform.platform()
  'Windows-Vista-6.0.6002-SP2'
  >>> platform.version()
  '6.0.6002'
  >>> platform.win32_ver()
  ('Vista', '6.0.6002', 'SP2', u'Multiprocessor Free')

Windows 2003 Server SP2 in English
  Python 3.1
  >>> platform.platform()
  'Windows-2003Server-5.2.3790-SP2'
  >>> platform.version()
  '5.2.3790'
  >>> platform.win32_ver()
  ('2003Server', '5.2.3790', 'SP2', 'Uniprocessor Free')

Everything seems fine, however I don't have any non-English Windows
here. Do you know if it's possible to download and install language
packs and if they may affect the text in the version? If so, I could try
to do it and see if I can reproduce the original issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3410>
_______________________________________

From report at bugs.python.org  Mon Jul  6 09:28:10 2009
From: report at bugs.python.org (Jarek)
Date: Mon, 06 Jul 2009 07:28:10 +0000
Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
Message-ID: <1246865290.91.0.620082500169.issue1424152@psf.upfronthosting.co.za>


Jarek <jarek.jpa at gmail.com> added the comment:

+1 for mercurial inoperability from behind proxy

----------
nosy: +jarek.jpa

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1424152>
_______________________________________

From report at bugs.python.org  Mon Jul  6 10:18:38 2009
From: report at bugs.python.org (Sjoerd)
Date: Mon, 06 Jul 2009 08:18:38 +0000
Subject: [issue6425] imaplib.IMAP4.fetch() is missing documentation for
	message_set parameter
In-Reply-To: <1246868318.71.0.0692124898896.issue6425@psf.upfronthosting.co.za>
Message-ID: <1246868318.71.0.0692124898896.issue6425@psf.upfronthosting.co.za>


New submission from Sjoerd <sjoerd-python at linuxonly.nl>:

The message_set parameter imaplib.IMAP4.fetch(message_set,
message_parts) is not a set or list, but a comma-separated string, it
seems. This could use some documentation.

----------
assignee: georg.brandl
components: Documentation
messages: 90165
nosy: Sjoerder, georg.brandl
severity: normal
status: open
title: imaplib.IMAP4.fetch() is missing documentation for message_set parameter
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6425>
_______________________________________

From report at bugs.python.org  Mon Jul  6 10:22:59 2009
From: report at bugs.python.org (Sjoerd)
Date: Mon, 06 Jul 2009 08:22:59 +0000
Subject: [issue6426] imaplib.IMAP4 "command illegal in this state" is
	unhelpful error message
In-Reply-To: <1246868579.93.0.42678360783.issue6426@psf.upfronthosting.co.za>
Message-ID: <1246868579.93.0.42678360783.issue6426@psf.upfronthosting.co.za>


New submission from Sjoerd <sjoerd-python at linuxonly.nl>:

If you do not IMAP4.select(), you get the following error:
imaplib.error: command SEARCH illegal in state AUTH.

This does not inform the user that he has to do IMAP4.select(). Better
would be: 
imaplib.error: command SEARCH illegal in state AUTH, allowed in state
SELECTED.

See also:
http://mail.python.org/pipermail/patches/2006-December/021308.html

----------
components: Library (Lib)
messages: 90166
nosy: Sjoerder
severity: normal
status: open
title: imaplib.IMAP4 "command illegal in this state" is unhelpful error message
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6426>
_______________________________________

From report at bugs.python.org  Mon Jul  6 10:45:13 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 06 Jul 2009 08:45:13 +0000
Subject: [issue6423] The cgi docs should advertize using "in" instead of
	"has_key"
In-Reply-To: <1246809932.04.0.15312988227.issue6423@psf.upfronthosting.co.za>
Message-ID: <1246869913.36.0.282212331478.issue6423@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Patch looks good and is ready to commit.  Py3k seems to have been fixed
already.

----------
assignee: georg.brandl -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6423>
_______________________________________

From report at bugs.python.org  Mon Jul  6 11:04:36 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 06 Jul 2009 09:04:36 +0000
Subject: [issue3410] platform.version() don't work as expected in Vista
	in	portuguese
In-Reply-To: <1246859336.78.0.825608989816.issue3410@psf.upfronthosting.co.za>
Message-ID: <4A51BE20.802@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Ezio Melotti wrote:
> Ezio Melotti <ezio.melotti at gmail.com> added the comment:
> 
> Here are the results.
> Windows Vista SP2 in English
>   Python 3.0.1:
>   >>> platform.platform()
>   'Windows-Vista-6.0.6002-SP2'
>   >>> platform.version()
>   '6.0.6002'
>   >>> platform.win32_ver()
>   ('Vista', '6.0.6002', 'SP2', 'Multiprocessor Free')
> 
>   Python 2.6.2:
>   >>> platform.platform()
>   'Windows-Vista-6.0.6002-SP2'
>   >>> platform.version()
>   '6.0.6002'
>   >>> platform.win32_ver()
>   ('Vista', '6.0.6002', 'SP2', u'Multiprocessor Free')
> 
> Windows 2003 Server SP2 in English
>   Python 3.1
>   >>> platform.platform()
>   'Windows-2003Server-5.2.3790-SP2'
>   >>> platform.version()
>   '5.2.3790'
>   >>> platform.win32_ver()
>   ('2003Server', '5.2.3790', 'SP2', 'Uniprocessor Free')

Thanks.

> Everything seems fine, however I don't have any non-English Windows
> here. 

Indeed.

> Do you know if it's possible to download and install language
> packs and if they may affect the text in the version? If so, I could try
> to do it and see if I can reproduce the original issue.

I'm not sure whether that would make a difference.

On XP this does not make a difference - I've tested this with
a German Win XP version.

I think the best strategy is to run win32_ver() through the
pdb debugger in step-by-step mode and on the Vista machine
where you saw the problem.

BTW: Do you have the win32 tools installed on that machine ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3410>
_______________________________________

From report at bugs.python.org  Mon Jul  6 12:30:51 2009
From: report at bugs.python.org (Jack Diederich)
Date: Mon, 06 Jul 2009 10:30:51 +0000
Subject: [issue6427] Rename float*.[ch] to double.[ch]
In-Reply-To: <1246876251.06.0.606868517099.issue6427@psf.upfronthosting.co.za>
Message-ID: <1246876251.06.0.606868517099.issue6427@psf.upfronthosting.co.za>


New submission from Jack Diederich <jackdied at gmail.com>:

The core types use doubles, not floats.  The file and function names
should reflect that (the docs already do).

----------
components: None
messages: 90169
nosy: jackdied
severity: normal
status: open
title: Rename float*.[ch] to double.[ch]
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6427>
_______________________________________

From report at bugs.python.org  Mon Jul  6 12:34:36 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 06 Jul 2009 10:34:36 +0000
Subject: [issue3410] platform.version() don't work as expected in Vista
	in	portuguese
In-Reply-To: <1216410595.08.0.936182141358.issue3410@psf.upfronthosting.co.za>
Message-ID: <1246876476.88.0.882496051814.issue3410@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

On the Vista machine that returned ('', '6.0.6002', 'SP2',
'Multiprocessor Free') there is ActiveState's Python 2.5.2 that includes
the pywin32 extension.

I managed to run pdb on it and the result was http://dpaste.com/hold/63642/
Python 2.5 doesn't have any check for Vista, and in win32_ver(), inside
the "elif plat == VER_PLATFORM_WIN32_NT:" it only checks for maj <= 4
and maj == 5. Vista is 6 and 'release' remains unset [1]. In Py 2.6
there's also if maj == 6 [2] (and now maj == 7 should be added too).

However, I also tried to run what the OP said and indeed I found some
problem. With pdb.run('platform._syscmd_ver()'), on Vista in English I get:
-> info = pipe.read()
(Pdb) s
> c:\program files\python26\lib\platform.py(493)_syscmd_ver()
-> if pipe.close():
(Pdb) info
'\nMicrosoft Windows [Version 6.0.6002]\n'
...
-> m = _ver_output.match(info)
(Pdb) s
> c:\program files\python26\lib\platform.py(511)_syscmd_ver()
-> if m is not None:
(Pdb) m
<_sre.SRE_Match object at 0x0000000002812AE0>
(Pdb) m.groups()
('Microsoft', 'Windows', '6.0.6002')

where _ver_output = re.compile(r'(?:([\w ]+) ([\w.]+) '
                         '.*'
                         'Version ([\d.]+))')

In non-English versions instead the regex doesn't match:
-> if pipe.close():
(Pdb) p info
'\nMicrosoft Windows [Versione 6.0.6002]\n'
...
> c:\program files\python25\lib\platform.py(420)_syscmd_ver()
-> m = _ver_output.match(info)
(Pdb) n
> c:\program files\python25\lib\platform.py(421)_syscmd_ver()
-> if m:
(Pdb) m
(Pdb)

Since 'Version' is translated, the regex fails if the translation is
different because it checks specifically for the word 'Version'.
Replacing it with \S+ as the OP suggested sounds like a reasonable
solution. It is possible that even other versions of Windows (e.g. XP)
have 'Version' translated, can you reproduce it with your German XP?

Later I can try on another non-English XP and see if the regex match.

[1]: /python/branches/release25-maint/Lib/platform.py?view=markup
[2]: /python/branches/release26-maint/Lib/platform.py?view=markup

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3410>
_______________________________________

From report at bugs.python.org  Mon Jul  6 12:49:35 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 06 Jul 2009 10:49:35 +0000
Subject: [issue3410] platform.version() don't work as expected in Vista
	in	portuguese
In-Reply-To: <1246876476.88.0.882496051814.issue3410@psf.upfronthosting.co.za>
Message-ID: <4A51D6AE.808@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Ezio Melotti wrote:
> Ezio Melotti <ezio.melotti at gmail.com> added the comment:
> 
> On the Vista machine that returned ('', '6.0.6002', 'SP2',
> 'Multiprocessor Free') there is ActiveState's Python 2.5.2 that includes
> the pywin32 extension.
> 
> I managed to run pdb on it and the result was http://dpaste.com/hold/63642/
> Python 2.5 doesn't have any check for Vista, and in win32_ver(), inside
> the "elif plat == VER_PLATFORM_WIN32_NT:" it only checks for maj <= 4
> and maj == 5. Vista is 6 and 'release' remains unset [1]. In Py 2.6
> there's also if maj == 6 [2] (and now maj == 7 should be added too).

Ah, that makes sense: Vista support only got added in Python 2.6.
We cannot add that support to Python 2.5, since that branch is
closed.

Note however that platform.py does work with multiple Python versions,
so you can always copy the module from a later version and hand-replace
the one from the original distribution with an updated one.

> However, I also tried to run what the OP said and indeed I found some
> problem. With pdb.run('platform._syscmd_ver()'), on Vista in English I get:
> -> info = pipe.read()
> (Pdb) s
>> c:\program files\python26\lib\platform.py(493)_syscmd_ver()
> -> if pipe.close():
> (Pdb) info
> '\nMicrosoft Windows [Version 6.0.6002]\n'
> ...
> -> m = _ver_output.match(info)
> (Pdb) s
>> c:\program files\python26\lib\platform.py(511)_syscmd_ver()
> -> if m is not None:
> (Pdb) m
> <_sre.SRE_Match object at 0x0000000002812AE0>
> (Pdb) m.groups()
> ('Microsoft', 'Windows', '6.0.6002')
> 
> where _ver_output = re.compile(r'(?:([\w ]+) ([\w.]+) '
>                          '.*'
>                          'Version ([\d.]+))')
> 
> In non-English versions instead the regex doesn't match:
> -> if pipe.close():
> (Pdb) p info
> '\nMicrosoft Windows [Versione 6.0.6002]\n'
> ...
>> c:\program files\python25\lib\platform.py(420)_syscmd_ver()
> -> m = _ver_output.match(info)
> (Pdb) n
>> c:\program files\python25\lib\platform.py(421)_syscmd_ver()
> -> if m:
> (Pdb) m
> (Pdb)

Thanks for checking.

> Since 'Version' is translated, the regex fails if the translation is
> different because it checks specifically for the word 'Version'.
> Replacing it with \S+ as the OP suggested sounds like a reasonable
> solution. It is possible that even other versions of Windows (e.g. XP)
> have 'Version' translated, can you reproduce it with your German XP?

Interesting. In the German XP uses 'Version' as well, so the regexp
matches just fine.

I'll correct the regexp to only try matching on 'Ver\w+'.

> Later I can try on another non-English XP and see if the regex match.
> 
> [1]: /python/branches/release25-maint/Lib/platform.py?view=markup
> [2]: /python/branches/release26-maint/Lib/platform.py?view=markup

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3410>
_______________________________________

From report at bugs.python.org  Mon Jul  6 12:54:49 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 06 Jul 2009 10:54:49 +0000
Subject: [issue3410] platform.version() don't work as expected in Vista
	in	portuguese
In-Reply-To: <1216410595.08.0.936182141358.issue3410@psf.upfronthosting.co.za>
Message-ID: <1246877689.17.0.0756175055702.issue3410@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Won't that fail with Windows versions in Japanese, Chinese, Arab and
similar?
If 'Version' is translated in all the languages as a single word and
it's between whitespaces (or even between a [ and a space), \S+ should
be safe enough, otherwise \w+ with the re.U flag should work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3410>
_______________________________________

From report at bugs.python.org  Mon Jul  6 13:31:39 2009
From: report at bugs.python.org (Felipe Portella)
Date: Mon, 06 Jul 2009 11:31:39 +0000
Subject: [issue3410] platform.version() don't work as expected in Vista in
	portuguese
In-Reply-To: <1246877689.17.0.0756175055702.issue3410@psf.upfronthosting.co.za>
Message-ID: <56d0c53f0907060431i6deb57c8pa6a26e409f480b5e@mail.gmail.com>


Felipe Portella <felipe at portella.com.br> added the comment:

The same happens in Portuguese version ... the regex fails because ver
returns "Vers??o" ...

[]'s

On Mon, Jul 6, 2009 at 7:54 AM, Ezio Melotti <report at bugs.python.org> wrote:

>
> Ezio Melotti <ezio.melotti at gmail.com> added the comment:
>
> Won't that fail with Windows versions in Japanese, Chinese, Arab and
> similar?
> If 'Version' is translated in all the languages as a single word and
> it's between whitespaces (or even between a [ and a space), \S+ should
> be safe enough, otherwise \w+ with the re.U flag should work.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3410>
> _______________________________________
>

----------
title: platform.version() don't work as expected in Vista in	portuguese -> platform.version() don't work as expected in Vista in portuguese
Added file: http://bugs.python.org/file14457/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3410>
_______________________________________
-------------- next part --------------
The same happens in Portuguese version ... the regex fails because ver returns &quot;Vers??o&quot; ...<br><br>[]&#39;s<br><br><div class="gmail_quote">On Mon, Jul 6, 2009 at 7:54 AM, Ezio Melotti <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im"><br>
Ezio Melotti &lt;<a href="mailto:ezio.melotti at gmail.com">ezio.melotti at gmail.com</a>&gt; added the comment:<br>
<br>
</div>Won&#39;t that fail with Windows versions in Japanese, Chinese, Arab and<br>
similar?<br>
If &#39;Version&#39; is translated in all the languages as a single word and<br>
it&#39;s between whitespaces (or even between a [ and a space), \S+ should<br>
be safe enough, otherwise \w+ with the re.U flag should work.<br>
<br>
----------<br>
<div><div></div><div class="h5"><br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue3410" target="_blank">http://bugs.python.org/issue3410</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br>

From report at bugs.python.org  Mon Jul  6 13:59:27 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 06 Jul 2009 11:59:27 +0000
Subject: [issue3410] platform.version() don't work as expected in Vista in
	portuguese
In-Reply-To: <1216410595.08.0.936182141358.issue3410@psf.upfronthosting.co.za>
Message-ID: <1246881567.82.0.3612388609.issue3410@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

According to Google Translate, in Vietnamese 'Version' is 'Phi?n b?n'.
If this is true both \S+ and \w+ will fail.
I also noticed a few more regex (namely _release_filename,
_lsb_release_version and _release_version) which contain the words
'version' and 'release' and may fail if these are translated.
I guess I'll have to check with some live cd (since these regex are used
for Linux apparently) and some other language to see if it works.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3410>
_______________________________________

From report at bugs.python.org  Mon Jul  6 14:12:11 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 06 Jul 2009 12:12:11 +0000
Subject: [issue6427] Rename float*.[ch] to double.[ch]
In-Reply-To: <1246876251.06.0.606868517099.issue6427@psf.upfronthosting.co.za>
Message-ID: <1246882331.97.0.455334739872.issue6427@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

'float' is how python names its floating point number type, and this
won't change.  Yes, it is based on the C double, but I think that the
code is very careful to avoid the confusion.

For example, in the C sources, the word 'float' always has a 'Py'
prefix, or an 'object' suffix, to assert that it refers to the python
type (e.g. PyFloat_FromDouble, floatobject.c)

Do you have a precise example where the distinction is not clear?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6427>
_______________________________________

From report at bugs.python.org  Mon Jul  6 14:51:29 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 06 Jul 2009 12:51:29 +0000
Subject: [issue6377] distutils compiler switch ignored
In-Reply-To: <1246299740.9.0.786372120366.issue6377@psf.upfronthosting.co.za>
Message-ID: <1246884689.47.0.907977535796.issue6377@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

done in r73864, waiting for the buildbots to build trunk, then will be
applied in 3.x

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6377>
_______________________________________

From report at bugs.python.org  Mon Jul  6 14:59:34 2009
From: report at bugs.python.org (Eric Smith)
Date: Mon, 06 Jul 2009 12:59:34 +0000
Subject: [issue6427] Rename float*.[ch] to double.[ch]
In-Reply-To: <1246876251.06.0.606868517099.issue6427@psf.upfronthosting.co.za>
Message-ID: <1246885174.7.0.167329978539.issue6427@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

-1

The time to change this was 3.0, if it was ever needed. It would break
too much code now. We could develop some strategy using macros, but I
just don't think it's worth it.

And as Amaury points it, the type is known in python as "float", so to
change it would be confusing. That it uses C doubles is an
implementation detail.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6427>
_______________________________________

From report at bugs.python.org  Mon Jul  6 15:03:07 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 06 Jul 2009 13:03:07 +0000
Subject: [issue824371] ntpath.expandvars doesn't expand Windows-style
	variables.
Message-ID: <1246885387.3.0.819994490668.issue824371@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This is already part of 2.6:

>>> os.path.expandvars("%WIndir%/foo")
'C:\\WINNT/foo'
>>> os.path.expandvars("%invalid%")
'%invalid%'

----------
nosy: +amaury.forgeotdarc
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue824371>
_______________________________________

From report at bugs.python.org  Mon Jul  6 15:55:46 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 06 Jul 2009 13:55:46 +0000
Subject: [issue6377] distutils compiler switch ignored
In-Reply-To: <1246299740.9.0.786372120366.issue6377@psf.upfronthosting.co.za>
Message-ID: <1246888546.51.0.272833307767.issue6377@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

merged in r73866 in py3k


Thanks for the feedback

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6377>
_______________________________________

From report at bugs.python.org  Mon Jul  6 16:26:42 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 06 Jul 2009 14:26:42 +0000
Subject: [issue6395] Add Pickle Support to the codecs Module
In-Reply-To: <1246463188.35.0.320675118154.issue6395@psf.upfronthosting.co.za>
Message-ID: <1246890402.61.0.782074173872.issue6395@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

I don't understand the use case for this. 

If the StreamWriter/Reader cannot pickle the underlying stream (which is
probably always the case), why should the object itself be pickleable ?

What we could do is implement .__get/setstate__() and have it raise an
exception to inform the user of the problem.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6395>
_______________________________________

From report at bugs.python.org  Mon Jul  6 16:45:34 2009
From: report at bugs.python.org (SilentGhost)
Date: Mon, 06 Jul 2009 14:45:34 +0000
Subject: [issue6428] TypeError: __bool__ should return bool or int,
	returned int
In-Reply-To: <1246891534.57.0.238134342776.issue6428@psf.upfronthosting.co.za>
Message-ID: <1246891534.57.0.238134342776.issue6428@psf.upfronthosting.co.za>


New submission from SilentGhost <michael.mischurow+bpo at gmail.com>:

According to docs
(http://docs.python.org/3.1/reference/datamodel.html#object.__bool__)
__bool__ can return 1 or 0 instead of True or False.
However, when I ran the following code:

Python 3.1 (r31:73574, Jun 26 2009, 20:21:35) [MSC v.1500 32 bit
(Intel)] on win32
>>> class Spam():
	def __bool__(self):
		return 1

	
>>> if Spam():
	print('ham')

I got the following error:
	
Traceback (most recent call last):
  File "<pyshell#72>", line 1, in <module>
    if Spam():
TypeError: __bool__ should return bool or int, returned int

So, do I misunderstand the docs or is it an error in them?

----------
assignee: georg.brandl
components: Documentation, Interpreter Core
messages: 90181
nosy: SilentGhost, georg.brandl
severity: normal
status: open
title: TypeError: __bool__ should return bool or int, returned int
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6428>
_______________________________________

From report at bugs.python.org  Mon Jul  6 18:17:07 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 06 Jul 2009 16:17:07 +0000
Subject: [issue6382] test_socketserver fails on trunk in test_ForkingTCPServer
In-Reply-To: <1246327124.37.0.772968679477.issue6382@psf.upfronthosting.co.za>
Message-ID: <1246897027.32.0.241003543663.issue6382@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I now get a different error, followed by zsh detecting an alarm:

rdmurray at partner:~/python/trunk>./python -m test.regrtest -uall
test_socketserver
Could not find '/home/rdmurray/python/trunk/Lib/test' in sys.path to
remove it
test_socketserver
Exception in thread SocketServer.ForkingUDPServer serving:
Traceback (most recent call last):
  File "/home/rdmurray/python/trunk/Lib/threading.py", line 524, in
__bootstrap_inner
    self.run()
  File "/home/rdmurray/python/trunk/Lib/threading.py", line 477, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/home/rdmurray/python/trunk/Lib/SocketServer.py", line 226, in
serve_forever
    self._handle_request_noblock()
  File "/home/rdmurray/python/trunk/Lib/SocketServer.py", line 283, in
_handle_request_noblock
    self.handle_error(request, client_address)
  File "/home/rdmurray/python/trunk/Lib/SocketServer.py", line 281, in
_handle_request_noblock
    self.process_request(request, client_address)
  File "/home/rdmurray/python/trunk/Lib/SocketServer.py", line 535, in
process_request
    request.close() #close socket handle in parent process
AttributeError: 'tuple' object has no attribute 'close'

zsh: alarm      ./python -m test.regrtest -uall test_socketserver

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6382>
_______________________________________

From report at bugs.python.org  Mon Jul  6 19:13:15 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 06 Jul 2009 17:13:15 +0000
Subject: [issue6429] 2to3: fix_future conflicts with fix_print
In-Reply-To: <1246900395.55.0.0522093786653.issue6429@psf.upfronthosting.co.za>
Message-ID: <1246900395.55.0.0522093786653.issue6429@psf.upfronthosting.co.za>


New submission from Alexandre Vassalotti <alexandre at peadrop.com>:

Running 2to3 with the default options on the following code:

  from __future__ import print_function
  x,y = 1,2
  print(x, y)

produces the following diff:

  --- future_print.py (original)
  +++ future_print.py (refactored)
  @@ -1,5 +1,5 @@
  -from __future__ import print_function
  +
  
   x = 1
   y = 2
  -print(x, y)
  +print((x, y))

If the "--nofix=future" options is specified, 2to3 produces the correct
output.

I found this while working on a fixer for removing future_builtins
imports. It seems that fixer_util.does_tree_import() is unable to find
the __future__ import node and thus causes FixPrint to be run instead of
being skipped.

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 90183
nosy: alexandre.vassalotti, benjamin.peterson
priority: normal
severity: normal
stage: needs patch
status: open
title: 2to3: fix_future conflicts with fix_print
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6429>
_______________________________________

From report at bugs.python.org  Mon Jul  6 19:41:38 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 06 Jul 2009 17:41:38 +0000
Subject: [issue6314] logging.basicConfig(level='DEBUG',
	... and setLevel("DEBUG") result in no logging
In-Reply-To: <1245473929.89.0.283081310598.issue6314@psf.upfronthosting.co.za>
Message-ID: <1246902098.3.0.141866579268.issue6314@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

There is still a problem here, though not something a typical user would
run into:

rdmurray at partner:~/python/trunk>./python
Python 2.7a0 (trunk:73845M, Jul  4 2009, 12:43:10)
[GCC 4.1.2 (Gentoo 4.1.2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import logging
>>> logging.basicConfig(level=object())
>>> logging.info("test")

However, I've expanded the title to cover a second way this bug can be
encountered that is more likely to bite someone (and thus I am reopening
it):

Python 2.7a0 (trunk:73845M, Jul  4 2009, 12:43:10) 
[GCC 4.1.2 (Gentoo 4.1.2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import logging
>>> logging.basicConfig(level=logging.DEBUG)
>>> logging.info('test')
INFO:root:test
>>> logging.getLogger().setLevel("DEBUG")
>>> logging.info('test')

Neither one of these is a problem in 3.x in the sense that if you pass a
string argument under 3.x, the result is not silence:

Python 3.2a0 (py3k:73867M, Jul  6 2009, 12:52:11) 
[GCC 4.1.2 (Gentoo 4.1.2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import logging
>>> logging.basicConfig(level=object())
>>> logging.info("foo")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/rdmurray/python/py3k/Lib/logging/__init__.py", line 1471,
in info
    root.info(msg, *args, **kwargs)
  File "/home/rdmurray/python/py3k/Lib/logging/__init__.py", line 1045,
in info
    if self.isEnabledFor(INFO):
  File "/home/rdmurray/python/py3k/Lib/logging/__init__.py", line 1236,
in isEnabledFor
    return level >= self.getEffectiveLevel()
TypeError: unorderable types: int() >= object()

However, it seems like it would be much better even in the 3.x case to
have the error occur when the level is set rather than when it is used.

To fix this bug I think setLevel should do a type check.  Log already
does a type check (isintance(level, int)), so that's what I think
setLevel should do.  One could alternatively enhance the logging API to
have setLevel accept a string.  That, however, is an enhancement and not
a bugfix, IMO.

I've included a patch that adds the isinstance check, and tests for
same, and reverts the basicConfig change.  Vinay, if you'd rather have
the level-name-lookup enhancement I'd be happy to do it and also do the
doc update, but I don't think the enhancement bits should be backported
to 2.6 or 3.1 so I would do it as a separate patch.

Oh, and one last note: I didn't do the raiseExceptions test in setLevel
the way 'log' does because I figure an error at the config level should
not be suppressed...but raiseExceptions doesn't seem to be documented
(at least, I couldn't find it) so I'm not sure if that's the right thing
to do.

----------
keywords: +patch
nosy: +r.david.murray
priority:  -> normal
resolution: fixed -> 
stage:  -> patch review
status: closed -> open
title: logging.basicConfig(level='DEBUG', ... -> logging.basicConfig(level='DEBUG', ... and setLevel("DEBUG") result in no logging
versions: +Python 2.6, Python 2.7, Python 3.2
Added file: http://bugs.python.org/file14458/issue6314.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6314>
_______________________________________

From report at bugs.python.org  Mon Jul  6 20:01:06 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 06 Jul 2009 18:01:06 +0000
Subject: [issue5683] Speed up cPickle's pickling generally
In-Reply-To: <1238803338.21.0.932870288543.issue5683@psf.upfronthosting.co.za>
Message-ID: <1246903266.71.0.531317907518.issue5683@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Any updates?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5683>
_______________________________________

From report at bugs.python.org  Mon Jul  6 20:17:08 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 06 Jul 2009 18:17:08 +0000
Subject: [issue6151] Make PyDescr_COMMON conform to standard C
In-Reply-To: <1243725945.44.0.74609777501.issue6151@psf.upfronthosting.co.za>
Message-ID: <1246904228.74.0.700546390065.issue6151@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I'm not sure what the "new patch" is since you haven't uploaded it, but
the original patch looks ok. In any case, it shouldn't go into 3.1 since
it breaks source-level compatibility.

----------
nosy: +pitrou
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6151>
_______________________________________

From report at bugs.python.org  Mon Jul  6 21:10:50 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 06 Jul 2009 19:10:50 +0000
Subject: [issue6151] Make PyDescr_COMMON conform to standard C
In-Reply-To: <1243725945.44.0.74609777501.issue6151@psf.upfronthosting.co.za>
Message-ID: <1246907450.35.0.938471707646.issue6151@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

> I'm not sure what the "new patch" is since you haven't uploaded it

Oh silly me. Here's the new patch.

----------
Added file: http://bugs.python.org/file14459/strict-aliasing-pydescr-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6151>
_______________________________________

From report at bugs.python.org  Mon Jul  6 21:33:17 2009
From: report at bugs.python.org (Chris Withers)
Date: Mon, 06 Jul 2009 19:33:17 +0000
Subject: [issue3250] datetime.time does not support arithmetic
In-Reply-To: <1214905740.54.0.833672968887.issue3250@psf.upfronthosting.co.za>
Message-ID: <1246908797.5.0.316835676532.issue3250@psf.upfronthosting.co.za>


Chris Withers <chris at simplistix.co.uk> added the comment:

I think so.

FWIW, I'd recommend looking at:

http://pypi.python.org/pypi/python-dateutil

...for doing things that python's builtin datetime stuff doesn't cater 
for.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3250>
_______________________________________

From report at bugs.python.org  Mon Jul  6 21:40:03 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 06 Jul 2009 19:40:03 +0000
Subject: [issue6428] TypeError: __bool__ should return bool or int,
	returned int
In-Reply-To: <1246891534.57.0.238134342776.issue6428@psf.upfronthosting.co.za>
Message-ID: <1246909203.38.0.302760223728.issue6428@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It's not only the docs, the error message is self-contradictory as well.

----------
assignee: georg.brandl -> 
nosy: +pitrou
priority:  -> normal
stage:  -> needs patch
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6428>
_______________________________________

From report at bugs.python.org  Mon Jul  6 22:40:27 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 06 Jul 2009 20:40:27 +0000
Subject: [issue6430] array.array falsely advertises support for 'w' in
	documentation
In-Reply-To: <1246912827.43.0.704118006779.issue6430@psf.upfronthosting.co.za>
Message-ID: <1246912827.43.0.704118006779.issue6430@psf.upfronthosting.co.za>


New submission from Alexandre Vassalotti <alexandre at peadrop.com>:

It looks like either array's 'w' support got lost in a merge, or the
documentation is just wrong.


>>> import array
>>> array.array('w', "hello")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: bad typecode (must be b, B, u, h, H, i, I, l, L, f or d)
>>> print(array.__doc__)
This module defines an object type which can efficiently represent
an array of basic values: characters, integers, floating point
numbers.  Arrays are sequence types and behave very much like lists,
except that the type of objects stored in them is constrained.  The
type is specified at object creation time by using a type code, which
is a single character.  The following type codes are defined:

    Type code   C Type             Minimum size in bytes 
    'b'         signed integer     1 
    'B'         unsigned integer   1 
    'u'         Unicode character  2 (see note) 
    'h'         signed integer     2 
    'H'         unsigned integer   2 
    'i'         signed integer     2 
    'I'         unsigned integer   2 
    'w'         unicode character  4 
    'l'         signed integer     4 
    'L'         unsigned integer   4 
    'f'         floating point     4 
    'd'         floating point     8 

NOTE: The 'u' typecode corresponds to Python's unicode character. On 
narrow builds this is 2-bytes on wide builds this is 4-bytes.

----------
assignee: georg.brandl
components: Documentation, Extension Modules
messages: 90190
nosy: alexandre.vassalotti, georg.brandl
priority: low
severity: normal
status: open
title: array.array falsely advertises support for 'w' in documentation
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6430>
_______________________________________

From report at bugs.python.org  Mon Jul  6 22:58:00 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 06 Jul 2009 20:58:00 +0000
Subject: [issue6427] Rename float*.[ch] to double.[ch]
In-Reply-To: <1246876251.06.0.606868517099.issue6427@psf.upfronthosting.co.za>
Message-ID: <1246913880.52.0.205477687329.issue6427@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

As Amaury explains, it's called float because it *is* a floating point
type. 

It is not a double type, as it is not two types, but only a single one
:-) In 2.x, the "int" type was also represented with a C long, yet the
type called "long" was not represented with longs but with shorts.

----------
nosy: +loewis
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6427>
_______________________________________

From report at bugs.python.org  Mon Jul  6 23:13:55 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 06 Jul 2009 21:13:55 +0000
Subject: [issue3250] datetime.time does not support arithmetic
In-Reply-To: <1214905740.54.0.833672968887.issue3250@psf.upfronthosting.co.za>
Message-ID: <1246914835.78.0.155205410533.issue3250@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Or use the "original" lib on which this is all based :-)

http://www.egenix.com/products/python/mxBase/mxDateTime/

(and which, of course, does allow subtracting times)

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3250>
_______________________________________

From report at bugs.python.org  Mon Jul  6 23:23:54 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 06 Jul 2009 21:23:54 +0000
Subject: [issue6410] Dictionaries should support __add__
In-Reply-To: <1246653238.95.0.314927755738.issue6410@psf.upfronthosting.co.za>
Message-ID: <1246915434.82.0.149410571884.issue6410@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

FWIW, I'm -1 on the proposal because it partially overlaps the existing
capability of dict.update().  To the extent it doesn't overlap, it is
use case challenged (typically, it doesn't make sense to build a
brand-new dictionary from two independent dictionaries and the atypical
case easily fulfilled by a couple of updates on an empty dict).  

Also, the notation itself is at odds with the existing pipe-operator
used by sets and by dict views.

FWIW, there are other alternatives to directly combining dictionaries. 
See http://code.activestate.com/recipes/305268/ for one example.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6410>
_______________________________________

From report at bugs.python.org  Mon Jul  6 23:47:07 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 06 Jul 2009 21:47:07 +0000
Subject: [issue6410] Dictionaries should support __add__
In-Reply-To: <1246653238.95.0.314927755738.issue6410@psf.upfronthosting.co.za>
Message-ID: <1246916827.15.0.189224391628.issue6410@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

FWIW, here are some use cases:

http://twistedmatrix.com/trac/browser/tags/releases/twisted-8.2.0/twisted/python/context.py#L32
http://twistedmatrix.com/trac/browser/tags/releases/twisted-8.2.0/twisted/python/log.py#L270
http://twistedmatrix.com/trac/browser/tags/releases/twisted-8.2.0/twisted/words/xish/utility.py#L23
http://twistedmatrix.com/trac/browser/tags/releases/twisted-8.2.0/twisted/web/microdom.py#L720
http://twistedmatrix.com/trac/browser/tags/releases/twisted-8.2.0/twisted/web/microdom.py#L738
http://twistedmatrix.com/trac/browser/tags/releases/twisted-8.2.0/twisted/test/test_adbapi.py#L370
http://twistedmatrix.com/trac/browser/tags/releases/twisted-8.2.0/twisted/test/test_zshcomp.py#L34
http://twistedmatrix.com/trac/browser/tags/releases/twisted-8.2.0/twisted/mail/scripts/mailmail.py#L345
http://twistedmatrix.com/trac/browser/tags/releases/twisted-8.2.0/twisted/internet/_dumbwin32proc.py#L167
http://twistedmatrix.com/trac/browser/tags/releases/twisted-8.2.0/twisted/lore/default.py#L17

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6410>
_______________________________________

From report at bugs.python.org  Tue Jul  7 00:50:10 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 06 Jul 2009 22:50:10 +0000
Subject: [issue6428] TypeError: __bool__ should return bool or int,
	returned int
In-Reply-To: <1246891534.57.0.238134342776.issue6428@psf.upfronthosting.co.za>
Message-ID: <1246920610.44.0.47233078048.issue6428@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Probably a misguided merge. Here is a patch that updates the error 
message, and the documentation.

----------
keywords: +needs review, patch
nosy: +amaury.forgeotdarc
Added file: http://bugs.python.org/file14460/bool.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6428>
_______________________________________

From report at bugs.python.org  Tue Jul  7 00:50:26 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 06 Jul 2009 22:50:26 +0000
Subject: [issue6428] TypeError: __bool__ should return bool or int,
	returned int
In-Reply-To: <1246891534.57.0.238134342776.issue6428@psf.upfronthosting.co.za>
Message-ID: <1246920626.94.0.0602769068336.issue6428@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6428>
_______________________________________

From report at bugs.python.org  Tue Jul  7 01:26:45 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 06 Jul 2009 23:26:45 +0000
Subject: [issue6420] Fix warning in nismodule.c on OpenBSD
In-Reply-To: <1246743567.03.0.331926957573.issue6420@psf.upfronthosting.co.za>
Message-ID: <1246922805.74.0.787474013005.issue6420@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Does someone know whether FreeBSD or NetBSD need the same treatment?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6420>
_______________________________________

From report at bugs.python.org  Tue Jul  7 01:30:41 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 06 Jul 2009 23:30:41 +0000
Subject: [issue2389] Array pickling exposes internal memory representation of
	elements
In-Reply-To: <1205851091.96.0.575523128038.issue2389@psf.upfronthosting.co.za>
Message-ID: <1246923041.9.0.505872255541.issue2389@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

I know believe that arrays should be pickled as a list of values on
Python 2.x. Doing otherwise makes it impossible to unpickle arrays
coming from Python 2.x using Python 3.x, since pickle on Python 3
decodes all the strings from 2.x to Unicode.

However, we still can use the compact memory representation on Python 3.x.

So, I propose that we change the array module on Python 2.x to emit a
list instead of memory string and implement the portable array pickling
mechanism only on Python 3.x.

----------
versions: +Python 3.2 -Python 3.1
Added file: http://bugs.python.org/file14461/portable_array_pickling-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2389>
_______________________________________

From report at bugs.python.org  Tue Jul  7 01:41:39 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 06 Jul 2009 23:41:39 +0000
Subject: [issue6382] test_socketserver fails on trunk in test_ForkingTCPServer
In-Reply-To: <1246327124.37.0.772968679477.issue6382@psf.upfronthosting.co.za>
Message-ID: <1246923699.56.0.857248159707.issue6382@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

How unfortunate.  This means that we need to virtualize the shutdown. I'll 
submit a proposed patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6382>
_______________________________________

From report at bugs.python.org  Tue Jul  7 01:42:07 2009
From: report at bugs.python.org (Henry Precheur)
Date: Mon, 06 Jul 2009 23:42:07 +0000
Subject: [issue6420] Fix warning in nismodule.c on OpenBSD
In-Reply-To: <1246922805.74.0.787474013005.issue6420@psf.upfronthosting.co.za>
Message-ID: <20090706234203.GB7169@wrap.novuscom.net>


Henry Precheur <henry at precheur.org> added the comment:

FreeBSD does.

http://svn.freebsd.org/viewvc/base/stable/7/include/rpcsvc/ypclnt.h?revision=172506&view=markup

But NetBSD doesn't:

http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/include/rpcsvc/ypclnt.h?rev=1.13&content-type=text/plain&only_with_tag=MAIN

On Mon, Jul 06, 2009 at 11:26:45PM +0000, Amaury Forgeot d'Arc wrote:
> 
> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:
> 
> Does someone know whether FreeBSD or NetBSD need the same treatment?
> 
> ----------
> nosy: +amaury.forgeotdarc
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue6420>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6420>
_______________________________________

From report at bugs.python.org  Tue Jul  7 01:42:26 2009
From: report at bugs.python.org (Eric Smith)
Date: Mon, 06 Jul 2009 23:42:26 +0000
Subject: [issue6428] TypeError: __bool__ should return bool or int,
	returned int
In-Reply-To: <1246891534.57.0.238134342776.issue6428@psf.upfronthosting.co.za>
Message-ID: <1246923746.4.0.755039673512.issue6428@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

The patch looks good to me. In particular, removing the test for
using_len looks correct.

The assignment of "result = -1" after PyErr_Format isn't needed, but
doesn't hurt (and it was already there, anyway).

----------
keywords:  -needs review
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6428>
_______________________________________

From report at bugs.python.org  Tue Jul  7 01:48:17 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 06 Jul 2009 23:48:17 +0000
Subject: [issue5885] uuid.uuid1() is too slow
In-Reply-To: <1241086416.5.0.850110966894.issue5885@psf.upfronthosting.co.za>
Message-ID: <1246924097.42.0.819752772854.issue5885@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Can you provide a patch?

----------
nosy: +alexandre.vassalotti
priority:  -> low
stage:  -> needs patch
versions: +Python 3.2 -Python 2.4, Python 2.5, Python 2.6, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5885>
_______________________________________

From report at bugs.python.org  Tue Jul  7 01:59:24 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 06 Jul 2009 23:59:24 +0000
Subject: [issue6410] Dictionaries should support __add__
In-Reply-To: <1246653238.95.0.314927755738.issue6410@psf.upfronthosting.co.za>
Message-ID: <1246924764.3.0.0500539799218.issue6410@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

ISTM these examples show how little value would come from fattening-up
the dict API.  The examples use the copy/update pattern which is clear,
explicit, and extendable to n-ary cases without incurring O(n**2)
behavior.  Tranforming them to a f=d+e pattern saves a few characters;
doesn't add any speed; makes it less clear that we're operating on
dictionaries; and does not extend well to the n-ary case (f=a+b+c+d+e
which copies a's elements five times, b's four times, etc.)  No new
functionality gets added -- all this is is a piece of syntactic sugar
that obscures what is going-on under the hood.  The dict API is one of
the most fundamental in the language; it needs to be kept as clean and
hazard-free as possible.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6410>
_______________________________________

From report at bugs.python.org  Tue Jul  7 02:00:28 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Tue, 07 Jul 2009 00:00:28 +0000
Subject: [issue6410] Dictionaries should support __add__
In-Reply-To: <1246653238.95.0.314927755738.issue6410@psf.upfronthosting.co.za>
Message-ID: <1246924828.68.0.561430186035.issue6410@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Cool.  I'm convinced.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6410>
_______________________________________

From report at bugs.python.org  Tue Jul  7 02:13:59 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 07 Jul 2009 00:13:59 +0000
Subject: [issue6382] test_socketserver fails on trunk in test_ForkingTCPServer
In-Reply-To: <1246327124.37.0.772968679477.issue6382@psf.upfronthosting.co.za>
Message-ID: <1246925639.18.0.57109796256.issue6382@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

I'm uploading a patched SocketServer.py.  Could you please try it out on 
the gentoo box before I commit it?

----------
Added file: http://bugs.python.org/file14462/SocketServer.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6382>
_______________________________________

From report at bugs.python.org  Tue Jul  7 02:37:07 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 07 Jul 2009 00:37:07 +0000
Subject: [issue2919] Merge profile/cProfile in 3.0
In-Reply-To: <1211227334.77.0.551300594218.issue2919@psf.upfronthosting.co.za>
Message-ID: <1246927027.81.0.418760035609.issue2919@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Here's an updated version of my lsprof.py module. I fixed a few bugs,
includes the awful reference leak that was present in the previous
version (i.e., the profiler code was keeping a reference to every frame
executed).

I consider the lsprof.py code functionally equivalent to _lsprof. Now, I
am wondering if I should add the features from profile.py missing in
_lsprof, e.g., the bias argument and the calibration code.

----------
Added file: http://bugs.python.org/file14463/lsprof.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2919>
_______________________________________

From report at bugs.python.org  Tue Jul  7 02:37:16 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 07 Jul 2009 00:37:16 +0000
Subject: [issue2919] Merge profile/cProfile in 3.0
In-Reply-To: <1211227334.77.0.551300594218.issue2919@psf.upfronthosting.co.za>
Message-ID: <1246927036.03.0.175611757891.issue2919@psf.upfronthosting.co.za>


Changes by Alexandre Vassalotti <alexandre at peadrop.com>:


Removed file: http://bugs.python.org/file14376/lsprof.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2919>
_______________________________________

From report at bugs.python.org  Tue Jul  7 02:45:51 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 07 Jul 2009 00:45:51 +0000
Subject: [issue6428] TypeError: __bool__ should return bool or int,
	returned int
In-Reply-To: <1246891534.57.0.238134342776.issue6428@psf.upfronthosting.co.za>
Message-ID: <1246927551.14.0.446050509979.issue6428@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

fixed in r73868 (py3k) and r73869 (3.1)
Thanks for the report!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6428>
_______________________________________

From report at bugs.python.org  Tue Jul  7 03:00:05 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 07 Jul 2009 01:00:05 +0000
Subject: [issue6420] Fix warning in nismodule.c on OpenBSD
In-Reply-To: <1246743567.03.0.331926957573.issue6420@psf.upfronthosting.co.za>
Message-ID: <1246928405.1.0.414436189231.issue6420@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

What about this new patch?

----------
keywords: +patch
Added file: http://bugs.python.org/file14464/nismodule.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6420>
_______________________________________

From report at bugs.python.org  Tue Jul  7 03:10:22 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 07 Jul 2009 01:10:22 +0000
Subject: [issue6070] Python 2.6 makes .pyc/.pyo bytecode files executable
In-Reply-To: <1242817129.44.0.860392010944.issue6070@psf.upfronthosting.co.za>
Message-ID: <1246929022.68.0.965197488208.issue6070@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

#ifndef version of the patch applied to trunk in r73870, with tests. 
Leaving open until I merge it.

----------
assignee:  -> r.david.murray
nosy: +brett.cannon
resolution:  -> fixed
stage: test needed -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6070>
_______________________________________

From report at bugs.python.org  Tue Jul  7 03:38:40 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 07 Jul 2009 01:38:40 +0000
Subject: [issue6382] test_socketserver fails on trunk in test_ForkingTCPServer
In-Reply-To: <1246327124.37.0.772968679477.issue6382@psf.upfronthosting.co.za>
Message-ID: <1246930720.65.0.0394837005451.issue6382@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I had to fix one line, but after that it runs successfully.  Updated
patch attached.  The change is to add the 'request' argument to the
close_request call on line 549.

----------
keywords: +patch
Added file: http://bugs.python.org/file14465/issue6382.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6382>
_______________________________________

From report at bugs.python.org  Tue Jul  7 03:49:18 2009
From: report at bugs.python.org (Henry Precheur)
Date: Tue, 07 Jul 2009 01:49:18 +0000
Subject: [issue6420] Fix warning in nismodule.c on OpenBSD
In-Reply-To: <1246928405.1.0.414436189231.issue6420@psf.upfronthosting.co.za>
Message-ID: <20090707014914.GA14570@wrap.novuscom.net>


Henry Precheur <henry at precheur.org> added the comment:

It works on OpenBSD, but I don't have any FreeBSD to test. I should be
safe to commit though, the patch is rather trivial.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6420>
_______________________________________

From report at bugs.python.org  Tue Jul  7 07:41:36 2009
From: report at bugs.python.org (Case Van Horsen)
Date: Tue, 07 Jul 2009 05:41:36 +0000
Subject: [issue6431] Fraction fails equality test with a user-defined type
In-Reply-To: <1246945296.27.0.280023368175.issue6431@psf.upfronthosting.co.za>
Message-ID: <1246945296.27.0.280023368175.issue6431@psf.upfronthosting.co.za>


New submission from Case Van Horsen <casevh at gmail.com>:

I've ported the GMPY module to Python 3 and found a problem comparing
Fraction to gmpy.mpq. mpq is the rational type in gmpy and knows how to
convert a Fraction into an mpq. All operations appear to work properly
except "Fraction == mpq".

"mpq == Fraction" does work correctly. gmpy's rich comparison routine
recognizes the other argument as Fraction and converts to an mpq value
properly. However, when "Fraction == mpq" is done, the Fraction argument
is converted to a float before gmpy's rich comparison is called.

The __eq__ routine in fractions.py is:

    def __eq__(a, b):
        """a == b"""
        if isinstance(b, numbers.Rational):
            return (a._numerator == b.numerator and
                    a._denominator == b.denominator)
        if isinstance(b, numbers.Complex) and b.imag == 0:
            b = b.real
        if isinstance(b, float):
            return a == a.from_float(b)
        else:
            # XXX: If b.__eq__ is implemented like this method, it may
            # give the wrong answer after float(a) changes a's
            # value. Better ways of doing this are welcome.
            return float(a) == b

Shouldn't __eq__ return NotImplemented if it doesn't know how to handle
the other argument? I changed "return float(a) == b" to "return
NotImplemented" and GMPY and Python's test suite passed all tests.

I used the same logic for comparisons between gmpy.mpf and Decimal and
they all work correctly. Decimal does return NotImplemented when it
can't convert the other argument.

(GMPY 1.10 alpha2 fails due to this issue.)

----------
components: Library (Lib)
messages: 90211
nosy: casevh
severity: normal
status: open
title: Fraction fails equality test with a user-defined type
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6431>
_______________________________________

From report at bugs.python.org  Tue Jul  7 08:14:01 2009
From: report at bugs.python.org (Jerry Chen)
Date: Tue, 07 Jul 2009 06:14:01 +0000
Subject: [issue5683] Speed up cPickle's pickling generally
In-Reply-To: <1238803338.21.0.932870288543.issue5683@psf.upfronthosting.co.za>
Message-ID: <1246947241.85.0.875425629856.issue5683@psf.upfronthosting.co.za>


Jerry Chen <jerry at 3rdengine.com> added the comment:

Applied collinwinter's patch and svn up'd to r73872; replaced additional
instances of self->write_func with _Pickler_Write.

Passed test_xpickle.py as referenced by issue 5665.

----------
nosy: +jcsalterego
Added file: http://bugs.python.org/file14466/cpickle_writes-r73872.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5683>
_______________________________________

From report at bugs.python.org  Tue Jul  7 08:53:36 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 07 Jul 2009 06:53:36 +0000
Subject: [issue6420] Fix warning in nismodule.c on OpenBSD
In-Reply-To: <1246743567.03.0.331926957573.issue6420@psf.upfronthosting.co.za>
Message-ID: <1246949616.63.0.152861443165.issue6420@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Thanks, fixed in r73873, r73874, r73875 and r73876.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6420>
_______________________________________

From report at bugs.python.org  Tue Jul  7 09:10:01 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 07 Jul 2009 07:10:01 +0000
Subject: [issue6314] logging.basicConfig(level='DEBUG',
	... and setLevel("DEBUG") result in no logging
In-Reply-To: <1245473929.89.0.283081310598.issue6314@psf.upfronthosting.co.za>
Message-ID: <1246950601.6.0.612023381423.issue6314@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

The change that I made was in the wrong place - it should have been in
the setLevel rather than in basicConfig itself. However, this would not
have covered setLevel for Handlers...

That setLevel behaves differently to basicConfig for the level argument
could be seen as a bug. ISTM I should add a function _checkLevel as follows:

def _checkLevel(level):
    if isinstance(level, int):
        rv = level
    elif str(level) == level:
        if level not in _levelNames:
            raise ValueError("Unknown level: %r" % level)
        rv = _levelNames[level]
    else:
        raise TypeError("Level not an integer or a valid string: %r" %
level)
    return rv


and then have all setLevel(level) methods do a "level =
_checkLevel(level)" before actually setting the level.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6314>
_______________________________________

From report at bugs.python.org  Tue Jul  7 09:11:41 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 07 Jul 2009 07:11:41 +0000
Subject: [issue6343] TimedRotatingFileHandler permission denied rename failure
	on Windows
In-Reply-To: <1245949185.33.0.897995880567.issue6343@psf.upfronthosting.co.za>
Message-ID: <1246950701.89.0.510193063373.issue6343@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
assignee:  -> vsajip
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6343>
_______________________________________

From report at bugs.python.org  Tue Jul  7 10:10:13 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 07 Jul 2009 08:10:13 +0000
Subject: [issue6430] array.array falsely advertises support for 'w' in
	documentation
In-Reply-To: <1246912827.43.0.704118006779.issue6430@psf.upfronthosting.co.za>
Message-ID: <1246954213.87.0.923250472369.issue6430@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Apparently 'w' and 'u' were used for wide and narrow builds
respectively. In r58441 the distinction was removed and now 'u' can be
either 2 or 4 bytes, depending on the build.
I think that 'w' can be removed.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6430>
_______________________________________

From report at bugs.python.org  Tue Jul  7 10:26:09 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 07 Jul 2009 08:26:09 +0000
Subject: [issue6431] Fraction fails equality test with a user-defined type
In-Reply-To: <1246945296.27.0.280023368175.issue6431@psf.upfronthosting.co.za>
Message-ID: <1246955169.62.0.66026944622.issue6431@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I agree this should be fixed.  The conversion to float in the else 
clause seems wrong to me: it can lose precision, making two unequal 
values compare equal.  I also agree that we should be getting 
NotImplemented here.

Do you have a patch available?

As an aside, I'm interested that you're implementing comparisons between 
mpf and Decimal;  how does that work?  Do you also implement binary 
arithmetic operations between mpf and Decimal?  What's the result type?

----------
nosy: +jyasskin, marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6431>
_______________________________________

From report at bugs.python.org  Tue Jul  7 10:32:42 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 07 Jul 2009 08:32:42 +0000
Subject: [issue6431] Fraction fails equality test with a user-defined type
In-Reply-To: <1246945296.27.0.280023368175.issue6431@psf.upfronthosting.co.za>
Message-ID: <1246955562.85.0.139074355636.issue6431@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
stage:  -> needs patch
versions: +Python 2.6, Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6431>
_______________________________________

From report at bugs.python.org  Tue Jul  7 10:35:00 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 07 Jul 2009 08:35:00 +0000
Subject: [issue6430] array.array falsely advertises support for 'w' in
	documentation
In-Reply-To: <1246912827.43.0.704118006779.issue6430@psf.upfronthosting.co.za>
Message-ID: <1246955700.78.0.14140194029.issue6430@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The problem seems to affect Python 2 too. See also #1268.
In the online doc 'w' is not mentioned but a note about the size of 'u'
that changes depending on the build should be added too.
Also in the table in the Python 2 doc [1] the "Python Type" for
'unsigned int' and 'signed long' seem swapped [2].

[1]: http://docs.python.org/library/array.html
[2]: Modules/arraymodule.c under "/* Description of types */"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6430>
_______________________________________

From report at bugs.python.org  Tue Jul  7 11:04:57 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 07 Jul 2009 09:04:57 +0000
Subject: [issue6426] imaplib.IMAP4 "command illegal in this state" is
	unhelpful error message
In-Reply-To: <1246868579.93.0.42678360783.issue6426@psf.upfronthosting.co.za>
Message-ID: <1246957497.59.0.192856018915.issue6426@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Can you provide a patch?

----------
keywords: +easy
nosy: +ezio.melotti
priority:  -> low
stage:  -> needs patch
versions: +Python 2.7 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6426>
_______________________________________

From report at bugs.python.org  Tue Jul  7 11:09:56 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 07 Jul 2009 09:09:56 +0000
Subject: [issue6382] test_socketserver fails on trunk in test_ForkingTCPServer
In-Reply-To: <1246327124.37.0.772968679477.issue6382@psf.upfronthosting.co.za>
Message-ID: <1246957796.23.0.172605333466.issue6382@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

committed in revision 73877 and revision 73878

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6382>
_______________________________________

From report at bugs.python.org  Tue Jul  7 11:14:27 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 07 Jul 2009 09:14:27 +0000
Subject: [issue6425] imaplib.IMAP4.fetch() is missing documentation for
	message_set parameter
In-Reply-To: <1246868318.71.0.0692124898896.issue6425@psf.upfronthosting.co.za>
Message-ID: <1246958067.17.0.120147910431.issue6425@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The 4th paragraph in the section IMAP4 Objects [1] specifies that:
"The message_set options to commands below is a string specifying one or
more messages to be acted upon. It may be a simple message number ('1'),
a range of message numbers ('2:4'), or a group of non-contiguous ranges
separated by commas ('1:3,6:9'). A range can contain an asterisk to
indicate an infinite upper bound ('3:*')."

A link to this paragraph could be added in the methods where message_set
is used.

[1]: http://docs.python.org/library/imaplib.html#imap4-objects

----------
nosy: +ezio.melotti
priority:  -> low
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
versions: +Python 2.7 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6425>
_______________________________________

From report at bugs.python.org  Tue Jul  7 11:25:47 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 07 Jul 2009 09:25:47 +0000
Subject: [issue6422] timeit called from within Python should allow autoranging
In-Reply-To: <1246806912.2.0.722769600334.issue6422@psf.upfronthosting.co.za>
Message-ID: <1246958747.09.0.611321380474.issue6422@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
priority:  -> normal
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6422>
_______________________________________

From report at bugs.python.org  Tue Jul  7 11:28:24 2009
From: report at bugs.python.org (Marco Buccini)
Date: Tue, 07 Jul 2009 09:28:24 +0000
Subject: [issue6070] Python 2.6 makes .pyc/.pyo bytecode files executable
In-Reply-To: <1242817129.44.0.860392010944.issue6070@psf.upfronthosting.co.za>
Message-ID: <1246958904.81.0.623561220716.issue6070@psf.upfronthosting.co.za>


Marco Buccini <marcusbu at gmail.com> added the comment:

@r.david.murray:
Does this works on Windows? Are you sure Oleg? :)
Since you've done this:
#ifndef MS_WINDOWS
 /* mode = ..*/
#endif

but on Windows the compiler "jumps" over this code, so you can get a
binding error, since it doesn't find the variable "mode"...

E.g (on my Debian):

#ifndef __GNUC__
 #define X 10
#endif

int main()
{
    printf("%d\n", X);
}

it gives error: ?X? undeclared (first use in this function)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6070>
_______________________________________

From report at bugs.python.org  Tue Jul  7 11:28:53 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 07 Jul 2009 09:28:53 +0000
Subject: [issue6333] logging: ValueError: I/O operation on closed file
In-Reply-To: <1245807768.39.0.536701423847.issue6333@psf.upfronthosting.co.za>
Message-ID: <1246958933.08.0.77039126421.issue6333@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
priority:  -> normal
stage:  -> test needed
status: pending -> open
versions: +Python 2.7 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6333>
_______________________________________

From report at bugs.python.org  Tue Jul  7 11:33:27 2009
From: report at bugs.python.org (Oleg Broytmann)
Date: Tue, 07 Jul 2009 09:33:27 +0000
Subject: [issue6070] Python 2.6 makes .pyc/.pyo bytecode files executable
In-Reply-To: <1246958904.81.0.623561220716.issue6070@psf.upfronthosting.co.za>
Message-ID: <20090707093324.GB27812@phd.pp.ru>


Oleg Broytmann <phd at phd.pp.ru> added the comment:

I didn't test ifndef-version, I tested the full version (issue6070.patch)
on both Linux and w32. You are right, 'mode' must be defined even on w32.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6070>
_______________________________________

From report at bugs.python.org  Tue Jul  7 11:49:22 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 07 Jul 2009 09:49:22 +0000
Subject: [issue6070] Python 2.6 makes .pyc/.pyo bytecode files executable
In-Reply-To: <1242817129.44.0.860392010944.issue6070@psf.upfronthosting.co.za>
Message-ID: <1246960162.02.0.276029547797.issue6070@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Drat. I should have uploaded the revised patch first for testing.  I'll
update it to the tested patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6070>
_______________________________________

From report at bugs.python.org  Tue Jul  7 11:52:56 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 07 Jul 2009 09:52:56 +0000
Subject: [issue6414] struct module : processor endianness descriptions
	misleading
In-Reply-To: <1246693590.67.0.013392500744.issue6414@psf.upfronthosting.co.za>
Message-ID: <1246960376.25.0.456869687424.issue6414@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Something like "Motorola and Sun processors are usually big-endian;
Intel and DEC processors are usually little-endian" (or "most
of"/"several") might be enough.

----------
keywords: +easy
nosy: +ezio.melotti
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6414>
_______________________________________

From report at bugs.python.org  Tue Jul  7 12:30:24 2009
From: report at bugs.python.org (=?utf-8?q?Jean-Paul_Mi=C3=A9ville?=)
Date: Tue, 07 Jul 2009 10:30:24 +0000
Subject: [issue6432] ImageTk.PhotoImage
In-Reply-To: <1246962624.44.0.14182359808.issue6432@psf.upfronthosting.co.za>
Message-ID: <1246962624.44.0.14182359808.issue6432@psf.upfronthosting.co.za>


New submission from Jean-Paul Mi?ville <jpmieville at gmail.com>:

When using the function ImageTk.PhotoImage. I got the following 
traceback.

    self.chart = ImageTk.PhotoImage(self.image)
  File "C:\Python25\Lib\site-packages\PIL\ImageTk.py", line 116, in 
__init__
    self.paste(image)
  File "C:\Python25\Lib\site-packages\PIL\ImageTk.py", line 181, in 
paste
    import _imagingtk
ImportError: DLL load failed: The specified module could not be found.

_imagintk exists in the directory C:\Python25\Lib\site-packages\PIL

I have re-installed python (ActivePython 2.5.4.4 (r254:67916, Apr 27 
2009, 15:41:14)and PIL and still the same problem.

----------
components: Tkinter
messages: 90225
nosy: jpmieville
severity: normal
status: open
title: ImageTk.PhotoImage
type: crash
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6432>
_______________________________________

From report at bugs.python.org  Tue Jul  7 12:45:13 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 07 Jul 2009 10:45:13 +0000
Subject: [issue6432] ImageTk.PhotoImage
In-Reply-To: <1246962624.44.0.14182359808.issue6432@psf.upfronthosting.co.za>
Message-ID: <1246963513.11.0.968978828637.issue6432@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Can you provide a sample script to reproduce this or try it with a plain
version of python?

>From the traceback it looks like ImageTk is something defined by the
PIL, and since it's not part of the stdlib this is probably not the
right place where to report this bug. It could be a problem of
ActiveState Python or of the PIL itself, if you can't reproduce it with
a plain Python try to report it on their bug trackers.

FWIW I found in the doc the class Tkinter.PhotoImage(), if you can
reproduce the problem using it instead of ImageTk.PhotoImage() then it
might be a Python bug.

----------
nosy: +ezio.melotti
priority:  -> normal
stage:  -> test needed
versions: +Python 2.7 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6432>
_______________________________________

From report at bugs.python.org  Tue Jul  7 13:20:18 2009
From: report at bugs.python.org (Mike)
Date: Tue, 07 Jul 2009 11:20:18 +0000
Subject: [issue6399] Error reporting by logging.config.fileConfig()
In-Reply-To: <1246528231.33.0.0905986098741.issue6399@psf.upfronthosting.co.za>
Message-ID: <1246965618.66.0.230223554595.issue6399@psf.upfronthosting.co.za>


Mike <python at amadron.com> added the comment:

Sorry, I only started learning Python a couple of weeks ago.  Didn't
know that there was a ConfigParser module.  So this would really be a
feature request of ConfigParser?

Interesting you should mention Postel's Law.  Being liberal about what
you accept from others doesn't mean ignoring non-conformance.  Jon
Postel was clear that although you endeavour to continue when
encountering non-conformance you should always report it, lest
non-conformance propogates (sic).

I can think of two ways ConfigParser could report these problems. 
Either you give it a callback function it can call as it encounters
problems, or, after you have parsed a file you can call another function
that gives a list of any problems encountered.

If ConfigParser had this functionality it would then be straightforward
for the logging.config.fileConfig module to send these warnings to the
root logger.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6399>
_______________________________________

From report at bugs.python.org  Tue Jul  7 13:39:04 2009
From: report at bugs.python.org (Eric Eisner)
Date: Tue, 07 Jul 2009 11:39:04 +0000
Subject: [issue6433] multiprocessing: pool.map hangs on empty list
In-Reply-To: <1246966744.58.0.524623595855.issue6433@psf.upfronthosting.co.za>
Message-ID: <1246966744.58.0.524623595855.issue6433@psf.upfronthosting.co.za>


New submission from Eric Eisner <ede at mit.edu>:

In multiprocessing, if you give a pool.map a zero-length iterator and
specify a nonzero chunksize, the process hangs indefinitely. Example:

import multiprocessing
pool = multiprocessing.Pool()
pool.map(len, [], chunksize=1)
# hang forever

Attached simple testcase and simple fix. I observed this behavior on 2.6
and 3.1, but only verified the patch on 3.1. Unless the line numbers
changed it will probably fix it on 2.6 as well.

----------
components: Library (Lib)
files: map_testandfix.patch
keywords: patch
messages: 90228
nosy: ede
severity: normal
status: open
title: multiprocessing: pool.map hangs on empty list
type: crash
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file14467/map_testandfix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6433>
_______________________________________

From report at bugs.python.org  Tue Jul  7 13:44:51 2009
From: report at bugs.python.org (=?utf-8?q?Jean-Paul_Mi=C3=A9ville?=)
Date: Tue, 07 Jul 2009 11:44:51 +0000
Subject: [issue6432] ImageTk.PhotoImage
In-Reply-To: <1246962624.44.0.14182359808.issue6432@psf.upfronthosting.co.za>
Message-ID: <1246967091.0.0.652182205285.issue6432@psf.upfronthosting.co.za>


Jean-Paul Mi?ville <jpmieville at gmail.com> added the comment:

You are right I think that the problem is related to PIL. I will
reported to the mailing list of PIL.

I have attached a script for testing this case.

----------
status: open -> closed
Added file: http://bugs.python.org/file14468/Script1.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6432>
_______________________________________

From report at bugs.python.org  Tue Jul  7 13:56:19 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 07 Jul 2009 11:56:19 +0000
Subject: [issue6414] struct module : processor endianness descriptions
	misleading
In-Reply-To: <1246693590.67.0.013392500744.issue6414@psf.upfronthosting.co.za>
Message-ID: <1246967779.29.0.604248049284.issue6414@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Maybe it's better to avoid the platform-specific statements altogether, 
and just point out the existence of sys.byteorder for those who want to 
check the endianness of the system they're currently working on.

Or maybe just mention that the x86 and AMD64 (aka x86-64) architectures 
are little-endian;  I'd guess that this covers a good proportion of the 
processors that people are currently running Python on.  People using more 
exotic architectures probably already know their endianness.

----------
nosy: +marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6414>
_______________________________________

From report at bugs.python.org  Tue Jul  7 14:06:01 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 07 Jul 2009 12:06:01 +0000
Subject: [issue6433] multiprocessing: pool.map hangs on empty list
In-Reply-To: <1246966744.58.0.524623595855.issue6433@psf.upfronthosting.co.za>
Message-ID: <1246968361.92.0.964319406268.issue6433@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I'm not familiar with multiprocessing but I gave a quick look at the
patch. If the 'iterable' is an iterator/generator "if len(iterable) ==
0:" may fail since these objects don't usually have a __len__. More
tests for this situation are probably needed too.

----------
nosy: +ezio.melotti
priority:  -> normal
type: crash -> behavior
versions: +Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6433>
_______________________________________

From report at bugs.python.org  Tue Jul  7 14:19:16 2009
From: report at bugs.python.org (Eric Eisner)
Date: Tue, 07 Jul 2009 12:19:16 +0000
Subject: [issue6433] multiprocessing: pool.map hangs on empty list
In-Reply-To: <1246966744.58.0.524623595855.issue6433@psf.upfronthosting.co.za>
Message-ID: <1246969156.51.0.6438214437.issue6433@psf.upfronthosting.co.za>


Eric Eisner <ede at mit.edu> added the comment:

A few lines before this patch the code turns iterable into a list if it
does not hasattr('__len__') for the purpose of calculating the chunksize.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6433>
_______________________________________

From report at bugs.python.org  Tue Jul  7 14:24:43 2009
From: report at bugs.python.org (toxik)
Date: Tue, 07 Jul 2009 12:24:43 +0000
Subject: [issue5814] SocketServer: TypeError: waitpid() takes no keyword
	arguments
In-Reply-To: <1240402546.97.0.496265243234.issue5814@psf.upfronthosting.co.za>
Message-ID: <1246969483.68.0.088712768763.issue5814@psf.upfronthosting.co.za>


toxik <ludvig.ericson at users.sourceforge.net> added the comment:

I don't really get how this could've ever worked. I tested using keyword 
arguments in py24 and py25, didn't work there either.

I think the best approach would be fixing the SocketServer.py code (which 
obviously needs a test as well, because it's never run.)

----------
nosy: +ludvig.ericson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5814>
_______________________________________

From report at bugs.python.org  Tue Jul  7 15:08:44 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 07 Jul 2009 13:08:44 +0000
Subject: [issue5814] SocketServer: TypeError: waitpid() takes no keyword
	arguments
In-Reply-To: <1240402546.97.0.496265243234.issue5814@psf.upfronthosting.co.za>
Message-ID: <1246972124.75.0.251164683247.issue5814@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The socketserver code was changed on trunk in r69927 by neil.schemenauer
(I can't find his roundup id or I'd make him nosy) so the bug no longer
exists there or in the 3.x branch.  I've backported it to 2.6 in r73887.

----------
nosy: +r.david.murray
priority:  -> normal
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5814>
_______________________________________

From report at bugs.python.org  Tue Jul  7 15:11:48 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 07 Jul 2009 13:11:48 +0000
Subject: [issue6433] multiprocessing: pool.map hangs on empty list
In-Reply-To: <1246966744.58.0.524623595855.issue6433@psf.upfronthosting.co.za>
Message-ID: <1246972308.12.0.343537428769.issue6433@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6433>
_______________________________________

From report at bugs.python.org  Tue Jul  7 15:13:14 2009
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 07 Jul 2009 13:13:14 +0000
Subject: [issue6433] multiprocessing: pool.map hangs on empty list
In-Reply-To: <1246966744.58.0.524623595855.issue6433@psf.upfronthosting.co.za>
Message-ID: <1246972394.01.0.563816222823.issue6433@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------
assignee:  -> jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6433>
_______________________________________

From report at bugs.python.org  Tue Jul  7 15:15:24 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 07 Jul 2009 13:15:24 +0000
Subject: [issue6399] Error reporting by logging.config.fileConfig()
In-Reply-To: <1246528231.33.0.0905986098741.issue6399@psf.upfronthosting.co.za>
Message-ID: <1246972524.3.0.992613590335.issue6399@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Well, there are other systems around (e.g. ConfigObj) which will allow
you to validate against a schema, but it's not part of the core so
logging can't rely on it.

I'm not sure how much interest there'd be in adding this kind of
validation to ConfigParser, but you could always try working up a patch
and assigning it to whoever maintains ConfigParser, or contacting that
person beforehand to see if it's worth it, or posting on c.lpy with the
same objective.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6399>
_______________________________________

From report at bugs.python.org  Tue Jul  7 16:54:30 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 07 Jul 2009 14:54:30 +0000
Subject: [issue665336] win32 os.path.normpath not correct for leading slash
	cases
Message-ID: <1246978470.43.0.125390879807.issue665336@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

On Windows, os.path.normpath(r"\\x\y\z") must return the string
unchanged, because this is the syntax for UNC paths:
    \\server\share\file.txt

Closing as invalid.

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue665336>
_______________________________________

From report at bugs.python.org  Tue Jul  7 17:11:34 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 07 Jul 2009 15:11:34 +0000
Subject: [issue1523] xdrlib fails to detect overflow (struct bug?)
In-Reply-To: <1196356512.02.0.767950905039.issue1523@psf.upfronthosting.co.za>
Message-ID: <1246979494.02.0.301610452642.issue1523@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The deprecated overflow wrapping has been removed from trunk in r73891.  
(It was already removed in py3k a while ago.)

I'd really like to remove the deprecated float coercion from trunk too, 
but since the warnings weren't functioning properly in 2.6, this probably 
has to wait until 2.8.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1523>
_______________________________________

From report at bugs.python.org  Tue Jul  7 17:19:15 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 07 Jul 2009 15:19:15 +0000
Subject: [issue5864] format(1234.5, '.4') gives misleading result
In-Reply-To: <1240918701.29.0.448631018547.issue5864@psf.upfronthosting.co.za>
Message-ID: <1246979955.77.0.653870044891.issue5864@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I'm not going to backport this to 2.6.  The problem is that the fix for 
this issue is tied up with the corresponding change to str (str(1e11) 
produces '1e+11' in trunk and 100000000000.0 in release26-maint);  I 
daren't change str() in 2.6, so backporting would mean separating out the 
str and format changes.

I'm not opposed to the backport itself; it's just a lack of time and 
confidence of getting it right on my part.  If anyone else wants to 
backport feel free.

----------
assignee: marketdickinson -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5864>
_______________________________________

From report at bugs.python.org  Tue Jul  7 17:19:48 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 07 Jul 2009 15:19:48 +0000
Subject: [issue5864] format(1234.5, '.4') gives misleading result
In-Reply-To: <1240918701.29.0.448631018547.issue5864@psf.upfronthosting.co.za>
Message-ID: <1246979988.3.0.930293556936.issue5864@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

... and 3.0 is dead.

----------
versions:  -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5864>
_______________________________________

From report at bugs.python.org  Tue Jul  7 17:28:42 2009
From: report at bugs.python.org (Eric Smith)
Date: Tue, 07 Jul 2009 15:28:42 +0000
Subject: [issue5864] format(1234.5, '.4') gives misleading result
In-Reply-To: <1240918701.29.0.448631018547.issue5864@psf.upfronthosting.co.za>
Message-ID: <1246980522.39.0.832994951359.issue5864@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I agree that backporting it to 2.6 would be nice, but it would be a huge
change. There's too much risk involved. So this will just be a new
feature in 2.7. It's already in Misc/NEWS, so you're all set there.

I'm closing the issue, marking it as "wont fix" because it's only
assigned to 2.6 currently.

----------
assignee:  -> marketdickinson
resolution:  -> wont fix
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5864>
_______________________________________

From report at bugs.python.org  Tue Jul  7 17:45:04 2009
From: report at bugs.python.org (Case Van Horsen)
Date: Tue, 07 Jul 2009 15:45:04 +0000
Subject: [issue6431] Fraction fails equality test with a user-defined type
In-Reply-To: <1246955169.62.0.66026944622.issue6431@psf.upfronthosting.co.za>
Message-ID: <99e0b9530907070844x4c7bfd80o26a5eefeabc8a286@mail.gmail.com>


Case Van Horsen <casevh at gmail.com> added the comment:

On Tue, Jul 7, 2009 at 1:26 AM, Mark Dickinson<report at bugs.python.org> wrote:
>
> Mark Dickinson <dickinsm at gmail.com> added the comment:
>
> I agree this should be fixed. ?The conversion to float in the else
> clause seems wrong to me: it can lose precision, making two unequal
> values compare equal. ?I also agree that we should be getting
> NotImplemented here.
>
> Do you have a patch available?

I'll upload a patch this evening.

>
> As an aside, I'm interested that you're implementing comparisons between
> mpf and Decimal; ?how does that work? ?Do you also implement binary
> arithmetic operations between mpf and Decimal? ?What's the result type?

When I do binary operations (including comparison), I check the type
of both operands. If both operands are Integer (mpz, int, long), I
convert both operands to an mpz and then perform the operation.
Otherwise, if both operands are Rational (mpz, int, long, mpq,
Fraction), I convert both operands to an mpq. Finally, if both
operands appear to be a Number (mpz, int, long, mpq, Fraction, mpf,
Decimal), I convert both operands to an mpf. In the latest release of
GMPY, I always return a GMPY type (unless you are converting to float
or int/long).

To do the conversions, I just do mpq(str(Fraction)) or
mpf(str(Decimal)). I realize that the conversions aren't perfect but
are probably what a user expects. The fact that GMP uses radix 2^32 or
2^64 floating point with (randomly) either [prec+1] or [prec+2] digits
makes predictable floating point challenging. ;-) (prec =
floor(precision_in_bits/limb_size).) In GMPY 1.04, I forced all mpf
results to have [prec+1] digits but it's still messy. Time to start
working on MPFR support.
>
> ----------
> nosy: +jyasskin, marketdickinson
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue6431>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6431>
_______________________________________

From report at bugs.python.org  Tue Jul  7 19:10:59 2009
From: report at bugs.python.org (segfault42)
Date: Tue, 07 Jul 2009 17:10:59 +0000
Subject: [issue6434] buffer overflow in Zipfile when wrinting more than 2gig
	file
In-Reply-To: <1246986659.26.0.972556799924.issue6434@psf.upfronthosting.co.za>
Message-ID: <1246986659.26.0.972556799924.issue6434@psf.upfronthosting.co.za>


New submission from segfault42 <brice.nahum at free.fr>:

Hello, 

I have a problem with the librairy zipfile.py
http://svn.python.org/view/python/trunk/Lib/zipfile.py?revision=73565&view=markup


Zinfo structure limit the size of a file to an int max value with the
ZIP64_LIMIT value ( equal to "(1 << 31) - 1 " so to 2147483647 . 

The problem is happening when you write a big file in the line 1095 : 

self.fp.write(struct.pack("<lLL", zinfo.CRC, zinfo.compress_size,
                 zinfo.file_size))

zinfo.file_size is limited to a int  size and if you have a file bigger
than ZIP64_LIMIT you make a buffer overflow even if you set the flag
allowZip64 to true.

----------
components: Library (Lib)
files: zipfile.py
messages: 90242
nosy: segfault42
severity: normal
status: open
title: buffer overflow in Zipfile when wrinting more than 2gig file
versions: Python 2.4, Python 3.0
Added file: http://bugs.python.org/file14469/zipfile.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6434>
_______________________________________

From report at bugs.python.org  Tue Jul  7 19:14:31 2009
From: report at bugs.python.org (segfault42)
Date: Tue, 07 Jul 2009 17:14:31 +0000
Subject: [issue6434] buffer overflow in Zipfile when wrinting more than 2gig
	file
In-Reply-To: <1246986659.26.0.972556799924.issue6434@psf.upfronthosting.co.za>
Message-ID: <1246986871.53.0.329453472431.issue6434@psf.upfronthosting.co.za>


segfault42 <brice.nahum at free.fr> added the comment:

look like issue 1182788

----------
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6434>
_______________________________________

From report at bugs.python.org  Tue Jul  7 21:29:47 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 07 Jul 2009 19:29:47 +0000
Subject: [issue2977] truncation of text in tables in Library Reference PDF
In-Reply-To: <1211834269.04.0.0744383580947.issue2977@psf.upfronthosting.co.za>
Message-ID: <1246994987.05.0.251553749581.issue2977@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Yes, Sphinx should use longtables now where appropriate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2977>
_______________________________________

From report at bugs.python.org  Tue Jul  7 23:29:30 2009
From: report at bugs.python.org (Scott David Daniels)
Date: Tue, 07 Jul 2009 21:29:30 +0000
Subject: [issue6422] timeit called from within Python should allow autoranging
In-Reply-To: <1246958747.17.0.270405672758.issue6422@psf.upfronthosting.co.za>
Message-ID: <4A53BFE9.6090002@Acm.Org>


Scott David Daniels <Scott.Daniels at Acm.Org> added the comment:

I've got the code "working" on trunk2 for my tests.
Should I port to py3K before checking in, and give diffs from there, or 
what?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6422>
_______________________________________

From report at bugs.python.org  Wed Jul  8 00:12:04 2009
From: report at bugs.python.org (Peter Simanyi)
Date: Tue, 07 Jul 2009 22:12:04 +0000
Subject: [issue6074] .pyc files created readonly if .py file is readonly,
	python won't overwrite
In-Reply-To: <1242857063.47.0.919073638283.issue6074@psf.upfronthosting.co.za>
Message-ID: <1247004724.67.0.954757520636.issue6074@psf.upfronthosting.co.za>


Peter Simanyi <psimanyi at namcobandaigames.com> added the comment:

I verified that launching the script from a CMD.EXE window instead of
from Cygwin also reproduces the "can't overwrite ZZZ.pyc". Here's a
sample of "python -v" showing this:

 # C:\depot\central\ntf\tools\bin\build1.pyc has bad mtime
 import build1 # from C:\depot\central\ntf\tools\bin\build1.py
 # can't create C:\depot\central\ntf\tools\bin\build1.pyc

If you would like some help, I can discuss this with Windows expert
programmers here and see whether they can suggest a solution you might
find acceptable. Thank you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6074>
_______________________________________

From report at bugs.python.org  Wed Jul  8 04:18:04 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 08 Jul 2009 02:18:04 +0000
Subject: [issue6435] logging: cache the traceback text on formatter,
	instead of record
In-Reply-To: <1247019484.09.0.843372167885.issue6435@psf.upfronthosting.co.za>
Message-ID: <1247019484.09.0.843372167885.issue6435@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

In Formatter.format():

           # Cache the traceback text to avoid converting it multiple 
times
            # (it's constant anyway)
            if not record.exc_text:
                record.exc_text = self.formatException(record.exc_info)

The result must ideally be cache on the formatter object (self) itself 
rather than the record object. Because, record object is reused in 
multiple handlers .. thus multiple formatters. If the first formatter, 
caches the traceback text, then subsequent formatters will use the same 
even though of them is apparently a custom Formatter with overridden 
`formatException`.

----------
components: Library (Lib)
messages: 90247
nosy: srid, vsajip
severity: normal
status: open
title: logging: cache the traceback text on formatter, instead of record
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6435>
_______________________________________

From report at bugs.python.org  Wed Jul  8 04:18:19 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 08 Jul 2009 02:18:19 +0000
Subject: [issue6435] logging: cache the traceback text on formatter,
	instead of record
In-Reply-To: <1247019484.09.0.843372167885.issue6435@psf.upfronthosting.co.za>
Message-ID: <1247019499.04.0.0698239210002.issue6435@psf.upfronthosting.co.za>


Changes by Sridhar Ratnakumar <sridharr at activestate.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6435>
_______________________________________

From report at bugs.python.org  Wed Jul  8 04:25:12 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 08 Jul 2009 02:25:12 +0000
Subject: [issue6435] logging: cache the traceback text on formatter,
	instead of record
In-Reply-To: <1247019484.09.0.843372167885.issue6435@psf.upfronthosting.co.za>
Message-ID: <1247019912.26.0.587316383218.issue6435@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

For example, see: http://paste.pocoo.org/show/127167/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6435>
_______________________________________

From report at bugs.python.org  Wed Jul  8 04:31:42 2009
From: report at bugs.python.org (Ned Deily)
Date: Wed, 08 Jul 2009 02:31:42 +0000
Subject: [issue4017] Tkinter cannot find Tcl/Tk on Mac OS X
In-Reply-To: <1222960590.08.0.635891151551.issue4017@psf.upfronthosting.co.za>
Message-ID: <1247020302.53.0.578007514196.issue4017@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

@keflavich: To include 64-bit support for Tcl/Tk on OSX, you'll need to 
modify python's setup.py file.  Search down for
  "All existing framework builds of Tcl/Tk don't support 64-bit"
around line 1500 in 2.6; there is explicit code there to prevent tkinter 
from attempting to link with x86_64 and ppc64 libraries.

----------
nosy: +nad

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4017>
_______________________________________

From report at bugs.python.org  Wed Jul  8 05:08:26 2009
From: report at bugs.python.org (Case Van Horsen)
Date: Wed, 08 Jul 2009 03:08:26 +0000
Subject: [issue6431] Fraction fails equality test with a user-defined type
In-Reply-To: <1246945296.27.0.280023368175.issue6431@psf.upfronthosting.co.za>
Message-ID: <1247022506.18.0.351720584899.issue6431@psf.upfronthosting.co.za>


Case Van Horsen <casevh at gmail.com> added the comment:

Change Fraction __eq__ method to give the other operand a chance to
perform the comparison if Fraction doesn't understand the other operand.

----------
keywords: +patch
Added file: http://bugs.python.org/file14470/fractions_patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6431>
_______________________________________

From report at bugs.python.org  Wed Jul  8 08:15:42 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 08 Jul 2009 06:15:42 +0000
Subject: [issue4017] Tkinter cannot find Tcl/Tk on Mac OS X
In-Reply-To: <1222960590.08.0.635891151551.issue4017@psf.upfronthosting.co.za>
Message-ID: <1247033742.79.0.490484562285.issue4017@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

keflavich: Please open a new issue for the problem you are running in, it 
is a completely seperate issue than the one you appended your message to.

Where can I download a 64-bit capable version of Tcl/Tk? 

BTW. The correct fix would be to add a probe to setup.py that detects if 
Tcl/Tk was build with 64-bit support or not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4017>
_______________________________________

From report at bugs.python.org  Wed Jul  8 08:37:38 2009
From: report at bugs.python.org (Mark Summerfield)
Date: Wed, 08 Jul 2009 06:37:38 +0000
Subject: [issue6436] trace module doesn't seem to produce .cover files for Py3
	(but does for Py2)
In-Reply-To: <1247035057.94.0.368292747718.issue6436@psf.upfronthosting.co.za>
Message-ID: <1247035057.94.0.368292747718.issue6436@psf.upfronthosting.co.za>


New submission from Mark Summerfield <mark at qtrac.eu>:

When I execute the following command line (Linux, Fedora 10) using
Python 2.5 or 2.6, I get a .cover file:

python2.5 -m trace --count MyModule.py

But when I do this with Python 3.0 or 3.1, no .cover file is output.

I didn't notice anything in the documentation suggesting a change in
behaviour, but I'm not familiar with this module, so perhaps I've missed
something.

----------
components: Library (Lib)
messages: 90252
nosy: mark
severity: normal
status: open
title: trace module doesn't seem to produce .cover files for Py3 (but does for Py2)
type: behavior
versions: Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6436>
_______________________________________

From report at bugs.python.org  Wed Jul  8 09:30:35 2009
From: report at bugs.python.org (Alexey Shamrin)
Date: Wed, 08 Jul 2009 07:30:35 +0000
Subject: [issue2931] optparse: various problems with unicode and gettext
In-Reply-To: <1211297479.44.0.970954846769.issue2931@psf.upfronthosting.co.za>
Message-ID: <1247038235.37.0.502567167001.issue2931@psf.upfronthosting.co.za>


Alexey Shamrin <shamrin at gmail.com> added the comment:

More than a year passed since I reported this... Could someone suggest
how to move this forward? If needed, I can try to improve patch, test or
description of this issue. Should I, for example, split this into
separate issues?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2931>
_______________________________________

From report at bugs.python.org  Wed Jul  8 09:36:49 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 08 Jul 2009 07:36:49 +0000
Subject: [issue6431] Fraction fails equality test with a user-defined type
In-Reply-To: <1246945296.27.0.280023368175.issue6431@psf.upfronthosting.co.za>
Message-ID: <1247038609.83.0.384914421336.issue6431@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks.  Could you provide some tests?  (If you don't have time then 
that's fine: I'll probably get to this eventually, but it might take a 
while...)

----------
assignee:  -> marketdickinson
priority:  -> normal
stage: needs patch -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6431>
_______________________________________

From report at bugs.python.org  Wed Jul  8 09:40:56 2009
From: report at bugs.python.org (Sjoerd)
Date: Wed, 08 Jul 2009 07:40:56 +0000
Subject: [issue6425] imaplib.IMAP4.fetch() is missing documentation for
	message_set parameter
In-Reply-To: <1246868318.71.0.0692124898896.issue6425@psf.upfronthosting.co.za>
Message-ID: <1247038856.36.0.75649433567.issue6425@psf.upfronthosting.co.za>


Sjoerd <sjoerd-python at linuxonly.nl> added the comment:

Thanks, I missed that. I only read the documentation for the methods.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6425>
_______________________________________

From report at bugs.python.org  Wed Jul  8 09:45:19 2009
From: report at bugs.python.org (Sjoerd)
Date: Wed, 08 Jul 2009 07:45:19 +0000
Subject: [issue6426] imaplib.IMAP4 "command illegal in this state" is
	unhelpful error message
In-Reply-To: <1246868579.93.0.42678360783.issue6426@psf.upfronthosting.co.za>
Message-ID: <1247039119.3.0.218893610936.issue6426@psf.upfronthosting.co.za>


Sjoerd <sjoerd-python at linuxonly.nl> added the comment:

See http://bugs.python.org/issue1605192

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6426>
_______________________________________

From report at bugs.python.org  Wed Jul  8 09:58:53 2009
From: report at bugs.python.org (Manas)
Date: Wed, 08 Jul 2009 07:58:53 +0000
Subject: [issue6437] Personal invitation from Manas
In-Reply-To: <20090708035849.-1594888511@unyk.com>
Message-ID: <20090708035849.-1594888511@unyk.com>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
	<title>UNYK</title>
</head>
<body>
	<div id="um_container" style="width: 500px; color: #003366; font-family: verdana, arial, geneva, sans-serif;
		font-size: 12px; font-style: normal; font-weight: normal; line-height: 14px;
		text-align: left; text-decoration: none;">
		<div id="um_watermark" style="color: #808080;font-size: 10px; margin-bottom: 5px;">
			
			If you are not able to click these links, click the following: ????Show content???? and try again.<br>
			E-mail sent 7/8/2009 3:57:22 AM, by Manas Thapliyal:
		
		</div>
		<div id="um_header" style="border-bottom: solid 1px black;">
			<table width="100%">
				<tr>
					<td id="um_subject" style="width: auto; vertical-align: bottom; padding-left: 10px;
						padding-bottom: 15px; color: #003366; font-family: verdana, arial, geneva, sans-serif;
						font-weight: bold; font-size: 16px;">
						Personal invitation from Manas</td>
					<td id="um_logo" style="width: 131px;">
						
<a href="http://www.unyk.com/ml/354/66/?i=629FDC41B12F4673BBD647F7424EE0E3&s=15202900"><img border="0" src="http://www.unyk.com/img/common/logo_131x76.gif"></a></td>
				</tr>
			</table>
		</div>
		<div id="um_content" style="padding: 25px 10px 25px 10px;">
			<table cellpadding="0" cellspacing="0" border="0" width="100%">
				<tr>
					<td style="padding: 5px 0px 5px 5px; background-color: #f3f3f3;"><img src="http://photos.unyk.com/img/common/avatar_H.gif" border="0" /><br /></td>
					<td style="padding: 5px; background-color: #f3f3f3;" valign="top" align="left">
						
			Hello,<br />
			<br />
			To keep all friends together<br />
			<br />
			Finally, a smart and simple way to manage your contacts!<br />
			<br />
			With UNYK, I put all my contacts together in <b>one address book</b> that is <b>automatically updated</b>. One of my contacts changes his or her information at UNYK.com: My address book is updated. I change information at UNYK.com: My contacts?? address books are updated. Simple, but life-changing!<br />
			<br />
			Can I add you as one of my contacts? 
<a href="http://www.unyk.com/ml/354/66/?i=629FDC41B12F4673BBD647F7424EE0E3&s=15202900">To accept, click here!</a><br />
			<br />
			You too can create your own smart address book. <br />
		<br />
					</td>
				</tr>
			</table>
			<table cellpadding="0" cellspacing="0" border="0" width="100%">
				<tr>
					<td style="padding: 10px 5px 0px 5px; background-color: #ffffff; font-size: 11px;">
						
			Manas Thapliyal<br>
			UNYK : ASI 610
		
				</td>
				</tr>
			</table>
		</div>
		<div id="um_footer" style="border-top: solid 1px black; padding-top: 3px; font-weight: bold;
			font-size: 10px; font-family: arial, geneva, sans-serif;">
			
			UNYK, the first smart address book that updates itself!
		
		</div>
		<div id="um_unsubscribe" style="color: #808080; font-size: 10px; padding-top: 50px;">
			
			
<a href="http://www.unyk.com/ml/354/79/?mid=9E96A4A47B7D839D&email=report at bugs.python.org&s=15202900">Click here</a> if you no longer wish to receive invitations from Manas Thapliyal to try UNYK! <br />
			
<a href="http://www.unyk.com/ml/354/67/?i=629FDC41B12F4673BBD647F7424EE0E3&s=15202900">Click here</a> if you no longer wish to receive invitations to try UNYK from your contacts!<br />
		
		</div>
	</div>
</body>
</html>




-------------- next part --------------
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
	<title>UNYK</title>
</head>
<body>
	<div id="um_container" style="width: 500px; color: #003366; font-family: verdana, arial, geneva, sans-serif;
		font-size: 12px; font-style: normal; font-weight: normal; line-height: 14px;
		text-align: left; text-decoration: none;">
		<div id="um_watermark" style="color: #808080;font-size: 10px; margin-bottom: 5px;">
			
			If you are not able to click these links, click the following: ????Show content???? and try again.<br>
			E-mail sent 7/8/2009 3:57:22 AM, by Manas Thapliyal:
		
		</div>
		<div id="um_header" style="border-bottom: solid 1px black;">
			<table width="100%">
				<tr>
					<td id="um_subject" style="width: auto; vertical-align: bottom; padding-left: 10px;
						padding-bottom: 15px; color: #003366; font-family: verdana, arial, geneva, sans-serif;
						font-weight: bold; font-size: 16px;">
						Personal invitation from Manas</td>
					<td id="um_logo" style="width: 131px;">
						
<a href="http://www.unyk.com/ml/354/66/?i=629FDC41B12F4673BBD647F7424EE0E3&s=15202900"><img border="0" src="http://www.unyk.com/img/common/logo_131x76.gif"></a></td>
				</tr>
			</table>
		</div>
		<div id="um_content" style="padding: 25px 10px 25px 10px;">
			<table cellpadding="0" cellspacing="0" border="0" width="100%">
				<tr>
					<td style="padding: 5px 0px 5px 5px; background-color: #f3f3f3;"><img src="http://photos.unyk.com/img/common/avatar_H.gif" border="0" /><br /></td>
					<td style="padding: 5px; background-color: #f3f3f3;" valign="top" align="left">
						
			Hello,<br />
			<br />
			To keep all friends together<br />
			<br />
			Finally, a smart and simple way to manage your contacts!<br />
			<br />
			With UNYK, I put all my contacts together in <b>one address book</b> that is <b>automatically updated</b>. One of my contacts changes his or her information at UNYK.com: My address book is updated. I change information at UNYK.com: My contacts?? address books are updated. Simple, but life-changing!<br />
			<br />
			Can I add you as one of my contacts? 
<a href="http://www.unyk.com/ml/354/66/?i=629FDC41B12F4673BBD647F7424EE0E3&s=15202900">To accept, click here!</a><br />
			<br />
			You too can create your own smart address book. <br />
		<br />
					</td>
				</tr>
			</table>
			<table cellpadding="0" cellspacing="0" border="0" width="100%">
				<tr>
					<td style="padding: 10px 5px 0px 5px; background-color: #ffffff; font-size: 11px;">
						
			Manas Thapliyal<br>
			UNYK : ASI 610
		
				</td>
				</tr>
			</table>
		</div>
		<div id="um_footer" style="border-top: solid 1px black; padding-top: 3px; font-weight: bold;
			font-size: 10px; font-family: arial, geneva, sans-serif;">
			
			UNYK, the first smart address book that updates itself!
		
		</div>
		<div id="um_unsubscribe" style="color: #808080; font-size: 10px; padding-top: 50px;">
			
			
<a href="http://www.unyk.com/ml/354/79/?mid=9E96A4A47B7D839D&email=report at bugs.python.org&s=15202900">Click here</a> if you no longer wish to receive invitations from Manas Thapliyal to try UNYK! <br />
			
<a href="http://www.unyk.com/ml/354/67/?i=629FDC41B12F4673BBD647F7424EE0E3&s=15202900">Click here</a> if you no longer wish to receive invitations to try UNYK from your contacts!<br />
		
		</div>
	</div>
</body>
</html>





From report at bugs.python.org  Wed Jul  8 10:02:53 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 08 Jul 2009 08:02:53 +0000
Subject: [issue6437] Personal invitation from Manas
In-Reply-To: <20090708035849.-1594888511@unyk.com>
Message-ID: <1247040173.56.0.409460542257.issue6437@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6437>
_______________________________________

From report at bugs.python.org  Wed Jul  8 10:12:20 2009
From: report at bugs.python.org (ThomasH)
Date: Wed, 08 Jul 2009 08:12:20 +0000
Subject: [issue6395] Infinite Recursion during Unpickling a codecs Object
In-Reply-To: <1246463188.35.0.320675118154.issue6395@psf.upfronthosting.co.za>
Message-ID: <1247040740.55.0.848674873938.issue6395@psf.upfronthosting.co.za>


ThomasH <thomas.bugzilla at gmx.net> added the comment:

Sounds good to me. The main intention of this bug is not to make codecs
objects pickleable by all means (I don't know if this would be sensible
and/or possible), but at least to have them degrade gracefully during
pickling, particularly without infinite recursion. I've changed the bug
title to reflect this.

----------
title: Add Pickle Support to the codecs Module -> Infinite Recursion during Unpickling a codecs Object

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6395>
_______________________________________

From report at bugs.python.org  Wed Jul  8 10:12:41 2009
From: report at bugs.python.org (Max Bowsher)
Date: Wed, 08 Jul 2009 08:12:41 +0000
Subject: [issue5329] os.popen2 and os.popen3 in python 2.6 incompatible with
	os.popen* in python 2.5
In-Reply-To: <1235121245.47.0.613044216429.issue5329@psf.upfronthosting.co.za>
Message-ID: <1247040761.09.0.555594656884.issue5329@psf.upfronthosting.co.za>


Changes by Max Bowsher <maxb at f2s.com>:


----------
nosy: +maxb

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5329>
_______________________________________

From report at bugs.python.org  Wed Jul  8 10:15:11 2009
From: report at bugs.python.org (Max Bowsher)
Date: Wed, 08 Jul 2009 08:15:11 +0000
Subject: [issue5329] os.popen2 and os.popen3 in python 2.6 incompatible with
	os.popen* in python 2.5
In-Reply-To: <1235121245.47.0.613044216429.issue5329@psf.upfronthosting.co.za>
Message-ID: <1247040911.05.0.0437518623688.issue5329@psf.upfronthosting.co.za>


Max Bowsher <maxb at f2s.com> added the comment:

With or without tests, this is a regression from Python 2.5 - shouldn't
something be done about that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5329>
_______________________________________

From report at bugs.python.org  Wed Jul  8 10:15:35 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 08 Jul 2009 08:15:35 +0000
Subject: [issue6438] cygwincompiler regular expressions broken
In-Reply-To: <1247040935.54.0.909113570309.issue6438@psf.upfronthosting.co.za>
Message-ID: <1247040935.54.0.909113570309.issue6438@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

The regular expressions used in distutils to build a extension using the
mingw32 compiler are messed up because they try to work with bytes
(since Popen behavior changed) using string patterns.

I have to cleanup these regular expressions before any new 3.x release

----------
assignee: tarek
components: Distutils
messages: 90260
nosy: tarek
priority: critical
severity: normal
status: open
title: cygwincompiler regular expressions broken
versions: Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6438>
_______________________________________

From report at bugs.python.org  Wed Jul  8 11:00:44 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 08 Jul 2009 09:00:44 +0000
Subject: [issue6434] buffer overflow in Zipfile when wrinting more than 2gig
	file
In-Reply-To: <1246986659.26.0.972556799924.issue6434@psf.upfronthosting.co.za>
Message-ID: <1247043644.01.0.296853591726.issue6434@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I don't see how it can be a buffer overflow. Or is it an exception
raised by the struct.pack function?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6434>
_______________________________________

From report at bugs.python.org  Wed Jul  8 12:00:08 2009
From: report at bugs.python.org (Peter Funk)
Date: Wed, 08 Jul 2009 10:00:08 +0000
Subject: [issue1448934] urllib2+https+proxy not working
Message-ID: <1247047208.02.0.271694663946.issue1448934@psf.upfronthosting.co.za>


Peter Funk <pefu at users.sourceforge.net> added the comment:

I stumbled about this here because of testing the Ubuntuone project:

http://en.oreilly.com/oscon2009/public/schedule/detail/8843

The client for the ubuntuone cloud computing suffers from being
unable to connect through a HTTPS proxy.  May be some of the folks
at Canonical are now willing to spend some time on this issue here?
It is recorded in the Ubuntu tracker as:
https://bugs.launchpad.net/ubuntu/+source/python2.6/+bug/94130

I think a lot of the corporate Ubuntu Linux users behind restrictive 
firewalls are affected by this problem.

----------
nosy: +pefu

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1448934>
_______________________________________

From report at bugs.python.org  Wed Jul  8 12:07:19 2009
From: report at bugs.python.org (Senthil)
Date: Wed, 08 Jul 2009 10:07:19 +0000
Subject: [issue1448934] urllib2+https+proxy not working
Message-ID: <1247047639.92.0.577130247225.issue1448934@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

I noticed this one yesterday. There is a similar issue Issue1424152, the
fix for which is available in Py2.7. Would you try to that patch?

----------
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1448934>
_______________________________________

From report at bugs.python.org  Wed Jul  8 12:08:50 2009
From: report at bugs.python.org (Senthil)
Date: Wed, 08 Jul 2009 10:08:50 +0000
Subject: [issue1448934] urllib2+https+proxy not working
Message-ID: <1247047730.92.0.517325627088.issue1448934@psf.upfronthosting.co.za>


Changes by Senthil <orsenthil at gmail.com>:


----------
assignee:  -> orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1448934>
_______________________________________

From report at bugs.python.org  Wed Jul  8 14:01:50 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 08 Jul 2009 12:01:50 +0000
Subject: [issue6422] timeit called from within Python should allow autoranging
In-Reply-To: <1246806912.2.0.722769600334.issue6422@psf.upfronthosting.co.za>
Message-ID: <1247054510.96.0.381174658291.issue6422@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

You can still upload available patches to this tracker.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6422>
_______________________________________

From report at bugs.python.org  Wed Jul  8 14:37:45 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 08 Jul 2009 12:37:45 +0000
Subject: [issue6431] Fraction fails equality test with a user-defined type
In-Reply-To: <1246945296.27.0.280023368175.issue6431@psf.upfronthosting.co.za>
Message-ID: <1247056665.23.0.0125118098593.issue6431@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

A good solution should ensure that all 6 comparison operators behave in 
the same way for the same input types:  that is, if x == y returns 
NotImplemented for some particular Python objects x and y, then x < y, x 
<= y, etc. should also return NotImplemented, and vice versa.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6431>
_______________________________________

From report at bugs.python.org  Wed Jul  8 15:22:06 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 08 Jul 2009 13:22:06 +0000
Subject: [issue5329] os.popen2 and os.popen3 in python 2.6 incompatible with
	os.popen* in python 2.5
In-Reply-To: <1235121245.47.0.613044216429.issue5329@psf.upfronthosting.co.za>
Message-ID: <1247059326.82.0.66769845822.issue5329@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The test is the proof the the regression, and shows the change in
behavior and the purpose of the development.
There happens to be a test for os.popen3 (in Lib/test/test_popen2.py)
which passes a list; this one at least passes.

os.popen3() accepts a sequence, except that since 2.6, the first item is
the whole command string, and additional items are treated as additional
shell arguments!

Your patch is correct. A unit test could be:
    w, r, e = os.popen3(['echo', 'hello'])
    assert r.read() == 'hello\n'
And should be disabled on non-posix platforms.

----------
keywords: +needs review
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5329>
_______________________________________

From report at bugs.python.org  Wed Jul  8 16:11:11 2009
From: report at bugs.python.org (Campbell Barton)
Date: Wed, 08 Jul 2009 14:11:11 +0000
Subject: [issue6439] Demo/embed/demo.c use of PySys_SetArgv() is invalid
In-Reply-To: <1247062271.71.0.103757159811.issue6439@psf.upfronthosting.co.za>
Message-ID: <1247062271.71.0.103757159811.issue6439@psf.upfronthosting.co.za>


New submission from Campbell Barton <ideasman42 at gmail.com>:

in python 3.2 (current rev 73893)
Demo/embed/demo.c passes a 'char **' to PySys_SetArgv rather then a
'wsize_t **'

Im also confused as to how this conversion should be made in a portable
way, without copying some farily large static functions from python's code.

----------
components: Demos and Tools
messages: 90267
nosy: ideasman42
severity: normal
status: open
title: Demo/embed/demo.c use of PySys_SetArgv() is invalid
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6439>
_______________________________________

From report at bugs.python.org  Wed Jul  8 16:11:31 2009
From: report at bugs.python.org (Campbell Barton)
Date: Wed, 08 Jul 2009 14:11:31 +0000
Subject: [issue6439] Demo/embed/demo.c use of PySys_SetArgv() is invalid
In-Reply-To: <1247062271.71.0.103757159811.issue6439@psf.upfronthosting.co.za>
Message-ID: <1247062291.1.0.960948169043.issue6439@psf.upfronthosting.co.za>


Changes by Campbell Barton <ideasman42 at gmail.com>:


----------
type:  -> compile error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6439>
_______________________________________

From report at bugs.python.org  Wed Jul  8 16:13:20 2009
From: report at bugs.python.org (Eric Eisner)
Date: Wed, 08 Jul 2009 14:13:20 +0000
Subject: [issue6440] 2to3: convert deprecated string.maketrans to str.maketrans
In-Reply-To: <1247062399.96.0.431147395298.issue6440@psf.upfronthosting.co.za>
Message-ID: <1247062399.96.0.431147395298.issue6440@psf.upfronthosting.co.za>


New submission from Eric Eisner <ede at mit.edu>:

string.maketrans has been deprecated in 3.x in favor of the more
specific bytes.maketrans and str.maketrans (see issue5675). It would be
nice if 2to3 would automatically translate this to one of those two
(probably str.maketrans).

I briefly looked at lib2to3/fixes/fix_renames.py, but this only seems to
convert things of the form module.X to module.Y. Is there another script
that deals with these jumping-around functions?

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 90268
nosy: ede
severity: normal
status: open
title: 2to3: convert deprecated string.maketrans to str.maketrans
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6440>
_______________________________________

From report at bugs.python.org  Wed Jul  8 17:05:33 2009
From: report at bugs.python.org (Adam Ginsburg)
Date: Wed, 08 Jul 2009 15:05:33 +0000
Subject: [issue6441] Tkinter cannot find *64 bit* Tcl/Tk on Mac OS X
In-Reply-To: <1247065533.17.0.251181010063.issue6441@psf.upfronthosting.co.za>
Message-ID: <1247065533.17.0.251181010063.issue6441@psf.upfronthosting.co.za>


New submission from Adam Ginsburg <keflavich at gmail.com>:

While it is possible to compile 64 bit python on Mac OS X, the default
tcl/tk is NOT 64 bit.  If you do install a 64 bit version of tcl/tk,
python still will not find it - lines 1503-1515 prevent it:

        if 'x86_64' in archs or 'ppc64' in archs:
            try:
                archs.remove('x86_64')
            except ValueError:
                pass
            try:
                archs.remove('ppc64')
            except ValueError:
                pass

            for a in archs:
                frameworks.append('-arch')
                frameworks.append(a)


I was able to successfully get 64 bit tkinter working by commenting out
these lines as suggested by Ned Deily.

Ronald Oussoren suggests:
"BTW. The correct fix would be to add a probe to setup.py that detects
if Tcl/Tk was build with 64-bit support or not."

----------
components: Tkinter
messages: 90269
nosy: keflavich, nad, ronaldoussoren
severity: normal
status: open
title: Tkinter cannot find *64 bit* Tcl/Tk on Mac OS X
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6441>
_______________________________________

From report at bugs.python.org  Wed Jul  8 17:17:02 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 08 Jul 2009 15:17:02 +0000
Subject: [issue6441] Tkinter cannot find *64 bit* Tcl/Tk on Mac OS X
In-Reply-To: <1247065533.17.0.251181010063.issue6441@psf.upfronthosting.co.za>
Message-ID: <1247066222.59.0.338161585119.issue6441@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Adam: where can I download a 64-bit version of Tcl/Tk?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6441>
_______________________________________

From report at bugs.python.org  Wed Jul  8 17:25:20 2009
From: report at bugs.python.org (Adam Ginsburg)
Date: Wed, 08 Jul 2009 15:25:20 +0000
Subject: [issue6441] Tkinter cannot find *64 bit* Tcl/Tk on Mac OS X
In-Reply-To: <1247065533.17.0.251181010063.issue6441@psf.upfronthosting.co.za>
Message-ID: <1247066720.85.0.66224799037.issue6441@psf.upfronthosting.co.za>


Adam Ginsburg <keflavich at gmail.com> added the comment:

Sorry Ronald, I had misinterpreted your last message.

Look at these posts:
http://buffalothedestroyer.blogspot.com/2009/07/installing-64-bit-tcltk-on-mac-os-x.html
http://www.nabble.com/Error-compiling-tk-8.5.7-on-Mac-OS-X-10.5-td23790967.html

or try this script:
curl -O
'http://osdn.dl.sourceforge.net/sourceforge/tcl/t{cl,k}8.5.7-src.tar.gz'
for f in t*8.5.7*.gz; do tar zxf $f; done
cd tcl8.5.7/unix/
./configure --enable-framework --enable-64-bit
cd tk8.5.7/unix/
./configure --enable-framework --enable-64-bit
make -j 4 -C tcl8.5.7/unix
make -j 4 -C tk8.5.7/unix
sudo make install -C tcl8.5.7/unix
sudo make install -C tk8.5.7/unix

----------
assignee:  -> ronaldoussoren
components: +Macintosh

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6441>
_______________________________________

From report at bugs.python.org  Wed Jul  8 18:13:24 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 08 Jul 2009 16:13:24 +0000
Subject: [issue1008086] socket.inet_aton returns 8 bytes on LP64 platforms
Message-ID: <1247069604.21.0.589854467097.issue1008086@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Ping?
This has been merged to py3k with r69560 and is present in 3.1, what
about 2.6?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1008086>
_______________________________________

From report at bugs.python.org  Wed Jul  8 18:19:54 2009
From: report at bugs.python.org (Scott David Daniels)
Date: Wed, 08 Jul 2009 16:19:54 +0000
Subject: [issue6422] timeit called from within Python should allow autoranging
In-Reply-To: <1246806912.2.0.722769600334.issue6422@psf.upfronthosting.co.za>
Message-ID: <1247069994.05.0.365850846213.issue6422@psf.upfronthosting.co.za>


Changes by Scott David Daniels <Scott.Daniels at Acm.Org>:


----------
keywords: +patch
Added file: http://bugs.python.org/file14472/timeit.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6422>
_______________________________________

From report at bugs.python.org  Wed Jul  8 18:47:56 2009
From: report at bugs.python.org (Mike)
Date: Wed, 08 Jul 2009 16:47:56 +0000
Subject: [issue6399] Error reporting by logging.config.fileConfig()
In-Reply-To: <1246528231.33.0.0905986098741.issue6399@psf.upfronthosting.co.za>
Message-ID: <1247071676.13.0.851058901233.issue6399@psf.upfronthosting.co.za>


Mike <python at amadron.com> added the comment:

Hi Vinay,
I will bow to your greater expertise on this and will let this go.
It looks like it will be far more easier and robust just to invent my
own logging config file format and read it myself.
Thanks for your help.
Mike.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6399>
_______________________________________

From report at bugs.python.org  Wed Jul  8 18:53:57 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Wed, 08 Jul 2009 16:53:57 +0000
Subject: [issue6377] distutils compiler switch ignored
In-Reply-To: <1246299740.9.0.786372120366.issue6377@psf.upfronthosting.co.za>
Message-ID: <1247072037.08.0.114051925464.issue6377@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

It looks like this change may have broken some parts of distutils.  For
example, Twisted's setup.py now produces this output when running the
build_ext command:

$ ~/Projects/python/trunk/python setup.py build_ext
running build_ext
Traceback (most recent call last):
  File "setup.py", line 97, in <module>
    main(sys.argv[1:])
  File "setup.py", line 92, in main
    setup(**setup_args)
  File "./twisted/python/dist.py", line 47, in setup
    return core.setup(**get_setup_args(**kw))
  File "/home/exarkun/Projects/python/trunk/Lib/distutils/core.py", line
149, in setup
    dist.run_commands()
  File "/home/exarkun/Projects/python/trunk/Lib/distutils/dist.py", line
926, in run_commands
    self.run_command(cmd)
  File "/home/exarkun/Projects/python/trunk/Lib/distutils/dist.py", line
945, in run_command
    cmd_obj.run()
  File
"/home/exarkun/Projects/python/trunk/Lib/distutils/command/build_ext.py", line
380, in run
    self.build_extensions()
  File "./twisted/python/dist.py", line 327, in build_extensions
    self.prepare_extensions()
  File "./twisted/python/dist.py", line 318, in prepare_extensions
    if x.condition(self)]
  File "twisted/runner/topfiles/setup.py", line 14, in <lambda>
    condition=lambda builder: builder._check_header("rpc/rpc.h")),
  File "./twisted/python/dist.py", line 359, in _check_header
    self.compiler.announce("checking for %s ..." % header_name, 0)
AttributeError: 'NoneType' object has no attribute 'announce'

And PyCrypto produces this output:

running build_ext
Traceback (most recent call last):
  File "setup.py", line 163, in <module>
    core.setup(**kw)
  File "/tmp/python-buildbot/local/lib/python2.7/distutils/core.py",
line 149, in setup
    dist.run_commands()
  File "/tmp/python-buildbot/local/lib/python2.7/distutils/dist.py",
line 926, in run_commands
    self.run_command(cmd)
  File "/tmp/python-buildbot/local/lib/python2.7/distutils/dist.py",
line 945, in run_command
    cmd_obj.run()
  File
"/tmp/python-buildbot/local/lib/python2.7/distutils/command/install.py",
line 580, in run
    self.run_command('build')
  File "/tmp/python-buildbot/local/lib/python2.7/distutils/cmd.py", line
326, in run_command
    self.distribution.run_command(command)
  File "/tmp/python-buildbot/local/lib/python2.7/distutils/dist.py",
line 945, in run_command
    cmd_obj.run()
  File
"/tmp/python-buildbot/local/lib/python2.7/distutils/command/build.py",
line 132, in run
    self.run_command(cmd_name)
  File "/tmp/python-buildbot/local/lib/python2.7/distutils/cmd.py", line
326, in run_command
    self.distribution.run_command(command)
  File "/tmp/python-buildbot/local/lib/python2.7/distutils/dist.py",
line 945, in run_command
    cmd_obj.run()
  File
"/tmp/python-buildbot/local/lib/python2.7/distutils/command/build_ext.py",
line 380, in run
    self.build_extensions()
  File "setup.py", line 115, in build_extensions
    self.detect_modules()
  File "setup.py", line 119, in detect_modules
    lib_dirs = self.compiler.library_dirs + ['/lib', '/usr/lib']
AttributeError: 'NoneType' object has no attribute 'library_dirs'

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6377>
_______________________________________

From report at bugs.python.org  Wed Jul  8 19:05:44 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 08 Jul 2009 17:05:44 +0000
Subject: [issue6422] timeit called from within Python should allow autoranging
In-Reply-To: <1246806912.2.0.722769600334.issue6422@psf.upfronthosting.co.za>
Message-ID: <1247072744.88.0.579684755143.issue6422@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I would like to look at this in context of all the other proposed build-
outs to timeit.

----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6422>
_______________________________________

From report at bugs.python.org  Wed Jul  8 20:24:32 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 08 Jul 2009 18:24:32 +0000
Subject: [issue6377] distutils compiler switch ignored
In-Reply-To: <1246299740.9.0.786372120366.issue6377@psf.upfronthosting.co.za>
Message-ID: <1247077472.99.0.537080874252.issue6377@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Tarek, the .compiler attribute is needed by bdist_ext, so cannot just be
removed or renamed to .compiler_obj. There's a lot of bdist_ext
distutils code out there relying on having the .compiler object available.

A much better fix would be to map the option to a new attribute in
build_ext, e.g. .compiler_name or to remove the option altogether and
always inherit the setting from the global dist option --compiler.

In general, when making such changes, please test these against a few
well-known packages such as twisted, pycrypto or egenix-mx-base which do
include C extensions.

Thanks.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6377>
_______________________________________

From report at bugs.python.org  Wed Jul  8 20:50:55 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 08 Jul 2009 18:50:55 +0000
Subject: [issue6377] distutils compiler switch ignored
In-Reply-To: <1246299740.9.0.786372120366.issue6377@psf.upfronthosting.co.za>
Message-ID: <1247079055.59.0.534886944948.issue6377@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Note that the config command also uses a .compiler instance for actually
doing work, rather than as command option.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6377>
_______________________________________

From report at bugs.python.org  Wed Jul  8 20:51:22 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 08 Jul 2009 18:51:22 +0000
Subject: [issue6377] distutils compiler switch ignored
In-Reply-To: <1246299740.9.0.786372120366.issue6377@psf.upfronthosting.co.za>
Message-ID: <1247079082.75.0.205898011941.issue6377@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Added Python 2.7 since it fails there as well.

----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6377>
_______________________________________

From report at bugs.python.org  Wed Jul  8 20:56:05 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 08 Jul 2009 18:56:05 +0000
Subject: [issue6377] distutils compiler switch ignored
In-Reply-To: <1247077472.99.0.537080874252.issue6377@psf.upfronthosting.co.za>
Message-ID: <4A54EBC2.6030805@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Marc-Andre Lemburg wrote:
> Tarek, the .compiler attribute is needed by bdist_ext, so cannot just be
> removed or renamed to .compiler_obj. There's a lot of bdist_ext
> distutils code out there relying on having the .compiler object available.

Sorry, the above should have read build_ext, not bdist_ext...

> A much better fix would be to map the option to a new attribute in
> build_ext, e.g. .compiler_name or to remove the option altogether and
> always inherit the setting from the global dist option --compiler.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6377>
_______________________________________

From report at bugs.python.org  Wed Jul  8 21:20:06 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 08 Jul 2009 19:20:06 +0000
Subject: [issue6439] Demo/embed/demo.c use of PySys_SetArgv() is invalid
In-Reply-To: <1247062271.71.0.103757159811.issue6439@psf.upfronthosting.co.za>
Message-ID: <1247080806.14.0.0593259399296.issue6439@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6439>
_______________________________________

From report at bugs.python.org  Wed Jul  8 21:39:59 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 08 Jul 2009 19:39:59 +0000
Subject: [issue6377] distutils compiler switch ignored
In-Reply-To: <1246299740.9.0.786372120366.issue6377@psf.upfronthosting.co.za>
Message-ID: <1247081999.37.0.935078374151.issue6377@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

Trunk may be is not affected. I successfully cross-compile with GNU
compiler for windows (see issue 3871).

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6377>
_______________________________________

From report at bugs.python.org  Wed Jul  8 21:45:11 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 08 Jul 2009 19:45:11 +0000
Subject: [issue6377] distutils compiler switch ignored
In-Reply-To: <1247081999.37.0.935078374151.issue6377@psf.upfronthosting.co.za>
Message-ID: <4A54F742.5010609@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Roumen Petrov wrote:
> Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:
> 
> Trunk may be is not affected. I successfully cross-compile with GNU
> compiler for windows (see issue 3871).

It is affected in the sense that .compile was changed
to .compile_obj and that change breaks 3rd party setup.py
code which uses the compiler instance to run its own
compilations or needs to tweak the setup by e.g. adding
more libs or dirs to its configuration.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6377>
_______________________________________

From report at bugs.python.org  Wed Jul  8 21:50:34 2009
From: report at bugs.python.org (Philipp)
Date: Wed, 08 Jul 2009 19:50:34 +0000
Subject: [issue6393] OS X: python3 from python-3.1.dmg crashes at startup
In-Reply-To: <1246445517.38.0.373229118664.issue6393@psf.upfronthosting.co.za>
Message-ID: <1247082634.95.0.887796338235.issue6393@psf.upfronthosting.co.za>


Changes by Philipp <pkalder at googlemail.com>:


----------
nosy: +Phil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6393>
_______________________________________

From report at bugs.python.org  Wed Jul  8 22:49:55 2009
From: report at bugs.python.org (Kevin Walzer)
Date: Wed, 08 Jul 2009 20:49:55 +0000
Subject: [issue6441] Tkinter cannot find *64 bit* Tcl/Tk on Mac OS X
In-Reply-To: <1247065533.17.0.251181010063.issue6441@psf.upfronthosting.co.za>
Message-ID: <1247086195.32.0.651693621708.issue6441@psf.upfronthosting.co.za>


Changes by Kevin Walzer <wordtech at users.sourceforge.net>:


----------
nosy: +wordtech

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6441>
_______________________________________

From report at bugs.python.org  Wed Jul  8 23:01:39 2009
From: report at bugs.python.org (segfault42)
Date: Wed, 08 Jul 2009 21:01:39 +0000
Subject: [issue6434] buffer overflow in Zipfile when wrinting more than 2gig
	file
In-Reply-To: <1246986659.26.0.972556799924.issue6434@psf.upfronthosting.co.za>
Message-ID: <1247086899.84.0.506359874959.issue6434@psf.upfronthosting.co.za>


segfault42 <brice.nahum at free.fr> added the comment:

yes it's zinfo.file_size which is bigger than the long specify in the 
struct.pack

There's must have a solution with the extra header because a lot of tools 
can zip big file and these zip file can be open by zipfile.py

it's easy to reproduice with a big file of 3 gig.

i think that the problem come from that the write methode do not take 
care of the flag allowZip64

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6434>
_______________________________________

From report at bugs.python.org  Wed Jul  8 23:31:46 2009
From: report at bugs.python.org (Brian)
Date: Wed, 08 Jul 2009 21:31:46 +0000
Subject: [issue4660] multiprocessing.JoinableQueue task_done() issue
In-Reply-To: <1246275984.03.0.474769425381.issue4660@psf.upfronthosting.co.za>
Message-ID: <4a3ced360907081431s19bce1c2ie547942b769feee4@mail.gmail.com>


Brian <brian at merrells.org> added the comment:

Cool., let me know if there is anything I can do to help.

On Mon, Jun 29, 2009 at 7:46 AM, Jesse Noller <report at bugs.python.org>wrote:

>
> Jesse Noller <jnoller at gmail.com> added the comment:
>
> I'm leaning towards the properly protecting JoinableQueue.put() fix, I'm
> not a terribly big fan of removing error checking. I'm trying to carve off
> time this week to beat on my bug queue, so I'm hoping to be able to commit
> something (once I have docs+tests) this week.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue4660>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file14473/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4660>
_______________________________________
-------------- next part --------------
Cool., let me know if there is anything I can do to help.<br><br><br><div class="gmail_quote">On Mon, Jun 29, 2009 at 7:46 AM, Jesse Noller <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Jesse Noller &lt;<a href="mailto:jnoller at gmail.com">jnoller at gmail.com</a>&gt; added the comment:<br>
<br>
I&#39;m leaning towards the properly protecting JoinableQueue.put() fix, I&#39;m<br>
not a terribly big fan of removing error checking. I&#39;m trying to carve off<br>
time this week to beat on my bug queue, so I&#39;m hoping to be able to commit<br>
something (once I have docs+tests) this week.<br>
<br>
----------<br>
<div><div></div><div class="h5"><br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue4660" target="_blank">http://bugs.python.org/issue4660</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br>

From report at bugs.python.org  Wed Jul  8 23:46:43 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 08 Jul 2009 21:46:43 +0000
Subject: [issue6377] distutils compiler switch ignored
In-Reply-To: <1246299740.9.0.786372120366.issue6377@psf.upfronthosting.co.za>
Message-ID: <1247089603.79.0.0668545999521.issue6377@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I'll set back the compiler attribute when compiler_obj is set too, 
so third-party code will be able to work with it as before.

The current code will deprecate this usage, by displaying a deprecation
warning:

- if the compiler is set to anything else than a string.
- if the compiler is get and happens to be a compiler instance.

so we can keep "compiler" as its initial purpose.

And I'll test it on twisted and egenix. Thanks for the feedback

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6377>
_______________________________________

From report at bugs.python.org  Wed Jul  8 23:58:29 2009
From: report at bugs.python.org (Ned Deily)
Date: Wed, 08 Jul 2009 21:58:29 +0000
Subject: [issue6393] OS X: python3 from python-3.1.dmg crashes at startup
In-Reply-To: <1246445517.38.0.373229118664.issue6393@psf.upfronthosting.co.za>
Message-ID: <1247090309.57.0.216230218073.issue6393@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

This is a side effect of the fix for Issue6202.  Prior to r73268, 
locale.getpreferredencoding always returned "mac-roman" regardless of the 
setting of LANG, so this wasn't a problem in py3k (or 3.0.x builds) up 
through 3.1rc1.  I can reproduce it on current py3k and release31-maint.

----------
nosy: +nad

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6393>
_______________________________________

From report at bugs.python.org  Thu Jul  9 00:05:12 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 08 Jul 2009 22:05:12 +0000
Subject: [issue6440] 2to3: convert deprecated string.maketrans to str.maketrans
In-Reply-To: <1247062399.96.0.431147395298.issue6440@psf.upfronthosting.co.za>
Message-ID: <1247090712.14.0.947928866012.issue6440@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Doesn't that create an issue depending on whether your 2-to-3 target is
3.0 or 3.1?  I don't think minor release changes should be conflated
with the major release changes.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6440>
_______________________________________

From report at bugs.python.org  Thu Jul  9 00:34:04 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 08 Jul 2009 22:34:04 +0000
Subject: [issue6333] logging: ValueError: I/O operation on closed file
In-Reply-To: <1245807768.39.0.536701423847.issue6333@psf.upfronthosting.co.za>
Message-ID: <1247092444.74.0.859025403654.issue6333@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

I have attached a script that repros this bug. Run it using py.test 
(instructions inside the file).

Workaround is by uncommenting the last few lines ('flush' method).

----------
Added file: http://bugs.python.org/file14474/issue6333repro.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6333>
_______________________________________

From report at bugs.python.org  Thu Jul  9 00:39:04 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 08 Jul 2009 22:39:04 +0000
Subject: [issue6333] logging: ValueError: I/O operation on closed file
In-Reply-To: <1245807768.39.0.536701423847.issue6333@psf.upfronthosting.co.za>
Message-ID: <1247092744.33.0.720900674187.issue6333@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Note: It appears that py.test assigns a temporary file to sys.std[out|
err].

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6333>
_______________________________________

From report at bugs.python.org  Thu Jul  9 00:45:39 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 08 Jul 2009 22:45:39 +0000
Subject: [issue6377] distutils compiler switch ignored
In-Reply-To: <1246299740.9.0.786372120366.issue6377@psf.upfronthosting.co.za>
Message-ID: <1247093139.82.0.544742014172.issue6377@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

done in r73895, r73896. (and tested with twisted trunk).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6377>
_______________________________________

From report at bugs.python.org  Thu Jul  9 00:47:17 2009
From: report at bugs.python.org (Corbin Simpson)
Date: Wed, 08 Jul 2009 22:47:17 +0000
Subject: [issue6442] Backwards __contains__/has_key in xml/sax/xmlreader.py
In-Reply-To: <1247093237.58.0.29054416119.issue6442@psf.upfronthosting.co.za>
Message-ID: <1247093237.58.0.29054416119.issue6442@psf.upfronthosting.co.za>


New submission from Corbin Simpson <MostAwesomeDude at gmail.com>:

Not a big deal, but these two methods were backwards in AttributesImpl
in xml/sax/xmlreader.py, and it was causing fun little problems in some
of my code on Python 2.6.0, so I decided to whip up a patch.

(Of course, this is fixed in Py3k since has_key() got nuked.)

~ C.

----------
components: Library (Lib)
files: temp.patch
keywords: patch
messages: 90290
nosy: MostAwesomeDude
severity: normal
status: open
title: Backwards __contains__/has_key in xml/sax/xmlreader.py
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14475/temp.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6442>
_______________________________________

From report at bugs.python.org  Thu Jul  9 00:58:16 2009
From: report at bugs.python.org (Retro)
Date: Wed, 08 Jul 2009 22:58:16 +0000
Subject: [issue6358] os.popen exit code inconsistent
In-Reply-To: <1246224690.37.0.731708410356.issue6358@psf.upfronthosting.co.za>
Message-ID: <1247093896.85.0.938293857674.issue6358@psf.upfronthosting.co.za>


Retro <vinetouu at gmail.com> added the comment:

os.popen is deprecated. Use the subprocess module.

----------
nosy: +Retro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6358>
_______________________________________

From report at bugs.python.org  Thu Jul  9 01:06:43 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 08 Jul 2009 23:06:43 +0000
Subject: [issue6333] logging: ValueError: I/O operation on closed file
In-Reply-To: <1245807768.39.0.536701423847.issue6333@psf.upfronthosting.co.za>
Message-ID: <1247094403.99.0.220717793902.issue6333@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Perhaps it's a py.test issue. Have you tried with unittest and nose?
Remember, py.test has had little love for a while and so perhaps has a
few rougher edges (though I hear in the blogosphere that the project may
be rejuvenated shortly).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6333>
_______________________________________

From report at bugs.python.org  Thu Jul  9 01:10:29 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 08 Jul 2009 23:10:29 +0000
Subject: [issue6399] Error reporting by logging.config.fileConfig()
In-Reply-To: <1246528231.33.0.0905986098741.issue6399@psf.upfronthosting.co.za>
Message-ID: <1247094629.57.0.337328511011.issue6399@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Mike,

That's just fine. Sorry if I appear unhelpful, but in the open source
world we mostly scratch our own itches. I believe I have a reasonable
record on accepting patches from the community (though I don't of course
accept everything), and I unfortunately don't have much time to spend on
this because of other, more pressing itches :-( 

Best of luck with it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6399>
_______________________________________

From report at bugs.python.org  Thu Jul  9 01:19:08 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 08 Jul 2009 23:19:08 +0000
Subject: [issue6333] logging: ValueError: I/O operation on closed file
In-Reply-To: <1245807768.39.0.536701423847.issue6333@psf.upfronthosting.co.za>
Message-ID: <1247095148.7.0.63830251108.issue6333@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Perhaps there is an issue with py.test.

My understanding is that: if the logging module is designed to let 
users implement their own custom handlers (like I did with 
ConsoleHandler), is it not expected that they may do whatever they want 
with it including closing the file (in this case - sys.stdout is a 
temporary file that is obviously closed at one stage)? Shouldn't the 
logging module be reliable in such cases?

I will point holger (author of py.test) to this issue in case if he has 
any comments.

Anyways, this is a very low-prio bug for me .. especially when there is 
a workaround.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6333>
_______________________________________

From report at bugs.python.org  Thu Jul  9 01:20:40 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 08 Jul 2009 23:20:40 +0000
Subject: [issue6440] 2to3: convert deprecated string.maketrans to str.maketrans
In-Reply-To: <1247062399.96.0.431147395298.issue6440@psf.upfronthosting.co.za>
Message-ID: <1247095240.3.0.845208322179.issue6440@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I think 2to3 should target 3.1.  We don't expect/want people to use 3.0
in production.

----------
nosy: +r.david.murray
priority:  -> normal
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6440>
_______________________________________

From report at bugs.python.org  Thu Jul  9 01:30:59 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 08 Jul 2009 23:30:59 +0000
Subject: [issue6440] 2to3: convert deprecated string.maketrans to str.maketrans
In-Reply-To: <1247062399.96.0.431147395298.issue6440@psf.upfronthosting.co.za>
Message-ID: <1247095859.67.0.573386075675.issue6440@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

It's the users wants not yours that matter.  If someone already has 3.0
in production and is maintaining code in both 2.6 and 3.0, then this
change will break their build.

Also, it is not a necessary change.  We already have a warning in-place
to alert anyone who is interested and the removal of the feature doesn't
take place until 3.2.  

It is feature creep to start retargeting the 2-to-3 tool.  This is just
a normal difference between minor versions and is outside the scope of
that tool.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6440>
_______________________________________

From report at bugs.python.org  Thu Jul  9 01:31:56 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 08 Jul 2009 23:31:56 +0000
Subject: [issue6435] logging: cache the traceback text on formatter,
	instead of record
In-Reply-To: <1247019484.09.0.843372167885.issue6435@psf.upfronthosting.co.za>
Message-ID: <1247095916.73.0.340371272083.issue6435@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

A real-life recipe where this bug showed up: 

  http://code.activestate.com/recipes/576836/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6435>
_______________________________________

From report at bugs.python.org  Thu Jul  9 01:42:03 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 08 Jul 2009 23:42:03 +0000
Subject: [issue6440] 2to3: convert deprecated string.maketrans to str.maketrans
In-Reply-To: <1247062399.96.0.431147395298.issue6440@psf.upfronthosting.co.za>
Message-ID: <1247096523.57.0.984185076386.issue6440@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Ah, I missed the fact that this was a 3.2 change.  Somehow I thought it
was a 3.1 thing.  So you are right, IMO, this would be feature creap.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6440>
_______________________________________

From report at bugs.python.org  Thu Jul  9 04:16:15 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 09 Jul 2009 02:16:15 +0000
Subject: [issue6377] distutils compiler switch ignored
In-Reply-To: <1246299740.9.0.786372120366.issue6377@psf.upfronthosting.co.za>
Message-ID: <1247105775.01.0.00871017060561.issue6377@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Cool, thanks.  PyCrypto also works again now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6377>
_______________________________________

From report at bugs.python.org  Thu Jul  9 05:21:10 2009
From: report at bugs.python.org (Andrew Ziem)
Date: Thu, 09 Jul 2009 03:21:10 +0000
Subject: [issue6443] _winreg.QueryValueEx confused on double null terminated
	strings
In-Reply-To: <1247109670.35.0.187157773378.issue6443@psf.upfronthosting.co.za>
Message-ID: <1247109670.35.0.187157773378.issue6443@psf.upfronthosting.co.za>


New submission from Andrew Ziem <ahz001 at gmail.com>:

QueryValueEx only returns one string when the contents are double null
terminated, yet QueryValueEx works when the string is singly null
terminated.

In Python 2.5.4 on Windows XP Sp3, the first key-value only returns the
first part up to \0\0.
-------------------
C:\>reg query "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager" /v
Pending
FileRenameOperations

! REG.EXE VERSION 3.0

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager
    PendingFileRenameOperations REG_MULTI_SZ    \??\C:\Documents and
Settings\All Users\Application Data\McAfee\Common
Framework\UpdateDir\0\0\??\C:\Program
Files\Google\GoogleToolbarNotifier\5.2.4204.1700\0\0\??\C:\Documents and
Settings\All Users\Application Data\McAfee\Common
Framework\UpdateDir\0\0\??\C:\Documents and Settings\All
Users\Application Data\McAfee\Common
Framework\UpdateDir\0\0\??\C:\Documents and Settings\All
Users\Application Data\McAfee\Common
Framework\UpdateDir\0\0\??\C:\Documents and Settings\All
Users\Application Data\McAfee\Common
Framework\UpdateDir\0\0\??\C:\Documents and Settings\All
Users\Application Data\McAfee\Common
Framework\UpdateDir\0\0\??\C:\Documents and Settings\All Users\A
pplication Data\McAfee\Common Framework\UpdateDir\0\0\??\C:\Documents
and Settings\All Users\Application Data\McAfee\Common
Framework\UpdateDir\0\0\0

C:\>reg query "HKLM\SYSTEM\CurrentControlSet\Services\Browser" /v 
DependOnService

! REG.EXE VERSION 3.0

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Browser
    DependOnService     REG_MULTI_SZ    LanmanWorkstation\0LanmanServer\0\0

----------
components: Windows
messages: 90300
nosy: AndrewZiem
severity: normal
status: open
title: _winreg.QueryValueEx confused on double null terminated strings
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6443>
_______________________________________

From report at bugs.python.org  Thu Jul  9 05:28:54 2009
From: report at bugs.python.org (Andrew Ziem)
Date: Thu, 09 Jul 2009 03:28:54 +0000
Subject: [issue6443] _winreg.QueryValueEx confused on double null terminated
	strings
In-Reply-To: <1247109670.35.0.187157773378.issue6443@psf.upfronthosting.co.za>
Message-ID: <1247110134.89.0.30796312214.issue6443@psf.upfronthosting.co.za>


Andrew Ziem <ahz001 at gmail.com> added the comment:

The bug is noted in the Python source code in file PC/_winreg.c in in
function fixupMultiSZ() where it admits Python does not mimic Microsoft
regedit.exe

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6443>
_______________________________________

From report at bugs.python.org  Thu Jul  9 05:55:42 2009
From: report at bugs.python.org (Ned Deily)
Date: Thu, 09 Jul 2009 03:55:42 +0000
Subject: [issue6393] OS X: python3 from python-3.1.dmg crashes at startup
In-Reply-To: <1246445517.38.0.373229118664.issue6393@psf.upfronthosting.co.za>
Message-ID: <1247111742.29.0.763946868613.issue6393@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Note, you can produce the same error on OS X or linux by setting 
PYTHONIOENCODING="", which effectively overrides the value returned 
nl_langinfo(CODESET).  In pythonrun.c, create_stdio passes 
PYTHONENCODING, if set, on as the "encoding" value to TextIOWrapper.  If 
no encoding was specified, TextIOWrapper uses the value returned by 
locale.getpreferrencoding().  It then calls PyCodec_IncrementalDecoder 
and the unknown (or empty) encoding is finally detected.

That raises the question of how far python should go in protecting the 
user.  One *could* add a check in pythonrun.c to substitute some 
suitable default (UTF-8) if nl_langinfo(CODESET) returns an empty value.  
Or perhaps just abort there with a more meaningful error message.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6393>
_______________________________________

From report at bugs.python.org  Thu Jul  9 05:58:06 2009
From: report at bugs.python.org (Ned Deily)
Date: Thu, 09 Jul 2009 03:58:06 +0000
Subject: [issue6393] OS X: python3 from python-3.1.dmg crashes at startup
In-Reply-To: <1246445517.38.0.373229118664.issue6393@psf.upfronthosting.co.za>
Message-ID: <1247111886.49.0.46987634635.issue6393@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

"... create_stdio passes PYTHONIOENCODING ..."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6393>
_______________________________________

From report at bugs.python.org  Thu Jul  9 08:59:16 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 09 Jul 2009 06:59:16 +0000
Subject: [issue6435] logging: cache the traceback text on formatter,
	instead of record
In-Reply-To: <1247019484.09.0.843372167885.issue6435@psf.upfronthosting.co.za>
Message-ID: <1247122756.51.0.532572459757.issue6435@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I fail to follow your logic, in the following respects:

1. The exception text cannot be cached in the formatter because a
formatter will format lots and lots of records. Formatters live for a
long time, records do not.
2. The exception text needs to be stored in the record, because in some
instances (e.g. pickling and sending over a socket) this information
will not be available at the other end in any other way.
3. The way it works now, if you have multiple formatters attached to
multiple handlers (e.g. with ISO time for log files, with no ISO time
for console output), then the traceback is only converted to text once.
4. There's nothing stopping you from overriding Formatter.format, is
there? the base version uses the cache, you can override format in your
custom formatter and ignore the cache altogether if you like.

Are you sure you've thought this through? ;-)

----------
assignee:  -> vsajip
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6435>
_______________________________________

From report at bugs.python.org  Thu Jul  9 09:19:54 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 09 Jul 2009 07:19:54 +0000
Subject: [issue6435] logging: cache the traceback text on formatter,
	instead of record
In-Reply-To: <1247122756.51.0.532572459757.issue6435@psf.upfronthosting.co.za>
Message-ID: <op.uwsha9zb1q4jlt@dhcp-106.activestate.com>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

On Wed, 08 Jul 2009 23:59:17 -0700, Vinay Sajip <report at bugs.python.org>  
wrote:

> 1. The exception text cannot be cached in the formatter because a
> formatter will format lots and lots of records. Formatters live for a
> long time, records do not.

Ah, yes.

> Are you sure you've thought this through?

Not thoroughly .. as I missed the point 1. on formatter processing  
multiple records.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6435>
_______________________________________

From report at bugs.python.org  Thu Jul  9 09:33:39 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 09 Jul 2009 07:33:39 +0000
Subject: [issue6435] logging: cache the traceback text on formatter,
	instead of record
In-Reply-To: <1247019484.09.0.843372167885.issue6435@psf.upfronthosting.co.za>
Message-ID: <1247124819.12.0.234298573122.issue6435@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> Not thoroughly .. as I missed the point 1. on formatter processing  
> multiple records.

But what do you say to points 2, 3 and 4? Of course they may not apply
to your use case, but are they not valid points?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6435>
_______________________________________

From report at bugs.python.org  Thu Jul  9 09:34:00 2009
From: report at bugs.python.org (Max Arnold)
Date: Thu, 09 Jul 2009 07:34:00 +0000
Subject: [issue6444] multiline exception logging via syslog handler
In-Reply-To: <1247124840.28.0.246529396761.issue6444@psf.upfronthosting.co.za>
Message-ID: <1247124840.28.0.246529396761.issue6444@psf.upfronthosting.co.za>


New submission from Max Arnold <lwarxx at gmail.com>:

I use syslog message routing mechanism to log high-priority messages
from my python code to separate file.  When exceptions are logged, only
first line routed to specified file, and the rest goes in /var/log/messages.

Such problem exists when SyslogHandler instantiated with "/dev/log".

If logging is performed to remote host via udp socket, then exception
logged as one long string with all lines being concatenated.

Probably multiline log messages should be automatically splitted and
logged line-by-line with the same facility, severity and program name.
Also it will be good to have special formatter tag which expands as
empty string in first logged line, and as user-defined string in
remaining ones. This can simplify automated log analysis.

----------
components: Library (Lib)
messages: 90307
nosy: LwarX
severity: normal
status: open
title: multiline exception logging via syslog handler
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6444>
_______________________________________

From report at bugs.python.org  Thu Jul  9 09:51:48 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 09 Jul 2009 07:51:48 +0000
Subject: [issue6393] OS X: python3 from python-3.1.dmg crashes at startup
In-Reply-To: <1246445517.38.0.373229118664.issue6393@psf.upfronthosting.co.za>
Message-ID: <1247125908.54.0.575386464499.issue6393@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> One *could* add a check in pythonrun.c to substitute some suitable
> default (UTF-8) if nl_langinfo(CODESET) returns an empty value.

While googling for the source of this problem, I found other software 
projects that take this approach.  It doesn't seem totally unreasonable.

I just wish I understood *why* nl_langinfo(CODESET) is returning "" in 
these cases.  I've looked for the source at 
http://www.opensource.apple.com, but can't find it;  maybe that part of 
Darwin isn't open source.

It seems that a lot of people end up with an OS X Terminal setup such that 
LC_CTYPE is 'UTF-8' (perhaps this is a 10.4 thing---I haven't encountered 
this myself);  I don't think these people should have to deal with a 
confusing error on startup;  defaulting to UTF-8 on OS X seems like a 
reasonable compromise.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6393>
_______________________________________

From report at bugs.python.org  Thu Jul  9 09:55:15 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 09 Jul 2009 07:55:15 +0000
Subject: [issue6377] distutils compiler switch ignored
In-Reply-To: <1247089603.79.0.0668545999521.issue6377@psf.upfronthosting.co.za>
Message-ID: <4A55A260.7050009@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Tarek Ziad? wrote:
> Tarek Ziad? <ziade.tarek at gmail.com> added the comment:
> 
> I'll set back the compiler attribute when compiler_obj is set too, 
> so third-party code will be able to work with it as before.
> 
> The current code will deprecate this usage, by displaying a deprecation
> warning:
> 
> - if the compiler is set to anything else than a string.
> - if the compiler is get and happens to be a compiler instance.
> 
> so we can keep "compiler" as its initial purpose.

Could you please elaborate a bit on the reasoning behind
deprecating using .compiler for the compiler instance ?

The code did work before, so I'm not sure why you are trying
to fix something that wasn't really broken.

With the change you:

 * make the code more complex just to be able to raise
   a warning

 * introduce an cross-version incompatibility for tools
   using build_ext: they will now have to use .compiler
   for Python 2.3-2.6 and .compiler_obj for 2.7 and up

Wouldn't it be better to either leave things are they have
been for years (without problems) or find another solution ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6377>
_______________________________________

From report at bugs.python.org  Thu Jul  9 10:02:55 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 09 Jul 2009 08:02:55 +0000
Subject: [issue6393] OS X: python3 from python-3.1.dmg crashes at startup
In-Reply-To: <1246445517.38.0.373229118664.issue6393@psf.upfronthosting.co.za>
Message-ID: <1247126575.59.0.225585776744.issue6393@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The manpage says that nl_langinfo returns an empty string when there is 
an invalid setting.

There is validity in saying that 'LANG=utf-8' is an invalid setting, the 
LANG variable is supposed to a locale name, which would be a language 
setting (possibly combined with a codeset definition). "utf-8" is not a 
language.

I wouldn't mind falling back to utf-8 as the default codeset when 
nl_langinfo returns an empty string because utf-8 is the default 
character set on OSX, and furthermore defaulting to some value is way 
better than crashing.

I do wonder how the user ended up with LANG=utf-8 in the first place.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6393>
_______________________________________

From report at bugs.python.org  Thu Jul  9 10:06:36 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 09 Jul 2009 08:06:36 +0000
Subject: [issue6435] logging: cache the traceback text on formatter,
	instead of record
In-Reply-To: <1247122756.51.0.532572459757.issue6435@psf.upfronthosting.co.za>
Message-ID: <op.uwsjg5e71q4jlt@activestate-users-macbook.local>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

> 2. The exception text needs to be stored in the record, because in some
> instances (e.g. pickling and sending over a socket) this information
> will not be available at the other end in any other way.

Caching in the record object is thus the way to go. But the cache needs to  
be invalidated when `exc_info` is changed .. as in set to None when it was  
a traceback object. I'd change the following:

         if record.exc_text:
             if s[-1:] != "\n":

to:

         if record.exc_info and record.exc_text:
             if s[-1:] != "\n":

(or, move the body of this IF to the preceding IF)

> 3. The way it works now, if you have multiple formatters attached to
> multiple handlers (e.g. with ISO time for log files, with no ISO time
> for console output), then the traceback is only converted to text once.

Yes, that is the benefit of caching I see.

> 4. There's nothing stopping you from overriding Formatter.format, is
> there? the base version uses the cache, you can override format in your
> custom formatter and ignore the cache altogether if you like.

I can, but I'd rather not duplicate that code. From the recipe I linked  
above:

     def format(self, record):
         # attach 'error:' prefix to error/critical messages
         s = logging.Formatter.format(self, record)
         if record.levelno >= logging.ERROR:
             return 'error: {0}'.format(s)
         else:
             return s

Here, I simply call the base class's `format` method.

And do you know of a better way to suppress traceback output (in the  
custom handler during `log.exception`) than the hack used in the recipe?

         elif record.levelno >= logging.ERROR:
             if record.exc_info and self.verbosity_level < 1:
                 # supress full traceback with verbosity_level <= 0
                 with new_record_exc_info(record, None):
                     self.__emit(record, sys.stderr)
             else:
                 self.__emit(record, sys.stderr)

.. http://code.activestate.com/recipes/576836/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6435>
_______________________________________

From report at bugs.python.org  Thu Jul  9 10:11:51 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 09 Jul 2009 08:11:51 +0000
Subject: [issue6393] OS X: python3 from python-3.1.dmg crashes at startup
In-Reply-To: <1246445517.38.0.373229118664.issue6393@psf.upfronthosting.co.za>
Message-ID: <1247127111.8.0.545471928469.issue6393@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> There is validity in saying that 'LANG=utf-8' is an invalid setting

Agreed.  But that doesn't really explain why e.g. LANG=en_US also 
produces "", while LANG=invalid produces "US-ASCII".

> I do wonder how the user ended up with LANG=utf-8 in the first place.

Me too.  As far as I can gather, it's a result of setting the Terminal 
preferences (particularly the character encoding and 'Set LANG 
environment variable on startup' checkbox) in some particular way, on 
some versions of OS X, for users in some countries, at some particular 
phases of the moon, etc...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6393>
_______________________________________

From report at bugs.python.org  Thu Jul  9 10:12:46 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 09 Jul 2009 08:12:46 +0000
Subject: [issue6377] distutils compiler switch ignored
In-Reply-To: <1246299740.9.0.786372120366.issue6377@psf.upfronthosting.co.za>
Message-ID: <1247127166.06.0.880800959811.issue6377@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

The build_ext command cannot be run twice, because the first time, the
"compiler" option may be set to "unix" for example, or left to None, and
then is transformed into a compiler object. That's the bug.

If you call it again, it'll break because the new_compiler() function
will receive self.compiler, which is supposed to be a string not a
compiler object.

"compiler" is described as the "compiler type" in the options list of
build_ext and should receive a string value.

So what's broken is the fact that third-party code is using "compiler" 
as a compiler object attribute for years, because the command was
creating the compiler object on the compiler option, rather than using
its own attribute for that. And from an architectural point of view, if
you have to tweak the compiler options by tweaking them direclty, it
means that the build_ext command did a bad job with in the options
it provides.

For the cross-version incompatibility you are mentioning, it means that
your code is working with "compiler" as a string option, then continue
to work with it as a compiler object right after the command is run.
But either way, there will be an incompatibility starting at 3.3 because
we are going from the state "compiler is a string and also a compiler
object, depending on when you use it" to "compiler is a only string option"

This is an inconsistent behavior I am fixing here. While the code may be
more complex with the descriptor, this will eventually go away in 3.3
(and 2.8 if it exists).

What is the other solution you where thinking about ? adding a
compiler_type option and keep the compiler option woud introduce more
incompatibilities since "compiler" is used to configure build_ext by
many code out there, while tweaking the compiler object itself is an
advanced usage done by less people, which may do the same thing in an
easy way by using another attribute.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6377>
_______________________________________

From report at bugs.python.org  Thu Jul  9 10:31:25 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 09 Jul 2009 08:31:25 +0000
Subject: [issue6393] OS X: python3 from python-3.1.dmg crashes at startup
In-Reply-To: <1246445517.38.0.373229118664.issue6393@psf.upfronthosting.co.za>
Message-ID: <1247128285.84.0.312964773425.issue6393@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The attached patch (issue6393-fix.patch) seems to fix the issue.

Could you please test and have a look at the patch? It basicly tests if 
the output of nl_langinfo(CODESET) is the empty string and defaults to 
'UTF-8' in that case (but only on OSX).

I intent to apply this patch unless someone objects to that.

----------
keywords: +needs review, patch
Added file: http://bugs.python.org/file14476/issue6393-fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6393>
_______________________________________

From report at bugs.python.org  Thu Jul  9 10:47:56 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 09 Jul 2009 08:47:56 +0000
Subject: [issue6377] distutils compiler switch ignored
In-Reply-To: <1247127166.06.0.880800959811.issue6377@psf.upfronthosting.co.za>
Message-ID: <4A55AEB9.4030401@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Tarek Ziad? wrote:
> Tarek Ziad? <ziade.tarek at gmail.com> added the comment:
> 
> The build_ext command cannot be run twice, because the first time, the
> "compiler" option may be set to "unix" for example, or left to None, and
> then is transformed into a compiler object. That's the bug.
> 
> If you call it again, it'll break because the new_compiler() function
> will receive self.compiler, which is supposed to be a string not a
> compiler object.

You never run a command twice unless you explicitly reinitialize it
(which then resets .compiler to None and then fetches the command line
option again), so the above is not a problem.

> "compiler" is described as the "compiler type" in the options list of
> build_ext and should receive a string value.
> 
> So what's broken is the fact that third-party code is using "compiler" 
> as a compiler object attribute for years, because the command was
> creating the compiler object on the compiler option, rather than using
> its own attribute for that. And from an architectural point of view, if
> you have to tweak the compiler options by tweaking them direclty, it
> means that the build_ext command did a bad job with in the options
> it provides.

I agree that it's not exactly ideal to have an attribute first
be a string and then an object.

> For the cross-version incompatibility you are mentioning, it means that
> your code is working with "compiler" as a string option, then continue
> to work with it as a compiler object right after the command is run.

Not quite: extensions of build_ext will likely customize the
way the extension objects are built, ie. override .build_extensions()
which is called after .compiler has been set to the compiler instance.

So they always work with the compiler instance. And they don't really care
about the option at all, since all that information is available from
looking at the compiler object.

> But either way, there will be an incompatibility starting at 3.3 because
> we are going from the state "compiler is a string and also a compiler
> object, depending on when you use it" to "compiler is a only string option"
> 
> This is an inconsistent behavior I am fixing here. While the code may be
> more complex with the descriptor, this will eventually go away in 3.3
> (and 2.8 if it exists).
> 
> What is the other solution you where thinking about ? adding a
> compiler_type option and keep the compiler option woud introduce more
> incompatibilities since "compiler" is used to configure build_ext by
> many code out there, while tweaking the compiler object itself is an
> advanced usage done by less people, which may do the same thing in an
> easy way by using another attribute.

First of all, you only use a single compiler for building an
Python package, so using the global build compiler option will do
just fine (and is also required if you have other commands
rely on this information as well, such as the config command,
the build_clib command or other custom commands).

The "compiler" option on the build_ext and config commands
are not really needed. Their .finalize_options() methods could
easily pull in the build option value and place it into
an .compiler_type attribute which then gets used as basis for
creating the .compiler instance, or even better refactor the
various commands to use a central method on the build
command object to create a compiler object and avoid all
the copy&paste code for this.

Furthermore, the .finalize_options() methods could detect whether
a per-command option as used and deprecate this use instead,
redirecting to the build command option.

Please note that it's common practice in distutils to have
the compiler instance in an .compiler attribute, so either
you change it in all cases or not at all.

The fact that the options on some of those commands is
named --compiler as well, is rather unfortunate.

Regarding wide-spread use of the compiler command line option:
I am only aware of the cygwin/mingw32 case where you'd really
need it. In all other cases I know, the default choice based
on the compiler with which Python itself was compiled will
work fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6377>
_______________________________________

From report at bugs.python.org  Thu Jul  9 11:18:27 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 09 Jul 2009 09:18:27 +0000
Subject: [issue6377] distutils compiler switch ignored
In-Reply-To: <4A55AEB9.4030401@egenix.com>
Message-ID: <4A55B5DF.7000104@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

FWIW: I've changed our mxSetup code to use a method for accessing
the compiler instance.

Perhaps that's the better way to go for standard distutils commands
as well ?! E.g. .get_compiler_object()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6377>
_______________________________________

From report at bugs.python.org  Thu Jul  9 11:24:58 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 09 Jul 2009 09:24:58 +0000
Subject: [issue6443] _winreg.QueryValueEx confused on double null terminated
	strings
In-Reply-To: <1247109670.35.0.187157773378.issue6443@psf.upfronthosting.co.za>
Message-ID: <1247131498.09.0.377590653735.issue6443@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The double null is supposed to mark the end of the whole sequence; the
content you show under "PendingFileRenameOperations" is a invalid
REG_MULTI_SZ value to me.
How does regedit display it?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6443>
_______________________________________

From report at bugs.python.org  Thu Jul  9 11:25:26 2009
From: report at bugs.python.org (OG7)
Date: Thu, 09 Jul 2009 09:25:26 +0000
Subject: [issue5870] subprocess.DEVNULL
In-Reply-To: <1240946644.39.0.609275389725.issue5870@psf.upfronthosting.co.za>
Message-ID: <1247131526.59.0.195011445276.issue5870@psf.upfronthosting.co.za>


Changes by OG7 <onyxg7 at users.sourceforge.net>:


----------
nosy: +OG7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5870>
_______________________________________

From report at bugs.python.org  Thu Jul  9 11:29:53 2009
From: report at bugs.python.org (OG7)
Date: Thu, 09 Jul 2009 09:29:53 +0000
Subject: [issue6445] Add check parameter to subprocess.Popen.communicate
In-Reply-To: <1247131793.49.0.582429022768.issue6445@psf.upfronthosting.co.za>
Message-ID: <1247131793.49.0.582429022768.issue6445@psf.upfronthosting.co.za>


New submission from OG7 <onyxg7 at users.sourceforge.net>:

communicate is often used in one-liners, but becomes a four-liner if you
want to check the process exit status. Adding a check parameter would
make it more convenient to get things right and write non-buggy code.

The CalledProcessError requires a cmd argument, which means also adding
a cmd member to Popen objects.

----------
messages: 90318
nosy: OG7
severity: normal
status: open
title: Add check parameter to subprocess.Popen.communicate

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6445>
_______________________________________

From report at bugs.python.org  Thu Jul  9 11:40:35 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 09 Jul 2009 09:40:35 +0000
Subject: [issue6443] _winreg.QueryValueEx confused on double null terminated
	strings
In-Reply-To: <1247109670.35.0.187157773378.issue6443@psf.upfronthosting.co.za>
Message-ID: <1247132435.68.0.802370119291.issue6443@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

It seems that regedit itself cannot handle these values, see how users
have to edit data in binary mode to enter empty strings:
http://www.pcreview.co.uk/forums/thread-1715654.php

Here is a script that shows the problem: the value is returned truncated
before the empty string.

from _winreg import *
test_key_name = "SOFTWARE\\Python Registry Test Key - Delete Me"
hkey = CreateKey(HKEY_CURRENT_USER, test_key_name)
SetValueEx(hkey, "Multi", 0, REG_MULTI_SZ,
           ['test', 'with', '', 'an', 'empty', 'line'])
print QueryValueEx(hkey, "Multi")

----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6443>
_______________________________________

From report at bugs.python.org  Thu Jul  9 11:55:03 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 09 Jul 2009 09:55:03 +0000
Subject: [issue6393] OS X: python3 from python-3.1.dmg crashes at startup
In-Reply-To: <1246445517.38.0.373229118664.issue6393@psf.upfronthosting.co.za>
Message-ID: <1247133303.93.0.47639650763.issue6393@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks, Ronald!  The patch fixes the problem for me.
(I directly patched the locale.py file installed from
the Python dmg, since I still haven't figured out how
to build a python executable that exhibits this
problem.)

The patch doesn't look quite right, though: in the else clause,
it looks as though you're testing 'result' before it exists.
Shouldn't the 'result = nl_langinfo(CODESET)' line come
before the 'if not result and ....' line?

On the subject of Terminal and LANG, LC_CTYPE settings, I found an 
interesting link:

http://pastie.textmate.org/111807

Indeed, after setting my region to 'South Africa' in Preferences -> 
International -> Formats, a newly opened Terminal window gives me:

newton:~ dickinsm$ locale
LANG=
LC_COLLATE="C"
LC_CTYPE="UTF-8"
LC_MESSAGES="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_ALL=

And then python3 crashes on startup as above.  This is on a newborn (3-
week old) MacBook Pro that's been barely changed from default settings 
(and no transfer of files and settings from an old Mac, either).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6393>
_______________________________________

From report at bugs.python.org  Thu Jul  9 12:02:28 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 09 Jul 2009 10:02:28 +0000
Subject: [issue6435] logging: cache the traceback text on formatter,
	instead of record
In-Reply-To: <1247019484.09.0.843372167885.issue6435@psf.upfronthosting.co.za>
Message-ID: <1247133748.27.0.644493436822.issue6435@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> But the cache needs to be invalidated when `exc_info` is changed -
> as in set to None when it was a traceback object.

When does the exc_info change for a record? AFAIK it's set when you 
create a LogRecord, and that's it.

To be honest, I'm not sure why you need that specific recipe. Notice 
the comment made by a user against the recipe. But if you are set on 
doing it like this, then suppose I configure as follows:

Create a StreamHandler(sys.stderr) and a StreamHandler(sys.stdout).
Create a Formatter and attach it to the output handler.
Create a Formatter with the format string used above but with 
an "error:" prefix, and attach it to the error handler.
Add a Filter to each handler. This can be a single Filter class which 
either passes everything above a threshold or everything below a 
threshold. This will only have a few lines of code. Attach two such 
instances, suitably configured, to the appropriate handlers.
Attach both handlers to the root logger (or some other logger).

How will this differ in its effect from your recipe?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6435>
_______________________________________

From report at bugs.python.org  Thu Jul  9 12:10:59 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 09 Jul 2009 10:10:59 +0000
Subject: [issue6333] logging: ValueError: I/O operation on closed file
In-Reply-To: <1245807768.39.0.536701423847.issue6333@psf.upfronthosting.co.za>
Message-ID: <1247134259.9.0.0900667474527.issue6333@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> Shouldn't the logging module be reliable in such cases?

It tries to be, but it's neither omnipotent nor omniscient. It doesn't 
expect streams which it's using to be closed out from under it.

See my comments about your ConsoleHandler recipe(s) on issue6345. Sorry 
if it seems I'm trying to rain on your parade - I'm just calling it as 
I see it.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6333>
_______________________________________

From report at bugs.python.org  Thu Jul  9 12:16:10 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 09 Jul 2009 10:16:10 +0000
Subject: [issue6393] OS X: python3 from python-3.1.dmg crashes at startup
In-Reply-To: <1246445517.38.0.373229118664.issue6393@psf.upfronthosting.co.za>
Message-ID: <1247134570.56.0.80692027515.issue6393@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Good catch, the code in the else is indeed in the wrong order.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6393>
_______________________________________

From report at bugs.python.org  Thu Jul  9 12:47:46 2009
From: report at bugs.python.org (holger krekel)
Date: Thu, 09 Jul 2009 10:47:46 +0000
Subject: [issue6333] logging: ValueError: I/O operation on closed file
In-Reply-To: <1245807768.39.0.536701423847.issue6333@psf.upfronthosting.co.za>
Message-ID: <1247136466.51.8.5141820455e-06.issue6333@psf.upfronthosting.co.za>


holger krekel <holger.krekel at gmail.com> added the comment:

I think the issue is unrelated to py.test - it just presents a use case
as it wants to run 1000's of tests and capture stdout/stderr per each
test function, cannot guess about a test's logging-usage yet wants to
minimize memory/resource usage and close any temporary files it opens.  

Anyway, a standalone minimal example involving the issue is this:

import logging
import StringIO
stream = StringIO.StringIO()
logging.basicConfig(stream=stream)
stream.close() # to free memory/release resources

At exit logging's shutdown() will try to flush/close resulting in an
exception.  Is it a problem to have the logging module be a bit more
defensive and only try a flush/close if the stream isn't already closed?

----------
nosy: +hpk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6333>
_______________________________________

From report at bugs.python.org  Thu Jul  9 13:31:48 2009
From: report at bugs.python.org (Julian Andres Klode)
Date: Thu, 09 Jul 2009 11:31:48 +0000
Subject: [issue6446] import_spam() in extending python can fail without
	setting the error.
In-Reply-To: <1247139108.9.0.128424367437.issue6446@psf.upfronthosting.co.za>
Message-ID: <1247139108.9.0.128424367437.issue6446@psf.upfronthosting.co.za>


New submission from Julian Andres Klode <jak at jak-linux.org>:

The given example function initspam fails if an 

Based on some experience with my own code, I have found out that the
function import_spam() fails when the module is not importable. In this
case, it returns 0, although it should return -1 when an error occurs.

This causes a standalone program to crash if it has a main() function like:

    Py_Initialize();
    if (import_spam() < 0) {
        Py_Finalize();
        return 1;
    }
    Py_Finalize();

The function should return -1, so we can know there is an error and are
able to handle it.

----------
assignee: georg.brandl
components: Documentation
messages: 90325
nosy: georg.brandl, jak
severity: normal
status: open
title: import_spam() in extending python can fail without setting the error.
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6446>
_______________________________________

From report at bugs.python.org  Thu Jul  9 14:21:43 2009
From: report at bugs.python.org (Alexey Shamrin)
Date: Thu, 09 Jul 2009 12:21:43 +0000
Subject: [issue6414] struct module : processor endianness descriptions
	misleading
In-Reply-To: <1246693590.67.0.013392500744.issue6414@psf.upfronthosting.co.za>
Message-ID: <1247142103.41.0.132757166652.issue6414@psf.upfronthosting.co.za>


Alexey Shamrin <shamrin at gmail.com> added the comment:

Good suggestions, Mark! We should do both, I think. I didn't know about
sys.byteorder before your message ;-) Thanks for education!

How about this:

"Native byte order is big-endian or little-endian, depending on the host 
system. For example, Intel x86 and AMD64 (x86-64) are little-endian;
Motorola 68000 and PowerPC G5 are big-endian; some are even bi-endian
(switchable endianess) - ARM and DEC Alpha. Use sys.byteorder to check
the endianess of your system."

Sorry for any spelling and styling mistakes...

----------
nosy: +ash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6414>
_______________________________________

From report at bugs.python.org  Thu Jul  9 14:24:21 2009
From: report at bugs.python.org (Alexey Shamrin)
Date: Thu, 09 Jul 2009 12:24:21 +0000
Subject: [issue6414] struct module : processor endianness descriptions
	misleading
In-Reply-To: <1246693590.67.0.013392500744.issue6414@psf.upfronthosting.co.za>
Message-ID: <1247142261.65.0.517272627989.issue6414@psf.upfronthosting.co.za>


Alexey Shamrin <shamrin at gmail.com> added the comment:

Little style:

"Native byte order is big-endian or little-endian, depending on the host 
system. For example, Intel x86 and AMD64 (x86-64) are little-endian;
Motorola 68000 and PowerPC G5 are big-endian; ARM and DEC Alpha feature
switchable endianness (bi-endian). Use sys.byteorder to check the
endianess of your system."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6414>
_______________________________________

From report at bugs.python.org  Thu Jul  9 15:48:28 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 09 Jul 2009 13:48:28 +0000
Subject: [issue6333] logging: ValueError: I/O operation on closed file
In-Reply-To: <1245807768.39.0.536701423847.issue6333@psf.upfronthosting.co.za>
Message-ID: <1247147308.48.0.357012194202.issue6333@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> Is it a problem to have the logging module be a bit more defensive and
> only try a flush/close if the stream isn't already closed?

Not particularly, but it would be better if the following approach were
taken:

import logging
import StringIO
stream = StringIO.StringIO()
h = logging.StreamHandler(stream)
r = logging.getLogger()
r.addHandler(h)
#Do your testing work
r.removeHandler(h)
h.close() # closes underlying stream, also removes logging refs to h

It should be understood that if a stream is passed to a StreamHandler,
the ownership of that stream is passed as well, so closing the handler
rather than the underlying stream is the right thing to do. ISTM this is
good practice in general and not exclusive to logging.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6333>
_______________________________________

From report at bugs.python.org  Thu Jul  9 16:00:51 2009
From: report at bugs.python.org (Jan Lieskovsky)
Date: Thu, 09 Jul 2009 14:00:51 +0000
Subject: [issue5753] CVE-2008-5983 python: untrusted python modules search path
In-Reply-To: <1239709179.65.0.173847743531.issue5753@psf.upfronthosting.co.za>
Message-ID: <1247148051.5.0.834921092426.issue5753@psf.upfronthosting.co.za>


Jan Lieskovsky <iankko at seznam.cz> added the comment:

Hello guys,

  what's the current state of this issue? The proposed patch hasn't
still been projected into upstream Python code, so wondering:
1, when and if it will be?
2, if you have found another solution / patch?

Thanks && Regards, Jan.
--
Jan iankko Lieskovsky

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5753>
_______________________________________

From report at bugs.python.org  Thu Jul  9 16:07:42 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 09 Jul 2009 14:07:42 +0000
Subject: [issue5753] CVE-2008-5983 python: untrusted python modules search path
In-Reply-To: <1247148051.5.0.834921092426.issue5753@psf.upfronthosting.co.za>
Message-ID: <1247148621.5439.9.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hello,

>   what's the current state of this issue? The proposed patch hasn't
> still been projected into upstream Python code, so wondering:
> 1, when and if it will be?

I was hoping for more feedback before committing it. While it has been
labeled a security issue, not many people seem to actually care. Distro
maintainers doing their own patching without communicating with us
doesn't help either.

> 2, if you have found another solution / patch?

If it were so this bug would have been closed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5753>
_______________________________________

From report at bugs.python.org  Thu Jul  9 16:27:33 2009
From: report at bugs.python.org (Yinon Ehrlich)
Date: Thu, 09 Jul 2009 14:27:33 +0000
Subject: [issue6447] PATCH: typo (English) in subprocess module
Message-ID: <1247149653.39.0.921151734241.issue6447@psf.upfronthosting.co.za>


Changes by Yinon Ehrlich <yinoneh at users.sourceforge.net>:


----------
components: Library (Lib)
files: subprocess.patch
keywords: patch
nosy: Yinon
severity: normal
status: open
title: PATCH: typo (English) in subprocess module
versions: Python 2.7
Added file: http://bugs.python.org/file14477/subprocess.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6447>
_______________________________________

From report at bugs.python.org  Thu Jul  9 16:54:28 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 09 Jul 2009 14:54:28 +0000
Subject: [issue816059] popen2 work, fixes bugs 768649 and 761888
Message-ID: <1247151268.81.0.501012209018.issue816059@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

OTOH, the test code runs fine with python 2.4.4, so what is the purpose
of this patch?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue816059>
_______________________________________

From report at bugs.python.org  Thu Jul  9 17:02:13 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 09 Jul 2009 15:02:13 +0000
Subject: [issue5191] Partial function application 'from the right'
In-Reply-To: <1234187960.68.0.343533185797.issue5191@psf.upfronthosting.co.za>
Message-ID: <1247151733.15.0.380231935917.issue5191@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Closing as requested.

----------
nosy: +amaury.forgeotdarc
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5191>
_______________________________________

From report at bugs.python.org  Thu Jul  9 17:07:26 2009
From: report at bugs.python.org (Jordan Bettis)
Date: Thu, 09 Jul 2009 15:07:26 +0000
Subject: [issue6448] imp.find_module() -- be explicity that 'path' must be a
	list
In-Reply-To: <1247152045.93.0.157775961524.issue6448@psf.upfronthosting.co.za>
Message-ID: <1247152045.93.0.157775961524.issue6448@psf.upfronthosting.co.za>


New submission from Jordan Bettis <jordanb at hafdconsulting.com>:

Hi. I just spent a while fighting with imp.find_module because I was
trying to pass the path as a string, rather than a string embedded in a
list:

result = find_module('mod', '/path')

rather than

result = find_module('mod', ['/path'])

The issue is compounded by an incredibly unhelpful error message:

ImportError: No frozen submodule named /path.mod

Now the documentation *does* say that path should be a list, if you read
it carefully, so perhaps it was just my reading comprehension. But doing
a google search I found a discussion from 2006 along the same lines:

http://www.techlists.org/archives/programming/pythonlist/2006-01/msg01445.shtml

So I thought it might be good to clarify that a string will not work.
Perhaps the wording could be changed to something like this:


   Try to find the module *name* on the search path *path*.  The
   *path* argument is a list of directory names. Each directory is
   searched for files with any of the suffixes returned
   by :func:`get_suffixes` above.  Invalid names in the list are
   silently ignored (but all list items must be strings).  If
   *path* is omitted or ``None``, the list of directory names
   given by ``sys.path`` is searched, but first it searches a few
   special places: it tries to find a built-in module with the
   given name (:const:`C_BUILTIN`), then a frozen
   module (:const:`PY_FROZEN`), and on some systems some other
   places are looked in as well (on Windows, it looks in the
   registry which may point to a specific file).

I think what is confusing is the conditional about the type of 'path',
The possibilities are 'list' or 'not present' (or None) but when I read
it I think I saw the 'not present' option as being implicit, and the
conditional implying that it could be a string or a list of strings.
>From the discussion above it seems like the other person had the same
trouble, so removing the conditional should be enough to make it clear
that path *must* be a list if it exists.

----------
assignee: georg.brandl
components: Documentation
messages: 90333
nosy: georg.brandl, jordanb
severity: normal
status: open
title: imp.find_module() -- be explicity that 'path' must be a list
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6448>
_______________________________________

From report at bugs.python.org  Thu Jul  9 17:50:56 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 09 Jul 2009 15:50:56 +0000
Subject: [issue6414] struct module : processor endianness descriptions
	misleading
In-Reply-To: <1246693590.67.0.013392500744.issue6414@psf.upfronthosting.co.za>
Message-ID: <1247154656.46.0.955282524468.issue6414@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee: georg.brandl -> rhettinger
nosy: +rhettinger
versions: +Python 3.2 -Python 2.5, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6414>
_______________________________________

From report at bugs.python.org  Thu Jul  9 19:07:03 2009
From: report at bugs.python.org (Nicolas Dumazet)
Date: Thu, 09 Jul 2009 17:07:03 +0000
Subject: [issue6377] distutils compiler switch ignored
In-Reply-To: <1246299740.9.0.786372120366.issue6377@psf.upfronthosting.co.za>
Message-ID: <1247159223.14.0.125433179816.issue6377@psf.upfronthosting.co.za>


Nicolas Dumazet <nicdumz at gmail.com> added the comment:

It seems that the fix is still not perfect.

At the moment ( r73906 ), if you try to build trunk using Python 2.6,
you get:

> python setup.py build
running build
running build_ext
Traceback (most recent call last):
  File "setup.py", line 1901, in <module>
    main()
  File "setup.py", line 1896, in main
    'Lib/smtpd.py']
  File "/usr/lib/python2.6/distutils/core.py", line 152, in setup
    dist.run_commands()
  File "/usr/lib/python2.6/distutils/dist.py", line 975, in run_commands
    self.run_command(cmd)
  File "/usr/lib/python2.6/distutils/dist.py", line 995, in run_command
    cmd_obj.run()
  File "/usr/lib/python2.6/distutils/command/build.py", line 135, in run
    self.run_command(cmd_name)
  File "/usr/lib/python2.6/distutils/cmd.py", line 333, in run_command
    self.distribution.run_command(command)
  File "/usr/lib/python2.6/distutils/dist.py", line 995, in run_command
    cmd_obj.run()
  File "/usr/lib/python2.6/distutils/command/build_ext.py", line 345, in run
    self.build_extensions()
  File "setup.py", line 103, in build_extensions
    missing = self.detect_modules()
  File "setup.py", line 302, in detect_modules
    add_dir_to_list(self.compiler_obj.library_dirs, '/usr/local/lib')
  File "/usr/lib/python2.6/distutils/cmd.py", line 112, in __getattr__
    raise AttributeError, attr
AttributeError: compiler_obj

----------
nosy: +nicdumz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6377>
_______________________________________

From report at bugs.python.org  Thu Jul  9 19:32:08 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 09 Jul 2009 17:32:08 +0000
Subject: [issue6416] Failed to compile selectmodule.c on windows (trunk)
In-Reply-To: <1246706675.4.0.617951670977.issue6416@psf.upfronthosting.co.za>
Message-ID: <1247160728.98.0.32521677411.issue6416@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This constant was introduced in r73818 by Gregory, so I'm assigning this
ticket to him.  Note that the trunk Windows buildbot is also failing to
compile because of this bug.

----------
assignee:  -> gregory.p.smith
components: +Library (Lib) -Windows
keywords: +easy
nosy: +gregory.p.smith, r.david.murray
priority: high -> critical
stage:  -> needs patch
type:  -> compile error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6416>
_______________________________________

From report at bugs.python.org  Thu Jul  9 19:39:19 2009
From: report at bugs.python.org (Tomas Hoger)
Date: Thu, 09 Jul 2009 17:39:19 +0000
Subject: [issue5753] CVE-2008-5983 python: untrusted python modules search path
In-Reply-To: <1239709179.65.0.173847743531.issue5753@psf.upfronthosting.co.za>
Message-ID: <1247161159.86.0.531684680361.issue5753@psf.upfronthosting.co.za>


Tomas Hoger <thoger at redhat.com> added the comment:

Have you considered something like this? (patch against 3.1)

--- Python/sysmodule.c.orig
+++ Python/sysmodule.c
@@ -1643,6 +1643,7 @@ PySys_SetArgv(int argc, wchar_t **argv)
 #endif /* Unix */
 		}
 #endif /* All others */
+		if (n > 0 || argv0 == NULL || wcscmp(argv0, L"-c") == 0) {
 		a = PyUnicode_FromWideChar(argv0, n);
 		if (a == NULL)
 			Py_FatalError("no mem for sys.path insertion");
@@ -1650,6 +1651,7 @@ PySys_SetArgv(int argc, wchar_t **argv)
 			Py_FatalError("sys.path.insert(0) failed");
 		Py_DECREF(a);
+		}
 	}
 	Py_DECREF(av);
 }

I presume main problem here is that '' may end up as first item in
sys.path in certain cases.

That is desired in some cases, namely:
- python run in interactive mode
- python -c '...'

It does not happen and is not desired in other cases:
- ./foo.py
- python foo.py
- env python foo.py

Here foo.py can be just filename or filename with relative or absolute
path.  In all these cases python seems to set argv0 to something
realpath can resolve.

Problematic case is embedded use when bogus argv0 can cause '' to be
added to sys.path, but it's usually not desired / expected (is anyone
aware of the case when that is expected?).  It can be argued whether
apps should use garbage as argv0, but example in Demo/embed/demo.c do it
as well...

Patch above attempts to skip modification of sys.path when realpath
failed (n == 0).  There are two special cases, that are treated as
special on couple of other places in PySys_SetArgv already:
- argv0 == NULL (interactive python)
- argv0 == "-c" (python -c)

This should fix the problem for apps embedding python and providing
garbage argv0.  It would not make a difference for apps that provide
some valid path as argv0.  I'm not aware of non-embedded python use that
will end up with different sys.path after this patch.

Ideas?  Anyone is aware of the valid usecase that can break with this?

Advantage to Ex approach is that it does not require change on the
embedding apps side, and should really impact only those setting garbage
argv0.

----------
nosy: +thoger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5753>
_______________________________________

From report at bugs.python.org  Thu Jul  9 19:53:53 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 09 Jul 2009 17:53:53 +0000
Subject: [issue6416] Failed to compile selectmodule.c on windows (trunk)
In-Reply-To: <1246706675.4.0.617951670977.issue6416@psf.upfronthosting.co.za>
Message-ID: <1247162033.56.0.543806447299.issue6416@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I found this article that might be of interest with regards to PIPE_BUF
(or rather lack thereof) on Windows:

http://cygwin.com/ml/cygwin-patches/2004-q3/msg00084.html

It doesn't look like "doing the right thing" in Windows where in Posix
you would use PIPE_BUF is particularly easy, but that doesn't really
impact fixing the compile error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6416>
_______________________________________

From report at bugs.python.org  Thu Jul  9 20:14:23 2009
From: report at bugs.python.org (David Schnur)
Date: Thu, 09 Jul 2009 18:14:23 +0000
Subject: [issue2504] Add gettext.pgettext() and variants support
In-Reply-To: <1206756624.13.0.664664048525.issue2504@psf.upfronthosting.co.za>
Message-ID: <1247163263.21.0.491390922301.issue2504@psf.upfronthosting.co.za>


David Schnur <david.schnur at dartware.com> added the comment:

I came across this ticket while looking for alternatives to Python's
gettext, since I need msgctx support.  It seems a patch was supplied for
this a while back.  I have never contributed to Python, and am not
familiar with your release process, but is there anything preventing its
inclusion?  It would be very convenient to have this in a release version.

----------
nosy: +DNS

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2504>
_______________________________________

From report at bugs.python.org  Thu Jul  9 20:31:25 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 09 Jul 2009 18:31:25 +0000
Subject: [issue2504] Add gettext.pgettext() and variants support
In-Reply-To: <1206756624.13.0.664664048525.issue2504@psf.upfronthosting.co.za>
Message-ID: <1247164285.18.0.639112827197.issue2504@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Only my lack of time prevents inclusion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2504>
_______________________________________

From report at bugs.python.org  Thu Jul  9 20:43:54 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 09 Jul 2009 18:43:54 +0000
Subject: [issue6449] Improve/update python.org/dev/
In-Reply-To: <1247165034.18.0.173554225695.issue6449@psf.upfronthosting.co.za>
Message-ID: <1247165034.18.0.173554225695.issue6449@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

Reading python.org/dev/ I noticed a few things that could be
improved/updated:
1) in http://www.python.org/dev/implementations/ Unladen Swallow is missing;
2) in http://www.python.org/dev/contributing/ there's an "any and any"
that should probably be "any and all";
3) in the same page, in the "fixing bugs" section, there are some
**..**, is that some ReST markup that was not supposed to be there?
4) in http://www.python.org/dev/intro/ the IRC channels are not
mentioned (#python, #python-dev, #python-docs);
5) in the same page there's an XXX that should be fixed;
6) in the following line there's a "what ever" that should probably be
"whatever";
7) always there, a link to http://www.python.org/psf/donations/ should
be added in the second last paragraph;
8) in http://www.python.org/dev/buildbot/ there should probably be 3.2
in "(what will become 3.1)";
9) is http://www.python.org/dev/summary/ still alive?
10) in the last list of links in http://www.python.org/dev/ the trailing
'/' are missing, but they are present in the menu on the left;

(I'm not sure this is the right place where to report this.)

----------
assignee: georg.brandl
components: Documentation
keywords: easy
messages: 90340
nosy: ezio.melotti, georg.brandl
priority: low
severity: normal
status: open
title: Improve/update python.org/dev/

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6449>
_______________________________________

From report at bugs.python.org  Thu Jul  9 20:49:56 2009
From: report at bugs.python.org (Erik Sandberg)
Date: Thu, 09 Jul 2009 18:49:56 +0000
Subject: [issue6450] normpath() sometimes maps unicode to str
In-Reply-To: <1247165396.23.0.921821362773.issue6450@psf.upfronthosting.co.za>
Message-ID: <1247165396.23.0.921821362773.issue6450@psf.upfronthosting.co.za>


New submission from Erik Sandberg <sandberg at virtutech.com>:

On Linux, I get the following:

>>> import os
>>> os.path.normpath(u'/')
'/'

I would expect unicode to be mapped to unicode. os.path.abspath() has
the same problem, see also issue 3426.

This causes problems in my project, where a function requires its
parameters to be Unicode. Do the standard Python library functions that
operate on strings guarantee anything in general with respect to
conserving unicode? Can I make any assumption as to which codec was used
to encode the str returned from normpath?

----------
components: Library (Lib)
messages: 90341
nosy: sandberg
severity: normal
status: open
title: normpath() sometimes maps unicode to str
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6450>
_______________________________________

From report at bugs.python.org  Thu Jul  9 20:51:01 2009
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 09 Jul 2009 18:51:01 +0000
Subject: [issue6449] Improve/update python.org/dev/
In-Reply-To: <1247165034.18.0.173554225695.issue6449@psf.upfronthosting.co.za>
Message-ID: <1247165461.13.0.992358932399.issue6449@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Technically pydotorg at python.org is the proper place to report this stuff, 
but it's not a big deal as I unofficially in charge of /dev so I will take 
care of it.

----------
assignee: georg.brandl -> brett.cannon
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6449>
_______________________________________

From report at bugs.python.org  Thu Jul  9 21:02:07 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 09 Jul 2009 19:02:07 +0000
Subject: [issue6450] normpath() sometimes maps unicode to str
In-Reply-To: <1247165396.23.0.921821362773.issue6450@psf.upfronthosting.co.za>
Message-ID: <1247166127.72.0.849367522964.issue6450@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
components: +Unicode
nosy: +ezio.melotti
priority:  -> normal
stage:  -> test needed
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6450>
_______________________________________

From report at bugs.python.org  Thu Jul  9 21:02:58 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 09 Jul 2009 19:02:58 +0000
Subject: [issue6450] normpath() sometimes maps unicode to str
In-Reply-To: <1247165396.23.0.921821362773.issue6450@psf.upfronthosting.co.za>
Message-ID: <4A563EDE.4070307@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Do the standard Python library functions that
> operate on strings guarantee anything in general with respect to
> conserving unicode? Can I make any assumption as to which codec was used
> to encode the str returned from normpath?

The bug tracker is not really a place to ask questions. Please ask them
on python-list or elsewhere, or read the source code of normpath.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6450>
_______________________________________

From report at bugs.python.org  Thu Jul  9 21:33:46 2009
From: report at bugs.python.org (holger krekel)
Date: Thu, 09 Jul 2009 19:33:46 +0000
Subject: [issue6333] logging: ValueError: I/O operation on closed file
In-Reply-To: <1245807768.39.0.536701423847.issue6333@psf.upfronthosting.co.za>
Message-ID: <1247168026.63.0.0731198297991.issue6333@psf.upfronthosting.co.za>


holger krekel <holger.krekel at gmail.com> added the comment:

To recap the use case: stdout is redirected during a test function run
which might trigger arbitrary usage of logging-functionality.  Not
closing the temporary file would mean that there could be as many open
files as there are test functions - or one needs to rely on garbage
collection for closing the resource - this is generally considered bad
practise.  So I consider it best practise to do resource cleanup
immediately and close the temp file.  

Note that the test tool *does not touch the logging module at all*, and
it has no way to mandate the usage of the logging module like you suggest.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6333>
_______________________________________

From report at bugs.python.org  Thu Jul  9 21:56:33 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 09 Jul 2009 19:56:33 +0000
Subject: [issue6333] logging: ValueError: I/O operation on closed file
In-Reply-To: <1247147308.48.0.357012194202.issue6333@psf.upfronthosting.co.za>
Message-ID: <op.uwtgbpffbrrvlq@double>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

On Thu, 09 Jul 2009 06:48:28 -0700, Vinay Sajip <report at bugs.python.org>  
wrote:

> It should be understood that if a stream is passed to a StreamHandler,
> the ownership of that stream is passed as well, so closing the handler
> rather than the underlying stream is the right thing to do. ISTM this is
> good practice in general and not exclusive to logging.

However, sys.stdout|err can be assigned to some thing else (eg: py.test  
assigning it to an open file object) .. in which case it is legitimate to  
handle (close) such objects (handles) by who created it (py.test).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6333>
_______________________________________

From report at bugs.python.org  Thu Jul  9 21:58:48 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 09 Jul 2009 19:58:48 +0000
Subject: [issue6333] logging: ValueError: I/O operation on closed file
In-Reply-To: <1245807768.39.0.536701423847.issue6333@psf.upfronthosting.co.za>
Message-ID: <1247169528.73.0.991178705281.issue6333@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

> See my comments about your ConsoleHandler recipe(s) on issue6345

Correction: issue6435

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6333>
_______________________________________

From report at bugs.python.org  Thu Jul  9 22:02:41 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 09 Jul 2009 20:02:41 +0000
Subject: [issue6435] logging: cache the traceback text on formatter,
	instead of record
In-Reply-To: <1247133748.27.0.644493436822.issue6435@psf.upfronthosting.co.za>
Message-ID: <op.uwtglvldbrrvlq@double>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

> Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:
>
>> But the cache needs to be invalidated when `exc_info` is changed -
>> as in set to None when it was a traceback object.
>
> When does the exc_info change for a record? AFAIK it's set when you
> create a LogRecord, and that's it.

Ok.

> To be honest, I'm not sure why you need that specific recipe. Notice
> the comment made by a user against the recipe.

I've responded as well .. that will explain why I need this specific  
recipe.

> But if you are set on
> doing it like this, then suppose I configure as follows:
>
> Create a StreamHandler(sys.stderr) and a StreamHandler(sys.stdout).
> Create a Formatter and attach it to the output handler.
> Create a Formatter with the format string used above but with
> an "error:" prefix, and attach it to the error handler.
> Add a Filter to each handler. This can be a single Filter class which
> either passes everything above a threshold or everything below a
> threshold. This will only have a few lines of code. Attach two such
> instances, suitably configured, to the appropriate handlers.
> Attach both handlers to the root logger (or some other logger).
>
> How will this differ in its effect from your recipe?

Actually, I did not know about 'Filter' until now. I will give it a try  
sometime.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6435>
_______________________________________

From report at bugs.python.org  Thu Jul  9 22:08:44 2009
From: report at bugs.python.org (Andrew Ziem)
Date: Thu, 09 Jul 2009 20:08:44 +0000
Subject: [issue6443] _winreg.QueryValueEx confused on double null terminated
	strings
In-Reply-To: <1247109670.35.0.187157773378.issue6443@psf.upfronthosting.co.za>
Message-ID: <1247170124.81.0.432237442461.issue6443@psf.upfronthosting.co.za>


Andrew Ziem <ahz001 at gmail.com> added the comment:

Attached screenshot shows regedit handles \x00\x00 by showing all the
"invalid values" (each \x00 becomes a line break).  More importantly,
Windows apparently reads all the "invalid value" when processing
FileRenameOperations, so my Python program must be able to read "invalid
value" to append new instructions.

----------
Added file: http://bugs.python.org/file14478/regedit_screenshot.PNG

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6443>
_______________________________________

From report at bugs.python.org  Thu Jul  9 22:16:05 2009
From: report at bugs.python.org (Vasiliy)
Date: Thu, 09 Jul 2009 20:16:05 +0000
Subject: [issue6451] Additional brackets to print
In-Reply-To: <1247170565.19.0.652670356582.issue6451@psf.upfronthosting.co.za>
Message-ID: <1247170565.19.0.652670356582.issue6451@psf.upfronthosting.co.za>


New submission from Vasiliy <bazooka at megabox.ru>:

from __future__ import print_function
    print('Foo','Bar')
    print('FooBar')

2to3 translates it to

    print(('Foo','Bar'))
    print('FooBar')

is it right?

----------
components: 2to3 (2.x to 3.0 conversion tool)
files: test.py
messages: 90349
nosy: bazooka
severity: normal
status: open
title: Additional brackets to print
type: behavior
Added file: http://bugs.python.org/file14479/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6451>
_______________________________________

From report at bugs.python.org  Thu Jul  9 22:16:48 2009
From: report at bugs.python.org (Vasiliy)
Date: Thu, 09 Jul 2009 20:16:48 +0000
Subject: [issue6451] 2to3 adds additional brackets to print
In-Reply-To: <1247170565.19.0.652670356582.issue6451@psf.upfronthosting.co.za>
Message-ID: <1247170608.48.0.219291168827.issue6451@psf.upfronthosting.co.za>


Changes by Vasiliy <bazooka at megabox.ru>:


----------
title: Additional brackets to print -> 2to3 adds additional brackets to print

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6451>
_______________________________________

From report at bugs.python.org  Thu Jul  9 22:17:27 2009
From: report at bugs.python.org (Vasiliy)
Date: Thu, 09 Jul 2009 20:17:27 +0000
Subject: [issue6451] 2to3 adds spare brackets to print
In-Reply-To: <1247170565.19.0.652670356582.issue6451@psf.upfronthosting.co.za>
Message-ID: <1247170647.9.0.473443374591.issue6451@psf.upfronthosting.co.za>


Changes by Vasiliy <bazooka at megabox.ru>:


----------
title: 2to3 adds additional brackets to print -> 2to3 adds spare brackets to print

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6451>
_______________________________________

From report at bugs.python.org  Thu Jul  9 22:25:27 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 09 Jul 2009 20:25:27 +0000
Subject: [issue6451] 2to3 adds spare brackets to print
In-Reply-To: <1247170565.19.0.652670356582.issue6451@psf.upfronthosting.co.za>
Message-ID: <1247171127.24.0.411005212619.issue6451@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This is a duplicate of Issue6429.

----------
nosy: +r.david.murray
priority:  -> normal
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> 2to3: fix_future conflicts with fix_print

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6451>
_______________________________________

From report at bugs.python.org  Thu Jul  9 22:26:52 2009
From: report at bugs.python.org (Jamal Fanaian)
Date: Thu, 09 Jul 2009 20:26:52 +0000
Subject: [issue6452] urllib2.Request() will not work with long authorization
	headers
In-Reply-To: <1247171212.16.0.153578290973.issue6452@psf.upfronthosting.co.za>
Message-ID: <1247171212.16.0.153578290973.issue6452@psf.upfronthosting.co.za>


New submission from Jamal Fanaian <jfanaian at gmail.com>:

While testing this bug report in Gwibber
https://bugs.launchpad.net/gwibber/+bug/397297 I found that using
urllib2.Request() with a long authorization would cause it to error and
not authenticate. I'm not sure if it is because the header wasn't being
passed or any other issue.

The header would fail when the value part of the authorization string
was 89 characters.

I was able to resolve the issue by using urllib2.HTTPBasicAuthHandler()
and urllib2.install_opener() to install it, instead of passing the
Authorization header directly to urllib2.Request().

Please let me know if I can provide more information to test the issue.

----------
components: Library (Lib)
messages: 90351
nosy: jamal
severity: normal
status: open
title: urllib2.Request() will not work with long authorization headers
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6452>
_______________________________________

From report at bugs.python.org  Thu Jul  9 22:26:53 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 09 Jul 2009 20:26:53 +0000
Subject: [issue6429] 2to3: fix_future conflicts with fix_print
In-Reply-To: <1246900395.55.0.0522093786653.issue6429@psf.upfronthosting.co.za>
Message-ID: <1247171213.03.0.314262742605.issue6429@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

See also issue 2412, which might or might not have a relevant patch.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6429>
_______________________________________

From report at bugs.python.org  Thu Jul  9 22:31:53 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 09 Jul 2009 20:31:53 +0000
Subject: [issue4506] 3.0 make test failures on Solaris 10
In-Reply-To: <18742.62305.106334.384352@montanaro-dyndns-org.local>
Message-ID: <1247171513.45.0.331542746702.issue4506@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

NB: I fixed the test_posix failure on trunk/2.6/py3k/3.1 in r73908,
r73914, r73913, and r73915.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4506>
_______________________________________

From report at bugs.python.org  Thu Jul  9 22:49:05 2009
From: report at bugs.python.org (nestor)
Date: Thu, 09 Jul 2009 20:49:05 +0000
Subject: [issue6348] solaris/aix: Py_Initialize: can't initialize sys standard
	streams
In-Reply-To: <1246060162.58.0.439928346048.issue6348@psf.upfronthosting.co.za>
Message-ID: <1247172545.79.0.562419257696.issue6348@psf.upfronthosting.co.za>


nestor <nestornissen at gmail.com> added the comment:

Maybe make test will help troubleshoot this (BTW how do I enable verbose
mode?):

test test_ascii_formatd failed -- errors occurred; run in verbose mode
for details
test_cmath
test test_cmath failed -- Traceback (most recent call last):
  File
"/datawhse/test/data/export/ptst/Python-3.1/Lib/test/test_cmath.py",
line 362, in test_specific_values
    self.fail(error_message)
AssertionError: atan0000: atan(complex(0.0, 0.0))
Expected: complex(0.0, 0.0)
Received: complex(0.0, -0.0)
Received value insufficiently close to expected value.
test_cmd_line
test test_cmd_line failed -- errors occurred; run in verbose mode for
details
test_cmd_line_script
test test_cmd_line_script failed -- errors occurred; run in verbose mode
for details
test_code
test_distutils
Exception AttributeError: "'_Stream' object has no attribute 'cmp'" in
<bound method _Stream.__del__ of <tarfile._Stream object at 0x218c2d70>>
ignored
Exception AttributeError: "'_Stream' object has no attribute 'cmp'" in
<bound method _Stream.__del__ of <tarfile._Stream object at 0x21763bf0>>
ignored
unable to execute cc_r: No such file or directory
unable to execute cc_r: No such file or directory
unable to execute cc_r: No such file or directory
Exception AttributeError: "'_Stream' object has no attribute 'cmp'" in
<bound method _Stream.__del__ of <tarfile._Stream object at 0x21a3fc30>>
ignored
Exception AttributeError: "'_Stream' object has no attribute 'cmp'" in
<bound method _Stream.__del__ of <tarfile._Stream object at 0x21a3fdd0>>
ignored
test test_distutils failed -- errors occurred; run in verbose mode for
details
test_fileio
test test_fileio failed -- Traceback (most recent call last):
  File
"/datawhse/test/data/export/ptst/Python-3.1/Lib/test/test_fileio.py",
line 262, in testAbles
    self.assertEquals(f.seekable(), False)
AssertionError: True != False
test_httpservers
Fatal Python error: Py_Initialize: can't initialize sys standard streams
AttributeError: '_io.FileIO' object has no attribute 'raw'
Fatal Python error: Py_Initialize: can't initialize sys standard streams
AttributeError: '_io.FileIO' object has no attribute 'raw'
Fatal Python error: Py_Initialize: can't initialize sys standard streams
AttributeError: '_io.FileIO' object has no attribute 'raw'
Fatal Python error: Py_Initialize: can't initialize sys standard streams
AttributeError: '_io.FileIO' object has no attribute 'raw'
test test_httpservers failed -- errors occurred; run in verbose mode for
details
test_io
test test_io failed -- errors occurred; run in verbose mode for details
test_mmap
test test_mmap failed -- Traceback (most recent call last):
  File
"/datawhse/test/data/export/ptst/Python-3.1/Lib/test/test_mmap.py", line
219, in test_access_parameter
    m.flush()
mmap.error: [Errno 22] Invalid argument
test_multiprocessing
test test_multiprocessing failed -- errors occurred; run in verbose mode
for details

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6348>
_______________________________________

From report at bugs.python.org  Thu Jul  9 23:21:29 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 09 Jul 2009 21:21:29 +0000
Subject: [issue6453] Improve bool TypeError message
In-Reply-To: <1247174489.94.0.772158623478.issue6453@psf.upfronthosting.co.za>
Message-ID: <1247174489.94.0.772158623478.issue6453@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

>>> cc=c()
>>> bool(cc)
Traceback (most recent call last):
  File "<pyshell#5>", line 1, in <module>
    bool(cc)
TypeError: __bool__ should return bool or int, returned int

This is slightly jarring.
Adding ' 0 or 1' after 'or int' would be nice (and trivial).
Adding str(val) at the end after type(val) would be even nicer.

----------
components: Interpreter Core
keywords: easy
messages: 90355
nosy: tjreedy
severity: normal
status: open
title: Improve bool TypeError message
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6453>
_______________________________________

From report at bugs.python.org  Thu Jul  9 23:40:28 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 09 Jul 2009 21:40:28 +0000
Subject: [issue6453] Improve bool TypeError message
In-Reply-To: <1247174489.94.0.772158623478.issue6453@psf.upfronthosting.co.za>
Message-ID: <1247175628.8.0.398231258602.issue6453@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The error message is in error.  Int is not allowed in 3.x, only bool. 
This is thus superseded by issue 6428, which has already been fixed.

----------
nosy: +r.david.murray
priority:  -> normal
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> TypeError: __bool__ should return bool or int, returned int

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6453>
_______________________________________

From report at bugs.python.org  Fri Jul 10 00:07:35 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 09 Jul 2009 22:07:35 +0000
Subject: [issue6443] _winreg.QueryValueEx confused on double null terminated
	strings
In-Reply-To: <1247109670.35.0.187157773378.issue6443@psf.upfronthosting.co.za>
Message-ID: <1247177255.94.0.556721327146.issue6443@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Yes, but did you try to press "OK"? Regedit displays a warning that empty 
lines are not allowed, and *removes* them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6443>
_______________________________________

From report at bugs.python.org  Fri Jul 10 00:22:25 2009
From: report at bugs.python.org (Vladislav)
Date: Thu, 09 Jul 2009 22:22:25 +0000
Subject: [issue6323] Py3.1 pdb doesn't deal well with syntax errors
In-Reply-To: <1245679907.43.0.120493835283.issue6323@psf.upfronthosting.co.za>
Message-ID: <1247178145.32.0.673692110645.issue6323@psf.upfronthosting.co.za>


Vladislav <kurtoglu at list.ru> added the comment:

>>> lambda: pass
SyntaxError: invalid syntax (<pyshell#0>, line 1)
>>> lambda: pas
<function <lambda> at 0x00F5C858>
>>> func_1=lambda: pas
>>> func_1()
Traceback (most recent call last):
  File "<pyshell#3>", line 1, in <module>
    func_1()
  File "<pyshell#2>", line 1, in <lambda>
    func_1=lambda: pas
NameError: global name 'pas' is not defined
>>> func_1=lambda: pass
SyntaxError: invalid syntax (<pyshell#4>, line 1)
>>> 

This is very funny:)

----------
components: +Windows -Library (Lib)
nosy: +kurtoglu
type: behavior -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6323>
_______________________________________

From report at bugs.python.org  Fri Jul 10 00:39:59 2009
From: report at bugs.python.org (Casey McGinty)
Date: Thu, 09 Jul 2009 22:39:59 +0000
Subject: [issue3518] multiprocessing: BaseManager.from_address documented but
	doesn't exist
In-Reply-To: <1218131168.54.0.934616092257.issue3518@psf.upfronthosting.co.za>
Message-ID: <1247179199.75.0.706232263805.issue3518@psf.upfronthosting.co.za>


Casey McGinty <casey.mcginty at gmail.com> added the comment:

I would like to open this ticket back up.

Python 2.6.2 docs still reference unimplemented 'from_address' method.

http://docs.python.org/library/multiprocessing.html#multiprocessing.managers.BaseManager.from_address

BaseManager.__reduce__ method also calls unimplemented 'from_address'
method. This looks like a bug since there is no docs or comments that
indicate it is as an abstract method.

----------
nosy: +casey.mcginty at gmail.com

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3518>
_______________________________________

From report at bugs.python.org  Fri Jul 10 00:41:08 2009
From: report at bugs.python.org (Andreas Kloeckner)
Date: Thu, 09 Jul 2009 22:41:08 +0000
Subject: [issue6323] Py3.1 pdb doesn't deal well with syntax errors
In-Reply-To: <1245679907.43.0.120493835283.issue6323@psf.upfronthosting.co.za>
Message-ID: <1247179268.91.0.682361958215.issue6323@psf.upfronthosting.co.za>


Andreas Kloeckner <inform at tiker.net> added the comment:

Vladislav: The behavior you find funny is actually correct. "pass" is a
statement and as such not allowed in a lambda. (only expressions are)
Your posting is unrelated to this bug report. If you're still confused,
please ask on comp.lang.python.

----------
components: +Library (Lib) -Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6323>
_______________________________________

From report at bugs.python.org  Fri Jul 10 00:43:31 2009
From: report at bugs.python.org (Casey McGinty)
Date: Thu, 09 Jul 2009 22:43:31 +0000
Subject: [issue5862] multiprocessing 'using a remote manager' example errors
	and possible 'from_address' code leftover
In-Reply-To: <1240883702.69.0.562256281063.issue5862@psf.upfronthosting.co.za>
Message-ID: <1247179411.34.0.809238203314.issue5862@psf.upfronthosting.co.za>


Changes by Casey McGinty <casey.mcginty at gmail.com>:


----------
nosy: +cmcginty

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5862>
_______________________________________

From report at bugs.python.org  Fri Jul 10 00:44:45 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 09 Jul 2009 22:44:45 +0000
Subject: [issue6416] Failed to compile selectmodule.c on windows (trunk)
In-Reply-To: <1246706675.4.0.617951670977.issue6416@psf.upfronthosting.co.za>
Message-ID: <1247179485.56.0.544086539756.issue6416@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

PIPE_BUF was introduced for the subprocess module to use it... on posix 
platforms only.
r73916 (trunk) and r73917 (py3k) add the suggested #ifdef, and also fix 
test_subprocess.

----------
nosy: +amaury.forgeotdarc
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6416>
_______________________________________

From report at bugs.python.org  Fri Jul 10 00:45:25 2009
From: report at bugs.python.org (Jesse Noller)
Date: Thu, 09 Jul 2009 22:45:25 +0000
Subject: [issue3518] multiprocessing: BaseManager.from_address documented but
	doesn't exist
In-Reply-To: <1218131168.54.0.934616092257.issue3518@psf.upfronthosting.co.za>
Message-ID: <1247179525.58.0.064664031057.issue3518@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------
resolution: fixed -> accepted
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3518>
_______________________________________

From report at bugs.python.org  Fri Jul 10 01:08:29 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 09 Jul 2009 23:08:29 +0000
Subject: [issue6333] logging: ValueError: I/O operation on closed file
In-Reply-To: <1245807768.39.0.536701423847.issue6333@psf.upfronthosting.co.za>
Message-ID: <1247180909.95.0.416936742534.issue6333@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6333>
_______________________________________

From report at bugs.python.org  Fri Jul 10 01:21:14 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 09 Jul 2009 23:21:14 +0000
Subject: [issue6323] Py3.1 pdb doesn't deal well with syntax errors
In-Reply-To: <1245679907.43.0.120493835283.issue6323@psf.upfronthosting.co.za>
Message-ID: <1247181674.58.0.887029537067.issue6323@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Fixed in r73918 (py3k) and r73920 (release31-maint). Thanks for the 
report!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6323>
_______________________________________

From report at bugs.python.org  Fri Jul 10 01:43:47 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 09 Jul 2009 23:43:47 +0000
Subject: [issue6333] logging: ValueError: I/O operation on closed file
In-Reply-To: <1245807768.39.0.536701423847.issue6333@psf.upfronthosting.co.za>
Message-ID: <1247183027.1.0.4644863516.issue6333@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> However, sys.stdout|err can be assigned to some thing else
> (eg: py.test assigning it to an open file object) .. in which case it 
> is legitimate to handle (close) such objects (handles) by who
> created it (py.test).

@Sridhar: I disagree. Creation is not ownership. Clearly ownership is
*initially* with the creator, but when a stream is used to initialise a
StreamHandler, ownership of the stream passes to the StreamHandler.

@Holger: I am not asking that py.test be specially modified to cater for
use of a logging module it knows nothing about. But your example showed
logging calls; I indicated what changes were needed to that sample to
interoperate with logging. So if that was a part of the test cases, then
the design of test cases which use logging (and not py.test itself, if
it doesn't invoke logging directly) needs to consider the interaction
between each test case, logging and py.test. And it is not solely the
responsibility of py.test to minimise resource usage during test runs;
part of this is also the responsibility of the test case design, which
surely is why test frameworks have the concepts of setUp and tearDown.

Your example calls logging.basicConfig passing a stream, and the stream
is then immediately closed. If the test case had involved threads which
did logging, for example, how could you guarantee that a call on the
stream (other than flush) would never happen after the call to close the
stream? Would I then have to ensure not only that flush was defensively
programmed, but write as well? It seems like a can of worms to me,
because of the propensity of this kind of approach to mask logic errors.
I'm not saying you never have to resort to defensive programming - just
that errors shouldn't pass silently where this is avoidable. The design
of StreamHandler is predicated on it owning the stream (for example, it
takes care to serialise access to the stream with locks, to allow
thread-safe operation). This would be pointless if other code could
arbitrarily operate on the stream without worrying about thread-safety.

I also pointed out numerous flaws in Sridhar's reasoning both in this
issue and in issue6435 (not py.test related) and in my view, he needs to
look more closely at the logging package and the included functionality,
and if necessary the core's regression test module, test_logging.py, to
see what sorts of issues crop up. For example, I pointed out in msg90148
that file-like objects are not guaranteed to have a "closed" attribute,
to which he has not responded. I would appeal for more attention to detail.

And just in case it may seem otherwise, I'll state explicitly that I am
not trying to be difficult. Similar issues have arisen during the
initial development of test_logging.py. 

I will update the documentation for StreamHandler, FileHandler etc. to
highlight the issue of ownership of the stream, as perhaps it's not
clear enough. Sorry if this post seems a little long-winded.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6333>
_______________________________________

From report at bugs.python.org  Fri Jul 10 01:54:20 2009
From: report at bugs.python.org (Daniel Waylonis)
Date: Thu, 09 Jul 2009 23:54:20 +0000
Subject: [issue6454] Add "example" keyword argument to optparse constructor
In-Reply-To: <1247183660.32.0.307989578437.issue6454@psf.upfronthosting.co.za>
Message-ID: <1247183660.32.0.307989578437.issue6454@psf.upfronthosting.co.za>


New submission from Daniel Waylonis <danw at nekotech.com>:

It's useful to see and example or two detailing how a program should be 
invoked and the expected results.

I'd like to add the "example" keyword which will be printed below the 
"options:" when the usage is displayed.  It would not be formatted like 
the "description" string.

----------
components: Library (Lib)
messages: 90364
nosy: waylonis
severity: normal
status: open
title: Add "example" keyword argument to optparse constructor
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6454>
_______________________________________

From report at bugs.python.org  Fri Jul 10 01:54:22 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 09 Jul 2009 23:54:22 +0000
Subject: [issue6435] logging: cache the traceback text on formatter,
	instead of record
In-Reply-To: <1247019484.09.0.843372167885.issue6435@psf.upfronthosting.co.za>
Message-ID: <1247183662.84.0.695794207579.issue6435@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

[snip example of how to achieve same effect as recipe in a simpler way]
>> How will this differ in its effect from your recipe?

> Actually, I did not know about 'Filter' until now. I will give it a
> try sometime.

Wouldn't it improve your recipe further to use more effectively
functionality which is already present in the logging package, instead
of re-inventing the wheel? Filter has been part of the logging package
design from the beginning, and is reasonably well documented.

If my suggestion has the same effect as your recipe, it has the further
benefit of users being able to specify thresholds more flexibly. For
example, in your response to a comment on your recipe, you acknowledge
that perhaps the destination you initially chose for DEBUG message might
need to be reconsidered. This means that it's probably better to provide
mechanism, and leave policy more to the user. With moderately careful
design of the Filter class, more flexibility could be provided with no
real penalty in code size or complexity.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6435>
_______________________________________

From report at bugs.python.org  Fri Jul 10 02:01:44 2009
From: report at bugs.python.org (Daniel Waylonis)
Date: Fri, 10 Jul 2009 00:01:44 +0000
Subject: [issue6454] Add "example" keyword argument to optparse constructor
In-Reply-To: <1247183660.32.0.307989578437.issue6454@psf.upfronthosting.co.za>
Message-ID: <1247184104.61.0.629862087907.issue6454@psf.upfronthosting.co.za>


Daniel Waylonis <danw at nekotech.com> added the comment:

Looking at the source, there's the undocumented "epilog" keyword, but it, 
unfortunately is automatically pushed through the formatter, which would 
not be desirable for the output.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6454>
_______________________________________

From report at bugs.python.org  Fri Jul 10 02:09:38 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 10 Jul 2009 00:09:38 +0000
Subject: [issue6423] The cgi docs should advertize using "in" instead of
	"has_key"
In-Reply-To: <1246809932.04.0.15312988227.issue6423@psf.upfronthosting.co.za>
Message-ID: <1247184578.08.0.908709090506.issue6423@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6423>
_______________________________________

From report at bugs.python.org  Fri Jul 10 02:14:36 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 10 Jul 2009 00:14:36 +0000
Subject: [issue6333] logging: ValueError: I/O operation on closed file
In-Reply-To: <1247183027.1.0.4644863516.issue6333@psf.upfronthosting.co.za>
Message-ID: <op.uwtr9peibrrvlq@double>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

On Thu, 09 Jul 2009 16:43:49 -0700, Vinay Sajip <report at bugs.python.org>
wrote:

> Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:
>
>> However, sys.stdout|err can be assigned to some thing else
>> (eg: py.test assigning it to an open file object) .. in which case it
>> is legitimate to handle (close) such objects (handles) by who
>> created it (py.test).
> @Sridhar: I disagree. Creation is not ownership. Clearly ownership is
> *initially* with the creator, but when a stream is used to initialise a
> StreamHandler, ownership of the stream passes to the StreamHandler.

Are you suggesting that the ownership of `sys.stderr` belongs to the
logging module once logging.basicConfig (that initializes a StreamHandler
with stderr) is called? That no other module/library is to close
sys.stderr even though they created it (sys.__stderr__ being the backup)?

StreamHandler can take ownership of an arbitrary stream (say, created by
the caller) passed to it, but assuming ownership of a standard stream,
that are free to be overridden by a library (such as py.test), is rather
bizarre.

> I pointed out in msg90148
> that file-like objects are not guaranteed to have a "closed" attribute,
> to which he has not responded.

If this bug is acknowledged as a problem, then coming up with a fix is a  
different issue. I don't know how to detect whether a stream is closed or  
not .. especially when you say that not all file-like objects have a  
'closed' attribute (BTW, which doesn't?), but this is the only solution I  
know currently:

     ...
     # some streams, such as sys.stdout|err, cannot be owned by  
StreamHandler
     # they might have been closed by whoever customized it.
     closed = hasattr(self.stream, 'closed') and self.stream.closed
     if self.stream and hasattr(self.stream, 'flush') and not closed:
         self.stream.flush()
     ...

-srid

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6333>
_______________________________________

From report at bugs.python.org  Fri Jul 10 04:20:00 2009
From: report at bugs.python.org (Lucas Prado Melo)
Date: Fri, 10 Jul 2009 02:20:00 +0000
Subject: [issue6447] PATCH: typo (English) in subprocess module
In-Reply-To: <1247192400.02.0.488716044552.issue6447@psf.upfronthosting.co.za>
Message-ID: <1247192400.02.0.488716044552.issue6447@psf.upfronthosting.co.za>


New submission from Lucas Prado Melo <lucaspradomelo at gmail.com>:

I am pretty sure this patch is alright.

----------
nosy: +lucaspmelo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6447>
_______________________________________

From report at bugs.python.org  Fri Jul 10 04:25:33 2009
From: report at bugs.python.org (Andrew Ziem)
Date: Fri, 10 Jul 2009 02:25:33 +0000
Subject: [issue6443] _winreg.QueryValueEx confused on double null terminated
	strings
In-Reply-To: <1247109670.35.0.187157773378.issue6443@psf.upfronthosting.co.za>
Message-ID: <1247192733.6.0.670617837927.issue6443@psf.upfronthosting.co.za>


Andrew Ziem <ahz001 at gmail.com> added the comment:

Yes, regedit does remove the blanks, but this bug report is about
QueryValueEx---not about SetValueEx :).  There must be a way to read all
the values compatible with Windows

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6443>
_______________________________________

From report at bugs.python.org  Fri Jul 10 04:52:45 2009
From: report at bugs.python.org (Rene Dudfield)
Date: Fri, 10 Jul 2009 02:52:45 +0000
Subject: [issue2751] Regression for executing packages
In-Reply-To: <1209861378.3.0.693402002548.issue2751@psf.upfronthosting.co.za>
Message-ID: <1247194365.88.0.977021197983.issue2751@psf.upfronthosting.co.za>


Rene Dudfield <illume at users.sourceforge.net> added the comment:

Hi,

note -m on packages still works with python3.0 and python3.1.  It works
by allowing a __main__.py file that gets called by -m.

This is a really annoying regression for python2.6.  It's a fairly wide
spread feature too.

I can't see any PEP for why this regression exists.

For pygame we will probably work around it by using "python -m
tests.main" or "python -m pygame.tests.run" which is ugly, but at least
it'll work!


cheers,

----------
nosy: +illume

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2751>
_______________________________________

From report at bugs.python.org  Fri Jul 10 05:09:05 2009
From: report at bugs.python.org (Andrew Ziem)
Date: Fri, 10 Jul 2009 03:09:05 +0000
Subject: [issue6443] _winreg.QueryValueEx confused on double null terminated
	strings
In-Reply-To: <1247109670.35.0.187157773378.issue6443@psf.upfronthosting.co.za>
Message-ID: <1247195345.53.0.658354859521.issue6443@psf.upfronthosting.co.za>


Andrew Ziem <ahz001 at gmail.com> added the comment:

Well, I no longer need QueryValueEx because I found out
win32file.MoveFileEx() does more easily what I need, but MoveFileEx (see
attachment for working example) shows that the Microsoft Window API
itself creates these "invalid values"

----------
Added file: http://bugs.python.org/file14480/delete_locked_file.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6443>
_______________________________________

From report at bugs.python.org  Fri Jul 10 05:30:54 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 10 Jul 2009 03:30:54 +0000
Subject: [issue2751] Regression for executing packages
In-Reply-To: <1209861378.3.0.693402002548.issue2751@psf.upfronthosting.co.za>
Message-ID: <1247196654.12.0.988171904782.issue2751@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

It doesn't work in 2.6 or 3.0 because, as stated above, it was only due
to a bug that it even appeared to work at all in 2.5 (it was always
meant to be disallowed because it puts dodgy data in the import
machinery's internal records if you do it).

It took a new feature (looking for a __main__ module as described in
issue 4195 and as you already noted) to make it actually work properly
for 3.1 (and 2.7 when that is released).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2751>
_______________________________________

From report at bugs.python.org  Fri Jul 10 05:35:40 2009
From: report at bugs.python.org (Ned Deily)
Date: Fri, 10 Jul 2009 03:35:40 +0000
Subject: [issue6393] OS X: python3 from python-3.1.dmg crashes at startup
In-Reply-To: <1246445517.38.0.373229118664.issue6393@psf.upfronthosting.co.za>
Message-ID: <1247196940.39.0.451376999243.issue6393@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Looks good and the "patched" patch also works in a py3k installer build.

BTW, Mark, I was curious as to why you were unable to reproduce the 
problem with your own build.  I should have mentioned that my testing 
was with complete installer (framework) builds.  I subsequently 
experimented with a non-framework build and found that I could not 
reproduce the problem running from the ./python in the build directory.  
Stepping through gdb showed that, during the calls from create_stdio, 
the import of locale fails in textio.c, so it falls back to using 
"ascii" as the default encoding (~line 899) and avoids the crash.  If I 
do a make install, the unpatched installed bin/python3 does crash in the 
same way as with the installer python3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6393>
_______________________________________

From report at bugs.python.org  Fri Jul 10 05:37:26 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 10 Jul 2009 03:37:26 +0000
Subject: [issue6453] Improve bool TypeError message
In-Reply-To: <1247174489.94.0.772158623478.issue6453@psf.upfronthosting.co.za>
Message-ID: <1247197046.65.0.584782083293.issue6453@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Phooey. I searched for 'bool TypeError' but it failed to return 6428.
I will ask on py-dev why not.

----------
priority: normal -> 
resolution: duplicate -> 
stage: committed/rejected -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6453>
_______________________________________

From report at bugs.python.org  Fri Jul 10 06:53:26 2009
From: report at bugs.python.org (Alexey Shamrin)
Date: Fri, 10 Jul 2009 04:53:26 +0000
Subject: [issue2931] optparse: various problems with unicode and gettext
In-Reply-To: <1211297479.44.0.970954846769.issue2931@psf.upfronthosting.co.za>
Message-ID: <1247201606.62.0.0333660738725.issue2931@psf.upfronthosting.co.za>


Changes by Alexey Shamrin <shamrin at gmail.com>:


----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2931>
_______________________________________

From report at bugs.python.org  Fri Jul 10 07:21:42 2009
From: report at bugs.python.org (Rene Dudfield)
Date: Fri, 10 Jul 2009 05:21:42 +0000
Subject: [issue2751] Regression for executing packages
In-Reply-To: <1209861378.3.0.693402002548.issue2751@psf.upfronthosting.co.za>
Message-ID: <1247203302.91.0.241771426918.issue2751@psf.upfronthosting.co.za>


Rene Dudfield <illume at users.sourceforge.net> added the comment:

hello,

thanks for the explanation of why it's that way.  

Any ideas of a work around?


python2.5 has been out for ages now. Even if it was an accident, it's
the behavior people expect, and it's still a regression.

Also, why should it matter if a module is a package or a module?

Note how pygame.tests has a type of module, and not of package:
>>> import pygame.tests
>>> type(pygame.tests)
<type 'module'>

Even though it is a package, python calls its type a module.  This has
been true for a long time (at least as far back as python2.3).

Because it's a regression, I think this bug should be reopened.


To illustrate why it causes problems, here is part of the documentation
mentioning the __main__.


"""
You can do a self test with:
    python -m pygame.tests
Or with python2.6 do:
    python -m pygame.tests.__main__

See a list of examples...
  python -m pygame.examples
Or with python2.6,
  python -m pygame.examples.__main__
"""

It's twice as long, and I doubt anyone will remember the __main__ part.


People used to running their programs with -m now have broken programs
with python2.6.


Having said all that, maybe there is a work around...

One work around might be to make it into a module-module, not a
package-module.  Then have the module-module load the package-module
into its namespace.  I haven't tested that yet, but it might work.  Will
have to go through a round of testing to see how that works out.  Will
write back when I've found out the issues with that approach.


cheers,

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2751>
_______________________________________

From report at bugs.python.org  Fri Jul 10 08:16:06 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 10 Jul 2009 06:16:06 +0000
Subject: [issue6455] Lib/distutils/tests/test_build_ext.py fails on windows
In-Reply-To: <1247206566.47.0.851600165432.issue6455@psf.upfronthosting.co.za>
Message-ID: <1247206566.47.0.851600165432.issue6455@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

Extention name of shared object is ".pyd" not ".so" on windows.
I hope attached patch will fix this issue.

----------
assignee: tarek
components: Distutils, Windows
files: fix_distutils_test.patch
keywords: patch
messages: 90376
nosy: ocean-city, tarek
severity: normal
status: open
title: Lib/distutils/tests/test_build_ext.py fails on windows
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14481/fix_distutils_test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6455>
_______________________________________

From report at bugs.python.org  Fri Jul 10 08:44:19 2009
From: report at bugs.python.org (Alexey Shamrin)
Date: Fri, 10 Jul 2009 06:44:19 +0000
Subject: [issue4319] optparse and non-ascii help strings
In-Reply-To: <1226623162.39.0.530373397898.issue4319@psf.upfronthosting.co.za>
Message-ID: <1247208259.81.0.407048071907.issue4319@psf.upfronthosting.co.za>


Alexey Shamrin <shamrin at gmail.com> added the comment:

There's nothing to fix here, I think... There's no point in allowing
arbitrary byte strings in help strings. Especially because Python 3
features unicode strings by default.

IMHO, this issue should be closed. And see also #2931 for remaining i18n
problems with optparse.

----------
nosy: +ash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4319>
_______________________________________

From report at bugs.python.org  Fri Jul 10 10:00:04 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 10 Jul 2009 08:00:04 +0000
Subject: [issue6333] logging: ValueError: I/O operation on closed file
In-Reply-To: <1245807768.39.0.536701423847.issue6333@psf.upfronthosting.co.za>
Message-ID: <1247212804.38.0.475686568964.issue6333@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> Are you suggesting that the ownership of `sys.stderr` belongs to the
> logging module once logging.basicConfig (that initializes a 
> StreamHandler with stderr) is called?
> That no other module/library is to close sys.stderr even though they
> created it (sys.__stderr__ being the backup)?

> StreamHandler can take ownership of an arbitrary stream (say, created
> by the caller) passed to it, but assuming ownership of a
> standard stream, that are free to be overridden by a library (such as
> py.test), is rather bizarre.

Actually, it's not bizarre at all. Are you saying it's OK for multiple
threads in a program to write to sys.stderr, whenever they want, without
restriction, even if the end result is end-user visible output which is
gibberish (for example data from two logical streams interspersed
randomly)? Just because it's a "standard" stream? 

Also, perhaps you haven't noticed that StreamHandler has no way of
knowing whether the stream it was passed was a standard stream or not.
Logging may make certain hasattr-type checks e.g. for presence of
"flush" or "close", but it can't expect to not have ownership of the
stream, even for a standard stream.

I advise you to do the following: refactor your test cases to include
the explicit handler-adding code in your setup (instead of basicConfig),
and the handler-removing and closing code in your teardown.

def setUp(self):
  self.hdlr = logging.StreamHandler(stream)
  someLogger.addHandler(h)

def tearDown(self):
    someLogger.removeHandler(self.hdlr)
    self.hdlr.close()

where I have given someLogger module scope in the above snippet, you may
of course make it a testcase attribute too.

No changes to py.test are required. What happens if you do this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6333>
_______________________________________

From report at bugs.python.org  Fri Jul 10 10:01:29 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 10 Jul 2009 08:01:29 +0000
Subject: [issue6333] logging: ValueError: I/O operation on closed file
In-Reply-To: <1245807768.39.0.536701423847.issue6333@psf.upfronthosting.co.za>
Message-ID: <1247212889.66.0.456735835992.issue6333@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6333>
_______________________________________

From report at bugs.python.org  Fri Jul 10 10:03:06 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 10 Jul 2009 08:03:06 +0000
Subject: [issue6333] logging: ValueError: I/O operation on closed file
In-Reply-To: <1245807768.39.0.536701423847.issue6333@psf.upfronthosting.co.za>
Message-ID: <1247212986.3.0.834957585764.issue6333@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> Are you suggesting that the ownership of `sys.stderr` belongs to the
> logging module once logging.basicConfig (that initializes a 
> StreamHandler with stderr) is called?
> That no other module/library is to close sys.stderr even though they
> created it (sys.__stderr__ being the backup)?

> StreamHandler can take ownership of an arbitrary stream (say, created
> by the caller) passed to it, but assuming ownership of a
> standard stream, that are free to be overridden by a library (such as
> py.test), is rather bizarre.

Actually, it's not bizarre at all. Are you saying it's OK for multiple
threads in a program to write to sys.stderr, whenever they want, without
restriction, even if the end result is end-user visible output which is
gibberish (for example data from two logical streams interspersed
randomly)? Just because it's a "standard" stream? 

Also, perhaps you haven't noticed that StreamHandler has no way of
knowing whether the stream it was passed was a standard stream or not.
Logging may make certain hasattr-type checks e.g. for presence of
"flush" or "close", but it can't expect to not have ownership of the
stream, even for a standard stream.

I advise you to do the following: refactor your test cases to include
the explicit handler-adding code in your setup (instead of basicConfig),
and the handler-removing and closing code in your teardown.

def setUp(self):
  self.hdlr = logging.StreamHandler(stream)
  someLogger.addHandler(h)

def tearDown(self):
    someLogger.removeHandler(self.hdlr)
    self.hdlr.close()

where I have given someLogger module scope in the above snippet, you may
of course make it a testcase attribute too. I've used a unittest-style
of setUp/tearDown, I assume py.test is similar.

No changes to py.test are required. What happens if you do this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6333>
_______________________________________

From report at bugs.python.org  Fri Jul 10 10:53:36 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 10 Jul 2009 08:53:36 +0000
Subject: [issue6453] Improve bool TypeError message
In-Reply-To: <1247174489.94.0.772158623478.issue6453@psf.upfronthosting.co.za>
Message-ID: <1247216016.6.0.278134412472.issue6453@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6453>
_______________________________________

From report at bugs.python.org  Fri Jul 10 11:08:02 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 10 Jul 2009 09:08:02 +0000
Subject: [issue2751] Regression for executing packages
In-Reply-To: <1209861378.3.0.693402002548.issue2751@psf.upfronthosting.co.za>
Message-ID: <1247216882.57.0.564008608806.issue2751@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

If you need to support Python 2.6 as well as 3.1, the simplest thing to
do is just tell people to run "pygame.tests.main" always (i.e.
completely skip the idea of executing the package directly and always
run a submodule instead).

The reason the distinction between packages and modules matters is that
the import system has to do more bookkeeping for packages (since they
can contain modules and subpackages). Direct execution of packages was
meant to be disallowed because the Python 2.5 accident means the
__init__ module runs without that extra bookkeeping having been set up
properly, which can lead to a broken import system. Unfortunately, the
relevant error message was lost for 2.5 in a refactoring that merged
duplicated code from a couple of different parts of the standard library.

I added Barry to the nosy list as the 2.6 release manager. I'm reluctant
to re-enable a known-broken behaviour at all, but if Barry thinks it
would be worthwhile downgrading this to a DeprecationWarning rather than
an outright error in the next 2.6 maintenance then I would be willing to
do that. That would still leave you with people getting a warning
though, so I don't think it would be that much of a gain in practice.

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2751>
_______________________________________

From report at bugs.python.org  Fri Jul 10 11:16:44 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 10 Jul 2009 09:16:44 +0000
Subject: [issue6455] Lib/distutils/tests/test_build_ext.py fails on windows
In-Reply-To: <1247206566.47.0.851600165432.issue6455@psf.upfronthosting.co.za>
Message-ID: <1247217404.59.0.284003733688.issue6455@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Applied in r73921 in trunk, and propagated in branches.

Thanks !

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6455>
_______________________________________

From report at bugs.python.org  Fri Jul 10 11:19:48 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 10 Jul 2009 09:19:48 +0000
Subject: [issue6377] distutils compiler switch ignored
In-Reply-To: <1246299740.9.0.786372120366.issue6377@psf.upfronthosting.co.za>
Message-ID: <1247217588.85.0.788230025939.issue6377@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

@Nicolas : That's because you run it with Python 2.6 distutils, which
doesn't have that change.

If you want to build the current trunk with Python 2.6, you may want to
install a standalone version of distutils. I have a nightly build of the
trunk you may install in 2.6 for this: 

http://nightly.ziade.org/

By the time 2.7 comes out, I'll probably publish an official standalone
version for 2.6 as Marc Andr? suggested in the past.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6377>
_______________________________________

From report at bugs.python.org  Fri Jul 10 11:34:43 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 10 Jul 2009 09:34:43 +0000
Subject: [issue6377] distutils compiler switch ignored
In-Reply-To: <1246299740.9.0.786372120366.issue6377@psf.upfronthosting.co.za>
Message-ID: <1247218483.44.0.638415406381.issue6377@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

> You never run a command twice unless you explicitly reinitialize it
> (which then resets .compiler to None and then fetches the command line
> option again), so the above is not a problem.

In practice yes that's true.

> The "compiler" option on the build_ext and config commands
> are not really needed. Their .finalize_options() methods could
> easily pull in the build option value and place it into
> an .compiler_type attribute which then gets used as basis for
> creating the .compiler instance, or even better refactor the
> various commands to use a central method on the build
> command object to create a compiler object and avoid all
> the copy&paste code for this.
> Furthermore, the .finalize_options() methods could detect whether
> a per-command option as used and deprecate this use instead,
> redirecting to the build command option.

Having a single location sounds like the best idea with the current
behavior, reachable from cmd.get_compiler_object() like you did.

Now the question is, in practice, could someone force a
different compiler in build_ext for instance, or with a different
configuration than in build_clib ?

I don't see a use case in practice for that, but if so, we would need to
keep a different compiler instance per command.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6377>
_______________________________________

From report at bugs.python.org  Fri Jul 10 12:27:37 2009
From: report at bugs.python.org (dauerbaustelle)
Date: Fri, 10 Jul 2009 10:27:37 +0000
Subject: [issue6456] locale.D_* and .T_* are int, not string
In-Reply-To: <1247221657.02.0.83286673792.issue6456@psf.upfronthosting.co.za>
Message-ID: <1247221657.02.0.83286673792.issue6456@psf.upfronthosting.co.za>


New submission from dauerbaustelle <jonas at lophus.org>:

The locale.D_* and locale.T_* attributes are ints with weird values
instead of strings (see documentation[1]).

Example:


>>> import locale
>>> locale.setlocale(locale.LC_ALL, 'en_US.utf8')
'en_US.utf8'
>>> locale.D_T_FMT
131112
>>> locale.D_FMT
131113
>>> locale.T_FMT
131114
>>> locale.T_FMT_AMPM
131115

It seems like the .DAY_* stuff is also broken:
>>> locale.DAY_1
131079
>>> locale.DAY_2
131080
>>> locale.DAY_7
131085

And many other variables:
>>> locale.THOUSEP
65537

The documentation says that every of these variables should be strings.

Regards,
db

[1]http://docs.python.org/library/locale.html#locale.D_T_FMT

----------
components: Library (Lib)
messages: 90384
nosy: dauerbaustelle
severity: normal
status: open
title: locale.D_* and .T_* are int, not string
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6456>
_______________________________________

From report at bugs.python.org  Fri Jul 10 12:34:55 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 10 Jul 2009 10:34:55 +0000
Subject: [issue6377] distutils compiler switch ignored
In-Reply-To: <1247218483.44.0.638415406381.issue6377@psf.upfronthosting.co.za>
Message-ID: <4A57194B.8040202@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Tarek Ziad? wrote:
>> The "compiler" option on the build_ext and config commands
>> are not really needed. Their .finalize_options() methods could
>> easily pull in the build option value and place it into
>> an .compiler_type attribute which then gets used as basis for
>> creating the .compiler instance, or even better refactor the
>> various commands to use a central method on the build
>> command object to create a compiler object and avoid all
>> the copy&paste code for this.
>> Furthermore, the .finalize_options() methods could detect whether
>> a per-command option as used and deprecate this use instead,
>> redirecting to the build command option.
> 
> Having a single location sounds like the best idea with the current
> behavior, reachable from cmd.get_compiler_object() like you did.
> 
> Now the question is, in practice, could someone force a
> different compiler in build_ext for instance, or with a different
> configuration than in build_clib ?
> 
> I don't see a use case in practice for that, but if so, we would need to
> keep a different compiler instance per command.

It is generally a bad idea to mix compiler types when compiling
Python extensions and usually doesn't work unless you are
very careful.

In practice, I don't think that any extension package will use
more than one compiler type for the various build parts.

However, it is well possible that a package may use differently
setup compiler instances on various commands, e.g. to point
it to different libraries, dirs, etc., so having just
one such instance on e.g. the top-level build command object
would not work out.

In fact, a single command object may even use multiple compiler
instances to e.g. build different C libs or extensions using
different sets of include and library search dirs.

I think a workable solution to the problem with the compiler
option would be to remove the option from the build_ext,
build_clib and config commands (plus any others, if there are
more) and only allow it on the build command.

The build.get_compiler_object() could then return an instance
of the chosen compiler type and the command object would then
store it in .compiler.

The various .finalize_options() method would need to propagate
any used "compiler" option back to the build command and reset
the .compiler attribute to None.

You'd still have the situation that .compiler is used as
option string and then as compiler instance, but only for
the short phase between .initialize_options() and
.finalize_options() which is not all that much of a problem
(you cannot make any use of non-finalized command objects
anyway).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6377>
_______________________________________

From report at bugs.python.org  Fri Jul 10 12:52:36 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 10 Jul 2009 10:52:36 +0000
Subject: [issue6456] locale.D_* and .T_* are int, not string
In-Reply-To: <1247221657.02.0.83286673792.issue6456@psf.upfronthosting.co.za>
Message-ID: <1247223156.82.0.0589078374706.issue6456@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

If you look a little further up in the page you will see:

"The nl_langinfo() function accepts one of the following keys. Most
descriptions are taken from the corresponding description in the GNU C
library."

I agree that the descriptions of the constants are a bit confusing, but
the fact that it says "return" instead of saying that it is _is_ a
string should be a clue that the item itself is not a string. 

A doc patch would certainly be considered if you see a way to make it
more obvious.

----------
nosy: +r.david.murray
priority:  -> normal
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6456>
_______________________________________

From report at bugs.python.org  Fri Jul 10 13:09:55 2009
From: report at bugs.python.org (dauerbaustelle)
Date: Fri, 10 Jul 2009 11:09:55 +0000
Subject: [issue6456] locale.D_* and .T_* are int, not string
In-Reply-To: <1247221657.02.0.83286673792.issue6456@psf.upfronthosting.co.za>
Message-ID: <1247224195.68.0.0566660992925.issue6456@psf.upfronthosting.co.za>


dauerbaustelle <jonas at lophus.org> added the comment:

I would suggest to make those constants be strings. There's no need for
those int values; in most cases, you want the strings and not the int
values.

Until then, I would put that nl_langinfo() stuff in a warning or info
box (or highlight it somehow differently).

Regards

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6456>
_______________________________________

From report at bugs.python.org  Fri Jul 10 13:33:26 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 10 Jul 2009 11:33:26 +0000
Subject: [issue4970] test_os causes delayed failure on x86 gentoo buildbot:
	Unknown signal 32
In-Reply-To: <1232190585.86.0.270883273991.issue4970@psf.upfronthosting.co.za>
Message-ID: <1247225606.03.0.546280198167.issue4970@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4970>
_______________________________________

From report at bugs.python.org  Fri Jul 10 13:35:31 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 10 Jul 2009 11:35:31 +0000
Subject: [issue6456] locale.D_* and .T_* are int, not string
In-Reply-To: <1247221657.02.0.83286673792.issue6456@psf.upfronthosting.co.za>
Message-ID: <1247225731.18.0.20685272088.issue6456@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The description of each of these constants could start like this:
"""
When passed to :func:`nl_langinfo`, return a string ...
"""

+ the "Example:" paragraph should be moved in a more prominent place,
near the top of the file for example.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6456>
_______________________________________

From report at bugs.python.org  Fri Jul 10 13:59:23 2009
From: report at bugs.python.org (holger krekel)
Date: Fri, 10 Jul 2009 11:59:23 +0000
Subject: [issue6333] logging: ValueError: I/O operation on closed file
In-Reply-To: <1245807768.39.0.536701423847.issue6333@psf.upfronthosting.co.za>
Message-ID: <1247227163.88.0.864233867848.issue6333@psf.upfronthosting.co.za>


holger krekel <holger.krekel at gmail.com> added the comment:

Actually py.test catches stdout separately for setup and for the test
code.  Moreover, functional or integration test code (py.test is not
only for unittests) can easily trigger some implicit logging-module
usage which cannot eaysily be factored into a testcase-setup method, i
am afraid.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6333>
_______________________________________

From report at bugs.python.org  Fri Jul 10 14:25:49 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 10 Jul 2009 12:25:49 +0000
Subject: [issue4970] test_os causes delayed failure on x86 gentoo buildbot:
	Unknown signal 32
In-Reply-To: <1232190585.86.0.270883273991.issue4970@psf.upfronthosting.co.za>
Message-ID: <1247228749.66.0.134473011324.issue4970@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

It would also be interesting to know whether Neal's system is using the 
LinuxThreads library, or whether it's using NPTL.  If it's the former, it 
might go some way to explaining the problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4970>
_______________________________________

From report at bugs.python.org  Fri Jul 10 14:36:05 2009
From: report at bugs.python.org (Dariusz Walczak)
Date: Fri, 10 Jul 2009 12:36:05 +0000
Subject: [issue6457] subprocess.Popen.communicate can lose data from
	output/error streams when broken input pipe occures
In-Reply-To: <1247229365.37.0.486388451669.issue6457@psf.upfronthosting.co.za>
Message-ID: <1247229365.37.0.486388451669.issue6457@psf.upfronthosting.co.za>


New submission from Dariusz Walczak <dariusz.walczak at gmail.com>:

It's possible to lose data piped through standard output and/or error
streams when large ammounts of data are transfered.

Reproduction:
1) Process A spawns process B with all standard I/O pipes and transfers
large ammount of data to it (100kB in my sample).
2) Process B exits very early (doesn't process all stdin data) and puts
large amount of data into its stderr or stdout streams.
3) IOError/OSError exception if errno variable set to errno.EPIPE is
raised on process A side.

Bug:
When the exception is catched Popen object's stdout and stderr members
may not contain data put into stderr/stdout streams by process B.

Note:
Described behaviour can be observed in Python 2.6.1 on FreeBSD 7.2 as
well as on Windows XP (Pro x64, SP2, up to date).

Real life example of such early end of process B:
openssl smime -verify -CApath /some/dir with large, unsigned email.

I attach simple reproduction code (execute sender.py script).

----------
components: Library (Lib)
files: subprocess.Popen.communicate_problem_reproduction.zip
messages: 90391
nosy: dwalczak
severity: normal
status: open
title: subprocess.Popen.communicate can lose data from output/error streams when broken input pipe occures
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14482/subprocess.Popen.communicate_problem_reproduction.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6457>
_______________________________________

From report at bugs.python.org  Fri Jul 10 15:28:46 2009
From: report at bugs.python.org (Sean)
Date: Fri, 10 Jul 2009 13:28:46 +0000
Subject: [issue6458] With logging.config.fileConfig can't create logger
	without handler
In-Reply-To: <1247232526.2.0.244135072278.issue6458@psf.upfronthosting.co.za>
Message-ID: <1247232526.2.0.244135072278.issue6458@psf.upfronthosting.co.za>


New submission from Sean <sean.davis15 at googlemail.com>:

Using "logging" module I can do the following:

    f = logging.Formatter("%(levelname)s: %(name)s: %(message)s")
    h = logging.StreamHandler()
    h.setLevel(logging.NOTSET)
    h.setFormatter(f)
    l = logging.getLogger()
    l.addHandler(h)

    l2 = logging.getLogger('x.y.z')
    l2.setLevel(logging.INFO)
    print len(l2.handlers)

    l2.critical('critical')
    l2.error('error')
    l2.warning('warning')
    l2.info('info')
    l2.debug('debug')

Note, the l2(x.y.z) logger does not have a handler (it just propagates
to the l(root) logger's handler) but the l2 logger does have a different
level set.

When I try to do this with logging.config.fileConfig it fails saying I
have not specified a handler for the x.y.z logger.  But I don't want to
specify a handler, I just want to set the level and have it propagate up
the hierarchy.

Am I doing something wrong?

Sean.

P.S. Here is the config file:

[loggers]
keys=root,xyz

[handlers]
keys=consoleStderr

[formatters]
keys=simpleFormatter

[logger_root]
level=NOTSET
handlers=consoleStderr

[logger_xyz]
level=DEBUG
qualname=x.y.z

[handler_consoleStderr]
class=StreamHandler
level=NOTSET
formatter=simpleFormatter
args=(sys.stderr,)

[formatter_simpleFormatter]
%(levelname)s: %(name)s: %(message)s

----------
messages: 90392
nosy: sean
severity: normal
status: open
title: With logging.config.fileConfig can't create logger without handler
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6458>
_______________________________________

From report at bugs.python.org  Fri Jul 10 18:31:08 2009
From: report at bugs.python.org (Sean)
Date: Fri, 10 Jul 2009 16:31:08 +0000
Subject: [issue6458] With logging.config.fileConfig can't create logger
	without handler
In-Reply-To: <1247232526.2.0.244135072278.issue6458@psf.upfronthosting.co.za>
Message-ID: <1247243468.66.0.789120981378.issue6458@psf.upfronthosting.co.za>


Sean <sean.davis15 at googlemail.com> added the comment:

there is a missing "format=" on the last line of my config file. Doesn't
change the stated problem though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6458>
_______________________________________

From report at bugs.python.org  Fri Jul 10 18:48:24 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 10 Jul 2009 16:48:24 +0000
Subject: [issue6447] PATCH: typo (English) in subprocess module
In-Reply-To: <1247192400.02.0.488716044552.issue6447@psf.upfronthosting.co.za>
Message-ID: <1247244504.38.0.323917093912.issue6447@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

applied with r73930. thanks for the patch!

----------
nosy: +amaury.forgeotdarc
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6447>
_______________________________________

From report at bugs.python.org  Fri Jul 10 22:30:30 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 10 Jul 2009 20:30:30 +0000
Subject: [issue6456] locale.D_* and .T_* are int, not string
In-Reply-To: <1247221657.02.0.83286673792.issue6456@psf.upfronthosting.co.za>
Message-ID: <1247257830.09.0.76956713868.issue6456@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

They can't be static string constants because they aren't constants. 
They depend on the current locale settings.

I'm reopening this as a doc bug.

----------
assignee:  -> georg.brandl
components: +Documentation -Library (Lib)
nosy: +georg.brandl
resolution: invalid -> 
stage: committed/rejected -> needs patch
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6456>
_______________________________________

From report at bugs.python.org  Fri Jul 10 22:35:11 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 10 Jul 2009 20:35:11 +0000
Subject: [issue4970] test_os causes delayed failure on x86 gentoo buildbot:
	Unknown signal 32
In-Reply-To: <1232190585.86.0.270883273991.issue4970@psf.upfronthosting.co.za>
Message-ID: <1247258111.25.0.619722352276.issue4970@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I was unable to reproduce this using the suggested regrtest pair, even
if I ran -R ::, on Gentoo, kernel 2.6.30, with nptl.

----------
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4970>
_______________________________________

From report at bugs.python.org  Fri Jul 10 23:01:33 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 10 Jul 2009 21:01:33 +0000
Subject: [issue6410] Dictionaries should support __add__
In-Reply-To: <1246653238.95.0.314927755738.issue6410@psf.upfronthosting.co.za>
Message-ID: <1247259693.46.0.559853356899.issue6410@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

> what would be the result of {"a": 1, "b": 2} + {"a": 2, "b": 1}?
> Should it be {"a": 1, "b": 2} or {"a": 2, "b": 1}?

or {"a":[1,2], "b":[1,2]}
As I remember, Guido rejected because of this ambiguity.

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6410>
_______________________________________

From report at bugs.python.org  Fri Jul 10 23:33:15 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 10 Jul 2009 21:33:15 +0000
Subject: [issue6453] Improve bool TypeError message
In-Reply-To: <1247174489.94.0.772158623478.issue6453@psf.upfronthosting.co.za>
Message-ID: <1247261595.45.0.0635934166373.issue6453@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Testing.
I am 99.9% sure *I* did not reopen. Testing to see if OP post auto-reopens.

----------
nosy:  -r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6453>
_______________________________________

From report at bugs.python.org  Fri Jul 10 23:36:03 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 10 Jul 2009 21:36:03 +0000
Subject: [issue6453] Improve bool TypeError message
In-Reply-To: <1247174489.94.0.772158623478.issue6453@psf.upfronthosting.co.za>
Message-ID: <1247261763.48.0.214344196395.issue6453@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Must have been random glitch. I certainly did not change state and priority.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6453>
_______________________________________

From report at bugs.python.org  Sat Jul 11 03:20:10 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 11 Jul 2009 01:20:10 +0000
Subject: [issue6459] Lib/distutils\tests\test_build_ext.py fails on VC6
In-Reply-To: <1247275210.18.0.83127119859.issue6459@psf.upfronthosting.co.za>
Message-ID: <1247275210.18.0.83127119859.issue6459@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

I got distutils error on Lib/distutils\tests\test_build_ext.py. I hope 
attached file will fix this issue. (This should complete r64127)

E:\python-dev\py3k>py3k Lib\distutils\tests\test_build_ext.py
test_build_ext (__main__.BuildExtTestCase) ... xxmodule.c
   Library c:\docume~1\whiter~1\locals~1\temp\tmpbj3fb0\Debug\docume~1
\whiter~1\l
ocals~1\temp\tmpbj3fb0\xx_d.lib ????????? c:\docume~1\whiter~1\locals~1
\temp\tm
pbj3fb0\Debug\docume~1\whiter~1\locals~1\temp\tmpbj3fb0\xx_d.exp is now 
being created
ok
test_check_extensions_list (__main__.BuildExtTestCase) ... ok
test_compiler_deprecation_warning (__main__.BuildExtTestCase) ... ok
test_compiler_option (__main__.BuildExtTestCase) ... ok
test_ext_fullpath (__main__.BuildExtTestCase) ... ok
test_finalize_options (__main__.BuildExtTestCase) ... ok
test_get_outputs (__main__.BuildExtTestCase) ... foo.c
LINK : error LNK2001: External symbol "PyInit_foo" is not resolved
c:\docume~1\whiter~1\locals~1\temp\tmp1bfgxq\tempt\docume~1\whiter~1
\locals~1\te
mp\tmpnttk0b\foo_d.lib : fatal error LNK1120: External symbol 1 is not 
resolved
LINK : fatal error LNK1141: Got trouble in building export file
ERROR
test_get_source_files (__main__.BuildExtTestCase) ... ok
test_optional_extension (__main__.BuildExtTestCase) ... ok
test_solaris_enable_shared (__main__.BuildExtTestCase) ... ok
test_user_site (__main__.BuildExtTestCase) ... ok

======================================================================
ERROR: test_get_outputs (__main__.BuildExtTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "e:\python-dev\py3k\lib\distutils\msvccompiler.py", line 524, in 
link
    self.spawn([self.linker] + ld_args)
  File "e:\python-dev\py3k\lib\distutils\ccompiler.py", line 981, in 
spawn
    spawn(cmd, dry_run=self.dry_run)
  File "e:\python-dev\py3k\lib\distutils\spawn.py", line 36, in spawn
    _spawn_nt(cmd, search_path, dry_run=dry_run)
  File "e:\python-dev\py3k\lib\distutils\spawn.py", line 77, in 
_spawn_nt
    "command '%s' failed with exit status %d" % (cmd[0], rc))
distutils.errors.DistutilsExecError: command '"C:\Program 
Files\Microsoft Visual
 Studio\VC98\BIN\link.exe"' failed with exit status 1141

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "Lib\distutils\tests\test_build_ext.py", line 323, in 
test_get_outputs
    cmd.run()
  File "e:\python-dev\py3k\lib\distutils\command\build_ext.py", line 
394, in run

    self.build_extensions()
  File "e:\python-dev\py3k\lib\distutils\command\build_ext.py", line 
503, in bui
ld_extensions
    self.build_extension(ext)
  File "e:\python-dev\py3k\lib\distutils\command\build_ext.py", line 
590, in bui
ld_extension
    target_lang=language)
  File "e:\python-dev\py3k\lib\distutils\ccompiler.py", line 791, in 
link_shared
_object
    extra_preargs, extra_postargs, build_temp, target_lang)
  File "e:\python-dev\py3k\lib\distutils\msvccompiler.py", line 526, in 
link
    raise LinkError(msg)
distutils.errors.LinkError: command '"C:\Program Files\Microsoft Visual 
Studio\V
C98\BIN\link.exe"' failed with exit status 1141

----------------------------------------------------------------------
Ran 11 tests in 1826.566s

FAILED (errors=1)
Traceback (most recent call last):
  File "Lib\distutils\tests\test_build_ext.py", line 432, in <module>

----------
assignee: tarek
components: Distutils, Windows
files: fix_distutils_test.patch
keywords: patch
messages: 90400
nosy: ocean-city, tarek
severity: normal
status: open
title: Lib/distutils\tests\test_build_ext.py fails on VC6
versions: Python 3.2
Added file: http://bugs.python.org/file14483/fix_distutils_test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6459>
_______________________________________

From report at bugs.python.org  Sat Jul 11 04:27:56 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 11 Jul 2009 02:27:56 +0000
Subject: [issue6453] Improve bool TypeError message
In-Reply-To: <1247174489.94.0.772158623478.issue6453@psf.upfronthosting.co.za>
Message-ID: <1247279276.12.0.062883860098.issue6453@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

On your test post I got deleted from the nosy list.  Was that intentional?

I wonder if your browser is doing something weird with the form field
settings.  Or it may have as you say been a random thing...I know that
has happened to me once or twice where I refreshed the page in an odd
order and reset some fields I wasn't intending to reset.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6453>
_______________________________________

From report at bugs.python.org  Sat Jul 11 05:09:42 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 11 Jul 2009 03:09:42 +0000
Subject: [issue6460] test failure in test_xmlrpc on Gentoo in trunk
In-Reply-To: <1247281782.39.0.752563688041.issue6460@psf.upfronthosting.co.za>
Message-ID: <1247281782.39.0.752563688041.issue6460@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

Another apparent fallout from r73638 (issue 6267).  On my gentoo system
I am currently seeing a consistent failure in test_xmlrpc of 'test_two'
in KeepaliveServerTestCase (as is the Gentoo buildbot).  I made the
assert the new GreaterEqual and stuck just a tad bit of extra tracing in
(printing the contents of myRequests to stderr) and this is what I see:

rdmurray at partner:~/python/trunk>./python -m test.regrtest test_xmlrpc
Could not find '/home/rdmurray/python/trunk/Lib/test' in sys.path to
remove it
test_xmlrpc
[['POST /RPC2 HTTP/1.1\r\n']]
test test_xmlrpc failed -- Traceback (most recent call last):
  File "/home/rdmurray/python/trunk/Lib/test/test_xmlrpc.py", line 550,
in test_two
    self.assertGreaterEqual(len(self.RequestHandler.myRequests[-1]), 2)
AssertionError: 1 not greater than or equal to 2

1 test failed:
    test_xmlrpc

The test appears to hit a time out.

If there are any tests you want me to run let me know.  Oddly enough I'm
not seeing this one on 3.2.

----------
assignee: krisvale
components: Library (Lib), Tests
messages: 90402
nosy: krisvale, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: test failure in test_xmlrpc on Gentoo in trunk
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6460>
_______________________________________

From report at bugs.python.org  Sat Jul 11 06:58:46 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 11 Jul 2009 04:58:46 +0000
Subject: [issue6453] Improve bool TypeError message
In-Reply-To: <1247174489.94.0.772158623478.issue6453@psf.upfronthosting.co.za>
Message-ID: <1247288326.3.0.70562442976.issue6453@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

yes, I was trying to avoid bothering you with the noise.
This is one of those 'everything gone wrong' situations.
If only I had unselected 'open only' when I did the search...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6453>
_______________________________________

From report at bugs.python.org  Sat Jul 11 08:03:30 2009
From: report at bugs.python.org (Ned Deily)
Date: Sat, 11 Jul 2009 06:03:30 +0000
Subject: [issue6460] test failure in test_xmlrpc on Gentoo in trunk
In-Reply-To: <1247281782.39.0.752563688041.issue6460@psf.upfronthosting.co.za>
Message-ID: <1247292210.84.0.171851798959.issue6460@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

FWIW, I've just seen a couple of intermittent 'test_two' failures with a 
current py3k on OS X but, in each case, the test passed when auto rerun 
in verbose mode.

test test_xmlrpc failed -- Traceback (most recent call last):
  File 
"/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/test/te
st_xmlrpc.py", line 514, in test_two
    self.assertTrue(len(self.RequestHandler.myRequests[-1]) >= 2)
AssertionError: False is not True

----------
nosy: +nad

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6460>
_______________________________________

From report at bugs.python.org  Sat Jul 11 08:08:28 2009
From: report at bugs.python.org (Stuart Mentzer)
Date: Sat, 11 Jul 2009 06:08:28 +0000
Subject: [issue6461] multiprocessing: freezing apps on Windows
In-Reply-To: <1247292508.31.0.803162103646.issue6461@psf.upfronthosting.co.za>
Message-ID: <1247292508.31.0.803162103646.issue6461@psf.upfronthosting.co.za>


New submission from Stuart Mentzer <sgm at objexx.com>:

Freezing apps with multiprocessing on Windows seems to be broken.

First, in get_command_line in multiprocessing/forking.py I find that
this code:

        if getattr(sys, 'frozen', False):
            return [sys.executable, '--multiprocessing-fork']
        else:
            prog = 'from multiprocessing.forking import main; main()'
            return [_python_exe, '-c', prog, '--multiprocessing-fork']

should be:

        elif getattr(sys, 'frozen', False) and not WINEXE:
            return [sys.executable, '--multiprocessing-fork']
        else:
            prog = 'from multiprocessing.forking import main; main()'
            return [_python_exe, '-c', prog, '--multiprocessing-fork']

in order for the _python_exe set with multiprocessing.set_executable to
be used rather than your app's exe.

Second, I can then get a working "frozen" package if I include
pythonw.exe (and use set_executable to point to it) and a subset of
Python's Lib directory that my process needs to call. If this is as
intended then it needs to be documented. This may just be a flaw in py2exe.

Third, the multiprocessing documentation page description for
set_executable has example code with the older setExecutable call.

----------
components: Library (Lib)
messages: 90405
nosy: sgm
severity: normal
status: open
title: multiprocessing: freezing apps on Windows
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6461>
_______________________________________

From report at bugs.python.org  Sat Jul 11 10:46:30 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sat, 11 Jul 2009 08:46:30 +0000
Subject: [issue6460] test failure in test_xmlrpc on Gentoo in trunk
In-Reply-To: <1247281782.39.0.752563688041.issue6460@psf.upfronthosting.co.za>
Message-ID: <1247301990.9.0.782936239628.issue6460@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

This is probably a race condition, where the server thread hasn't updated 
the stats yet when the client is testing them.  I'm so used to work with 
non-preemtive scheduling in stackless python that I sometimes forget how 
threads work :)
I submitted revision 73932 for the trunk, please test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6460>
_______________________________________

From report at bugs.python.org  Sat Jul 11 11:37:24 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 11 Jul 2009 09:37:24 +0000
Subject: [issue6358] os.popen exit code inconsistent
In-Reply-To: <1246224690.37.0.731708410356.issue6358@psf.upfronthosting.co.za>
Message-ID: <1247305044.65.0.45724215875.issue6358@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Added a few tests, and fixed in r73934 (py3k) and r73935 (3.1)
Thanks for the report!

----------
nosy: +amaury.forgeotdarc
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6358>
_______________________________________

From report at bugs.python.org  Sat Jul 11 11:59:27 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 11 Jul 2009 09:59:27 +0000
Subject: [issue6459] Lib/distutils\tests\test_build_ext.py fails on VC6
In-Reply-To: <1247275210.18.0.83127119859.issue6459@psf.upfronthosting.co.za>
Message-ID: <1247306367.38.0.150261438393.issue6459@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Confirmed with vs2008. I wonder why the buildbots don't fail.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6459>
_______________________________________

From report at bugs.python.org  Sat Jul 11 12:15:15 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 11 Jul 2009 10:15:15 +0000
Subject: [issue6446] import_spam() in extending python can fail without
	setting the error.
In-Reply-To: <1247139108.9.0.128424367437.issue6446@psf.upfronthosting.co.za>
Message-ID: <1247307315.53.0.788081384469.issue6446@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r73938.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6446>
_______________________________________

From report at bugs.python.org  Sat Jul 11 12:18:31 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 11 Jul 2009 10:18:31 +0000
Subject: [issue6448] imp.find_module() -- be explicity that 'path' must be a
	list
In-Reply-To: <1247152045.93.0.157775961524.issue6448@psf.upfronthosting.co.za>
Message-ID: <1247307511.95.0.878085222386.issue6448@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I reworded the paragraph a bit in r73939.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6448>
_______________________________________

From report at bugs.python.org  Sat Jul 11 12:31:37 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 11 Jul 2009 10:31:37 +0000
Subject: [issue6459] Lib/distutils\tests\test_build_ext.py fails on VC6
In-Reply-To: <1247275210.18.0.83127119859.issue6459@psf.upfronthosting.co.za>
Message-ID: <1247308297.94.0.997411007236.issue6459@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Thanks for the patch, I'll integrate asap.

Notice that I run the tests under windows but without a full range of VC
versions, so I count a lot on the buildbots to show me these kind of
failures.

----------
priority:  -> normal
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6459>
_______________________________________

From report at bugs.python.org  Sat Jul 11 12:39:32 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 11 Jul 2009 10:39:32 +0000
Subject: [issue6430] array.array falsely advertises support for 'w' in
	documentation
In-Reply-To: <1246912827.43.0.704118006779.issue6430@psf.upfronthosting.co.za>
Message-ID: <1247308772.59.0.636052680469.issue6430@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

OK, fixed this in r73940, r73941, r73942.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6430>
_______________________________________

From report at bugs.python.org  Sat Jul 11 12:43:19 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 11 Jul 2009 10:43:19 +0000
Subject: [issue6421] errors in docs re module initialization vs self arg to
	functions
In-Reply-To: <1246748021.93.0.159427637238.issue6421@psf.upfronthosting.co.za>
Message-ID: <1247308999.97.0.207874236518.issue6421@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed both instances in r73943.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6421>
_______________________________________

From report at bugs.python.org  Sat Jul 11 12:43:56 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 11 Jul 2009 10:43:56 +0000
Subject: [issue1921] Confusing Descrintro example
In-Reply-To: <1201181747.66.0.31684496906.issue1921@psf.upfronthosting.co.za>
Message-ID: <1247309036.46.0.967372961414.issue1921@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee: georg.brandl -> gvanrossum
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1921>
_______________________________________

From report at bugs.python.org  Sat Jul 11 12:47:36 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 11 Jul 2009 10:47:36 +0000
Subject: [issue6459] Lib/distutils\tests\test_build_ext.py fails on VC6
In-Reply-To: <1247275210.18.0.83127119859.issue6459@psf.upfronthosting.co.za>
Message-ID: <1247309256.42.0.894873448239.issue6459@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Mmm, also notice that the current build_ext trunk uses "init"
 in the code, which means that the "PyInit" prefix was added on 
py3k but not backported in the trunk.

So i'll fix that too

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6459>
_______________________________________

From report at bugs.python.org  Sat Jul 11 12:51:59 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 11 Jul 2009 10:51:59 +0000
Subject: [issue6456] locale.D_* and .T_* are int, not string
In-Reply-To: <1247221657.02.0.83286673792.issue6456@psf.upfronthosting.co.za>
Message-ID: <1247309519.47.0.291155049025.issue6456@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I moved the constants' description into the nl_langinfo() description
and clarified their use in r73945.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6456>
_______________________________________

From report at bugs.python.org  Sat Jul 11 12:52:58 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 11 Jul 2009 10:52:58 +0000
Subject: [issue6269] threading documentation makes no mention of the GIL
In-Reply-To: <1244752636.53.0.230892071938.issue6269@psf.upfronthosting.co.za>
Message-ID: <1247309578.04.0.398456116061.issue6269@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee: georg.brandl -> jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6269>
_______________________________________

From report at bugs.python.org  Sat Jul 11 12:53:27 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 11 Jul 2009 10:53:27 +0000
Subject: [issue6459] distutils.command.build_ext.get_export_symbols should use
	the "PyInit" prefix rather then "init"
In-Reply-To: <1247275210.18.0.83127119859.issue6459@psf.upfronthosting.co.za>
Message-ID: <1247309607.16.0.0906347900489.issue6459@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

The bug also exists in 2.6 so I'm backporting the fix

----------
title: Lib/distutils\tests\test_build_ext.py fails on VC6 -> distutils.command.build_ext.get_export_symbols should use the "PyInit" prefix rather then "init"
versions: +Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6459>
_______________________________________

From report at bugs.python.org  Sat Jul 11 13:01:57 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 11 Jul 2009 11:01:57 +0000
Subject: [issue6459] distutils.command.build_ext.get_export_symbols should use
	the "PyInit" prefix rather then "init"
In-Reply-To: <1247275210.18.0.83127119859.issue6459@psf.upfronthosting.co.za>
Message-ID: <1247310117.36.0.69655825222.issue6459@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

done in r73946, r73947 (2.6), r73948 (py3k), r73949 (3.1)

Thanks !

(also, the build_ext module is now perfectly similar between 2.x and 3.x)

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6459>
_______________________________________

From report at bugs.python.org  Sat Jul 11 13:08:43 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 11 Jul 2009 11:08:43 +0000
Subject: [issue6459] distutils.command.build_ext.get_export_symbols should use
	the "PyInit" prefix rather then "init"
In-Reply-To: <1247275210.18.0.83127119859.issue6459@psf.upfronthosting.co.za>
Message-ID: <1247310523.65.0.42761011071.issue6459@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Well, I'm not sure but.... for example,
Modules/_randomemodule.c uses "init_random" on trunk. Is it OK to 
use "PyInit" on trunk too?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6459>
_______________________________________

From report at bugs.python.org  Sat Jul 11 13:51:30 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 11 Jul 2009 11:51:30 +0000
Subject: [issue6459] distutils.command.build_ext.get_export_symbols should use
	the "PyInit" prefix rather then "init"
In-Reply-To: <1247275210.18.0.83127119859.issue6459@psf.upfronthosting.co.za>
Message-ID: <1247313090.29.0.961065949486.issue6459@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

What's the logic behind PyInit_ ? 

For instance Modules/_bsddb.c uses PyInit, so does Modules/zlibmodule.c

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6459>
_______________________________________

From report at bugs.python.org  Sat Jul 11 13:58:11 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 11 Jul 2009 11:58:11 +0000
Subject: [issue6459] distutils.command.build_ext.get_export_symbols should use
	the "PyInit" prefix rather then "init"
In-Reply-To: <1247275210.18.0.83127119859.issue6459@psf.upfronthosting.co.za>
Message-ID: <1247313491.5.0.257570883355.issue6459@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

bsddb seems to use #if directive to switch function name. 
("init_bsddb"  on trunk)

#if (PY_VERSION_HEX < 0x03000000)
DL_EXPORT(void) init_bsddb(void)
#else
PyMODINIT_FUNC  PyInit__bsddb(void)    /* Note the two underscores */
#endif

And zlibmodule.c, there is following line on line number 56.
#define PyInit_zlib initzlib

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6459>
_______________________________________

From report at bugs.python.org  Sat Jul 11 15:54:40 2009
From: report at bugs.python.org (Arjen Nienhuis)
Date: Sat, 11 Jul 2009 13:54:40 +0000
Subject: [issue3982] support .format for bytes
In-Reply-To: <1222530641.39.0.0764973101836.issue3982@psf.upfronthosting.co.za>
Message-ID: <1247320480.38.0.277534478263.issue3982@psf.upfronthosting.co.za>


Arjen Nienhuis <a.g.nienhuis at gmail.com> added the comment:

There are many binary formats that use ASCII numbers.

'HTTP chunking' uses ASCII mixed with binary (octets).

With 2.6 you could write:

def chunk(block):
    return b'{0:x}\r\n{1}\r\n'.format(len(block), block)

With 3.0 you'd have to write this:

def chunk(block):
    return format(len(block), 'x').encode('ascii') + b'\r\n' + block +
b'\r\n'

You cannot convert to ascii at the end of the pipeline as there are
bytes > 127 in the data blocks.

----------
nosy: +arjennienhuis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3982>
_______________________________________

From report at bugs.python.org  Sat Jul 11 16:11:25 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 11 Jul 2009 14:11:25 +0000
Subject: [issue6460] test failure in test_xmlrpc on Gentoo in trunk
In-Reply-To: <1247281782.39.0.752563688041.issue6460@psf.upfronthosting.co.za>
Message-ID: <1247321485.57.0.324683584741.issue6460@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

OK, the test passes on my box now.  But from the way the test is phrased
it sounds like there is still a small risk that the test will fail in
unusual timing circumstances?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6460>
_______________________________________

From report at bugs.python.org  Sat Jul 11 17:52:17 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 11 Jul 2009 15:52:17 +0000
Subject: [issue3982] support .format for bytes
In-Reply-To: <1247320480.38.0.277534478263.issue3982@psf.upfronthosting.co.za>
Message-ID: <4A58B52E.9050302@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> def chunk(block):
>     return format(len(block), 'x').encode('ascii') + b'\r\n' + block +
> b'\r\n'
> 
> You cannot convert to ascii at the end of the pipeline as there are
> bytes > 127 in the data blocks.

I wouldn't write it in such a complicated way. Instead, use

def chunk(block):
   return hex(len(block)).encode('ascii') + b'\r\n' + block + b'\r\n'

This doesn't need any format call, and describes adequatly how the
protocol works: send an ASCII-encoded hex length, send CRLF, send
the block, then send another CRLF. Of course, I would probably write
that into the socket right away, rather than copying it into a different
bytes object first.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3982>
_______________________________________

From report at bugs.python.org  Sat Jul 11 18:23:47 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 11 Jul 2009 16:23:47 +0000
Subject: [issue6460] test failure in test_xmlrpc on Gentoo in trunk
In-Reply-To: <1247281782.39.0.752563688041.issue6460@psf.upfronthosting.co.za>
Message-ID: <1247329427.95.0.656636037314.issue6460@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

By the way, although my system doesn't show it, the Gentoo 3.x buildbot
shows the error.  I'm sure you were going to forward port the patch
anyway :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6460>
_______________________________________

From report at bugs.python.org  Sat Jul 11 18:28:46 2009
From: report at bugs.python.org (Arjen Nienhuis)
Date: Sat, 11 Jul 2009 16:28:46 +0000
Subject: [issue3982] support .format for bytes
In-Reply-To: <4A58B52E.9050302@v.loewis.de>
Message-ID: <11ddbd200907110928r72828d3bxb6a01cdefc56be18@mail.gmail.com>


Arjen Nienhuis <a.g.nienhuis at gmail.com> added the comment:

> def chunk(block):
> ? return hex(len(block)).encode('ascii') + b'\r\n' + block + b'\r\n'

hex(10) returns '0xa' instead of 'a'.

> This doesn't need any format call, and describes adequatly how the
> protocol works: send an ASCII-encoded hex length, send CRLF, send
> the block, then send another CRLF. Of course, I would probably write
> that into the socket right away, rather than copying it into a different
> bytes object first.

The point is that need to convert to ascii for each int that you send.
You cannot just wrap the socket with an encoding. This makes porting
difficult.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3982>
_______________________________________

From report at bugs.python.org  Sat Jul 11 18:32:13 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 11 Jul 2009 16:32:13 +0000
Subject: [issue6462] bsddb3 intermittent test failures
In-Reply-To: <1247329933.16.0.47150397.issue6462@psf.upfronthosting.co.za>
Message-ID: <1247329933.16.0.47150397.issue6462@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

The buildbots periodically report failures in the bsddb3 test suite. 
These are not reproducible and presumably are timing-based.  It would be
best if the tests could be made to pass consistently, to make the
buildbot output more useful.

Here is one such failure that I see on a semi-regular basis on trunk
(this happens in my own tests runs as well, also not consistently):

test_bsddb3
Berkeley DB 4.7.25: (June 30, 2009)
Test path prefix:  /tmp/z-test_bsddb3-11362
test test_bsddb3 failed -- Traceback (most recent call last):
  File "/home/rdmurray/python/trunk/Lib/bsddb/test/test_replication.py",
line 134, in test01_basic_replication
    self.assertTrue(time.time()<timeout)
AssertionError: False is not True

I will add others here as I capture examples.

----------
assignee: jcea
components: Tests
messages: 90426
nosy: jcea, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: bsddb3 intermittent test failures
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6462>
_______________________________________

From report at bugs.python.org  Sat Jul 11 18:45:56 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 11 Jul 2009 16:45:56 +0000
Subject: [issue1921] Confusing Descrintro example
In-Reply-To: <1201181747.66.0.31684496906.issue1921@psf.upfronthosting.co.za>
Message-ID: <1247330756.73.0.850899198968.issue1921@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I'm guessing you weren't ready for learning about metaclasses if you
didn't get the fact that 'name' was the loop control variable in the two
different loops.  The example is only 11 lines long!

Still, I'm fine with the two suggested renames.

I'm not fine with rewriting the example using modern constructs, since
it is part of the docs for Python 2.2.  Perhaps the doc is still useful
but then it should be first moved into the regular doc tree and *then*
adapted to modern times (and we can't really release that version until
2.7 and 3.2 are released).

Unfortunately I do not have a checkout of the website handy any more (or
I can't remember where I put it).  Maybe one of the webmasters can make
the suggested fixes?

The fixed code that I agree with is:

class autoprop(type):
    def __init__(cls, name, bases, dict):
	super(autoprop, cls).__init__(name, bases, dict)
	props = {}
	for member in dict.keys():
            if member.startswith("_get_") or member.startswith("_set_"):
		props[member[5:]] = 1
	for prop in props.keys():
            fget = getattr(cls, "_get_%s" % prop, None)
            fset = getattr(cls, "_set_%s" % prop, None)
            setattr(cls, prop, property(fget, fset))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1921>
_______________________________________

From report at bugs.python.org  Sat Jul 11 18:47:35 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 11 Jul 2009 16:47:35 +0000
Subject: [issue3982] support .format for bytes
In-Reply-To: <11ddbd200907110928r72828d3bxb6a01cdefc56be18@mail.gmail.com>
Message-ID: <4A58C224.3090307@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> hex(10) returns '0xa' instead of 'a'.

Ah, right. So I would still use

   '{0:x}'.format(100).encode("ascii")

rather than the format builtin format function. Actually, I would
probably use

  ('%x' % len(bytes)).encode("ascii")

> The point is that need to convert to ascii for each int that you send.
> You cannot just wrap the socket with an encoding. This makes porting
> difficult.

This I don't understand. What porting becomes more difficult?
>From 2.x to 3.x? Why do you have any .format calls in your code that you
want to port - .format was only added in 2.6, so if you want to support
2.x, you surely are not using .format, are you?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3982>
_______________________________________

From report at bugs.python.org  Sat Jul 11 18:58:59 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 11 Jul 2009 16:58:59 +0000
Subject: [issue6459] distutils.command.build_ext.get_export_symbols should use
	the "PyInit" prefix rather then "init"
In-Reply-To: <1247275210.18.0.83127119859.issue6459@psf.upfronthosting.co.za>
Message-ID: <1247331539.76.0.736150256454.issue6459@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The "PyInit_" prefix is only to be used in Python 3, it is part of PEP 3121.

Please revert changes to trunk/2.6 that assume the "PyInit_" name.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6459>
_______________________________________

From report at bugs.python.org  Sat Jul 11 19:25:06 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 11 Jul 2009 17:25:06 +0000
Subject: [issue6459] distutils.command.build_ext.get_export_symbols should use
	the "PyInit" prefix rather then "init"
In-Reply-To: <1247275210.18.0.83127119859.issue6459@psf.upfronthosting.co.za>
Message-ID: <1247333106.48.0.771208039572.issue6459@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Thanks for the explanation, I've reverted the change on 2.x.

----------
status: open -> closed
versions:  -Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6459>
_______________________________________

From report at bugs.python.org  Sat Jul 11 20:31:54 2009
From: report at bugs.python.org (Kevin Walzer)
Date: Sat, 11 Jul 2009 18:31:54 +0000
Subject: [issue6463] IDLE with Tk-Cocoa: Edit, format menus hang
In-Reply-To: <1247337114.05.0.431997282863.issue6463@psf.upfronthosting.co.za>
Message-ID: <1247337114.05.0.431997282863.issue6463@psf.upfronthosting.co.za>


New submission from Kevin Walzer <wordtech at users.sourceforge.net>:

In running IDLE against a build of Tk-Cocoa (8.5.7) on OS X, the edit and 
format menus sometimes hang and require a force-quit of IDLE. This happens 
when I try to paste text, and also when trying to format selections of 
text with indentation, etc. I've looked closely at the code for 
Bindings.py, EditorWindow.py, PyShell.py, and macOSXSupport.py, and can 
find no obvious reason for these problems. I am confident that the problem 
is not with Tk-Cocoa itself, as copy, pasting, etc. in a basic Tkinter 
text widget presents no problems, but resides instead somewhere in IDLE's 
code and how it interacts with the Tk-Cocoa build. I'm testing against 
Python 2.6.2.

----------
components: IDLE
messages: 90431
nosy: wordtech
severity: normal
status: open
title: IDLE with Tk-Cocoa: Edit, format menus hang
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6463>
_______________________________________

From report at bugs.python.org  Sat Jul 11 20:46:58 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 11 Jul 2009 18:46:58 +0000
Subject: [issue6464] test_normalization failures due to truncated
	NormalizationTest.txt file
In-Reply-To: <1247338018.12.0.711917855883.issue6464@psf.upfronthosting.co.za>
Message-ID: <1247338018.12.0.711917855883.issue6464@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

I worked for a while tracking down a mysterious failure in
test_normalization on my machine.  I eventually discovered that a clean
checkout did not exhibit the problem.  A distclean on my original
checkout did not fix the problem.  By doing a diff I finally figured out
that the NormalizationTest.txt file is (a) downloaded the first time the
test is run and (b) not removed afterward and (c) not removed by distclean.

How I wound up with a truncated file I don't know, nor am I quite sure
what the best solution to this little confusion is.  It seems very odd
that a file is dumped and left in the CWD by a test.

----------
components: Tests
keywords: easy
messages: 90432
nosy: r.david.murray
priority: low
severity: normal
stage: needs patch
status: open
title: test_normalization failures due to truncated NormalizationTest.txt file
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6464>
_______________________________________

From report at bugs.python.org  Sat Jul 11 20:49:59 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 11 Jul 2009 18:49:59 +0000
Subject: [issue6464] test_normalization failures due to truncated
	NormalizationTest.txt file
In-Reply-To: <1247338018.12.0.711917855883.issue6464@psf.upfronthosting.co.za>
Message-ID: <1247338199.12.0.158638618759.issue6464@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +lemburg, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6464>
_______________________________________

From report at bugs.python.org  Sat Jul 11 21:25:48 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 11 Jul 2009 19:25:48 +0000
Subject: [issue6440] 2to3: convert deprecated string.maketrans to str.maketrans
In-Reply-To: <1247062399.96.0.431147395298.issue6440@psf.upfronthosting.co.za>
Message-ID: <1247340348.57.0.46474073549.issue6440@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6440>
_______________________________________

From report at bugs.python.org  Sat Jul 11 21:58:41 2009
From: report at bugs.python.org (jkg)
Date: Sat, 11 Jul 2009 19:58:41 +0000
Subject: [issue6465] email.feedparser regular expression bug (NLCRE_crack)
In-Reply-To: <1247342320.74.0.342668726051.issue6465@psf.upfronthosting.co.za>
Message-ID: <1247342320.74.0.342668726051.issue6465@psf.upfronthosting.co.za>


New submission from jkg <python at slashbot.com>:

If the parser is fed a chunk which ends with '\r' and the next chunk
begins with '\n', it incorrectly parses this into a line ending with
'\r' and an empty line ending with '\n' instead of a single line ending
with '\r\n'.

Test attached. Patch to follow.

----------
components: Library (Lib)
files: test_nlcre.py
messages: 90433
nosy: barry, jkg, tony_nelson
severity: normal
status: open
title: email.feedparser regular expression bug (NLCRE_crack)
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file14484/test_nlcre.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6465>
_______________________________________

From report at bugs.python.org  Sat Jul 11 22:01:29 2009
From: report at bugs.python.org (jkg)
Date: Sat, 11 Jul 2009 20:01:29 +0000
Subject: [issue6465] email.feedparser regular expression bug (NLCRE_crack)
In-Reply-To: <1247342320.74.0.342668726051.issue6465@psf.upfronthosting.co.za>
Message-ID: <1247342489.02.0.01123631081.issue6465@psf.upfronthosting.co.za>


jkg <python at slashbot.com> added the comment:

Patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file14485/nlcre.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6465>
_______________________________________

From report at bugs.python.org  Sat Jul 11 22:36:36 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sat, 11 Jul 2009 20:36:36 +0000
Subject: [issue6460] test failure in test_xmlrpc on Gentoo in trunk
In-Reply-To: <1247281782.39.0.752563688041.issue6460@psf.upfronthosting.co.za>
Message-ID: <1247344596.04.0.938249371636.issue6460@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

No, this should take care of it.  In order for the client side request to 
succeed, the server must have cycled through the previous request and 
updated its statistic.  It is only the statistic for the final request tha 
t may be missed.  And yes, I was going to fw. port, I was waiting for your 
confirmation.  Cheers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6460>
_______________________________________

From report at bugs.python.org  Sat Jul 11 23:57:46 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sat, 11 Jul 2009 21:57:46 +0000
Subject: [issue6460] test failure in test_xmlrpc on Gentoo in trunk
In-Reply-To: <1247281782.39.0.752563688041.issue6460@psf.upfronthosting.co.za>
Message-ID: <1247349466.16.0.5370255627.issue6460@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

merged testsuite fix to py3k in revision 73961

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6460>
_______________________________________

From report at bugs.python.org  Sun Jul 12 02:55:50 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 12 Jul 2009 00:55:50 +0000
Subject: [issue1921] Confusing Descrintro example
In-Reply-To: <1201181747.66.0.31684496906.issue1921@psf.upfronthosting.co.za>
Message-ID: <1247360150.45.0.635535837194.issue1921@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I've now updated the website to Guido's new code.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1921>
_______________________________________

From report at bugs.python.org  Sun Jul 12 03:38:07 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 12 Jul 2009 01:38:07 +0000
Subject: [issue6464] test_normalization failures due to truncated
	NormalizationTest.txt file
In-Reply-To: <1247338018.12.0.711917855883.issue6464@psf.upfronthosting.co.za>
Message-ID: <1247362687.92.0.0485457192768.issue6464@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Benjamin fixed this in r73962 by having the test support routine put the
files in Lib/test/data, and adding a rule to the distclean target to
empty that directory.

----------
nosy: +benjamin.peterson
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6464>
_______________________________________

From report at bugs.python.org  Sun Jul 12 03:39:07 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 12 Jul 2009 01:39:07 +0000
Subject: [issue6464] test_normalization failures due to truncated
	NormalizationTest.txt file
In-Reply-To: <1247338018.12.0.711917855883.issue6464@psf.upfronthosting.co.za>
Message-ID: <1247362747.33.0.399879336422.issue6464@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6464>
_______________________________________

From report at bugs.python.org  Sun Jul 12 09:32:35 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 12 Jul 2009 07:32:35 +0000
Subject: [issue6377] distutils compiler switch ignored
In-Reply-To: <1246299740.9.0.786372120366.issue6377@psf.upfronthosting.co.za>
Message-ID: <1247383955.03.0.80988036431.issue6377@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

> I think a workable solution to the problem with the compiler
> option would be to remove the option from the build_ext,
> build_clib and config commands (plus any others, if there are
> more) and only allow it on the build command.

The problem I see is that sometimes, people are using the build_ext
command on its own:

  $ python setup.py build_ext -i --compiler mingw32

So that means build_ext is not a subcommand of build in this case.
While we can instanciate a build command on the fly to get our compiler
and work with it, using get_command_obj(). 

But the code will have to be careful and not use the cache with this
method e.g. to re-create a new build command to avoid using the same
command instance if another build_ is called.

What about making it all simpler, by creating a base command class that
manages a compiler through some methods (like get_compiler_obj), then
make all our build+build_* command inherit from it ?

That would resolve the code duplication and will make it simpler each
command to deal with a compiler.

This base command would have one single option. e.g. "compiler" 


> You'd still have the situation that .compiler is used as
> option string and then as compiler instance, but only for
> the short phase between .initialize_options() and
> .finalize_options() which is not all that much of a problem

I am not sure to understand how .compiler will become a string 
again after .finalize_options() has been called. Could you provide 
an example ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6377>
_______________________________________

From report at bugs.python.org  Sun Jul 12 09:52:47 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 12 Jul 2009 07:52:47 +0000
Subject: [issue6438] cygwinccompiler regular expressions broken
In-Reply-To: <1247040935.54.0.909113570309.issue6438@psf.upfronthosting.co.za>
Message-ID: <1247385167.16.0.00760209372182.issue6438@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
resolution:  -> accepted
title: cygwincompiler regular expressions broken -> cygwinccompiler regular expressions broken

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6438>
_______________________________________

From report at bugs.python.org  Sun Jul 12 10:15:15 2009
From: report at bugs.python.org (Abdulmonem)
Date: Sun, 12 Jul 2009 08:15:15 +0000
Subject: [issue1616979] cp720 encoding map
Message-ID: <1247386515.71.0.720814517142.issue1616979@psf.upfronthosting.co.za>


Abdulmonem <dubaisi3g at gmail.com> added the comment:

As a user I experienced this bug. With  python 3.1, the interpreter 
terminate with fatal error:
"Py_Initialize: can't initialize sys standard streams
LookupError: unknown encoding: cp720"

I think, this can be replicated by changing the active code page in the 
cmd session, before invoking the interpreter. The following command will 
do so:
> chcp 720

without the patch python would crash after this command.
I think testing the patch after this command is sufficient.

----------
nosy: +abu_mohammed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1616979>
_______________________________________

From report at bugs.python.org  Sun Jul 12 10:20:42 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 12 Jul 2009 08:20:42 +0000
Subject: [issue6466] duplicate get_version() code between cygwinccompiler and
	emxccompiler
In-Reply-To: <1247386841.98.0.269164765319.issue6466@psf.upfronthosting.co.za>
Message-ID: <1247386841.98.0.269164765319.issue6466@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

Duplicate code, will create a single get_version() function in
distutils.util and make both commands use it + deprecate
cygwinccompiler.get_version and emxccompiler.get_version

----------
assignee: tarek
components: Distutils
messages: 90441
nosy: tarek
priority: normal
severity: normal
status: open
title: duplicate get_version() code between cygwinccompiler and emxccompiler
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6466>
_______________________________________

From report at bugs.python.org  Sun Jul 12 10:39:23 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 12 Jul 2009 08:39:23 +0000
Subject: [issue6438] cygwinccompiler regular expressions broken
In-Reply-To: <1247040935.54.0.909113570309.issue6438@psf.upfronthosting.co.za>
Message-ID: <1247387963.87.0.64530667637.issue6438@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

done in r73975, r73976

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6438>
_______________________________________

From report at bugs.python.org  Sun Jul 12 13:57:25 2009
From: report at bugs.python.org (Lucas Prado Melo)
Date: Sun, 12 Jul 2009 11:57:25 +0000
Subject: [issue6467] raw_input() doesn't work as expected when it gets
	multiple ^D
In-Reply-To: <1247399845.7.0.918611986455.issue6467@psf.upfronthosting.co.za>
Message-ID: <1247399845.7.0.918611986455.issue6467@psf.upfronthosting.co.za>


New submission from Lucas Prado Melo <lucaspradomelo at gmail.com>:

----------------------------------
$ cat raw_input_test.py
s = ''
try:
    while True:
        c = raw_input()
	print c
	s += c
except EOFError:
    pass
$ python raw_input_test.py
test^D^Dtes
^D
$ python --version
Python 2.7a0
$ bash --version
GNU bash, version 3.2.48(1)-release (i486-pc-linux-gnu)
Copyright (C) 2007 Free Software Foundation, Inc.
----------------------------------

Surprisingly, though:

----------------------------------
$ python raw_input_test.py > output
test^D^D^D
$ cat output
test
----------------------------------
^D = Press Ctrl+D

I am using Ubuntu 9.04 (Jaunty Jackalope).

----------
components: IO
messages: 90443
nosy: lucaspmelo
severity: normal
status: open
title: raw_input() doesn't work as expected when it gets multiple ^D
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6467>
_______________________________________

From report at bugs.python.org  Sun Jul 12 14:21:58 2009
From: report at bugs.python.org (Lucas Prado Melo)
Date: Sun, 12 Jul 2009 12:21:58 +0000
Subject: [issue5870] subprocess.DEVNULL
In-Reply-To: <1240946644.39.0.609275389725.issue5870@psf.upfronthosting.co.za>
Message-ID: <1247401318.08.0.463313270846.issue5870@psf.upfronthosting.co.za>


Lucas Prado Melo <lucaspradomelo at gmail.com> added the comment:

-1 on this one.
It is not a portable decision (only *nix OSes do have /dev/null).
Also, why would we want it as a default constant? The subprocess module
would need to open /dev/null every time. Despite that, I can't see how
would someone use the redirection of errors to /dev/null through a
python script and, at the same time, make it seem not a bad practice at all.

----------
nosy: +lucaspmelo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5870>
_______________________________________

From report at bugs.python.org  Sun Jul 12 14:49:48 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 12 Jul 2009 12:49:48 +0000
Subject: [issue6393] OS X: python3 from python-3.1.dmg crashes at startup
In-Reply-To: <1246445517.38.0.373229118664.issue6393@psf.upfronthosting.co.za>
Message-ID: <1247402988.64.0.134677043173.issue6393@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Once this patch is checked in, should we do an emergency 3.1.1 release?

----------
nosy: +benjamin.peterson, pitrou
priority:  -> critical
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6393>
_______________________________________

From report at bugs.python.org  Sun Jul 12 14:53:13 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 12 Jul 2009 12:53:13 +0000
Subject: [issue5870] subprocess.DEVNULL
In-Reply-To: <1240946644.39.0.609275389725.issue5870@psf.upfronthosting.co.za>
Message-ID: <1247403193.56.0.573306375974.issue5870@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Lucas, Windows has a /dev/null-like device. I think Jean's suggestion is
reasonable, but it should be a special constant instead of creating a
file descriptor unconditionnally (that is, the file should only be open
if needed). Also, a patch should be provided (with tests :-)).

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5870>
_______________________________________

From report at bugs.python.org  Sun Jul 12 15:01:01 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 12 Jul 2009 13:01:01 +0000
Subject: [issue6393] OS X: python3 from python-3.1.dmg crashes at startup
In-Reply-To: <1246445517.38.0.373229118664.issue6393@psf.upfronthosting.co.za>
Message-ID: <1247403661.58.0.740836224189.issue6393@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I'm don't know whether this is really worth a 3.1.1, all by itself.  
There's an easy workaround, which is for affected users to set their 
locale properly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6393>
_______________________________________

From report at bugs.python.org  Sun Jul 12 17:43:34 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 12 Jul 2009 15:43:34 +0000
Subject: [issue5753] CVE-2008-5983 python: untrusted python modules search path
In-Reply-To: <1239709179.65.0.173847743531.issue5753@psf.upfronthosting.co.za>
Message-ID: <1247413414.26.0.178390933713.issue5753@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Tomas, your patch is breaking an existing API, which may break existing
uses (I'm not sure which ones, but people are doing lots of things with
Python). That's why I proposed a separate API, which has the additional
benefit of making things clearer rather than muddier.

Besides, parsing of command line flags is already done in
Modules/main.c, we shouldn't repeat it in sysmodule.c.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5753>
_______________________________________

From report at bugs.python.org  Sun Jul 12 17:45:21 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 12 Jul 2009 15:45:21 +0000
Subject: [issue6465] email.feedparser regular expression bug (NLCRE_crack)
In-Reply-To: <1247342320.74.0.342668726051.issue6465@psf.upfronthosting.co.za>
Message-ID: <1247413521.88.0.0664003242792.issue6465@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Can you include your unit test in your patch rather than as a separate
script? Existing unit tests are in Lib/test.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6465>
_______________________________________

From report at bugs.python.org  Sun Jul 12 18:50:50 2009
From: report at bugs.python.org (Bosko Vukov)
Date: Sun, 12 Jul 2009 16:50:50 +0000
Subject: [issue6468] __missing__ not completely implemented in dictobject.c
In-Reply-To: <1247417450.47.0.16848043509.issue6468@psf.upfronthosting.co.za>
Message-ID: <1247417450.47.0.16848043509.issue6468@psf.upfronthosting.co.za>


New submission from Bosko Vukov <bvukov at users.sourceforge.net>:

For some reason functions PyDict_GetItem ( and PyDict_GetItemString )
don't try to check for '__missing__' on subclass, but
dict_subscript(dictobject *mp, register PyObject *key) does.
Only in this function a failure to get a value using
ma_lookup checks afterwards using !PyDict_CheckExact for subclass
definition of '__missing__', and then returns a value.
Is this intended or just a half implementation ?

----------
components: None
messages: 90450
nosy: bvukov
severity: normal
status: open
title: __missing__ not completely implemented in dictobject.c
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6468>
_______________________________________

From report at bugs.python.org  Sun Jul 12 19:03:03 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 12 Jul 2009 17:03:03 +0000
Subject: [issue6468] __missing__ not completely implemented in dictobject.c
In-Reply-To: <1247417450.47.0.16848043509.issue6468@psf.upfronthosting.co.za>
Message-ID: <1247418183.21.0.329276772424.issue6468@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Yes, this is intended. PyDict_GetItem already bypasses user __getitem__
methods, so it's logical it would do the same for __missing__.

----------
nosy: +benjamin.peterson
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6468>
_______________________________________

From report at bugs.python.org  Sun Jul 12 19:07:03 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 12 Jul 2009 17:07:03 +0000
Subject: [issue6429] 2to3: fix_future conflicts with fix_print
In-Reply-To: <1246900395.55.0.0522093786653.issue6429@psf.upfronthosting.co.za>
Message-ID: <1247418423.71.0.149540398097.issue6429@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r73981.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6429>
_______________________________________

From report at bugs.python.org  Sun Jul 12 19:07:10 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 12 Jul 2009 17:07:10 +0000
Subject: [issue2412] Check 2to3 for support of print function.
In-Reply-To: <1205883738.38.0.0352891857591.issue2412@psf.upfronthosting.co.za>
Message-ID: <1247418430.81.0.534164492522.issue2412@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r73981.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2412>
_______________________________________

From report at bugs.python.org  Sun Jul 12 20:08:05 2009
From: report at bugs.python.org (jkg)
Date: Sun, 12 Jul 2009 18:08:05 +0000
Subject: [issue6465] email.feedparser regular expression bug (NLCRE_crack)
In-Reply-To: <1247342320.74.0.342668726051.issue6465@psf.upfronthosting.co.za>
Message-ID: <1247422085.36.0.918576546294.issue6465@psf.upfronthosting.co.za>


jkg <python at slashbot.com> added the comment:

Combined patch as requested by pitrou.

(Sorry. This is my first submission.)

----------
Added file: http://bugs.python.org/file14486/nlcre_full.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6465>
_______________________________________

From report at bugs.python.org  Sun Jul 12 21:12:38 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 12 Jul 2009 19:12:38 +0000
Subject: [issue1772794] Telnetlib dosn't accept u'only ascii'
Message-ID: <1247425958.75.0.475948074443.issue1772794@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1772794>
_______________________________________

From report at bugs.python.org  Sun Jul 12 21:47:10 2009
From: report at bugs.python.org (Chris Perkins)
Date: Sun, 12 Jul 2009 19:47:10 +0000
Subject: [issue6469] Function definition expressions feature
In-Reply-To: <1247428030.55.0.162346159839.issue6469@psf.upfronthosting.co.za>
Message-ID: <1247428030.55.0.162346159839.issue6469@psf.upfronthosting.co.za>


New submission from Chris Perkins <chrisperkins99 at gmail.com>:

Proposed feature - function definition expressions, superficially
similar to Ruby blocks.

To be proposed on Python-ideas list.

----------
files: blocks.patch
keywords: patch
messages: 90455
nosy: grammati
severity: normal
status: open
title: Function definition expressions feature
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file14487/blocks.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6469>
_______________________________________

From report at bugs.python.org  Sun Jul 12 22:00:56 2009
From: report at bugs.python.org (Chris Perkins)
Date: Sun, 12 Jul 2009 20:00:56 +0000
Subject: [issue6469] Function definition expressions feature
In-Reply-To: <1247428030.55.0.162346159839.issue6469@psf.upfronthosting.co.za>
Message-ID: <1247428856.8.0.588646973602.issue6469@psf.upfronthosting.co.za>


Chris Perkins <chrisperkins99 at gmail.com> added the comment:

Forgot to mention - the patch is very much incomplete. It breaks tests,
contains none of the work that would need to be done in the ast package,
etc. This is just a proof-of-concept.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6469>
_______________________________________

From report at bugs.python.org  Sun Jul 12 22:22:44 2009
From: report at bugs.python.org (Christoph Gohlke)
Date: Sun, 12 Jul 2009 20:22:44 +0000
Subject: [issue6470] Tkinter import fails when running Python.exe from a
	network share
In-Reply-To: <1247430164.29.0.0724763544583.issue6470@psf.upfronthosting.co.za>
Message-ID: <1247430164.29.0.0724763544583.issue6470@psf.upfronthosting.co.za>


New submission from Christoph Gohlke <cgohlke at uci.edu>:

On Windows Vista 64-bit, when running Python 2.6.2 (32 or 64 bit) from a
network share, e.g. \\Server\Share\python26\python.exe,
importing Tkinter fails with "WindowsError: [Error 3] The system cannot
find the path specified". See session output below for traceback.

This is due to incomplete support for long UNC (UNCW) paths such as
\\?\UNC\Server\Share\File in FixTk.py. 

The attached patch solves this issue.

-Christoph


C:\>\\server\share\python26\python.exe
Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit
(Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from Tkinter import *
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "\\server\share\python26\lib\lib-tk\Tkinter.py", line 38, in <module>
    import FixTk
  File "\\server\share\python26\lib\lib-tk\FixTk.py", line 59, in <module>
    for name in os.listdir(prefix):
WindowsError: [Error 3] The system cannot find the path specified:
u'UNC\\server\\share\\Python26\\tcl\\*.*'

----------
components: Tkinter, Windows
files: Tkinter-import-UNCW.patch
keywords: patch
messages: 90457
nosy: cgohlke
severity: normal
status: open
title: Tkinter import fails when running Python.exe from a network share
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file14488/Tkinter-import-UNCW.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6470>
_______________________________________

From report at bugs.python.org  Sun Jul 12 22:54:35 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 12 Jul 2009 20:54:35 +0000
Subject: [issue6471] errno and strerror attributes incorrectly set on
	socket.error
In-Reply-To: <1247432074.99.0.825435411389.issue6471@psf.upfronthosting.co.za>
Message-ID: <1247432074.99.0.825435411389.issue6471@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

In Python 2.6, socket.error was changed to be a child class of IOError
[1]. IOError derives from EnvironmentError [2], and EnvironmentError
accepts a 2-tuple used to set the values of the errno and strerror
attributes respectively [3].
Apparently the IOError raised by the socket module are instantiated
passing (always?) 'socket error' as first arg and an instance of
socket.gaierror, socket.timeout or socket.herror (and maybe others) as
second arg.
The errno attributes ends up being a string (and not a number) and the
strerror another exception (and not a str):

>>> import socket
>>> from urllib import urlopen
>>> socket.setdefaulttimeout(0.01)
>>> try: urlopen('http://www.python.org')
... except Exception, e: err1 = e
...
>>> err1
IOError('socket error', timeout('timed out',))
>>> err1.errno
'socket error'
>>> err1.strerror
timeout('timed out',)
>>> err1.strerror.errno
>>> err1.strerror.strerror
>>>

>>> try: urlopen('http://www.pythonfoobarbaz.org')
... except Exception, e: err2 = e
...
>>> err2
IOError('socket error', gaierror(11001, 'getaddrinfo failed'))
>>> err1.errno
'socket error'
>>> err1.strerror
timeout('timed out',)
>>> err1.strerror.errno
>>> err2.errno
'socket error'
>>> err2.strerror
gaierror(11001, 'getaddrinfo failed')
>>> err2.strerror.errno
11001
>>> err2.strerror.strerror
'getaddrinfo failed'

The 'socket error' strings doesn't provide any useful information
(herror, gaierror and timeout are already subclasses of socket.error)
and it results in confusing messages like:
IOError: [Errno socket error] [Errno 11001] getaddrinfo failed

The relevant information is not accessible directly on the error but it
is in err.strerror/err.args[1].

IMHO the first arg should be the errno (if it's available) and the
second the message (e.g. 'getaddrinfo failed' or 'timed out').

The doc of socket.error [1] should be also changed because it says:
"The accompanying value is either a string telling what went wrong or a
pair (errno, string) representing an error returned by a system call,
similar to the value accompanying os.error." (and this is actually what
I'd like it to be, but right now it's something different.)

[1]: http://docs.python.org/library/socket.html#socket.error
[2]: http://docs.python.org/library/exceptions.html#exceptions.IOError
[3]:
http://docs.python.org/library/exceptions.html#exceptions.EnvironmentError

----------
assignee: georg.brandl
components: Documentation, Library (Lib)
messages: 90458
nosy: ezio.melotti, georg.brandl
priority: normal
severity: normal
status: open
title: errno and strerror attributes incorrectly set on socket.error
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6471>
_______________________________________

From report at bugs.python.org  Mon Jul 13 00:31:44 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 12 Jul 2009 22:31:44 +0000
Subject: [issue1616979] cp720 encoding map
Message-ID: <1247437904.1.0.224801637702.issue1616979@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Instead of using another source of third-party files, I suggest to use the Windows 
functions to generate the mapping.
The attached patch contains a script, genwincodec.py, which uses MultiByteToWideChar 
and generates a codec file.

I use it like this:
.\PCBuild\python Tools\unicode\genwincodec.py 720 > Lib\encodings\cp720.py

The generated file is also in the patch.

----------
keywords: +needs review -patch
nosy: +amaury.forgeotdarc
stage: test needed -> patch review
Added file: http://bugs.python.org/file14489/genwincodec-trunk.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1616979>
_______________________________________

From report at bugs.python.org  Mon Jul 13 00:41:29 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 12 Jul 2009 22:41:29 +0000
Subject: [issue1616979] cp720 encoding map
Message-ID: <1247438489.31.0.384583768285.issue1616979@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file14490/genwincodec-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1616979>
_______________________________________

From report at bugs.python.org  Mon Jul 13 00:46:22 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sun, 12 Jul 2009 22:46:22 +0000
Subject: [issue6267] Cumulative patcc:h to http and xmlrpc
In-Reply-To: <1244734235.6.0.17264314682.issue6267@psf.upfronthosting.co.za>
Message-ID: <1247438782.81.0.409646304343.issue6267@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Added more regression tests in revision 73986 and revision 73987

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6267>
_______________________________________

From report at bugs.python.org  Mon Jul 13 00:48:17 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 12 Jul 2009 22:48:17 +0000
Subject: [issue1820] Enhance Object/structseq.c to match namedtuple and tuple
	api
In-Reply-To: <1200284428.58.0.762384814897.issue1820@psf.upfronthosting.co.za>
Message-ID: <1247438897.8.0.930772489294.issue1820@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

In Py3.x, this fails:
    "%s.%s.%s-%s-%s" % sys.version_info

The reason is that PyUnicode_Format() expects a real tuple, not a tuple
lookalike.  The fix is to either have structseq inherit from tuple or to
modify PyUnicode_Format() to handle structseq:

   if (PyCheck_StructSeq(args)) {
      newargs = PyTuple_FromSequence(args);
      if (newargs == NULL)
          return NULL;
      result = PyUncode_Format(format, newargs);
      Py_DECREF(newargs);
      return result;
   }

----------
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1820>
_______________________________________

From report at bugs.python.org  Mon Jul 13 01:15:18 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 12 Jul 2009 23:15:18 +0000
Subject: [issue6471] errno and strerror attributes incorrectly set on
	socket.error
In-Reply-To: <1247432074.99.0.825435411389.issue6471@psf.upfronthosting.co.za>
Message-ID: <1247440518.36.0.827257466408.issue6471@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

No, it seems that 2.5 has the same problem. The 'socket error' message is 
raised in urllib.py.  The socket module is innocent to me...
It appears that this file routinely raises IOErrors, passing various 
arguments, which are not stored properly in the IOError object. IMO it 
should raise subclasses of IOError.
In this particular case of "socket error", it should let the exception 
propagate. Other occurrences need more thinking.

----------
assignee: georg.brandl -> 
components:  -Documentation
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6471>
_______________________________________

From report at bugs.python.org  Mon Jul 13 01:42:47 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 12 Jul 2009 23:42:47 +0000
Subject: [issue6465] email.feedparser regular expression bug (NLCRE_crack)
In-Reply-To: <1247342320.74.0.342668726051.issue6465@psf.upfronthosting.co.za>
Message-ID: <1247442167.66.0.198324665775.issue6465@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Sorry for giving you a slightly wrong indication. The email tests are
called from Lib/test/test_email.py, but it redirects to
Lib/email/test/*. In any case, there's no point in creating a separate
test script for such a detail, you should add your test to one of the
existing test scripts instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6465>
_______________________________________

From report at bugs.python.org  Mon Jul 13 02:06:50 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 13 Jul 2009 00:06:50 +0000
Subject: [issue6470] Tkinter import fails when running Python.exe from a
	network share
In-Reply-To: <1247430164.29.0.0724763544583.issue6470@psf.upfronthosting.co.za>
Message-ID: <1247443610.38.0.88607082412.issue6470@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Confirmed here. Added a unit test.

----------
assignee:  -> loewis
keywords: +needs review
nosy: +amaury.forgeotdarc, loewis
stage:  -> patch review
Added file: http://bugs.python.org/file14491/tk-unc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6470>
_______________________________________

From report at bugs.python.org  Mon Jul 13 02:55:53 2009
From: report at bugs.python.org (Mitchell Model)
Date: Mon, 13 Jul 2009 00:55:53 +0000
Subject: [issue6472] Inconsistent use of "iterator" in ElementTree doc & diff
	between Py and C modules
In-Reply-To: <1247446553.79.0.919218325186.issue6472@psf.upfronthosting.co.za>
Message-ID: <1247446553.79.0.919218325186.issue6472@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

I can't quite sort this out, because it's difficult to see what is
intended. The documentation of xml.etree.ElementTree (19.11 in the
Library doc) uses terms like "iterator", "tree iterator", "iterable",
"list" in vague and perhaps not quite accurate ways. I can't tell from
the documentation which functions/methods return lists, which return a
generator, which return an unspecified kind of iterable, and so on.
Moreover, the results are different using ElementTree than they are
using cElementTree. In particular, getiterator() returns a list in
ElementTree and a generator in cElementTree. This can make a substantial
difference in performance when iterating over a large number of nodes
(in addition to cElementTree's parsing being what appears to be about
10x faster).

I think someone should go over the page and sort this out and make it
clear what the user can expect. (I don't think it's fair to
overgeneralize to things like "iterables" if the module is really meant
to be making a commitment to a list or a generator.) I also think that
the differences in the results of methods returned in the Python and C
versions of the module should be highlighted.

I stumbled on this trying to parses and extract individual bits of
information out of large XML files. I full well realize there are better
ways to do this (SAX, e.g.) and better ways to search than just iterate
over all the tags of the type I'm interested in, but I should still know
what to expect from ElementTree, especially because it is so wonderful!

----------
assignee: georg.brandl
components: Documentation
messages: 90465
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Inconsistent use of "iterator" in ElementTree doc & diff between Py and C modules
versions: Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6472>
_______________________________________

From report at bugs.python.org  Mon Jul 13 03:32:33 2009
From: report at bugs.python.org (Jerry Chen)
Date: Mon, 13 Jul 2009 01:32:33 +0000
Subject: [issue6472] Inconsistent use of "iterator" in ElementTree doc & diff
	between Py and C modules
In-Reply-To: <1247446553.79.0.919218325186.issue6472@psf.upfronthosting.co.za>
Message-ID: <1247448753.1.0.306941490225.issue6472@psf.upfronthosting.co.za>


Changes by Jerry Chen <jerry at 3rdengine.com>:


----------
nosy: +effbot

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6472>
_______________________________________

From report at bugs.python.org  Mon Jul 13 04:24:16 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 13 Jul 2009 02:24:16 +0000
Subject: [issue6472] Inconsistent use of "iterator" in ElementTree doc & diff
	between Py and C modules
In-Reply-To: <1247446553.79.0.919218325186.issue6472@psf.upfronthosting.co.za>
Message-ID: <1247451856.48.0.0129093799584.issue6472@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee: georg.brandl -> effbot

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6472>
_______________________________________

From report at bugs.python.org  Mon Jul 13 04:37:01 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Jul 2009 02:37:01 +0000
Subject: [issue6471] errno and strerror attributes incorrectly set on
	socket.error
In-Reply-To: <1247432074.99.0.825435411389.issue6471@psf.upfronthosting.co.za>
Message-ID: <1247452621.75.0.383535447639.issue6471@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yes, it looks to me like urllib is intentionally putting the 'socket
error' or 'url error' into the errno position in the IOError arguments.
 Now that socket.error is an IOError, that at least seems wrong.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6471>
_______________________________________

From report at bugs.python.org  Mon Jul 13 04:37:48 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Jul 2009 02:37:48 +0000
Subject: [issue6471] errno and strerror attributes incorrectly set on socket
	errors wrapped by urllib
In-Reply-To: <1247432074.99.0.825435411389.issue6471@psf.upfronthosting.co.za>
Message-ID: <1247452668.42.0.834487293913.issue6471@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
title: errno and strerror attributes incorrectly set on socket.error -> errno and strerror attributes incorrectly set on socket errors wrapped by urllib

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6471>
_______________________________________

From report at bugs.python.org  Mon Jul 13 05:56:51 2009
From: report at bugs.python.org (Iain Wade)
Date: Mon, 13 Jul 2009 03:56:51 +0000
Subject: [issue6473] hmac sha384/sha512 fails test vectors
In-Reply-To: <1247457411.29.0.0335702117949.issue6473@psf.upfronthosting.co.za>
Message-ID: <1247457411.29.0.0335702117949.issue6473@psf.upfronthosting.co.za>


New submission from Iain Wade <iwade at optusnet.com.au>:

Test vectors are in the following draft rfc:
http://tools.ietf.org/html/draft-nystrom-smime-hmac-sha

The problem is that hmac.py has a hard-coded block size of 64, while 
SHA-384 and SHA-512 have a 128-byte block size.

Suggested fix is either:

a/ have the various hashlib libraries export block size (like they 
currently do for digest_size).

b/ parameterize blocksize to the constructor so that users can override.

c/ I have no third suggestion.

I have made available a codified version of the test vectors for your 
convenience.

----------
components: Library (Lib)
files: test_vectors.py
messages: 90467
nosy: iwade
severity: normal
status: open
title: hmac sha384/sha512 fails test vectors
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file14492/test_vectors.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6473>
_______________________________________

From report at bugs.python.org  Mon Jul 13 07:09:34 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 13 Jul 2009 05:09:34 +0000
Subject: [issue1616979] cp720 encoding map
Message-ID: <1247461774.33.0.335926925975.issue1616979@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Amaury: your approach sounds fine to me, please apply.

----------
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1616979>
_______________________________________

From report at bugs.python.org  Mon Jul 13 07:29:33 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 13 Jul 2009 05:29:33 +0000
Subject: [issue1616979] cp720 encoding map
Message-ID: <1247462973.99.0.316028614249.issue1616979@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Reconsidering, I'd like to ask for two changes:
- please record the command(s) used to generate tables on Windows
somewhere, in either Tools/unicode/Makefile, or a separate batch file.
- please arrange for the doc string of the generated file to identify
the source of the data base; in particular, make sure that the Windows
version on which this was run is identified. It might be that future
Windows versions change the mappings.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1616979>
_______________________________________

From report at bugs.python.org  Mon Jul 13 09:45:36 2009
From: report at bugs.python.org (ivank)
Date: Mon, 13 Jul 2009 07:45:36 +0000
Subject: [issue6071] no longer possible to hash arrays
In-Reply-To: <1242839835.2.0.379423337964.issue6071@psf.upfronthosting.co.za>
Message-ID: <1247471136.04.0.973393666524.issue6071@psf.upfronthosting.co.za>


ivank <ivan at ludios.org> added the comment:

It no longer works with objects created with buffer() either:

>>> hashlib.sha1(buffer("x")).hexdigest()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: object supporting the buffer API required

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6071>
_______________________________________

From report at bugs.python.org  Mon Jul 13 10:28:58 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 13 Jul 2009 08:28:58 +0000
Subject: [issue6457] subprocess.Popen.communicate can lose data from
	output/error streams when broken input pipe occures
In-Reply-To: <1247229365.37.0.486388451669.issue6457@psf.upfronthosting.co.za>
Message-ID: <1247473738.31.0.165136094949.issue6457@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Testing on Debian with latest trunk:
- the proposed example code works very well (I get all data).
- I added "subprocess._has_poll = False", and some (sometimes all) data
is lost. It seems that select() will return stdin even if it is not
writable.

On Windows of course, communicate() uses a blocking write, and always fail.

The proposed patch ignore the errors when EPIPE is raised, and simply
stops writing.

----------
keywords: +needs review, patch
nosy: +amaury.forgeotdarc
stage:  -> patch review
Added file: http://bugs.python.org/file14493/broken_pipe.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6457>
_______________________________________

From report at bugs.python.org  Mon Jul 13 10:56:28 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 13 Jul 2009 08:56:28 +0000
Subject: [issue1820] Enhance Object/structseq.c to match namedtuple and
	tuple	api
In-Reply-To: <1247438897.8.0.930772489294.issue1820@psf.upfronthosting.co.za>
Message-ID: <4A5AF6B9.8090604@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Raymond Hettinger wrote:
> Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:
> 
> In Py3.x, this fails:
>     "%s.%s.%s-%s-%s" % sys.version_info
> 
> The reason is that PyUnicode_Format() expects a real tuple, not a tuple
> lookalike.  The fix is to either have structseq inherit from tuple or to
> modify PyUnicode_Format() to handle structseq:
> 
>    if (PyCheck_StructSeq(args)) {
>       newargs = PyTuple_FromSequence(args);
>       if (newargs == NULL)
>           return NULL;
>       result = PyUncode_Format(format, newargs);
>       Py_DECREF(newargs);
>       return result;
>    }

-1

The special-casing of tuples vs. non-tuples for % is already
bad enough. Adding structseq as another special case doesn't
make that any better.

What's so hard about writing

"%s.%s.%s-%s-%s" % tuple(sys.version_info)

anyway ?

----------
nosy: +lemburg
title: Enhance Object/structseq.c to match namedtuple and tuple api -> Enhance Object/structseq.c to match namedtuple and tuple	api

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1820>
_______________________________________

From report at bugs.python.org  Mon Jul 13 12:21:42 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 13 Jul 2009 10:21:42 +0000
Subject: [issue6473] hmac sha384/sha512 fails test vectors
In-Reply-To: <1247457411.29.0.0335702117949.issue6473@psf.upfronthosting.co.za>
Message-ID: <1247480502.21.0.597112353256.issue6473@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
priority:  -> critical
stage:  -> needs patch
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6473>
_______________________________________

From report at bugs.python.org  Mon Jul 13 12:26:21 2009
From: report at bugs.python.org (Tomas Hoger)
Date: Mon, 13 Jul 2009 10:26:21 +0000
Subject: [issue5753] CVE-2008-5983 python: untrusted python modules search path
In-Reply-To: <1239709179.65.0.173847743531.issue5753@psf.upfronthosting.co.za>
Message-ID: <1247480781.92.0.954708331812.issue5753@psf.upfronthosting.co.za>


Tomas Hoger <thoger at redhat.com> added the comment:

Additional API has one disadvantage - it requires a modification of all
affected applications embedding python, which is not likely to happen
soon after the API is introduced.

Therefore, it may still be worth reviewing current behaviour (that
seemed to have had no documentation until recently, see issue #5144, and
can probably still benefit from more warnings related to the embedded
use) in this corner case (argv0 is bogus and contains no '/') to see if
it may be worth changing in future python versions.

As for command line flags, I presume you're referring to the
'wcscmp(argv0, L"-c")' part of the patch.  It's not more than a re-use
of the pattern already used couple of times in the PySys_SetArgv, that
got added via:

http://svn.python.org/view?view=rev&revision=39544

Again, it's an attempt to make sure this only changes behaviour in
rather specific case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5753>
_______________________________________

From report at bugs.python.org  Mon Jul 13 12:55:22 2009
From: report at bugs.python.org (Chris Perkins)
Date: Mon, 13 Jul 2009 10:55:22 +0000
Subject: [issue6469] Function definition expressions feature
In-Reply-To: <1247428030.55.0.162346159839.issue6469@psf.upfronthosting.co.za>
Message-ID: <1247482522.84.0.423957004083.issue6469@psf.upfronthosting.co.za>


Chris Perkins <chrisperkins99 at gmail.com> added the comment:

Details and discussion: 
http://groups.google.com/group/python-ideas/browse_frm/thread/a2bb1ff3992d9c01

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6469>
_______________________________________

From report at bugs.python.org  Mon Jul 13 12:56:22 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 13 Jul 2009 10:56:22 +0000
Subject: [issue6444] multiline exception logging via syslog handler
In-Reply-To: <1247124840.28.0.246529396761.issue6444@psf.upfronthosting.co.za>
Message-ID: <1247482582.46.0.255335786997.issue6444@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Why can't you either use %r in the format string if you know you'll be
printing out multiple lines, or define your own handler/formatter to do
exactly what you want? I can't see how to provide what you need in a
generally useful way in the stdlib.

----------
assignee:  -> vsajip
nosy: +vsajip
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6444>
_______________________________________

From report at bugs.python.org  Mon Jul 13 13:12:34 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 13 Jul 2009 11:12:34 +0000
Subject: [issue6458] With logging.config.fileConfig can't create logger
	without handler
In-Reply-To: <1247232526.2.0.244135072278.issue6458@psf.upfronthosting.co.za>
Message-ID: <1247483554.94.0.298099451154.issue6458@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Just set up a handlers= line in the relevant sections. You don't have to
actually specify any handlers.

----------
nosy: +vsajip
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6458>
_______________________________________

From report at bugs.python.org  Mon Jul 13 13:29:42 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 13 Jul 2009 11:29:42 +0000
Subject: [issue6314] logging.basicConfig(level='DEBUG',
	... and setLevel("DEBUG") result in no logging
In-Reply-To: <1245473929.89.0.283081310598.issue6314@psf.upfronthosting.co.za>
Message-ID: <1247484582.42.0.335169278755.issue6314@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Fixed checked into trunk & py3k as per msg90214.

----------
resolution:  -> fixed
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6314>
_______________________________________

From report at bugs.python.org  Mon Jul 13 14:12:17 2009
From: report at bugs.python.org (Dariusz Walczak)
Date: Mon, 13 Jul 2009 12:12:17 +0000
Subject: [issue6457] subprocess.Popen.communicate can lose data from
	output/error streams when broken input pipe occures
In-Reply-To: <1247229365.37.0.486388451669.issue6457@psf.upfronthosting.co.za>
Message-ID: <1247487137.02.0.351722153993.issue6457@psf.upfronthosting.co.za>


Dariusz Walczak <dariusz.walczak at gmail.com> added the comment:

Your patch works for me with one exception:

On FreeBSD (python 2.6.1) OSError exception is raised by os.write
instead of IOError exception (raised by self.stdin.write on Windows).
The error code is same on both platforms.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6457>
_______________________________________

From report at bugs.python.org  Mon Jul 13 14:19:16 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 13 Jul 2009 12:19:16 +0000
Subject: [issue6457] subprocess.Popen.communicate can lose data from
	output/error streams when broken input pipe occures
In-Reply-To: <1247229365.37.0.486388451669.issue6457@psf.upfronthosting.co.za>
Message-ID: <1247487556.64.0.97387796527.issue6457@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Right, file.write raises IOError when os.write raises OSError :-(
Updated the patch.

----------
Added file: http://bugs.python.org/file14494/broken_pipe-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6457>
_______________________________________

From report at bugs.python.org  Mon Jul 13 15:01:39 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 13 Jul 2009 13:01:39 +0000
Subject: [issue5753] CVE-2008-5983 python: untrusted python modules search path
In-Reply-To: <1239709179.65.0.173847743531.issue5753@psf.upfronthosting.co.za>
Message-ID: <1247490099.95.0.974436946034.issue5753@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Indeed, it would certainly be useful to review current behaviour and
document it precisely; and then, perhaps change it in order to fix the
current bug. The problem is that the current behaviour seems to have
evolved quite organically, and it's not obvious who relies on what (as I
said, Python has many users). I'm not myself motivated in doing such a
research. Perhaps other developers can chime in.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5753>
_______________________________________

From report at bugs.python.org  Mon Jul 13 15:14:41 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 13 Jul 2009 13:14:41 +0000
Subject: [issue5753] CVE-2008-5983 python: untrusted python modules search path
In-Reply-To: <1239709179.65.0.173847743531.issue5753@psf.upfronthosting.co.za>
Message-ID: <1247490881.58.0.679657787131.issue5753@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Besides, the new API makes the behaviour more explicit and puts the
decision in the hands of the embedding developer (which certainly knows
better than us what he wants to do).
As the Python Zen says:

In the face of ambiguity, refuse the temptation to guess.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5753>
_______________________________________

From report at bugs.python.org  Mon Jul 13 15:35:16 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Jul 2009 13:35:16 +0000
Subject: [issue6469] Function definition expressions feature
In-Reply-To: <1247428030.55.0.162346159839.issue6469@psf.upfronthosting.co.za>
Message-ID: <1247492116.95.0.283495770752.issue6469@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Even assuming you'd gotten a rough consensus on python-ideas (which it
does not appear that you have), a change of this nature would require a
PEP, and is thus not suitable for the tracker.

----------
nosy: +r.david.murray
priority:  -> normal
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6469>
_______________________________________

From report at bugs.python.org  Mon Jul 13 16:08:31 2009
From: report at bugs.python.org (Eric Eisner)
Date: Mon, 13 Jul 2009 14:08:31 +0000
Subject: [issue6433] multiprocessing: pool.map hangs on empty list
In-Reply-To: <1246966744.58.0.524623595855.issue6433@psf.upfronthosting.co.za>
Message-ID: <1247494111.9.0.872551746405.issue6433@psf.upfronthosting.co.za>


Eric Eisner <ede at mit.edu> added the comment:

Can anyone review this patch? It is a very simple fix to catch this one
edge case. As this can cause multiprocessing to enter a state where it
needs to be externally killed, it would be good if this made 2.6.3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6433>
_______________________________________

From report at bugs.python.org  Mon Jul 13 16:25:26 2009
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 13 Jul 2009 14:25:26 +0000
Subject: [issue6433] multiprocessing: pool.map hangs on empty list
In-Reply-To: <1246966744.58.0.524623595855.issue6433@psf.upfronthosting.co.za>
Message-ID: <1247495126.69.0.25575719347.issue6433@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

It's on my list for this week.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6433>
_______________________________________

From report at bugs.python.org  Mon Jul 13 16:36:45 2009
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Mon, 13 Jul 2009 14:36:45 +0000
Subject: [issue6474] Inconsistent TypeError message on function calls with
	wrong number of arguments
In-Reply-To: <1247495805.32.0.528519491274.issue6474@psf.upfronthosting.co.za>
Message-ID: <1247495805.32.0.528519491274.issue6474@psf.upfronthosting.co.za>


New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:

I think the following error messages are inconsistent and confusing:

>>> def f(a, b): pass
...
>>> f(a=1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: f() takes exactly 2 non-keyword positional arguments (1 given)
>>> f(b=1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: f() takes exactly 2 non-keyword positional arguments (0 given)


Strictly speaking, no positional arguments are given in either case, so
it should say "(0 given)" in both cases. On the other hand, the given
keyword arguments are filled into the positional argument slots, so
stating something like "(1 missing)" or "(1 unspecified)" in both cases
seems to make more sense. Any opinions?

----------
components: Interpreter Core
messages: 90485
nosy: hagen
severity: normal
status: open
title: Inconsistent TypeError message on function calls with wrong number of arguments
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6474>
_______________________________________

From report at bugs.python.org  Mon Jul 13 16:57:41 2009
From: report at bugs.python.org (Retro)
Date: Mon, 13 Jul 2009 14:57:41 +0000
Subject: [issue6475] Documentation > Tutorial > List Comprehensions
In-Reply-To: <1247497060.84.0.358633724956.issue6475@psf.upfronthosting.co.za>
Message-ID: <1247497060.84.0.358633724956.issue6475@psf.upfronthosting.co.za>


New submission from Retro <vinetouu at gmail.com>:

There's a mistake in the code snippet:

>>> freshfruit = ['  banana', '  loganberry ', 'passion fruit  ']
>>> [weapon.strip() for weapon in freshfruit]
['banana', 'loganberry', 'passion fruit']


The second line should be:
>>> [fruit.strip() for fruit in freshfruit]
['banana', 'loganberry', 'passion fruit']


The old code snippet had weapons as items which many people didn't like,
so the code snippet was changed into a friendlier version. Please fix
this code snippet so that weapons are not involved here, even though the
code is not broken. Thank you.

----------
assignee: georg.brandl
components: Documentation
messages: 90486
nosy: Retro, georg.brandl
severity: normal
status: open
title: Documentation > Tutorial > List Comprehensions
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6475>
_______________________________________

From report at bugs.python.org  Mon Jul 13 17:16:01 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 13 Jul 2009 15:16:01 +0000
Subject: [issue6475] Documentation > Tutorial > List Comprehensions
In-Reply-To: <1247497060.84.0.358633724956.issue6475@psf.upfronthosting.co.za>
Message-ID: <1247498161.11.0.166807407517.issue6475@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

That example was introduced in r16743 as:
>>> spcs = ["  Apple", " Banana ", "Coco  nut  "]
>>> print [s.strip() for s in spcs]
['Apple', 'Banana', 'Coco  nut']

and was changed in r16831 to:
>>> freshfruit = ['  banana', '  loganberry ', 'passion fruit  ']
>>> [weapon.strip() for weapon in freshfruit]
['banana', 'loganberry', 'passion fruit']

I think that the fresh fruits can really be considered as dangerous
weapons - especially the banana. <wink>

----------
nosy: +ezio.melotti
priority:  -> low
resolution:  -> rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6475>
_______________________________________

From report at bugs.python.org  Mon Jul 13 17:20:59 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 13 Jul 2009 15:20:59 +0000
Subject: [issue6475] Documentation > Tutorial > List Comprehensions
In-Reply-To: <1247497060.84.0.358633724956.issue6475@psf.upfronthosting.co.za>
Message-ID: <1247498459.61.0.716777051069.issue6475@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> I think that the fresh fruits can really be considered as dangerous
> weapons.

Indeed.  Google for "monty python self-defence against fresh fruit".

----------
nosy: +marketdickinson
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6475>
_______________________________________

From report at bugs.python.org  Mon Jul 13 17:21:12 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 13 Jul 2009 15:21:12 +0000
Subject: [issue6475] Documentation > Tutorial > List Comprehensions
In-Reply-To: <1247497060.84.0.358633724956.issue6475@psf.upfronthosting.co.za>
Message-ID: <1247498472.44.0.915163811425.issue6475@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6475>
_______________________________________

From report at bugs.python.org  Mon Jul 13 17:26:34 2009
From: report at bugs.python.org (Jorrit Posthuma)
Date: Mon, 13 Jul 2009 15:26:34 +0000
Subject: [issue1563] asyncore and asynchat incompatible with Py3k str and bytes
In-Reply-To: <1196967051.24.0.955219786763.issue1563@psf.upfronthosting.co.za>
Message-ID: <1247498794.38.0.595073177918.issue1563@psf.upfronthosting.co.za>


Jorrit Posthuma <j.posthuma at gmail.com> added the comment:

It's not 'that' clear you should only work with bytes on a socket. 
Especially not when using a wrapper like asynchat. They are supposed to 
make it easier, and passing a string is easier. Maybe it's possible to do 
a default byte conversion when the user is working with strings.

----------
nosy: +JPosthuma

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1563>
_______________________________________

From report at bugs.python.org  Mon Jul 13 17:33:23 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 13 Jul 2009 15:33:23 +0000
Subject: [issue1563] asyncore and asynchat incompatible with Py3k str and bytes
In-Reply-To: <1196967051.24.0.955219786763.issue1563@psf.upfronthosting.co.za>
Message-ID: <1247499203.27.0.314005382859.issue1563@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

> It's not 'that' clear you should only work with bytes on a socket. 

It's pretty clear to me. :)  That's what sockets can deal with - bytes.
 If you want to transfer something other than bytes via a socket, then
you need to convert it to bytes.  In the case of unicode, there are many
different choices which can be made for how to do this conversion. 
asyncore cannot know what the correct choice is in any particular
situation, so it shouldn't try to make it.

The attached patch forces the application to make this choice,
fortunately.  However, since push_str is only one line, I'm not sure
what the attraction is.  Why is push_str(foo, bar) preferable to
push(foo.encode(bar))?

> Maybe it's possible to do a default byte conversion when the user is
working with strings.

This definitely isn't reasonable and should not be done.  It's also not
what the last proposed patch does, so it doesn't seem to the direction
the other interested parties have been working in.

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1563>
_______________________________________

From report at bugs.python.org  Mon Jul 13 17:46:53 2009
From: report at bugs.python.org (Jorrit Posthuma)
Date: Mon, 13 Jul 2009 15:46:53 +0000
Subject: [issue1563] asyncore and asynchat incompatible with Py3k str and bytes
In-Reply-To: <1247499203.27.0.314005382859.issue1563@psf.upfronthosting.co.za>
Message-ID: <02161F39-4180-43BA-87CC-C9AD621C5A22@gmail.com>


Jorrit Posthuma <j.posthuma at gmail.com> added the comment:

On 13 jul 2009, at 17:33, Jean-Paul Calderone wrote:
>
> Jean-Paul Calderone <exarkun at divmod.com> added the comment:
>
>> It's not 'that' clear you should only work with bytes on a socket.
>
> It's pretty clear to me. :)  That's what sockets can deal with -  
> bytes.

It's allso clear to me, but there are people that don't know that.

> If you want to transfer something other than bytes via a socket, then
> you need to convert it to bytes.  In the case of unicode, there are  
> many
> different choices which can be made for how to do this conversion.
> asyncore cannot know what the correct choice is in any particular
> situation, so it shouldn't try to make it.
>
> The attached patch forces the application to make this choice,
> fortunately.  However, since push_str is only one line, I'm not sure
> what the attraction is.  Why is push_str(foo, bar) preferable to
> push(foo.encode(bar))?

It's not, I was more thinking of push_str(foo), where it uses a  
default encoding. I think some people don't know what unicode or  
encoding is, or don't want to worry about it.

>
>> Maybe it's possible to do a default byte conversion when the user  
>> is working with strings.
>
> This definitely isn't reasonable and should not be done.  It's also  
> not
> what the last proposed patch does, so it doesn't seem to the direction
> the other interested parties have been working in.

It's not an attack ;), i'm pretty new to Python, and it was just  
something that i noticed (after changing from 2 to 3)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1563>
_______________________________________

From report at bugs.python.org  Mon Jul 13 17:50:47 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 13 Jul 2009 15:50:47 +0000
Subject: [issue1563] asyncore and asynchat incompatible with Py3k str and bytes
In-Reply-To: <1196967051.24.0.955219786763.issue1563@psf.upfronthosting.co.za>
Message-ID: <1247500247.15.0.267895204685.issue1563@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

> It's not, I was more thinking of push_str(foo), where it uses a
default encoding. I think some people don't know what unicode or
encoding is, or don't want to worry about it.

Nice as it sounds, the problem with this is that those people cannot
write correct programs without understanding this.  A push_str API which
implicitly encodes unicode to str would just be a point for bugs to be
introduced.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1563>
_______________________________________

From report at bugs.python.org  Mon Jul 13 18:34:16 2009
From: report at bugs.python.org (Michael Foord)
Date: Mon, 13 Jul 2009 16:34:16 +0000
Subject: [issue6418] unittest.TestProgram change breaks nose
In-Reply-To: <1246739248.73.0.754849239276.issue6418@psf.upfronthosting.co.za>
Message-ID: <1247502856.08.0.15504767655.issue6418@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Committed in revision 6418. Still needs fixing in trunk (note the patch
itself can't be applied as it is missing a couple of 'self's).

Having problems testing this fix without causing spurious output on stderr.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6418>
_______________________________________

From report at bugs.python.org  Mon Jul 13 18:37:40 2009
From: report at bugs.python.org (Michael Foord)
Date: Mon, 13 Jul 2009 16:37:40 +0000
Subject: [issue6418] unittest.TestProgram change breaks nose
In-Reply-To: <1246739248.73.0.754849239276.issue6418@psf.upfronthosting.co.za>
Message-ID: <1247503060.53.0.370953426487.issue6418@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Oops - I meant revision 73997 of course.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6418>
_______________________________________

From report at bugs.python.org  Mon Jul 13 19:11:09 2009
From: report at bugs.python.org (Jose Fonseca)
Date: Mon, 13 Jul 2009 17:11:09 +0000
Subject: [issue6476] MSVCRT's spawnve/spawnvpe are not thread safe
In-Reply-To: <1247505068.9.0.23655949974.issue6476@psf.upfronthosting.co.za>
Message-ID: <1247505068.9.0.23655949974.issue6476@psf.upfronthosting.co.za>


New submission from Jose Fonseca <jose.r.fonseca at gmail.com>:

MSVCRT's implementation of _spawnve, _spawnvpe, or any version that
takes an environ as paramater is not thread-safe, because it stores a
temporary environment string into a global variable.

_spawnve, _spawnvpe, and friends call a function named _cenvarg which
concatenate the environment strings into a global variable called
_aenvptr, which gets free'd and zero'd after each invocation.

This was causing random build failures in scons when parallel build (-j)
was enabled.

The sample application evidences this problem. It also includes a simple
workaround in python, by acquiring a global lock around os.spawnve, and
simulating P_WAIT with P_NOWAIT to avoid holding the global lock while
the child process is running. I believe something along these lines
should be done for CPython on Windows.

----------
components: Interpreter Core
files: spawnve.py
messages: 90495
nosy: jfonseca
severity: normal
status: open
title: MSVCRT's spawnve/spawnvpe are not thread safe
type: crash
versions: Python 2.4, Python 2.5, Python 2.6
Added file: http://bugs.python.org/file14495/spawnve.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6476>
_______________________________________

From report at bugs.python.org  Mon Jul 13 19:20:42 2009
From: report at bugs.python.org (July Tikhonov)
Date: Mon, 13 Jul 2009 17:20:42 +0000
Subject: [issue6477] Pickling of NoneType raises PicklingError
In-Reply-To: <1247505641.96.0.188774248495.issue6477@psf.upfronthosting.co.za>
Message-ID: <1247505641.96.0.188774248495.issue6477@psf.upfronthosting.co.za>


New submission from July Tikhonov <july.tikh at gmail.com>:

Python 3.2a0 (py3k:73749M, Jul  1 2009, 23:17:59)
[GCC 4.3.2 [gcc-4_3-branch revision 141291]] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pickle
[40072 refs]
>>> pickle.dumps(type(None))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.2/pickle.py", line 1358, in dumps
    Pickler(f, protocol, fix_imports=fix_imports).dump(obj)
_pickle.PicklingError: Can't pickle <class 'NoneType'>: attribute 
lookup builtins.NoneType failed
[40137 refs]
>>>

----------
components: Library (Lib)
messages: 90496
nosy: July
severity: normal
status: open
title: Pickling of NoneType raises PicklingError
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6477>
_______________________________________

From report at bugs.python.org  Mon Jul 13 19:33:46 2009
From: report at bugs.python.org (Mihai Ibanescu)
Date: Mon, 13 Jul 2009 17:33:46 +0000
Subject: [issue6478] time.tzset does not reset _strptime's locale time cache
In-Reply-To: <1247506425.36.0.284798334504.issue6478@psf.upfronthosting.co.za>
Message-ID: <1247506425.36.0.284798334504.issue6478@psf.upfronthosting.co.za>


New submission from Mihai Ibanescu <mihai.ibanescu at gmail.com>:

If one changes from one timezone to another within the same python
process, and if one tries to parse a time string that includes the
timezone, the library malfunctions.

See attached script for a reproducer.

The problem is that, even though time.tzset() is called, the LocaleTime
persisted in the TimeRE global is not reset. In my example, the EDT
timezone name, compiled from the previous TZ variable, is not valid
anymore in the 'Pacific/Fiji' timezone.

To witness the behavior, run the attached script with no arguments. It
will parse the time in the America/New_York timezone just fine.

Then run it with an argument (like python ttime.py 1). It will first
prime the _strptime cache in the Pacific/Fiji timezone, then attempt to
parse the same time string in the America/New_York timezone.

Finally, you can change the "if 0" to "if 1" for working around the problem.

This has been verified in 2.4.4 and 2.6.1 (did not have a chance to
verify it against python 2.6.2 yet).

----------
components: Library (Lib)
files: ttime.py
messages: 90497
nosy: mibanescu
severity: normal
status: open
title: time.tzset does not reset _strptime's locale time cache
type: behavior
versions: Python 2.4, Python 2.6
Added file: http://bugs.python.org/file14496/ttime.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6478>
_______________________________________

From report at bugs.python.org  Mon Jul 13 21:02:35 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 13 Jul 2009 19:02:35 +0000
Subject: [issue6476] MSVCRT's spawnve/spawnvpe are not thread safe
In-Reply-To: <1247505068.9.0.23655949974.issue6476@psf.upfronthosting.co.za>
Message-ID: <1247511755.15.0.0581658106131.issue6476@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Indeed. But shouldn't you use the subprocess module instead?

----------
nosy: +amaury.forgeotdarc
resolution:  -> wont fix
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6476>
_______________________________________

From report at bugs.python.org  Mon Jul 13 21:38:15 2009
From: report at bugs.python.org (John Burnett)
Date: Mon, 13 Jul 2009 19:38:15 +0000
Subject: [issue6479] platform.py writes to hard coded platform dependant
	"dev/null"
In-Reply-To: <1247513895.35.0.806339405592.issue6479@psf.upfronthosting.co.za>
Message-ID: <1247513895.35.0.806339405592.issue6479@psf.upfronthosting.co.za>


New submission from John Burnett <python at johnburnett.com>:

The functions _syscmd_uname and _syscmd_file are hard-coded to pipe
stderr to "/dev/null", as opposed to os.devnull.  On Windows, this has
the effect of creating a file called "null" to a local "dev" directory
(if the directory exists).

Attached is a fix.  While the _syscmd_uname change isn't entirely
necessary on Windows due to its sys.platform check, I changed both
functions for consistency (and I'm not sure what other platforms might
not have a "/dev/null" either).

----------
components: Library (Lib)
files: devnull.patch
keywords: patch
messages: 90499
nosy: john.burnett
severity: normal
status: open
title: platform.py writes to hard coded platform dependant "dev/null"
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14497/devnull.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6479>
_______________________________________

From report at bugs.python.org  Mon Jul 13 21:45:47 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 13 Jul 2009 19:45:47 +0000
Subject: [issue6479] platform.py writes to hard coded platform dependant
	"dev/null"
In-Reply-To: <1247513895.35.0.806339405592.issue6479@psf.upfronthosting.co.za>
Message-ID: <1247514347.99.0.948967235662.issue6479@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> lemburg
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6479>
_______________________________________

From report at bugs.python.org  Mon Jul 13 22:14:58 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 13 Jul 2009 20:14:58 +0000
Subject: [issue6479] platform.py writes to hard coded platform dependant
	"dev/null"
In-Reply-To: <1247513895.35.0.806339405592.issue6479@psf.upfronthosting.co.za>
Message-ID: <1247516098.02.0.139225716695.issue6479@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On which Windows platform would that be ?

Both internal helper functions bypass using an external command for
Windows and DOS platforms.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6479>
_______________________________________

From report at bugs.python.org  Mon Jul 13 22:56:21 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 13 Jul 2009 20:56:21 +0000
Subject: [issue1616979] cp720 encoding map
Message-ID: <1247518581.57.0.774396426741.issue1616979@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The codec file now starts with the comment:
"""Python Character Mapping Codec cp720 generated on Windows:
Vista 6.0.6002 SP2 Multiprocessor Free with the command:
  python Tools/unicode/genwincodec.py 720
"""

I also added a file Tools\unicode\genwincodecs.bat that currently only 
generates cp720.py.

Applied in r74000 (trunk) and r74003 & r74004 (py3k)

----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1616979>
_______________________________________

From report at bugs.python.org  Mon Jul 13 23:05:24 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 13 Jul 2009 21:05:24 +0000
Subject: [issue6071] no longer possible to hash arrays
In-Reply-To: <1247471136.04.0.973393666524.issue6071@psf.upfronthosting.co.za>
Message-ID: <4A5BA190.8020304@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> It no longer works with objects created with buffer() either:

That's because the buffer objects don't implement the buffer protocol
(in particular, they don't define the Py_TPFLAGS_HAVE_NEWBUFFER flag,
and the bf_getbuffer/bf_releasebuffer operations that go with that flag.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6071>
_______________________________________

From report at bugs.python.org  Mon Jul 13 23:09:12 2009
From: report at bugs.python.org (Jose Fonseca)
Date: Mon, 13 Jul 2009 21:09:12 +0000
Subject: [issue6476] MSVCRT's spawnve/spawnvpe are not thread safe
In-Reply-To: <1247505068.9.0.23655949974.issue6476@psf.upfronthosting.co.za>
Message-ID: <1247519352.52.0.239858064584.issue6476@psf.upfronthosting.co.za>


Jose Fonseca <jose.r.fonseca at gmail.com> added the comment:

Perhaps. I'm not a scons developer -- just an user -- and I don't know
what versions of python far back in time they want support, but it
appears it would make sense to use subprocess where available indeed. I
already I've filled an issue with scons at
http://scons.tigris.org/issues/show_bug.cgi?id=2449 and linked back to
this issue and I trust the developers to do whatever they see fit to
address this problem.

Instead of just marking this issue as won't fix, shouldn't at least some
documentation be added, or something sensible like that? In
http://docs.python.org/library/os.html#process-management os.spawn* are
not marked as deprecated -- just says that "the subprocess module
provides more powerful facilities" and is "preferable" --, and it
certainly doesn't say these functions are not thread safe. It would be a
pity if other users would have to invest as much time as I did to find
this race condition (it was rare, and happened in a build farm so we
couldn't see the windows access violation dialog), and multithreading is
getting more and more common.

Also, if the only reason not to fix this is the lack of a patch I don't
mind in producing one FWIW.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6476>
_______________________________________

From report at bugs.python.org  Mon Jul 13 23:29:40 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 13 Jul 2009 21:29:40 +0000
Subject: [issue3410] platform.version() don't work as expected in Vista in
	portuguese
In-Reply-To: <1216410595.08.0.936182141358.issue3410@psf.upfronthosting.co.za>
Message-ID: <1247520580.63.0.968557346585.issue3410@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

I've checked in patch r74005 to address the problem.

Could you check whether the current SVN version of platform.py works on
your Portuguese Windows version ?

Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3410>
_______________________________________

From report at bugs.python.org  Mon Jul 13 23:59:22 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 13 Jul 2009 21:59:22 +0000
Subject: [issue6475] Documentation > Tutorial > List Comprehensions
In-Reply-To: <1247497060.84.0.358633724956.issue6475@psf.upfronthosting.co.za>
Message-ID: <1247522362.22.0.655085215104.issue6475@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Retro, you still won't give up, will you?

----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6475>
_______________________________________

From report at bugs.python.org  Tue Jul 14 00:01:07 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 13 Jul 2009 22:01:07 +0000
Subject: [issue1820] Enhance Object/structseq.c to match namedtuple and
	tuple	api
In-Reply-To: <1200284428.58.0.762384814897.issue1820@psf.upfronthosting.co.za>
Message-ID: <1247522467.68.0.611190855115.issue1820@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

ISTM that structseq should have been a tuple subclass anyway.  Isn't it
advertised as some sort of "tuple with attribute access"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1820>
_______________________________________

From report at bugs.python.org  Tue Jul 14 00:37:32 2009
From: report at bugs.python.org (John Burnett)
Date: Mon, 13 Jul 2009 22:37:32 +0000
Subject: [issue6479] platform.py writes to hard coded platform dependant
	"dev/null"
In-Reply-To: <1247513895.35.0.806339405592.issue6479@psf.upfronthosting.co.za>
Message-ID: <1247524652.97.0.236661624971.issue6479@psf.upfronthosting.co.za>


John Burnett <python at johnburnett.com> added the comment:

I'm not sure how you're seeing that those functions bypass external
commands?

I'm running Vista64, and it certainly looks like calling
platform.architecture calls _syscmd_file, which then immediately calls
os.popen("file %s 2> /dev/null").  This causes windows to try and open a
file called "file", which fails, and pipes the resulting error ("'file'
is not recognized as an internal or external command, operable program
or batch file.") to a file named "null" in my "c:\dev" directory.

This will happen on any system that doesn't /dev/null.  _syscmd_uname
does the same thing, but "protects" against it by testing for platform
type.  I'm not familiar enough with the supported platforms to know if
it's covering all the bases, but a safer thing to do would be to just
use os.devnull anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6479>
_______________________________________

From report at bugs.python.org  Tue Jul 14 00:52:40 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 13 Jul 2009 22:52:40 +0000
Subject: [issue6479] platform.py writes to hard coded platform dependant
	"dev/null"
In-Reply-To: <1247524652.97.0.236661624971.issue6479@psf.upfronthosting.co.za>
Message-ID: <4A5BBAB4.4020702@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

John Burnett wrote:
> John Burnett <python at johnburnett.com> added the comment:
> 
> I'm not sure how you're seeing that those functions bypass external
> commands?

Both functions use this bypass mechanism:

    if sys.platform in ('dos','win32','win16','os2'):
        return default

> I'm running Vista64, and it certainly looks like calling
> platform.architecture calls _syscmd_file, which then immediately calls
> os.popen("file %s 2> /dev/null").  This causes windows to try and open a
> file called "file", which fails, and pipes the resulting error ("'file'
> is not recognized as an internal or external command, operable program
> or batch file.") to a file named "null" in my "c:\dev" directory.

Could you please tell me what sys.platform is set to on Vista 64 ?

If it's "win64", then I'll have to add that to the above test.
AFAIK, we chose to leave it set to "win32" even on 64-bit Windows
versions, so the above test should trigger on Vista 64 as well.

> This will happen on any system that doesn't /dev/null.  _syscmd_uname
> does the same thing, but "protects" against it by testing for platform
> type.  I'm not familiar enough with the supported platforms to know if
> it's covering all the bases, but a safer thing to do would be to just
> use os.devnull anyway.

I've added a similar patch in r74002, but those functions should
not really do anything on Windows at all.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6479>
_______________________________________

From report at bugs.python.org  Tue Jul 14 01:53:56 2009
From: report at bugs.python.org (John Burnett)
Date: Mon, 13 Jul 2009 23:53:56 +0000
Subject: [issue6479] platform.py writes to hard coded platform dependant
	"dev/null"
In-Reply-To: <1247513895.35.0.806339405592.issue6479@psf.upfronthosting.co.za>
Message-ID: <1247529236.74.0.48220017683.issue6479@psf.upfronthosting.co.za>


John Burnett <python at johnburnett.com> added the comment:

You're right, Vista64 is returning "win32" for the platform.

And ahh, I see what I did: in Python 2.5.2, _syscmd_file wasn't using a
sys.platform check.  Then when I looked at the current version, I saw it
was still using "/dev/null", but didn't see a platform check was added
to skip that part in rev 66104.

Regardless, thanks for adding the change... who knows, it might get hit
some day on a new platform ;).

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6479>
_______________________________________

From report at bugs.python.org  Tue Jul 14 06:48:03 2009
From: report at bugs.python.org (Max Arnold)
Date: Tue, 14 Jul 2009 04:48:03 +0000
Subject: [issue6444] multiline exception logging via syslog handler
In-Reply-To: <1247124840.28.0.246529396761.issue6444@psf.upfronthosting.co.za>
Message-ID: <1247546882.95.0.106118390309.issue6444@psf.upfronthosting.co.za>


Max Arnold <lwarxx at gmail.com> added the comment:

> Why can't you either use %r in the format string, or define your own
handler/formatter to do exactly what you want?

I'm describing default behaviour of logger.exception(). Out of the box
(with SyslogHandler and "/dev/log") I'm unable to use it, because of
this problem.

Can you please explain in more details how I can change my code to
correcly log exceptions?  For example:

import logging, logging.handlers

log = logging.getLogger()
h = logging.handlers.SysLogHandler('/dev/log',
logging.handlers.SysLogHandler.LOG_LOCAL0)
h.setFormatter(logging.Formatter('%(name)s: %(levelname)s
%(funcName)s/%(lineno)d %(message)s'))
log.addHandler(h)

try:
        a = 1/0
except:
        log.exception('division by zero')

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6444>
_______________________________________

From report at bugs.python.org  Tue Jul 14 07:19:58 2009
From: report at bugs.python.org (Sean)
Date: Tue, 14 Jul 2009 05:19:58 +0000
Subject: [issue6480] code.runsource() parsing bug
In-Reply-To: <1247548798.14.0.468793071466.issue6480@psf.upfronthosting.co.za>
Message-ID: <1247548798.14.0.468793071466.issue6480@psf.upfronthosting.co.za>


New submission from Sean <smcallis at gmail.com>:

I'm writing a little pre-processor that just parses python snippets out
of a file and passes them to a code.InteractiveInterpreter, and I'm
noticing some somewhat nasty stuff in how runsource handles some code.

sys.version:
'2.6.2 (r262:71600, Jul 12 2009, 11:52:33) \n[GCC 4.0.1 (Apple Inc.
build 5465)]'     

Doesn't work:
 interpreter.runsource('print("Foo")\nprint "Bar"')  

Works: 
 interpreter.runsource('print("Foo");print "Bar"')

Doesn't work:
 interpreter.runsource('print("Foo");\nprint "Bar"')  
  

Exact output:
>>> interpreter.runsource('print("Foo")\nprint "Bar"')                 
                                            
Foo                                                                    
                                            
False                                                                  
                                            
>>> interpreter.runsource('print("Foo");print "Bar"')                  
                                            
Foo                                                                    
                                            
Bar                                                                    
                                            
False                                                                  
                                            
>>> interpreter.runsource('print("Foo");\nprint "Bar"')                
                                            
Foo                                                                    
                                            
False                                                                  
                                            
>>>     


Is this a known issue? I didn't see it while searching the bug database...

----------
components: None
messages: 90511
nosy: smcallis
severity: normal
status: open
title: code.runsource() parsing bug
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6480>
_______________________________________

From report at bugs.python.org  Tue Jul 14 07:35:37 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 14 Jul 2009 05:35:37 +0000
Subject: [issue6432] ImageTk.PhotoImage
In-Reply-To: <1246962624.44.0.14182359808.issue6432@psf.upfronthosting.co.za>
Message-ID: <1247549737.43.0.498737163348.issue6432@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

ActivePython bug: http://bugs.activestate.com/show_bug.cgi?id=83694

----------
nosy: +srid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6432>
_______________________________________

From report at bugs.python.org  Tue Jul 14 07:41:25 2009
From: report at bugs.python.org (Yinon Ehrlich)
Date: Tue, 14 Jul 2009 05:41:25 +0000
Subject: [issue6481] PATCH: typo in subprocess documentation
In-Reply-To: <1247550085.73.0.0615590411126.issue6481@psf.upfronthosting.co.za>
Message-ID: <1247550085.73.0.0615590411126.issue6481@psf.upfronthosting.co.za>


New submission from Yinon Ehrlich <yinoneh at users.sourceforge.net>:

os.waitpid returns a tuple (pid, status)

----------
assignee: georg.brandl
components: Documentation
files: subprocess.patch
keywords: patch
messages: 90513
nosy: Yinon, georg.brandl
severity: normal
status: open
title: PATCH: typo in subprocess documentation
versions: Python 2.6
Added file: http://bugs.python.org/file14498/subprocess.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6481>
_______________________________________

From report at bugs.python.org  Tue Jul 14 08:24:13 2009
From: report at bugs.python.org (Yinon Ehrlich)
Date: Tue, 14 Jul 2009 06:24:13 +0000
Subject: [issue6482] PATCH: tiny simplification for subprocess
Message-ID: <1247552653.1.0.820711824987.issue6482@psf.upfronthosting.co.za>


Changes by Yinon Ehrlich <yinoneh at users.sourceforge.net>:


----------
files: subprocess.patch
keywords: patch
nosy: Yinon
severity: normal
status: open
title: PATCH: tiny simplification for subprocess
versions: Python 2.7
Added file: http://bugs.python.org/file14499/subprocess.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6482>
_______________________________________

From report at bugs.python.org  Tue Jul 14 14:03:55 2009
From: report at bugs.python.org (Julian Andres Klode)
Date: Tue, 14 Jul 2009 12:03:55 +0000
Subject: [issue6483] Modules are not deallocated correctly if m_size = -1
In-Reply-To: <1247573035.84.0.508855898217.issue6483@psf.upfronthosting.co.za>
Message-ID: <1247573035.84.0.508855898217.issue6483@psf.upfronthosting.co.za>


New submission from Julian Andres Klode <jak at jak-linux.org>:

The documentation states that m_size should be -1 if no additional
memory is needed. But this causes the objects inside the module to not
be deallocated at all.

The attached module (test) stores an object of a type 'Test', which
prints "Deallocation is happening" in it's tp_dealloc. If m_size in the
TestModule is set to -1, this is never reached. If it is 0, it is reached.

----------
components: Interpreter Core
files: test.c
messages: 90514
nosy: jak
severity: normal
status: open
title: Modules are not deallocated correctly if m_size = -1
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file14500/test.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6483>
_______________________________________

From report at bugs.python.org  Tue Jul 14 16:08:13 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 14 Jul 2009 14:08:13 +0000
Subject: [issue6483] Modules are not deallocated correctly if m_size = -1
In-Reply-To: <1247573035.84.0.508855898217.issue6483@psf.upfronthosting.co.za>
Message-ID: <1247580493.09.0.882817433695.issue6483@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> loewis
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6483>
_______________________________________

From report at bugs.python.org  Tue Jul 14 16:11:05 2009
From: report at bugs.python.org (Floris Bruynooghe)
Date: Tue, 14 Jul 2009 14:11:05 +0000
Subject: [issue5672] Implement a way to change the python process name
In-Reply-To: <1238701084.1.0.0781987214897.issue5672@psf.upfronthosting.co.za>
Message-ID: <1247580665.21.0.862320877976.issue5672@psf.upfronthosting.co.za>


Changes by Floris Bruynooghe <floris.bruynooghe at gmail.com>:


----------
nosy: +flub

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5672>
_______________________________________

From report at bugs.python.org  Tue Jul 14 19:59:00 2009
From: report at bugs.python.org (Michael Foord)
Date: Tue, 14 Jul 2009 17:59:00 +0000
Subject: [issue6418] unittest.TestProgram change breaks nose
In-Reply-To: <1246739248.73.0.754849239276.issue6418@psf.upfronthosting.co.za>
Message-ID: <1247594340.88.0.513862783044.issue6418@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Committed to trunk in revision 74007.

----------
assignee:  -> michael.foord
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6418>
_______________________________________

From report at bugs.python.org  Tue Jul 14 20:39:07 2009
From: report at bugs.python.org (Greg)
Date: Tue, 14 Jul 2009 18:39:07 +0000
Subject: [issue6484] No unit test for mailcap module
In-Reply-To: <1247596747.53.0.161658367753.issue6484@psf.upfronthosting.co.za>
Message-ID: <1247596747.53.0.161658367753.issue6484@psf.upfronthosting.co.za>


New submission from Greg <crackityjones2004-p at yahoo.com>:

There is currently no test_mailcap or any other standalone unit test for
the mailcap module. The only existing test is a self-test at the end of
the module.

I would like to be assigned to work on this patch.

(Why am I assigning myself to write tests for a small, older module? I'm
a complete noob to the Python-Dev community and I'm getting my feet wet
with this. Let me know if you have any advice or if I'm doing something
wrong.)

----------
components: Tests
messages: 90516
nosy: gnofi
severity: normal
status: open
title: No unit test for mailcap module
type: feature request
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6484>
_______________________________________

From report at bugs.python.org  Tue Jul 14 21:04:42 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Jul 2009 19:04:42 +0000
Subject: [issue6484] No unit test for mailcap module
In-Reply-To: <1247596747.53.0.161658367753.issue6484@psf.upfronthosting.co.za>
Message-ID: <1247598282.67.0.668202462856.issue6484@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Welcome!

Please read the material at http://www.python.org/dev if you haven't
already, especially the dev FAQ.  At the moment the case can't be
assigned to you in the tracker interface, but your claiming it in the
text is sufficient.

Please write the tests and create a diff-patch as outlined in the FAQ. 
Then upload it here for review.  If you need advice, #python-dev on
Freenode is a good place to get it.

----------
nosy: +r.david.murray
priority:  -> low
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6484>
_______________________________________

From report at bugs.python.org  Tue Jul 14 21:29:30 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 14 Jul 2009 19:29:30 +0000
Subject: [issue6449] Improve/update python.org/dev/
In-Reply-To: <1247165034.18.0.173554225695.issue6449@psf.upfronthosting.co.za>
Message-ID: <1247599770.69.0.436802307522.issue6449@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Thanks for taking care of it.
There's also a typo ("thissmall") in the first line of
http://www.python.org/dev/faq/#why-should-i-use-svn-switch

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6449>
_______________________________________

From report at bugs.python.org  Tue Jul 14 22:15:53 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 14 Jul 2009 20:15:53 +0000
Subject: [issue6484] No unit test for mailcap module
In-Reply-To: <1247596747.53.0.161658367753.issue6484@psf.upfronthosting.co.za>
Message-ID: <1247602553.98.0.699616205672.issue6484@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Please also identify yourself with your full name.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6484>
_______________________________________

From report at bugs.python.org  Tue Jul 14 23:16:32 2009
From: report at bugs.python.org (Sean)
Date: Tue, 14 Jul 2009 21:16:32 +0000
Subject: [issue6480] code.runsource() parsing bug
In-Reply-To: <1247548798.14.0.468793071466.issue6480@psf.upfronthosting.co.za>
Message-ID: <1247606192.78.0.924421601798.issue6480@psf.upfronthosting.co.za>


Sean <smcallis at gmail.com> added the comment:

Seems to me it's probably an issue with the newlines, but from
help(code.compile_command):

    Compile a command and determine whether it is incomplete.
    
    Arguments:
    
    source -- the source string; <b>may contain \n characters</b>
    filename -- optional filename from which source was read; default
                "<input>"
    symbol -- optional grammar start symbol; "single" (default) or

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6480>
_______________________________________

From report at bugs.python.org  Wed Jul 15 00:30:24 2009
From: report at bugs.python.org (Travis H.)
Date: Tue, 14 Jul 2009 22:30:24 +0000
Subject: [issue6485] is_finished not exported by zlib
In-Reply-To: <1247610623.98.0.0463299283071.issue6485@psf.upfronthosting.co.za>
Message-ID: <1247610623.98.0.0463299283071.issue6485@psf.upfronthosting.co.za>


New submission from Travis H. <travis+w-python.org at subspacefield.org>:

The zlib C library has the capability to indicate the end of a
compressed stream by returning a Z_STREAM_END from a call to inflate.

This allows uncompressed data to follow some compressed data.  It is
necessary to know when the end of the compressed stream has been reached
so that one can query the "unused_data" attribute.

However, there is no way for python to know that the end of a compressed
stream has been reached.

I will shortly be submitting a small patch that creates a python integer
attribute called "is_finished" which evaluates to 1 when the end of a
compressed stream has been reached.

----------
components: Extension Modules
messages: 90521
nosy: solinym
severity: normal
status: open
title: is_finished not exported by zlib
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6485>
_______________________________________

From report at bugs.python.org  Wed Jul 15 00:32:04 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Tue, 14 Jul 2009 22:32:04 +0000
Subject: [issue6485] is_finished not exported by zlib
In-Reply-To: <1247610623.98.0.0463299283071.issue6485@psf.upfronthosting.co.za>
Message-ID: <1247610724.99.0.709222774488.issue6485@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

This is a duplicate of #5210, which has a patch attached.

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6485>
_______________________________________

From report at bugs.python.org  Wed Jul 15 00:38:08 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 14 Jul 2009 22:38:08 +0000
Subject: [issue6485] is_finished not exported by zlib
In-Reply-To: <1247610623.98.0.0463299283071.issue6485@psf.upfronthosting.co.za>
Message-ID: <1247611088.49.0.137333079268.issue6485@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> zlib does not indicate end of compressed stream properly

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6485>
_______________________________________

From report at bugs.python.org  Wed Jul 15 00:41:21 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 14 Jul 2009 22:41:21 +0000
Subject: [issue5210] zlib does not indicate end of compressed stream properly
In-Reply-To: <1234295180.57.0.273384677161.issue5210@psf.upfronthosting.co.za>
Message-ID: <1247611281.83.0.217329941746.issue5210@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Thanks for the patch!
Can you provide tests too?

----------
nosy: +ezio.melotti
priority:  -> normal
stage:  -> test needed
versions: +Python 2.7, Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5210>
_______________________________________

From report at bugs.python.org  Wed Jul 15 00:50:21 2009
From: report at bugs.python.org (Mitchell Model)
Date: Tue, 14 Jul 2009 22:50:21 +0000
Subject: [issue6486] Library doc introduction strangely points to "Built-in
	Objects" as a starting point
In-Reply-To: <1247611820.68.0.522695154729.issue6486@psf.upfronthosting.co.za>
Message-ID: <1247611820.68.0.522695154729.issue6486@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

At the end of the introduction page of the library documentation  there
is a strange suggestion to begin with "Built-in Objects" as a starting
point. The "Built-in Objects" page consists of two paragraphs that will
surely mystify people new to Python. I'm not sure where it was supposed
to point -- built-in functions? built-in types? But surely not "Built-in
Objects"?

Or another interpretation, which on deeper investigation, strikes me as
the correct one: "Built-in Objects", which references tables, operators,
etc. that don't appear on that page, is simply an introduction to
"Built-in Types", or an introduction to all the subsequent chapters. In
that case, I see the challenge for structuring the top-level chapters of
the library documentation, but perhaps these two paragraphs could simply
be moved to the introduction and the "Built-in Objects" eliminated.
Besides, aren't built-in functions and constants, which come before this
page, built-in objects too?

----------
assignee: georg.brandl
components: Documentation
messages: 90524
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Library doc introduction strangely points to "Built-in Objects" as a starting point
versions: Python 2.7, Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6486>
_______________________________________

From report at bugs.python.org  Wed Jul 15 00:52:55 2009
From: report at bugs.python.org (Mitchell Model)
Date: Tue, 14 Jul 2009 22:52:55 +0000
Subject: [issue6487] Some index entries appear in black
In-Reply-To: <1247611975.16.0.815449149574.issue6487@psf.upfronthosting.co.za>
Message-ID: <1247611975.16.0.815449149574.issue6487@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

Some index entries appear in black. I think this happens only with
top-level entries. I can't find any pattern to which ones are in black,
so it doesn't look like black has any actual significance. The C general
index page is rich with examples.

----------
messages: 90525
nosy: MLModel
severity: normal
status: open
title: Some index entries appear in black
versions: Python 2.7, Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6487>
_______________________________________

From report at bugs.python.org  Wed Jul 15 01:01:20 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 14 Jul 2009 23:01:20 +0000
Subject: [issue6487] Some index entries appear in black
In-Reply-To: <1247611975.16.0.815449149574.issue6487@psf.upfronthosting.co.za>
Message-ID: <1247612480.87.0.582095866079.issue6487@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
assignee:  -> georg.brandl
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6487>
_______________________________________

From report at bugs.python.org  Wed Jul 15 01:35:02 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 14 Jul 2009 23:35:02 +0000
Subject: [issue3341] "Suggest a change" link
In-Reply-To: <1215774609.12.0.768814080421.issue3341@psf.upfronthosting.co.za>
Message-ID: <1247614502.83.0.21124484371.issue3341@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

An easier approach would be to open the "create a new issue" page of the
tracker when the user clicks on "suggest a change".
The title can be set automatically to something like "Doc suggestion on
Page XYZ". The "Documentation" component and the version could be set
automatically too, and the "Comment" field could include a link to the page.
If the user is registered to the tracker, he would just have to write
the comment and submit, possibly changing/adjusting the fields.

I don't know if it's actually possible to do something like this, but it
shouldn't be too hard to hack the tracker in order to pass this
information when the users click on the link.

----------
nosy: +ajaksu2, ezio.melotti
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3341>
_______________________________________

From report at bugs.python.org  Wed Jul 15 01:55:31 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 14 Jul 2009 23:55:31 +0000
Subject: [issue6486] Library doc introduction strangely points to "Built-in
	Objects" as a starting point
In-Reply-To: <1247611820.68.0.522695154729.issue6486@psf.upfronthosting.co.za>
Message-ID: <1247615731.53.0.519301369991.issue6486@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I agree, the built-in functions page [1] is a good place where to start
and indeed it's the page that follows the introduction [2].
The built-in object page/section [3] should be probably
included/integrated with one of the other pages (and possibly rephrased
too - it's not immediately clear what this "symbol table" is. If it
refers to the __builtins__ namespace it should be stated clearly,
possibly pointing to a glossary entry or to another section).

[1]: http://docs.python.org/library/functions.html
[2]: http://docs.python.org/library/intro.html
[3]: http://docs.python.org/library/objects.html

----------
nosy: +ezio.melotti
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6486>
_______________________________________

From report at bugs.python.org  Wed Jul 15 02:55:29 2009
From: report at bugs.python.org (Mitchell Model)
Date: Wed, 15 Jul 2009 00:55:29 +0000
Subject: [issue6488] ElementTree documentation refers to "path" with no
	explanation, and inconsistently
In-Reply-To: <1247619329.11.0.425030564778.issue6488@psf.upfronthosting.co.za>
Message-ID: <1247619329.11.0.425030564778.issue6488@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

The documentation of ElementTree mentions "path" in describing the
arguments to certain methods. However, "path" is never defined. I
realize that a "path" is (at least a partial implementation of) an
XPath, but there's nothing in the documentation to suggest that to
someone who is not aware of XPath. I also realize that there is a
reference to the external ElementTree documentation, and that
ElementTree support for XPath is documented there. I think "path" should
at least be clarified with a reference that says something like "As used
here the term 'path' refers to ElementTree's support for the XML Path
Language (XPath); see
see http://effbot.org/zone/element-xpath.htm fordetails"

Next, a swarm of nits:

The documentation of the Element methods find, findall, and findtext say
that their arguments can be a tag name or path. (Using the same wording,
which makes it strange that the argument to findtext is called
"condition" while the argument to the other two methods are called
"match". I'm sure there's something important about this distinction,
but I can't figure it out from the documentation.

The documentation of the corresponding methods of ElementTree call the
arguments "path", rather than "tag" or "condition". The real problem is
that these methods are documented with respect to the element(s) "with
the given tag". [The "the" is missing from the documentation of
ElementTree.find and findall.] The documentation says these methods are
the same as calling the corresponding method on getroot(), but whereas
the Element methods refer to tag name or path, the ElementTree methods,
although they call their arguments "path", only mention tag names.
Finally, the ElementTree methods say "path is the [top-level] element to
look for", which, it seems to me, is redundant given the first sentence
of each of each method's documentation.

----------
assignee: georg.brandl
components: Documentation
messages: 90528
nosy: MLModel, georg.brandl
severity: normal
status: open
title: ElementTree documentation refers to "path" with no explanation, and inconsistently
versions: Python 2.7, Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6488>
_______________________________________

From report at bugs.python.org  Wed Jul 15 03:36:52 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 15 Jul 2009 01:36:52 +0000
Subject: [issue6488] ElementTree documentation refers to "path" with no
	explanation, and inconsistently
In-Reply-To: <1247619329.11.0.425030564778.issue6488@psf.upfronthosting.co.za>
Message-ID: <1247621812.41.0.180689158304.issue6488@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee: georg.brandl -> effbot
nosy: +effbot
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6488>
_______________________________________

From report at bugs.python.org  Wed Jul 15 04:02:20 2009
From: report at bugs.python.org (Mitchell Model)
Date: Wed, 15 Jul 2009 02:02:20 +0000
Subject: [issue6489] Documentation of ElementTree.Element.getiterator implies
	element will always be included
In-Reply-To: <1247623340.07.0.957339027178.issue6489@psf.upfronthosting.co.za>
Message-ID: <1247623340.07.0.957339027178.issue6489@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

Documentation of ElementTree.Element.getiterator implies element will
always be included, but it is only included if it matches. (It says
"creates a tree iterator with the current element as the root" and also
says, ambiguously, "iterates over this element and all the elements
below it that match the given tag".)

I also feel that it is unclear to leave the term "match" undescribed.
Especially with '*' explicitly mentioned as a possibility, it looks like
one could specify, say, 'Thing*' and get all elements whose tag names
begin with 'Thing', which does not appear to be the case. Also, using
the term "match" is confusing if one understands the term to mean match
an XPath, as (implicitly) used elsewhere in the document, unless match
also means an XPath here too, which I don't think it does. I think
"match" should be reserved for XPath matching in this documentation, and
"equals" for when that is the actual test performed, such as, I think,
in getiterator.

----------
assignee: georg.brandl
components: Documentation
messages: 90529
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Documentation of ElementTree.Element.getiterator implies element will always be included
versions: Python 2.7, Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6489>
_______________________________________

From report at bugs.python.org  Wed Jul 15 05:02:22 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 15 Jul 2009 03:02:22 +0000
Subject: [issue6489] Documentation of ElementTree.Element.getiterator implies
	element will always be included
In-Reply-To: <1247623340.07.0.957339027178.issue6489@psf.upfronthosting.co.za>
Message-ID: <1247626942.55.0.765441594876.issue6489@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee: georg.brandl -> effbot
nosy: +effbot
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6489>
_______________________________________

From report at bugs.python.org  Wed Jul 15 10:29:23 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 15 Jul 2009 08:29:23 +0000
Subject: [issue6444] multiline exception logging via syslog handler
In-Reply-To: <1247124840.28.0.246529396761.issue6444@psf.upfronthosting.co.za>
Message-ID: <1247646563.79.0.0202463918368.issue6444@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Well, I copied your script to "log1.py" and ran it twice. Here's a
screenshot from my system log viewer:

http://imgur.com/EYnfQ.png

I know you can't see all the output in the screenshot, but if I scroll
to the right as far as possible I can see that all the exception
information is there.

----------
resolution:  -> works for me
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6444>
_______________________________________

From report at bugs.python.org  Wed Jul 15 10:32:25 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 15 Jul 2009 08:32:25 +0000
Subject: [issue6136] Make logging configuration files easier to use
In-Reply-To: <1243494599.99.0.653406283097.issue6136@psf.upfronthosting.co.za>
Message-ID: <1247646745.93.0.206733494937.issue6136@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

There hasn't been any activity for around a month now - marking as
pending, will close shortly unless there's some reason not to.

----------
resolution:  -> wont fix
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6136>
_______________________________________

From report at bugs.python.org  Wed Jul 15 10:35:39 2009
From: report at bugs.python.org (krawyoti)
Date: Wed, 15 Jul 2009 08:35:39 +0000
Subject: [issue6490] os.popen documentation in 2.6 is probably wrong
In-Reply-To: <1247646939.28.0.091306950041.issue6490@psf.upfronthosting.co.za>
Message-ID: <1247646939.28.0.091306950041.issue6490@psf.upfronthosting.co.za>


New submission from krawyoti <krawyoti at yahoo.com>:

The documentation in Python 2.6 claims os.popen is deprecated [1]. This
is probably a false claim. I think that at some point os.popen got
confused with os.popen2, os.popen3, os.popen4 and the popen2 module, all
of which are correctly deprecated.

I bring three forward three pieces of evidence that os.popen is *not*
deprecated:

i) In Python 3.1, unlike the others, os.popen is still present and is
not even deprecated. [2]

ii) Unlike the others, using os.popen does not raise a DeprecationWarning;

iii) Unlike the others, its implementation is lifted straight from the
posix module.

--
[1] http://docs.python.org/2.6/library/os.html#os.popen
[2] http://docs.python.org/3.1/library/os.html#os.plock

----------
assignee: georg.brandl
components: Documentation
messages: 90532
nosy: georg.brandl, krawyoti
severity: normal
status: open
title: os.popen documentation in 2.6 is probably wrong
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6490>
_______________________________________

From report at bugs.python.org  Wed Jul 15 10:36:09 2009
From: report at bugs.python.org (krawyoti)
Date: Wed, 15 Jul 2009 08:36:09 +0000
Subject: [issue6490] os.popen documentation in 2.6 is probably wrong
In-Reply-To: <1247646939.28.0.091306950041.issue6490@psf.upfronthosting.co.za>
Message-ID: <1247646969.76.0.392270320921.issue6490@psf.upfronthosting.co.za>


Changes by krawyoti <krawyoti at yahoo.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6490>
_______________________________________

From report at bugs.python.org  Wed Jul 15 11:07:21 2009
From: report at bugs.python.org (Samuele Pedroni)
Date: Wed, 15 Jul 2009 09:07:21 +0000
Subject: [issue1370] Use System.identityHashCode for id()
In-Reply-To: <1247621542.82.0.282532321801.issue1370@psf.upfronthosting.co.za>
Message-ID: <4A5D9C44.1090300@openend.se>


Samuele Pedroni <pedronis at users.sourceforge.net> added the comment:

on a moving gc the identity hash is not unique, id() needs to be unique. 
So not using it is a matter of correctness not speed.

But this issue is too terse to be sure what is talking about.

----------
nosy: +pedronis
title: Doc changes left over after mega-merge from trunk -> Use System.identityHashCode for id()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1370>
_______________________________________

From report at bugs.python.org  Wed Jul 15 11:21:03 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 15 Jul 2009 09:21:03 +0000
Subject: [issue1370] Doc changes left over after mega-merge from trunk
In-Reply-To: <1193946491.89.0.831882388568.issue1370@psf.upfronthosting.co.za>
Message-ID: <1247649663.02.0.533263246379.issue1370@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

You probably wanted to send this message to the jython tracker :-)

----------
nosy: +amaury.forgeotdarc
title: Use System.identityHashCode for id() -> Doc changes left over after mega-merge from trunk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1370>
_______________________________________

From report at bugs.python.org  Wed Jul 15 13:26:51 2009
From: report at bugs.python.org (Julian Andres Klode)
Date: Wed, 15 Jul 2009 11:26:51 +0000
Subject: [issue6483] Modules are not deallocated correctly if m_size = -1
In-Reply-To: <1247573035.84.0.508855898217.issue6483@psf.upfronthosting.co.za>
Message-ID: <1247657211.43.0.89956124326.issue6483@psf.upfronthosting.co.za>


Julian Andres Klode <jak at jak-linux.org> added the comment:

I believe this may be related to Python/import.c (l. 592):

   def->m_base.m_copy = PyDict_Copy(dict);

It creates a copy of the module dictionary, but the reference count of
this copy is not decreased when the module object is deallocated, thus
causing the objects contained therein to be not allocated as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6483>
_______________________________________

From report at bugs.python.org  Wed Jul 15 18:19:33 2009
From: report at bugs.python.org (Max Arnold)
Date: Wed, 15 Jul 2009 16:19:33 +0000
Subject: [issue6444] multiline exception logging via syslog handler
In-Reply-To: <1247124840.28.0.246529396761.issue6444@psf.upfronthosting.co.za>
Message-ID: <1247674773.28.0.929320062415.issue6444@psf.upfronthosting.co.za>


Max Arnold <lwarxx at gmail.com> added the comment:

Which syslog daemon you use?  I've encountered this on syslog-ng. There
is stripped down syslog-ng.conf (messages with facility LOCAL0 are
routed to /var/log/local.log and all others to /var/log/default.log):

#------------------------------------------------------
options {
        chain_hostnames(off);
        use_dns (no);
        use_fqdn (no);
        sync(0);
        stats(43200);
};

source src {
        unix-stream("/dev/log" max-connections(256));
        internal();
        file("/proc/kmsg");
};

template t_filetmpl {
        template("$YEAR-$MONTH-$DAY $HOUR:$MIN:$SEC $HOST $MSG\n");
};

# Create destinations
destination default { file("/var/log/default.log" template(t_filetmpl) ); };
destination local { file("/var/log/local.log" template(t_filetmpl) ); };

# Create filters
filter local { facility(local0) or program("^root.*"); };

# Connect source and destinations
log { source(src); filter(local); destination(local); flags(final); };
log { source(src); destination(default); };
#------------------------------------------------------


And this is result:

# first line landed in /var/log/local.log
Jul 15 23:52:02 localhost root: ERROR <module>/14 division by zero

# remaining ones in /var/log/default.log
Jul 15 23:52:02 localhost Traceback (most recent call last):
Jul 15 23:52:02 localhost File "./test.py", line 12, in <module>
Jul 15 23:52:02 localhost a = 1/0
Jul 15 23:52:02 localhost ZeroDivisionError: integer division or modulo
by zero

Results like yours (which are not very readable but still appropriate
for me) I get only when logging performed via udp socket.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6444>
_______________________________________

From report at bugs.python.org  Wed Jul 15 18:46:10 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 15 Jul 2009 16:46:10 +0000
Subject: [issue6444] multiline exception logging via syslog handler
In-Reply-To: <1247124840.28.0.246529396761.issue6444@psf.upfronthosting.co.za>
Message-ID: <1247676370.13.0.590884282706.issue6444@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I'm using whatever came with my Ubuntu system - I supposes that's
syslogd. Perhaps there's some additional configuration with syslog-ng
which will give you the results you want?

Plainly, logging is send all the information across, whether it's via
UDP or a domain socket. And I'm not sure there are any other reports of
this problem with syslog-ng (I'm pretty sure that at least some users of
logging are using syslog-ng, and the problem you're seeing would show up
whenever an exception is logged.)

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6444>
_______________________________________

From report at bugs.python.org  Wed Jul 15 19:09:06 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Wed, 15 Jul 2009 17:09:06 +0000
Subject: [issue6477] Pickling of NoneType raises PicklingError
In-Reply-To: <1247505641.96.0.188774248495.issue6477@psf.upfronthosting.co.za>
Message-ID: <1247677746.69.0.527872505786.issue6477@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

I don't see why you want to pickle NoneType. Do you have a proper
use-case for this, or are you just playing around with pickle?

----------
nosy: +alexandre.vassalotti
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6477>
_______________________________________

From report at bugs.python.org  Wed Jul 15 19:18:07 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 15 Jul 2009 17:18:07 +0000
Subject: [issue6491] Improve --with-dbmliborder option
In-Reply-To: <1247678287.04.0.431591668248.issue6491@psf.upfronthosting.co.za>
Message-ID: <1247678287.04.0.431591668248.issue6491@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

--with-dbmliborder option doesn't allow to specify that no dbm modules
are requested. It also doesn't affect "Anthony Baxter's gdbm module".

The attached patch allows to specify "--with-dbmliborder=" which should
disable building of all dbm modules.

----------
components: Build
files: python-dbmliborder.patch
keywords: patch
messages: 90539
nosy: Arfrever
severity: normal
status: open
title: Improve --with-dbmliborder option
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file14501/python-dbmliborder.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6491>
_______________________________________

From report at bugs.python.org  Wed Jul 15 19:32:15 2009
From: report at bugs.python.org (July Tikhonov)
Date: Wed, 15 Jul 2009 17:32:15 +0000
Subject: [issue6477] Pickling of NoneType raises PicklingError
In-Reply-To: <1247505641.96.0.188774248495.issue6477@psf.upfronthosting.co.za>
Message-ID: <1247679135.58.0.186887373505.issue6477@psf.upfronthosting.co.za>


July Tikhonov <july.tikh at gmail.com> added the comment:

No, my program failed on this. It was not a big problem to manage this, 
but I think it is a bug. And it isn't documented (or I can't find it).

Other built-in types have no such problem. Is there something special 
with NoneType?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6477>
_______________________________________

From report at bugs.python.org  Wed Jul 15 20:22:32 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Wed, 15 Jul 2009 18:22:32 +0000
Subject: [issue2389] Array pickling exposes internal memory representation of
	elements
In-Reply-To: <1205851091.96.0.575523128038.issue2389@psf.upfronthosting.co.za>
Message-ID: <1247682152.25.0.558411656783.issue2389@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Committed fix for 3.x in r74013 and for 2.x in r74014.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2389>
_______________________________________

From report at bugs.python.org  Wed Jul 15 22:24:13 2009
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Wed, 15 Jul 2009 20:24:13 +0000
Subject: [issue6364] freeze tool broken in Python 3.x
In-Reply-To: <1246245349.44.0.542405438388.issue6364@psf.upfronthosting.co.za>
Message-ID: <1247689453.07.0.968140530882.issue6364@psf.upfronthosting.co.za>


Hagen F?rstenau <hfuerstenau at gmx.net> added the comment:

I'm attaching a patch with the minimal changes I had to make to get a
"hello world" script frozen under 3.x. They all have to do with changes
between 2.x and 3.x.

----------
keywords: +patch
Added file: http://bugs.python.org/file14502/freeze.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6364>
_______________________________________

From report at bugs.python.org  Wed Jul 15 22:54:54 2009
From: report at bugs.python.org (Jan Lieskovsky)
Date: Wed, 15 Jul 2009 20:54:54 +0000
Subject: [issue5753] CVE-2008-5983 python: untrusted python modules search path
In-Reply-To: <1239709179.65.0.173847743531.issue5753@psf.upfronthosting.co.za>
Message-ID: <1247691294.69.0.129101013522.issue5753@psf.upfronthosting.co.za>


Jan Lieskovsky <iankko at seznam.cz> added the comment:

Link to older Python tracker issue discussing the same problem and
closed with "won't fix":

    http://bugs.python.org/issue946373

Strange enough, but implied from reading above issue, just an
idea (don't shoot :)). Wouldn't it be possible to recognize,
if the module name the script | embedded application is trying
to load belongs to && conflicts with the 'standard' Python module
names as listed in:

  http://docs.python.org/modindex.html

and in that case:
  a, issue a warning by loading it?
  b, refuse to import it, in case it doesn't come from usual
     standard Python modules location?

Probably off-topic, but is there in Python some mechanism how to
determine, if the module / module name belongs to:
  a, 'standard Python module set' or
  b, is a custom module, written by Python user?
     (via the Python's interpreter __main__ module's namespace
      dictionary? -- based on [1])

[1] http://www.linuxjournal.com/article/8497

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5753>
_______________________________________

From report at bugs.python.org  Wed Jul 15 23:31:43 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 15 Jul 2009 21:31:43 +0000
Subject: [issue6076] Missing title for configDialog.py
In-Reply-To: <1242860050.65.0.436553744658.issue6076@psf.upfronthosting.co.za>
Message-ID: <1247693503.67.0.837821144341.issue6076@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Applied with r74019. Thanks for the patch!

----------
nosy: +amaury.forgeotdarc
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6076>
_______________________________________

From report at bugs.python.org  Wed Jul 15 23:43:12 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 15 Jul 2009 21:43:12 +0000
Subject: [issue4540] typo in a module describes utf-8 as uft-8
In-Reply-To: <1228433923.53.0.179522089961.issue4540@psf.upfronthosting.co.za>
Message-ID: <1247694192.8.0.576684220985.issue4540@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This was fixed together with issue5453

----------
resolution:  -> out of date
status: open -> closed
superseder:  -> pydoc -k fails (release30-maint patch)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4540>
_______________________________________

From report at bugs.python.org  Thu Jul 16 00:22:56 2009
From: report at bugs.python.org (Jim Garrison)
Date: Wed, 15 Jul 2009 22:22:56 +0000
Subject: [issue4147] xml.dom.minidom toprettyxml: omit whitespace for
	text-only elements
In-Reply-To: <1224430404.43.0.0672391440841.issue4147@psf.upfronthosting.co.za>
Message-ID: <1247696576.81.0.0758373575916.issue4147@psf.upfronthosting.co.za>


Jim Garrison <jgarrison at troux.com> added the comment:

Also needed here.  While pretty-printing should be able to insert
non-significant whitespace BETWEEN xml elements, it should never alter
the content of (i.e. insert whitespace into) existing text elements.

----------
nosy: +jgarrison

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4147>
_______________________________________

From report at bugs.python.org  Thu Jul 16 00:23:08 2009
From: report at bugs.python.org (Devon)
Date: Wed, 15 Jul 2009 22:23:08 +0000
Subject: [issue6492] xml.etree does not escape CR,
	LF and TAB characters within attribute values
In-Reply-To: <1247696588.32.0.942237333428.issue6492@psf.upfronthosting.co.za>
Message-ID: <1247696588.32.0.942237333428.issue6492@psf.upfronthosting.co.za>


New submission from Devon <devon.rueckner at temboo.com>:

similar minidom as reported in in #5752

----------
components: XML
files: test_tostring.py
messages: 90547
nosy: devon
severity: normal
status: open
title: xml.etree does not escape CR, LF and TAB characters within attribute values
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14503/test_tostring.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6492>
_______________________________________

From report at bugs.python.org  Thu Jul 16 00:25:15 2009
From: report at bugs.python.org (Devon)
Date: Wed, 15 Jul 2009 22:25:15 +0000
Subject: [issue5752] xml.dom.minidom does not escape CR,
	LF and TAB characters within attribute values
In-Reply-To: <1239707588.77.0.33795755364.issue5752@psf.upfronthosting.co.za>
Message-ID: <1247696715.52.0.940656787366.issue5752@psf.upfronthosting.co.za>


Devon <devon.rueckner at temboo.com> added the comment:

see also a similar issue in etree: #6492

----------
nosy: +devon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5752>
_______________________________________

From report at bugs.python.org  Thu Jul 16 03:11:59 2009
From: report at bugs.python.org (higstar)
Date: Thu, 16 Jul 2009 01:11:59 +0000
Subject: [issue6493] Can not set value for structure members larger than 32
	bits
In-Reply-To: <1247706719.26.0.735618414968.issue6493@psf.upfronthosting.co.za>
Message-ID: <1247706719.26.0.735618414968.issue6493@psf.upfronthosting.co.za>


New submission from higstar <adrian at higstar.com>:

Added a test to test_bitfields.py:
    def test_uint32(self):
        class X(Structure):
            _fields_ = [("a", c_uint32, 32)]

        x = X()
        x.a = 10
        self.failUnlessEqual(x.a, 10)

Run in Python 2.5.2 and 2.6.2:
======================================================================
FAIL: test_uint32 (__main__.BitFieldTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_bitfields.py", line 73, in test_uint32
    self.failUnlessEqual(x.a, 10)
AssertionError: 0L != 10

----------
assignee: theller
components: ctypes
messages: 90549
nosy: higstar, theller
severity: normal
status: open
title: Can not set value for structure members larger than 32 bits
versions: Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6493>
_______________________________________

From report at bugs.python.org  Thu Jul 16 03:34:33 2009
From: report at bugs.python.org (higstar)
Date: Thu, 16 Jul 2009 01:34:33 +0000
Subject: [issue6493] Can not set value for structure members larger than 32
	bits
In-Reply-To: <1247706719.26.0.735618414968.issue6493@psf.upfronthosting.co.za>
Message-ID: <1247708073.17.0.176742769038.issue6493@psf.upfronthosting.co.za>


higstar <adrian at higstar.com> added the comment:

Also run in 3.0

----------
versions: +Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6493>
_______________________________________

From report at bugs.python.org  Thu Jul 16 04:05:56 2009
From: report at bugs.python.org (Leo)
Date: Thu, 16 Jul 2009 02:05:56 +0000
Subject: [issue6494] xmlrpc client does not support HTTPS
In-Reply-To: <1247709956.54.0.66653244399.issue6494@psf.upfronthosting.co.za>
Message-ID: <1247709956.54.0.66653244399.issue6494@psf.upfronthosting.co.za>


New submission from Leo <thelists at optusnet.com.au>:

I just downloaded and installed V3.1 on Ubuntu and get the following error.

File "/usr/local/lib/python3.1/xmlrpc/client.py", line 1183, in send_request
    "your version of http.client doesn't support HTTPS")

Thanks,

Leo

----------
messages: 90551
nosy: lister171254
severity: normal
status: open
title: xmlrpc client does not support HTTPS
type: crash
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6494>
_______________________________________

From report at bugs.python.org  Thu Jul 16 05:49:29 2009
From: report at bugs.python.org (Max Arnold)
Date: Thu, 16 Jul 2009 03:49:29 +0000
Subject: [issue6444] multiline exception logging via syslog handler
In-Reply-To: <1247124840.28.0.246529396761.issue6444@psf.upfronthosting.co.za>
Message-ID: <1247716169.48.0.0247212532499.issue6444@psf.upfronthosting.co.za>


Max Arnold <lwarxx at gmail.com> added the comment:

I'll try to investigate this issue a bit more in a few days.  I plan to
compare sysklogd, sylog-ng and probably metalog. Maybe this issue is
specific to syslog-ng only.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6444>
_______________________________________

From report at bugs.python.org  Thu Jul 16 07:19:29 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 16 Jul 2009 05:19:29 +0000
Subject: [issue6494] xmlrpc client does not support HTTPS
In-Reply-To: <1247709956.54.0.66653244399.issue6494@psf.upfronthosting.co.za>
Message-ID: <1247721569.63.0.692667651879.issue6494@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This is not a bug in Python. You need to build Python with SSL support
for this to work.

----------
nosy: +loewis
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6494>
_______________________________________

From report at bugs.python.org  Thu Jul 16 07:22:35 2009
From: report at bugs.python.org (Case Van Horsen)
Date: Thu, 16 Jul 2009 05:22:35 +0000
Subject: [issue6431] Fraction fails equality test with a user-defined type
In-Reply-To: <1246945296.27.0.280023368175.issue6431@psf.upfronthosting.co.za>
Message-ID: <1247721755.2.0.323988119461.issue6431@psf.upfronthosting.co.za>


Case Van Horsen <casevh at gmail.com> added the comment:

I've attached a patch that creates DummyRational and then tests
comparisons between Fraction and DummyRational. The __eq__ method also
verifies that the type of the other argument is fractions.Fraction.

----------
Added file: http://bugs.python.org/file14504/patch_test_fractions.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6431>
_______________________________________

From report at bugs.python.org  Thu Jul 16 08:00:36 2009
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Thu, 16 Jul 2009 06:00:36 +0000
Subject: [issue6477] Pickling of NoneType raises PicklingError
In-Reply-To: <1247505641.96.0.188774248495.issue6477@psf.upfronthosting.co.za>
Message-ID: <1247724036.55.0.656860403465.issue6477@psf.upfronthosting.co.za>


Hagen F?rstenau <hfuerstenau at gmx.net> added the comment:

> but I think it is a bug

I think it is either a feature request (make NoneType picklable) or a
documentation issue (document that it's not).

----------
nosy: +hagen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6477>
_______________________________________

From report at bugs.python.org  Thu Jul 16 09:03:51 2009
From: report at bugs.python.org (Tomas Hoger)
Date: Thu, 16 Jul 2009 07:03:51 +0000
Subject: [issue5753] CVE-2008-5983 python: untrusted python modules search path
In-Reply-To: <1239709179.65.0.173847743531.issue5753@psf.upfronthosting.co.za>
Message-ID: <1247727831.21.0.500876553027.issue5753@psf.upfronthosting.co.za>


Tomas Hoger <thoger at redhat.com> added the comment:

This is not really the same thing as issue 946373.  That one seems to be
about adding script's directory as the first thing in sys.path. 
Comments there seem to mix both interactive ('' in sys.path) and
non-interactive (os.path.dirname(os.path.abspath(sys.argv[0])) in
sys.path) python uses, while CVE-2008-5983 is only about '' in sys.path,
mostly related to embedded use, rather than for python interpreter itself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5753>
_______________________________________

From report at bugs.python.org  Thu Jul 16 09:18:15 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 16 Jul 2009 07:18:15 +0000
Subject: [issue5910] kqueue for more than one event is broken.
In-Reply-To: <1241301488.84.0.663629523973.issue5910@psf.upfronthosting.co.za>
Message-ID: <1247728695.27.0.897133289763.issue5910@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Patch looks good, committed with test in r74020.

----------
assignee: christian.heimes -> georg.brandl
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5910>
_______________________________________

From report at bugs.python.org  Thu Jul 16 09:30:21 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 16 Jul 2009 07:30:21 +0000
Subject: [issue6490] os.popen documentation in 2.6 is probably wrong
In-Reply-To: <1247646939.28.0.091306950041.issue6490@psf.upfronthosting.co.za>
Message-ID: <1247729421.9.0.0132141875329.issue6490@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Actually popen() isn't documented anymore in the 3.1 docs.  However, I
don't know about the "real" deprecation status.  Benjamin?

----------
assignee: georg.brandl -> benjamin.peterson
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6490>
_______________________________________

From report at bugs.python.org  Thu Jul 16 09:34:02 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 16 Jul 2009 07:34:02 +0000
Subject: [issue6486] Library doc introduction strangely points to "Built-in
	Objects" as a starting point
In-Reply-To: <1247611820.68.0.522695154729.issue6486@psf.upfronthosting.co.za>
Message-ID: <1247729642.86.0.747892136956.issue6486@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I moved the link target to the "built-in functions" section in r74021. 
For the other issue, I wanted to restructure the builtins docs anyway
for a long time, this will be part of it.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6486>
_______________________________________

From report at bugs.python.org  Thu Jul 16 09:35:03 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 16 Jul 2009 07:35:03 +0000
Subject: [issue3341] "Suggest a change" link
In-Reply-To: <1215774609.12.0.768814080421.issue3341@psf.upfronthosting.co.za>
Message-ID: <1247729703.86.0.515133733255.issue3341@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Since this will be handled by Sphinx, it is not an issue for this tracker.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3341>
_______________________________________

From report at bugs.python.org  Thu Jul 16 09:37:04 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 16 Jul 2009 07:37:04 +0000
Subject: [issue6487] Some index entries appear in black
In-Reply-To: <1247611975.16.0.815449149574.issue6487@psf.upfronthosting.co.za>
Message-ID: <1247729824.21.0.384804192348.issue6487@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I'm not sure which items you refer to.  The only unlinked items I see
are some with subterms, where the parent term has no index entry.

----------
resolution:  -> works for me
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6487>
_______________________________________

From report at bugs.python.org  Thu Jul 16 09:38:46 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 16 Jul 2009 07:38:46 +0000
Subject: [issue6481] PATCH: typo in subprocess documentation
In-Reply-To: <1247550085.73.0.0615590411126.issue6481@psf.upfronthosting.co.za>
Message-ID: <1247729926.6.0.685754536074.issue6481@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r74022.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6481>
_______________________________________

From report at bugs.python.org  Thu Jul 16 09:55:12 2009
From: report at bugs.python.org (Christoph Burgmer)
Date: Thu, 16 Jul 2009 07:55:12 +0000
Subject: [issue6412] Titlecase as defined in Unicode Case Mappings not followed
In-Reply-To: <1246662889.32.0.498842923824.issue6412@psf.upfronthosting.co.za>
Message-ID: <1247730912.52.0.694401510162.issue6412@psf.upfronthosting.co.za>


Christoph Burgmer <cburgmer at ira.uka.de> added the comment:

Casing algorithms should follow Section 3.13 "Default Case Algorithms"
in the standard itself, not UTR#21.

See
http://www.unicode.org/Public/5.2.0/ucd/DerivedCoreProperties-5.2.0d11.
Unicode 5.2. A nice mail on the Unicode mail list has a bit explanation
to that: http://www.unicode.org/mail-arch/unicode-ml/y2009-

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6412>
_______________________________________

From report at bugs.python.org  Thu Jul 16 10:46:12 2009
From: report at bugs.python.org (tq0fqeu)
Date: Thu, 16 Jul 2009 08:46:12 +0000
Subject: [issue6495] particular variable's name case exception attributeError
In-Reply-To: <1247733971.96.0.782275709389.issue6495@psf.upfronthosting.co.za>
Message-ID: <1247733971.96.0.782275709389.issue6495@psf.upfronthosting.co.za>


New submission from tq0fqeu <tq0fqeu at gmail.com>:

To create a instance of Class Person
[code]
rosss = Person('ross')
rosss.sayHi()
rosss.howMany()
[/code]
It's OK

But
[code]
ross = Person('ross')
ross.sayHi()
ross.howMany()
[/code]
It has exception, get that:
Exception AttributeError: "'NoneType' object has no attribute
'population'" in <bound method Person.__del__ of <__main__.Person
instance at 0xb7e0b34c>> ignored

python 2.6.2 + gcc 4.3.3 + kernel 2.6.28-13-generic

----------
files: objvar.py
messages: 90564
nosy: tq0fqeu
severity: normal
status: open
title: particular variable's name case exception attributeError
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file14505/objvar.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6495>
_______________________________________

From report at bugs.python.org  Thu Jul 16 12:00:10 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 16 Jul 2009 10:00:10 +0000
Subject: [issue6495] particular variable's name case exception attributeError
In-Reply-To: <1247733971.96.0.782275709389.issue6495@psf.upfronthosting.co.za>
Message-ID: <1247738410.4.0.717647116837.issue6495@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

You examples both work for me.  Please go to python-list or python-tutor
for help debugging your code.  In particular you need to learn more
about __del__ and why you probably don't want to be using it.

rdmurray at maestro:~/python/trunk>./python  
Python 2.7a0 (trunk:74008, Jul 14 2009, 20:56:15) 
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from objvar import Person
>>> rosss = Person('ross')
(Initializing ross)
>>> rosss.sayHi()
Hi, my name is ross.
>>> rosss.howMany()
I am the only person here.
>>> ross = Person('ross')
(Initializing ross)
>>> ross.sayHi()
Hi, my name is ross.
>>> ross.howMany()
We have 2 persons here.

----------
components: +Interpreter Core
nosy: +r.david.murray
priority:  -> low
resolution:  -> works for me
stage:  -> committed/rejected
status: open -> closed
type: compile error -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6495>
_______________________________________

From report at bugs.python.org  Thu Jul 16 12:46:35 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 16 Jul 2009 10:46:35 +0000
Subject: [issue6495] particular variable's name case exception attributeError
In-Reply-To: <1247733971.96.0.782275709389.issue6495@psf.upfronthosting.co.za>
Message-ID: <1247741195.97.0.770548138866.issue6495@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This has to do with the order that things are deleted/cleaned-up on 
interpreter shutdown.  In the reported case, it just happens that the 
'Person' entry in the globals() dict is deleted *before* __del__ is called 
on the last Person instance, causing problems for the lookup of 'Person' 
that's involved in the line 'Person.population -= 1'.

I wonder whether the output from these 'ignored' exceptions on interpreter 
shutdown could be suppressed entirely, at least for non-debug builds?

----------
nosy: +marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6495>
_______________________________________

From report at bugs.python.org  Thu Jul 16 13:22:07 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 16 Jul 2009 11:22:07 +0000
Subject: [issue6495] particular variable's name case exception attributeError
In-Reply-To: <1247733971.96.0.782275709389.issue6495@psf.upfronthosting.co.za>
Message-ID: <1247743327.72.0.670561327902.issue6495@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Well, "Errors should never pass silently."
In this case, it is possible to replace "Person.population" by
"self.__class__.population".

This said, it could be interesting to cleanup modules in a more
predictive way, for example in the reverse order of their import order.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6495>
_______________________________________

From report at bugs.python.org  Thu Jul 16 13:36:35 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 16 Jul 2009 11:36:35 +0000
Subject: [issue6444] multiline exception logging via syslog handler
In-Reply-To: <1247124840.28.0.246529396761.issue6444@psf.upfronthosting.co.za>
Message-ID: <1247744195.89.0.357762357765.issue6444@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I can confirm the issue with syslog-ng, and also that it works fine with
FreeBSD's syslogd.

That said, in the googling I did I ran across code from another project
that splits log lines at newlines and also if the logged line is too
long...apparently some implementations of syslog don't handle long lines
well.

----------
nosy: +r.david.murray
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6444>
_______________________________________

From report at bugs.python.org  Thu Jul 16 14:54:51 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 16 Jul 2009 12:54:51 +0000
Subject: [issue6490] os.popen documentation in 2.6 is probably wrong
In-Reply-To: <1247646939.28.0.091306950041.issue6490@psf.upfronthosting.co.za>
Message-ID: <1247748891.13.0.941589655056.issue6490@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I have no idea either. It seems os.popen is now a hacked up to use
subprocess, so it seems intentional to keep it. Guido, you made this
change; is os.peopen supposed to be gone in 3.x?

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6490>
_______________________________________

From report at bugs.python.org  Thu Jul 16 16:14:06 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 16 Jul 2009 14:14:06 +0000
Subject: [issue6493] Can not set value for structure members larger than 32
	bits
In-Reply-To: <1247706719.26.0.735618414968.issue6493@psf.upfronthosting.co.za>
Message-ID: <1247753646.01.0.24720226922.issue6493@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

What's your platform? I could reproduce this on windows. And I found 
attached patch can workaround this.

----------
keywords: +patch
nosy: +ocean-city
Added file: http://bugs.python.org/file14506/ctypes_workaround.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6493>
_______________________________________

From report at bugs.python.org  Thu Jul 16 16:23:36 2009
From: report at bugs.python.org (Jesse Noller)
Date: Thu, 16 Jul 2009 14:23:36 +0000
Subject: [issue6433] multiprocessing: pool.map hangs on empty list
In-Reply-To: <1246966744.58.0.524623595855.issue6433@psf.upfronthosting.co.za>
Message-ID: <1247754216.58.0.748397251632.issue6433@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

committed r74023 on trunk

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6433>
_______________________________________

From report at bugs.python.org  Thu Jul 16 16:23:46 2009
From: report at bugs.python.org (Jesse Noller)
Date: Thu, 16 Jul 2009 14:23:46 +0000
Subject: [issue6433] multiprocessing: pool.map hangs on empty list
In-Reply-To: <1246966744.58.0.524623595855.issue6433@psf.upfronthosting.co.za>
Message-ID: <1247754226.26.0.787278351499.issue6433@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6433>
_______________________________________

From report at bugs.python.org  Thu Jul 16 16:28:50 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 16 Jul 2009 14:28:50 +0000
Subject: [issue6493] Can not set value for structure members larger than 32
	bits
In-Reply-To: <1247706719.26.0.735618414968.issue6493@psf.upfronthosting.co.za>
Message-ID: <1247754530.24.0.483598515661.issue6493@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


Added file: http://bugs.python.org/file14507/ctypes_workaround_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6493>
_______________________________________

From report at bugs.python.org  Thu Jul 16 16:48:34 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 16 Jul 2009 14:48:34 +0000
Subject: [issue6490] os.popen documentation in 2.6 is probably wrong
In-Reply-To: <1247646939.28.0.091306950041.issue6490@psf.upfronthosting.co.za>
Message-ID: <1247755714.13.0.534066936535.issue6490@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I am guessing the reason to keep os.popen() (albeit now reimplemented 
using subprocess) is that it is a convenient wrapper for a common use case 
and also familiar.  I see no problem with this.  (Indeed the big problem 
was with the proliferation of popenN with confusing signatures.)  So I 
guess it ought to be documented and removed from the list of deprecations 
in 2.6.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6490>
_______________________________________

From report at bugs.python.org  Thu Jul 16 16:52:05 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 16 Jul 2009 14:52:05 +0000
Subject: [issue6490] os.popen documentation in 2.6 is probably wrong
In-Reply-To: <1247646939.28.0.091306950041.issue6490@psf.upfronthosting.co.za>
Message-ID: <1247755925.33.0.921311761886.issue6490@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

By the way, shouldn't the various posix.spawnv* functions be officiall
deprecated as well?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6490>
_______________________________________

From report at bugs.python.org  Thu Jul 16 18:55:01 2009
From: report at bugs.python.org (Jim Garrison)
Date: Thu, 16 Jul 2009 16:55:01 +0000
Subject: [issue4147] xml.dom.minidom toprettyxml: omit whitespace for
	text-only elements
In-Reply-To: <1224430404.43.0.0672391440841.issue4147@psf.upfronthosting.co.za>
Message-ID: <1247763301.93.0.0199511987852.issue4147@psf.upfronthosting.co.za>


Jim Garrison <jgarrison at troux.com> added the comment:

To clarify:

... it should never alter the content of (i.e. insert whitespace into)
existing text elements that contain non-whitespace characters.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4147>
_______________________________________

From report at bugs.python.org  Thu Jul 16 19:58:59 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 16 Jul 2009 17:58:59 +0000
Subject: [issue1327594] Static Windows Build fails to locate existing
	installation
Message-ID: <1247767139.45.0.408262978778.issue1327594@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Do we want to support this? What is the use of a static build?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1327594>
_______________________________________

From report at bugs.python.org  Thu Jul 16 20:34:33 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 16 Jul 2009 18:34:33 +0000
Subject: [issue6431] Fraction fails equality test with a user-defined type
In-Reply-To: <1246945296.27.0.280023368175.issue6431@psf.upfronthosting.co.za>
Message-ID: <1247769273.72.0.0927937922347.issue6431@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks again, casevh!  The patch looks good.  I've added to it a bit,
though---see issue6431.patch.  In detail:

- don't use subtraction with unknown types for <, <=, >, >=;  this is
  dangerous, since the unknown type may well do a lossy conversion, and
  comparisons should really be exact where possible;  as with __eq__,
  it seems better to return NotImplemented and give the other type a
  chance.

- handle infs and nans correctly in comparisons with floats

- a few more tests.

casevh, please could you have a look at the attached patch and let me
know whether it still works with your gmpy port?

Jeffrey, any comments on these changes?

----------
stage: test needed -> patch review
Added file: http://bugs.python.org/file14508/issue6431.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6431>
_______________________________________

From report at bugs.python.org  Thu Jul 16 20:37:27 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 16 Jul 2009 18:37:27 +0000
Subject: [issue1327594] Static Windows Build fails to locate existing
	installation
Message-ID: <1247769447.75.0.0875621284394.issue1327594@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I think it would be nice to support it, atleast in the C files (not
necessarily, but possibly, in the project files as well).

The point of a static Python library is that you can embed it into an
application without requiring an additional DLL. That also allows you to
leave out modules that you don't need at link time. Combine this with
freeze, and you can embed an application without any additional files to
be shipped. Without embedding, but with freeze, you get true standalone
binaries (as opposed to py2exe-fake-I-silently-extract-at-run-time
standalone binaries)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1327594>
_______________________________________

From report at bugs.python.org  Thu Jul 16 21:25:00 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 16 Jul 2009 19:25:00 +0000
Subject: [issue6482] PATCH: tiny simplification for subprocess
In-Reply-To: <1247772300.79.0.980423597948.issue6482@psf.upfronthosting.co.za>
Message-ID: <1247772300.79.0.980423597948.issue6482@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

Thanks, committed in r74028.

----------
nosy: +georg.brandl
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6482>
_______________________________________

From report at bugs.python.org  Thu Jul 16 21:48:34 2009
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Thu, 16 Jul 2009 19:48:34 +0000
Subject: [issue6473] hmac sha384/sha512 fails test vectors
In-Reply-To: <1247457411.29.0.0335702117949.issue6473@psf.upfronthosting.co.za>
Message-ID: <1247773714.18.0.041356608815.issue6473@psf.upfronthosting.co.za>


Hagen F?rstenau <hfuerstenau at gmx.net> added the comment:

Seems like this has already been fixed as issue 1385.

----------
nosy: +hagen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6473>
_______________________________________

From report at bugs.python.org  Thu Jul 16 22:24:57 2009
From: report at bugs.python.org (Mitchell Model)
Date: Thu, 16 Jul 2009 20:24:57 +0000
Subject: [issue6487] Some index entries appear in black
In-Reply-To: <1247611975.16.0.815449149574.issue6487@psf.upfronthosting.co.za>
Message-ID: <1247775897.12.0.414156981577.issue6487@psf.upfronthosting.co.za>


Mitchell Model <mlm at acm.org> added the comment:

doh. sorry. I was in a reading mode, not a "using" mode, and wasn't
thinking of the entries as links, though of course I use them that way
all the time. The pages just seemed oddly sprinkled with black items.
All I said is that I couldn't find any pattern -- doesn't mean there
isn't an obvious one! Close it and forget I said anything about it....

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6487>
_______________________________________

From report at bugs.python.org  Thu Jul 16 22:25:07 2009
From: report at bugs.python.org (Mark Matusevich)
Date: Thu, 16 Jul 2009 20:25:07 +0000
Subject: [issue1524938] PEP MemoryError with a lot of available memory gc not
	called
Message-ID: <1247775907.73.0.842220517586.issue1524938@psf.upfronthosting.co.za>


Mark Matusevich <markmat at users.sourceforge.net> added the comment:

It looks like the severity of this problem is underestimated here.

A programmer working with a significant amount of data (e.g SciPy user)
and uses OOP will face this problem. Most OOP designs result in
existence of some loops (e.g. two way connections). Some object in those
loops will include huge amount of data which were allocated by a single
operation if the program deals with some kind of algorithms (signal
processing, image processing or even 3D games).

I apologize that my example is artificial. I had a real-life program of
8000 lines which was going into swap for no apparent reason and then
crashing. But instead of posting those 8000 lines, I posted a simple
example illustrating the problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1524938>
_______________________________________

From report at bugs.python.org  Thu Jul 16 22:36:44 2009
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Thu, 16 Jul 2009 20:36:44 +0000
Subject: [issue6431] Fraction fails equality test with a user-defined type
In-Reply-To: <1246945296.27.0.280023368175.issue6431@psf.upfronthosting.co.za>
Message-ID: <1247776604.62.0.157032515755.issue6431@psf.upfronthosting.co.za>


Jeffrey Yasskin <jyasskin at gmail.com> added the comment:

The fallback behavior in Fraction was meant to demonstrate the suggested 
fallback behavior for user-defined types. In particular, the idea was 
that all Reals would (by default) be comparable to each other, even if 
they didn't know about each other. Unfortunately, the comparison protocol 
provides no way to know if a particular call is the first call or the 
fallback, so __eq__(Fraction, b) has to return the same thing as 
__eq__(b, Fraction). If b doesn't know about Fraction, and Fraction wants 
to make a best attempt at comparing to it, then __eq__(Fraction, b) can't 
return NotImplemented.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6431>
_______________________________________

From report at bugs.python.org  Thu Jul 16 22:52:42 2009
From: report at bugs.python.org (David Goodger)
Date: Thu, 16 Jul 2009 20:52:42 +0000
Subject: [issue6482] PATCH: tiny simplification for subprocess
In-Reply-To: <1247772300.79.0.980423597948.issue6482@psf.upfronthosting.co.za>
Message-ID: <1247777562.38.0.454020073771.issue6482@psf.upfronthosting.co.za>


David Goodger <goodger at python.org> added the comment:

r74028 changes the logic of the code.  The "finally" clause always
executes, regardless of whether or not an exception was raised.  The
previous behavior only executed when there was an exception.

I don't know if the previous logic was correct, or the new logic, but
they are *not* the same.

----------
nosy: +goodger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6482>
_______________________________________

From report at bugs.python.org  Thu Jul 16 22:57:45 2009
From: report at bugs.python.org (David Goodger)
Date: Thu, 16 Jul 2009 20:57:45 +0000
Subject: [issue6482] PATCH: tiny simplification for subprocess
In-Reply-To: <1247772300.79.0.980423597948.issue6482@psf.upfronthosting.co.za>
Message-ID: <1247777865.08.0.671262707034.issue6482@psf.upfronthosting.co.za>


David Goodger <goodger at python.org> added the comment:

To clarify my last message: the log message for r74028 ('simplify
"except: raise" to "finally:"') implies a nonexistent equivalence.

So was the log message in error, or the change itself?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6482>
_______________________________________

From report at bugs.python.org  Thu Jul 16 22:59:47 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 16 Jul 2009 20:59:47 +0000
Subject: [issue6496] 2to3 generates "from urllib.parse import pathname2url"
In-Reply-To: <1247777987.6.0.0614003313413.issue6496@psf.upfronthosting.co.za>
Message-ID: <1247777987.6.0.0614003313413.issue6496@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

Both pathname2url and url2pathname are in the urllib.request module, 
but 2to3 thinks they are in urllib.parse module.

sridharr at double:~/tmp/eric1$ cat foo.py 
from urllib import pathname2url, url2pathname

sridharr at double:~/tmp/eric1$ /opt/ActivePython-3.1/bin/2to3 foo.py 
RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: set_literal
RefactoringTool: Skipping implicit fixer: ws_comma
--- foo.py (original)
+++ foo.py (refactored)
@@ -1,2 +1,2 @@
-from urllib import pathname2url, url2pathname
+from urllib.parse import pathname2url, url2pathname
 
RefactoringTool: Files that need to be modified:
RefactoringTool: foo.py
sridharr at double:~/tmp/eric1$

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 90585
nosy: srid
severity: normal
status: open
title: 2to3 generates "from urllib.parse import pathname2url"
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6496>
_______________________________________

From report at bugs.python.org  Thu Jul 16 23:18:04 2009
From: report at bugs.python.org (krawyoti)
Date: Thu, 16 Jul 2009 21:18:04 +0000
Subject: [issue6490] os.popen documentation in 2.6 is probably wrong
In-Reply-To: <1247646939.28.0.091306950041.issue6490@psf.upfronthosting.co.za>
Message-ID: <1247779084.47.0.597378438128.issue6490@psf.upfronthosting.co.za>


krawyoti <krawyoti at yahoo.com> added the comment:

Georg, please note that os.popen *is* documented in 3.1. See attached
screen shot.

----------
Added file: http://bugs.python.org/file14509/docs.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6490>
_______________________________________

From report at bugs.python.org  Thu Jul 16 23:28:49 2009
From: report at bugs.python.org (Walter Arrighetti)
Date: Thu, 16 Jul 2009 21:28:49 +0000
Subject: [issue6497] Support for digital Cinema/film DPX and Kodak Cineon
	image file formats in imghdr module
In-Reply-To: <1247779729.41.0.45019789349.issue6497@psf.upfronthosting.co.za>
Message-ID: <1247779729.41.0.45019789349.issue6497@psf.upfronthosting.co.za>


New submission from Walter Arrighetti <riemann.chaos at gmail.com>:

In the Digital Intermediate (DI) post-production world, as well as in
digital cinema/film technologies, video frames -especially those coming
from a film scanner- are stored in sequences of image files, whose two
primary formats are the Digital Picture Exchange (DPX,
http://en.wikipedia.org/wiki/DPX) and the Kodak Cineon
(http://en.wikipedia.org/wiki/Cineon).
This proposal of lines addiction only to imghdr module allows to
properly test DPX and Cineon files for validity, with imghdr.what()
returning either 'dpx' or 'cin' strings if either is found.

----------
components: Library (Lib)
files: imghdr_dpx_cineon_support.py
messages: 90587
nosy: waltermb
severity: normal
status: open
title: Support for digital Cinema/film DPX and Kodak Cineon image file formats in imghdr module
type: behavior
versions: Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14510/imghdr_dpx_cineon_support.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6497>
_______________________________________

From report at bugs.python.org  Thu Jul 16 23:36:54 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 16 Jul 2009 21:36:54 +0000
Subject: [issue6496] 2to3 generates "from urllib.parse import pathname2url"
In-Reply-To: <1247777987.6.0.0614003313413.issue6496@psf.upfronthosting.co.za>
Message-ID: <1247780214.2.0.947210152664.issue6496@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Attaching fix. Might have to merge to 2.6/2.7

----------
keywords: +patch
Added file: http://bugs.python.org/file14511/fix6496.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6496>
_______________________________________

From report at bugs.python.org  Thu Jul 16 23:46:11 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 16 Jul 2009 21:46:11 +0000
Subject: [issue6490] os.popen documentation in 2.6 is probably wrong
In-Reply-To: <1247646939.28.0.091306950041.issue6490@psf.upfronthosting.co.za>
Message-ID: <1247780771.39.0.220342334109.issue6490@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

That is not really a documentation for the function, but a pointer to a
section in which there is no documentation for popen.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6490>
_______________________________________

From report at bugs.python.org  Thu Jul 16 23:48:03 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 16 Jul 2009 21:48:03 +0000
Subject: [issue6482] PATCH: tiny simplification for subprocess
In-Reply-To: <1247772300.79.0.980423597948.issue6482@psf.upfronthosting.co.za>
Message-ID: <1247780883.06.0.0617690632857.issue6482@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Very true. Since there was no indication that the previous version was
faulty, reverted in r74029.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6482>
_______________________________________

From report at bugs.python.org  Thu Jul 16 23:48:35 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 16 Jul 2009 21:48:35 +0000
Subject: [issue6487] Some index entries appear in black
In-Reply-To: <1247611975.16.0.815449149574.issue6487@psf.upfronthosting.co.za>
Message-ID: <1247780915.77.0.596262685565.issue6487@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6487>
_______________________________________

From report at bugs.python.org  Fri Jul 17 00:10:04 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 16 Jul 2009 22:10:04 +0000
Subject: [issue6431] Fraction fails equality test with a user-defined type
In-Reply-To: <1246945296.27.0.280023368175.issue6431@psf.upfronthosting.co.za>
Message-ID: <1247782204.22.0.066423147658.issue6431@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

[Jeffrey]
> In particular, the idea was that all Reals would (by default) be
> comparable to each other, even if they didn't know about each other.

Understood, but I don't think this is an attainable goal.  I don't see 
any reasonable way to make it happen without doing significant guessing, 
or expanding the numbers ABC in some way.

At the moment, __eq__(a, b) falls back to 'float(a) == b' when b is not 
a float or an instance of Rational.  This seems problematic to me for a 
couple of reasons:

1. The conversion to float loses information.  As a result, we lose (a) 
transitivity of equality, (b) well-behaved hashing (x == y no longer 
implies hash(x) == hash(y)), and (c) consistency between == and the 
other comparison operators.

2. This fallback shuts out the other class even in cases where the other 
class *does* know how to handle the comparison.  So there's no way for 
another class to 'play nice' with the Fraction type and implement exact 
comparisons even if it wants to.

Here's an example of 1, on Python 2.6.  (bigfloat is a home-built 
wrapper for the MPFR library.)

newton:~ dickinsm$ python2.6
Python 2.6.2 (r262:71600, Jun 17 2009, 09:08:27) 
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from bigfloat import BigFloat
>>> from fractions import Fraction
>>> x = Fraction(2**60-1)
>>> y = Fraction(2**60+1)
>>> z = BigFloat(2**60)
>>> x == z
True
>>> y == z
True
>>> x == y
False
>>> hash(x) == hash(z)
False

I just don't see any reasonable way to make comparisons 'automatically' 
work:  one of the classes has to know how to handle both types, or else 
there's just going to be a lot of guesswork involved.  So it seems 
better to simply return NotImplemented in these cases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6431>
_______________________________________

From report at bugs.python.org  Fri Jul 17 00:14:27 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 16 Jul 2009 22:14:27 +0000
Subject: [issue6473] hmac sha384/sha512 fails test vectors
In-Reply-To: <1247457411.29.0.0335702117949.issue6473@psf.upfronthosting.co.za>
Message-ID: <1247782467.32.0.288459565582.issue6473@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Indeed, the provided test file passes on all python versions I have.
Iain, does this script fail on some version?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6473>
_______________________________________

From report at bugs.python.org  Fri Jul 17 00:28:00 2009
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Thu, 16 Jul 2009 22:28:00 +0000
Subject: [issue6431] Fraction fails equality test with a user-defined type
In-Reply-To: <1246945296.27.0.280023368175.issue6431@psf.upfronthosting.co.za>
Message-ID: <1247783280.23.0.907071437284.issue6431@psf.upfronthosting.co.za>


Jeffrey Yasskin <jyasskin at gmail.com> added the comment:

If you think it's better, I'm happy to make the other tradeoff.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6431>
_______________________________________

From report at bugs.python.org  Fri Jul 17 00:50:58 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 16 Jul 2009 22:50:58 +0000
Subject: [issue2622] Import errors in email.message.py
In-Reply-To: <1207978673.41.0.752617892341.issue2622@psf.upfronthosting.co.za>
Message-ID: <1247784658.44.0.842264761093.issue2622@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

applied with r37952 (trunk), r37953 (2.6) and r37978 (py3k, docstrings 
only). Thanks for the patch!

----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2622>
_______________________________________

From report at bugs.python.org  Fri Jul 17 00:55:27 2009
From: report at bugs.python.org (Case Van Horsen)
Date: Thu, 16 Jul 2009 22:55:27 +0000
Subject: [issue6431] Fraction fails equality test with a user-defined type
In-Reply-To: <1247769273.72.0.0927937922347.issue6431@psf.upfronthosting.co.za>
Message-ID: <99e0b9530907161555qb03ac6al142d9327f96dc714@mail.gmail.com>


Case Van Horsen <casevh at gmail.com> added the comment:

On Thu, Jul 16, 2009 at 11:34 AM, Mark Dickinson<report at bugs.python.org> wrote:
>
> Mark Dickinson <dickinsm at gmail.com> added the comment:
>
> Thanks again, casevh! ?The patch looks good. ?I've added to it a bit,
> though---see issue6431.patch. ?In detail:
>
> - don't use subtraction with unknown types for <, <=, >, >=; ?this is
> ?dangerous, since the unknown type may well do a lossy conversion, and
> ?comparisons should really be exact where possible; ?as with __eq__,
> ?it seems better to return NotImplemented and give the other type a
> ?chance.
>
> - handle infs and nans correctly in comparisons with floats
>
> - a few more tests.
>
> casevh, please could you have a look at the attached patch and let me
> know whether it still works with your gmpy port?

I've tested gmpy with attached patch and all tests pass successfully.
Thanks!

>
> Jeffrey, any comments on these changes?
>
> ----------
> stage: test needed -> patch review
> Added file: http://bugs.python.org/file14508/issue6431.patch
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue6431>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6431>
_______________________________________

From report at bugs.python.org  Fri Jul 17 01:30:23 2009
From: report at bugs.python.org (Rogi)
Date: Thu, 16 Jul 2009 23:30:23 +0000
Subject: [issue6498] Py_Main() does not return on SystemExit
In-Reply-To: <1247787023.18.0.165575901629.issue6498@psf.upfronthosting.co.za>
Message-ID: <1247787023.18.0.165575901629.issue6498@psf.upfronthosting.co.za>


New submission from Rogi <rogi at linuxmail.org>:

>From teh docs:

http://docs.python.org/c-api/veryhigh.html

int Py_Main(int argc, char **argv)?

    The main program for the standard interpreter. This is made
available for programs which embed Python. The argc and argv parameters
should be prepared exactly as those which are passed to a C program?s
main() function. It is important to note that the argument list may be
modified (but the contents of the strings pointed to by the argument
list are not). The return value will be the integer passed to the
sys.exit() function, 1 if the interpreter exits due to an exception, or
2 if the parameter list does not represent a valid Python command line.

    Note that if an otherwise unhandled SystemError is raised, this
function will not return 1, but exit the process, as long as
Py_InspectFlag is not set.

Py_Main() still does not return on SystemExit.

----------
assignee: georg.brandl
components: Documentation
messages: 90596
nosy: Rogi, georg.brandl
severity: normal
status: open
title: Py_Main() does not return on SystemExit
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6498>
_______________________________________

From report at bugs.python.org  Fri Jul 17 02:06:18 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 17 Jul 2009 00:06:18 +0000
Subject: [issue6026]
	test_(zipfile|zipimport|gzip|distutils|multiprocessing|xmlrpc|docxmlrpc)
	fail if zlib is not available
In-Reply-To: <1242349106.59.0.466065396405.issue6026@psf.upfronthosting.co.za>
Message-ID: <1247789178.83.0.132905702504.issue6026@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Now (Python2.7a0 trunk:74029) there are 3 more tests that fail because
zlib is not available: test_multiprocessing, test_xmlrpc and test_docxmlrpc.

----------
title: test_(zipfile|zipimport|gzip|distutils) fail if zlib is not available -> test_(zipfile|zipimport|gzip|distutils|multiprocessing|xmlrpc|docxmlrpc) fail if zlib is not available

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6026>
_______________________________________

From report at bugs.python.org  Fri Jul 17 03:46:51 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Jul 2009 01:46:51 +0000
Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
Message-ID: <1247795211.94.0.378595901966.issue1424152@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Note that this bug is also of concern to Ubuntu.  See for example
https://bugs.launchpad.net/python/+bug/94130.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1424152>
_______________________________________

From report at bugs.python.org  Fri Jul 17 04:20:09 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 17 Jul 2009 02:20:09 +0000
Subject: [issue6499] Can't import xmlrpclib,
	DocXMLRPCServer and SimpleXMLRPCServer when zlib is not available
In-Reply-To: <1247797208.72.0.744238846554.issue6499@psf.upfronthosting.co.za>
Message-ID: <1247797208.72.0.744238846554.issue6499@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

I'm working on #6026 and I noticed that the patch for #6267 introduced
an "import gzip" in Lib/xmlrpclib.py in r73638.
gzip tries to import zlib, and if it's not available the import fails.
This led to 3 new tests failures in the trunk: test_xmlrpc,
test_docxmlrpc and test_multiprocessing.
This also mean that the modules xmlrpclib, DocXMLRPCServer and
SimpleXMLRPCServer (and possibly others) cannot be imported anymore if
zlib is not available (they used to work on 2.6).

xmlrpclib should check if the "import gzip" fails and disable the new
gzip-related features (raising an error only when someone tries to use
them).

I don't know if this check can be moved directly on gzip but it seems
unlikely.

----------
assignee: krisvale
messages: 90599
nosy: ezio.melotti, krisvale
priority: normal
severity: normal
stage: needs patch
status: open
title: Can't import xmlrpclib, DocXMLRPCServer and SimpleXMLRPCServer when zlib is not available
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6499>
_______________________________________

From report at bugs.python.org  Fri Jul 17 04:22:50 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 17 Jul 2009 02:22:50 +0000
Subject: [issue6267] Cumulative patcc:h to http and xmlrpc
In-Reply-To: <1244734235.6.0.17264314682.issue6267@psf.upfronthosting.co.za>
Message-ID: <1247797370.43.0.055183196359.issue6267@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

xmlrpclib, DocXMLRPCServer and SimpleXMLRPCServer cannot be imported
after r73638 if zlib is missing, see #6499.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6267>
_______________________________________

From report at bugs.python.org  Fri Jul 17 04:32:31 2009
From: report at bugs.python.org (Raphaela)
Date: Fri, 17 Jul 2009 02:32:31 +0000
Subject: [issue6498] Py_Main() does not return on SystemExit
In-Reply-To: <1247787023.18.0.165575901629.issue6498@psf.upfronthosting.co.za>
Message-ID: <1247797951.67.0.148040699037.issue6498@psf.upfronthosting.co.za>


Raphaela <rakeka_moore at hotmail.com> added the comment:

I'm having the same problem. The source of the problem seem to be in
PyRun_InteractiveOneFlags(). It prints and clears the last error.

----------
nosy: +Rakeka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6498>
_______________________________________

From report at bugs.python.org  Fri Jul 17 04:40:30 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 17 Jul 2009 02:40:30 +0000
Subject: [issue6026]
	test_(zipfile|zipimport|gzip|distutils|multiprocessing|xmlrpc|docxmlrpc)
	fail if zlib is not available
In-Reply-To: <1242349106.59.0.466065396405.issue6026@psf.upfronthosting.co.za>
Message-ID: <1247798430.02.0.221393149417.issue6026@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The 3 new failures (test_multiprocessing, test_xmplrpc and
test_docxmlrpc) were introduced in r73638 and I opened a new issue about
that (#6499). I'll wait to see if and how they should be fixed (and
possibly open a new issue for them).

The attached patch fixes test_zipfile, test_zipimport, test_gzip and
test_distutils.

I used two techniques to fix these files:
1) checking if zlib was available with
   try:
       import zlib
   except ImportError:
       zlib = None
   and then using @skipUnless(zlib, "requires zlib")
   to skip individual tests/classes
2) using zlib = test_support.import_module('zlib') when
   zlib (or other modules like gzip) was necessary for
   all the tests

The patch includes the following fixes:

In test_zipfile there were 5 tests that were failing. Several other
tests work without zlib too. Fixed adding 3 @skipUnless(zlib, "requires
zlib") to two methods and to the TestsWithMultipleOpens class.

In test_zipimport there are 3 test classes. The 3rd class tests various
errors that are raised when, for example, the file doesn't exists. This
class works without zlib too, but since it's pointless to run it if the
other two don't work I decided to skip everything. Fixed adding zlib =
test_support.import_module('zlib').

In test_gzip all the files require gzip to work, and gzip requires zlib.
Fixed adding gzip = test_support.import_module('gzip').

In test_distutils there are several files affected:
test_sdist: fixed with 4 @skipUnless(zlib, "requires zlib")
test_bdist_dumb: fixed with a @skipUnless(zlib, "requires zlib")
test_archive_util: fixed with 3 @skipUnless(zlib, "requires zlib")

If the patch is good I'll commit it.

----------
dependencies: +Can't import xmlrpclib, DocXMLRPCServer and SimpleXMLRPCServer when zlib is not available
keywords: +needs review, patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file14512/issue6026.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6026>
_______________________________________

From report at bugs.python.org  Fri Jul 17 06:13:48 2009
From: report at bugs.python.org (Senthil)
Date: Fri, 17 Jul 2009 04:13:48 +0000
Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
Message-ID: <1247804028.99.0.958375797499.issue1424152@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

This is actually fixed in Py2.7 and I am trying to get it Py3.2 before
marking this as fixed.

Based on the comments, should this be backported to Py2.6?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1424152>
_______________________________________

From report at bugs.python.org  Fri Jul 17 07:22:44 2009
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 17 Jul 2009 05:22:44 +0000
Subject: [issue6415] warnings.warn segfaults on bad formatted string
In-Reply-To: <1246702444.15.0.967525803194.issue6415@psf.upfronthosting.co.za>
Message-ID: <1247808164.89.0.609164516887.issue6415@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
components: +Interpreter Core
priority:  -> release blocker
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6415>
_______________________________________

From report at bugs.python.org  Fri Jul 17 07:37:09 2009
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 17 Jul 2009 05:37:09 +0000
Subject: [issue6449] Improve/update python.org/dev/
In-Reply-To: <1247165034.18.0.173554225695.issue6449@psf.upfronthosting.co.za>
Message-ID: <1247809029.65.0.765571230735.issue6449@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

OK, fixed in r12412 for pydotorg sans the IRC stuff (don't feel 
comfortable pointing people that way when IRC is not under our control). 
Thanks for the fixes, Ezio.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6449>
_______________________________________

From report at bugs.python.org  Fri Jul 17 07:39:58 2009
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 17 Jul 2009 05:39:58 +0000
Subject: [issue6449] Improve/update python.org/dev/
In-Reply-To: <1247165034.18.0.173554225695.issue6449@psf.upfronthosting.co.za>
Message-ID: <1247809198.96.0.4904745218.issue6449@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6449>
_______________________________________

From report at bugs.python.org  Fri Jul 17 07:59:00 2009
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 17 Jul 2009 05:59:00 +0000
Subject: [issue6415] warnings.warn segfaults on bad formatted string
In-Reply-To: <1246702444.15.0.967525803194.issue6415@psf.upfronthosting.co.za>
Message-ID: <1247810340.58.0.603913556129.issue6415@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Here is a patch for test_warning to test for the failure. Hirokazu, since 
you found the fix, do you want to do the commit, or do you want me to 
handle it since this will need to be applied to all active branches?

----------
assignee: brett.cannon -> ocean-city
stage: patch review -> commit review
Added file: http://bugs.python.org/file14513/test_warnings.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6415>
_______________________________________

From report at bugs.python.org  Fri Jul 17 09:03:23 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 17 Jul 2009 07:03:23 +0000
Subject: [issue6415] warnings.warn segfaults on bad formatted string
In-Reply-To: <1246702444.15.0.967525803194.issue6415@psf.upfronthosting.co.za>
Message-ID: <1247814203.77.0.0434002746008.issue6415@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I've committed in r74040(trunk), r74043(release26-maint), r74046(py3k), 
r74047(release31-maint). Is release30-maint still active?

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6415>
_______________________________________

From report at bugs.python.org  Fri Jul 17 09:12:00 2009
From: report at bugs.python.org (Iain Wade)
Date: Fri, 17 Jul 2009 07:12:00 +0000
Subject: [issue6473] hmac sha384/sha512 fails test vectors
In-Reply-To: <1247457411.29.0.0335702117949.issue6473@psf.upfronthosting.co.za>
Message-ID: <1247814720.71.0.521532140757.issue6473@psf.upfronthosting.co.za>


Iain Wade <iwade at optusnet.com.au> added the comment:

d'oh, I should have checked HEAD before submitting the bug.

I am running 2.5.1 on OSX, the fix seems to be in 2.5.2 and above.

Thanks, and sorry for wasting your time.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6473>
_______________________________________

From report at bugs.python.org  Fri Jul 17 09:26:18 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 17 Jul 2009 07:26:18 +0000
Subject: [issue6496] 2to3 generates "from urllib.parse import pathname2url"
In-Reply-To: <1247777987.6.0.0614003313413.issue6496@psf.upfronthosting.co.za>
Message-ID: <1247815578.87.0.947827353408.issue6496@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +benjamin.peterson
priority:  -> normal
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6496>
_______________________________________

From report at bugs.python.org  Fri Jul 17 09:39:45 2009
From: report at bugs.python.org (Graham Dumpleton)
Date: Fri, 17 Jul 2009 07:39:45 +0000
Subject: [issue6393] OS X: python3 from python-3.1.dmg crashes at startup
In-Reply-To: <1246445517.38.0.373229118664.issue6393@psf.upfronthosting.co.za>
Message-ID: <1247816385.34.0.873252452563.issue6393@psf.upfronthosting.co.za>


Graham Dumpleton <Graham.Dumpleton at gmail.com> added the comment:

I see this problem on both MacOS X 10.5 and on Windows. This is when using 
Python embedded inside of Apache/mod_wsgi.

On MacOS X the error is:

Fatal Python error: Py_Initialize: can't initialize sys standard streams
ImportError: No module named encodings.utf_8

On Windows the error is:

Fatal Python error: Py_Initialize: can't initialize sys standard streams
LookupError: unknown encoding: cp0

The talk about the fix mentioned it only addressing MacOS X. What about 
Windows case I am seeing. Will it help with that at all?

----------
nosy: +grahamd

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6393>
_______________________________________

From report at bugs.python.org  Fri Jul 17 09:41:41 2009
From: report at bugs.python.org (Graham Dumpleton)
Date: Fri, 17 Jul 2009 07:41:41 +0000
Subject: [issue6393] OS X: python3 from python-3.1.dmg crashes at startup
In-Reply-To: <1246445517.38.0.373229118664.issue6393@psf.upfronthosting.co.za>
Message-ID: <1247816501.82.0.475844113211.issue6393@psf.upfronthosting.co.za>


Graham Dumpleton <Graham.Dumpleton at gmail.com> added the comment:

Hmmm, actually my MacOS X error is different, although Windows one is 
same, except that encoding is listed and isn't empty.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6393>
_______________________________________

From report at bugs.python.org  Fri Jul 17 09:49:11 2009
From: report at bugs.python.org (Graham Dumpleton)
Date: Fri, 17 Jul 2009 07:49:11 +0000
Subject: [issue6393] OS X: python3 from python-3.1.dmg crashes at startup
In-Reply-To: <1246445517.38.0.373229118664.issue6393@psf.upfronthosting.co.za>
Message-ID: <1247816951.43.0.781283419674.issue6393@psf.upfronthosting.co.za>


Graham Dumpleton <Graham.Dumpleton at gmail.com> added the comment:

You can ignore my MacOS X example as that was caused by something else.

My question still stands as to whether the fix will address the similar 
problem I saw on Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6393>
_______________________________________

From report at bugs.python.org  Fri Jul 17 10:19:44 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 17 Jul 2009 08:19:44 +0000
Subject: [issue6497] Support for digital Cinema/film DPX and Kodak Cineon
	image file formats in imghdr module
In-Reply-To: <1247779729.41.0.45019789349.issue6497@psf.upfronthosting.co.za>
Message-ID: <1247818784.63.0.14841797754.issue6497@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I can't judge the content of the patch because I don't know these
formats at all, however there are a few issues about the style:
1) there are tabs mixed with spaces, the standard is 4 spaces;
2) there should be an empty space before and after operators like ==, <
and >;
3) h and f are not really meaningful names, I can't figure out what they
are supposed to represent.
For further information about the style conventions see
http://www.python.org/dev/peps/pep-0008/

The "import struct" might be better at module level; 'f' is passed to
both the function and never used; the docstrings may be more comprehensive.

Finally, it would be nice if you could provide a patch against the
trunk, you can find more information about it on
http://www.python.org/dev/patches/ and
http://www.python.org/dev/faq/#patches

If you have any question feel free to ask.

----------
keywords: +patch
nosy: +ezio.melotti
priority:  -> low
versions:  -Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6497>
_______________________________________

From report at bugs.python.org  Fri Jul 17 10:26:14 2009
From: report at bugs.python.org (simon)
Date: Fri, 17 Jul 2009 08:26:14 +0000
Subject: [issue6500] urllib2 maximum recursion depth exceeded
In-Reply-To: <1247819174.12.0.0313325803352.issue6500@psf.upfronthosting.co.za>
Message-ID: <1247819174.12.0.0313325803352.issue6500@psf.upfronthosting.co.za>


New submission from simon <nkucyd at gmail.com>:

def __getattr__(self, attr):
        # XXX this is a fallback mechanism to guard against these
        # methods getting called in a non-standard order.  this may be
        # too complicated and/or unnecessary.
        # XXX should the __r_XXX attributes be public?
        if attr[:12] == '_Request__r_':
            name = attr[12:]
            if hasattr(Request, 'get_' + name):
                getattr(self, 'get_' + name)()
                return getattr(self, attr)
        raise AttributeError, attr

this may cause "maximum recursion depth exceeded"

>>> import urllib2
>>> req = urllib2.Request('http://www.nbc.com')
>>> req._Request__r_method
RuntimeError: maximum recursion depth exceeded

"return getattr(self, attr)"? should it be removed?

----------
components: Library (Lib)
messages: 90612
nosy: nako521
severity: normal
status: open
title: urllib2 maximum recursion depth exceeded
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6500>
_______________________________________

From report at bugs.python.org  Fri Jul 17 10:32:02 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 17 Jul 2009 08:32:02 +0000
Subject: [issue6449] Improve/update python.org/dev/
In-Reply-To: <1247165034.18.0.173554225695.issue6449@psf.upfronthosting.co.za>
Message-ID: <1247819522.85.0.1447873598.issue6449@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Thanks to you for fixing it!
However on http://www.python.org/dev/buildbot/ now there's 3.w (maybe
you missed the '2' key?).
About the IRC stuff, at least #python-dev (and probably #python-docs
too) are under our control (even if Freenode is not under our control,
these channels are used and managed by Python developers).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6449>
_______________________________________

From report at bugs.python.org  Fri Jul 17 10:37:07 2009
From: report at bugs.python.org (Rogi)
Date: Fri, 17 Jul 2009 08:37:07 +0000
Subject: [issue6498] Py_Main() does not return on SystemExit
In-Reply-To: <1247787023.18.0.165575901629.issue6498@psf.upfronthosting.co.za>
Message-ID: <1247819827.96.0.13870972558.issue6498@psf.upfronthosting.co.za>


Rogi <rogi at linuxmail.org> added the comment:

As a workaround, I copied teh function PyRun_InteractiveOneFlags() to my
own source and modified it so it would not print or clear exceptions.
However, I have never found documentation about PyArena* or
PyParser_AST*. Are those functions public or just for internal use?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6498>
_______________________________________

From report at bugs.python.org  Fri Jul 17 11:19:23 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 17 Jul 2009 09:19:23 +0000
Subject: [issue6500] urllib2 maximum recursion depth exceeded
In-Reply-To: <1247819174.12.0.0313325803352.issue6500@psf.upfronthosting.co.za>
Message-ID: <1247822363.2.0.286846312542.issue6500@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

That __getattr__ was removed in r70815 and in Python 3.1 it's OK.
The change wasn't backported to the trunk though.

Assigning to Jeremy to see what he thinks about it.

----------
assignee:  -> jhylton
nosy: +ezio.melotti, jhylton
priority:  -> normal
status: open -> pending
versions: +Python 2.7 -Python 2.4, Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6500>
_______________________________________

From report at bugs.python.org  Fri Jul 17 12:21:45 2009
From: report at bugs.python.org (Graham Dumpleton)
Date: Fri, 17 Jul 2009 10:21:45 +0000
Subject: [issue6501] Fatal LookupError: unknown encoding: cp0 on Windows
	embedded startup.
In-Reply-To: <1247826105.17.0.941734297485.issue6501@psf.upfronthosting.co.za>
Message-ID: <1247826105.17.0.941734297485.issue6501@psf.upfronthosting.co.za>


New submission from Graham Dumpleton <Graham.Dumpleton at gmail.com>:

When using Python 3.1 for Apache/mod_wsgi (3.0c4) on Windows, Apache will 
crash on startup because Python is forcing the process to exit with:

Fatal Python error: Py_Initialize: can't initialize sys standard streams
LookupError: unknown encoding: cp0

I first mentioned this on issue6393, but have now created it as a separate 
issue as appears to be distinct from the issue on MacOS X, athough possibly 
related.

In the Windows case there is actually an encoding, that of 'cp0' where as on 
MacOS X, the encoding name was empty.

The same mod_wsgi code works fine under Python 3.1 on MacOS X.

----------
components: Interpreter Core, Windows
messages: 90616
nosy: grahamd
severity: normal
status: open
title: Fatal LookupError: unknown encoding: cp0 on Windows embedded startup.
type: crash
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6501>
_______________________________________

From report at bugs.python.org  Fri Jul 17 12:24:43 2009
From: report at bugs.python.org (Graham Dumpleton)
Date: Fri, 17 Jul 2009 10:24:43 +0000
Subject: [issue6393] OS X: python3 from python-3.1.dmg crashes at startup
In-Reply-To: <1246445517.38.0.373229118664.issue6393@psf.upfronthosting.co.za>
Message-ID: <1247826283.08.0.69922374243.issue6393@psf.upfronthosting.co.za>


Graham Dumpleton <Graham.Dumpleton at gmail.com> added the comment:

I have created issue6501 for my Windows variant of this problem given that 
it appears to be subtly different due to there being an encoding where as 
the MacOS X variant doesn't have one.

Seeing that the fix for the MacOS X issue is in Python code, I will when I 
have a chance look at whether can work out any fix for the Windows 
variant. Not sure I have right tools to compile Python from C code on 
Windows, so if a C code problem, not sure can really investigate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6393>
_______________________________________

From report at bugs.python.org  Fri Jul 17 13:20:12 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 17 Jul 2009 11:20:12 +0000
Subject: [issue6501] Fatal LookupError: unknown encoding: cp0 on Windows
	embedded startup.
In-Reply-To: <1247826105.17.0.941734297485.issue6501@psf.upfronthosting.co.za>
Message-ID: <1247829612.34.0.992382444568.issue6501@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

- Apache is not a Console application, so the Windows GetConsoleCP()
function returns zero (and os.device_encoding(1) returns 'cp0').
- pythonw.exe has no console either; but in pythonrun.c, the test
(fileno(stdin) < 0) is true, and the standard streams are all set to None.
- It is probable that Apache has redefined stdin & co, so the previous
test does not work there.

As a workaround, I suggest to set the environment variable
PYTHONIOENCODING before starting Apache, or before the call to
Py_Initialize.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6501>
_______________________________________

From report at bugs.python.org  Fri Jul 17 13:27:03 2009
From: report at bugs.python.org (kai zhu)
Date: Fri, 17 Jul 2009 11:27:03 +0000
Subject: [issue6502] documentation error: missing comma between kwonlyargcount
	& nlocals
In-Reply-To: <1247830022.67.0.951938723623.issue6502@psf.upfronthosting.co.za>
Message-ID: <1247830022.67.0.951938723623.issue6502@psf.upfronthosting.co.za>


New submission from kai zhu <kaizhu256 at gmail.com>:

missing comma between kwonlyargcount & nlocals

class code(object)
 |  code(argcount, kwonlyargcount nlocals, stacksize, flags, codestring,
 |        constants, names, varnames, filename, name, firstlineno,
 |        lnotab[, freevars[, cellvars]])

----------
assignee: georg.brandl
components: Documentation
messages: 90619
nosy: georg.brandl, kaizhu
severity: normal
status: open
title: documentation error: missing comma between kwonlyargcount & nlocals
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6502>
_______________________________________

From report at bugs.python.org  Fri Jul 17 13:32:27 2009
From: report at bugs.python.org (Graham Dumpleton)
Date: Fri, 17 Jul 2009 11:32:27 +0000
Subject: [issue6501] Fatal LookupError: unknown encoding: cp0 on Windows
	embedded startup.
In-Reply-To: <1247826105.17.0.941734297485.issue6501@psf.upfronthosting.co.za>
Message-ID: <1247830347.91.0.0200592083257.issue6501@psf.upfronthosting.co.za>


Graham Dumpleton <Graham.Dumpleton at gmail.com> added the comment:

Yes, Apache remaps stdout and stderr to the Apache error log to still 
capture anything that errant modules don't log via the Apache error log 
functions. In mod_wsgi it replaces sys.stdout and sys.stderr with special 
file like objects that redirect via Apache error logging functions. This 
though obviously happens after Python first initialises sys.stdout and 
sys.stderr.

What would be an appropriate value to set PYTHONIOENCODING to on Windows 
as a workaround?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6501>
_______________________________________

From report at bugs.python.org  Fri Jul 17 13:55:59 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 17 Jul 2009 11:55:59 +0000
Subject: [issue6502] documentation error: missing comma between kwonlyargcount
	& nlocals
In-Reply-To: <1247830022.67.0.951938723623.issue6502@psf.upfronthosting.co.za>
Message-ID: <1247831759.69.0.077442645645.issue6502@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Thanks for the report.
This was introduced in r60313 (see also #1939).

----------
assignee: georg.brandl -> ezio.melotti
nosy: +ezio.melotti
priority:  -> low
resolution:  -> accepted
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6502>
_______________________________________

From report at bugs.python.org  Fri Jul 17 15:14:21 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Jul 2009 13:14:21 +0000
Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
Message-ID: <1247836461.06.0.159103283177.issue1424152@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Personally I would like to see that happen, but I think you should
probably poll python-dev since it can be argued either way as to whether
it is a bug fix or a new feature.  FWIW, from the feeder bug reports it
looks to me like the users perceive it as a bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1424152>
_______________________________________

From report at bugs.python.org  Fri Jul 17 15:14:36 2009
From: report at bugs.python.org (Michael Kesper)
Date: Fri, 17 Jul 2009 13:14:36 +0000
Subject: [issue6503] Python Docs: 6.6.4. Mutable Sequence Types
In-Reply-To: <1247836476.38.0.640968840899.issue6503@psf.upfronthosting.co.za>
Message-ID: <1247836476.38.0.640968840899.issue6503@psf.upfronthosting.co.za>


New submission from Michael Kesper <mkesper at schokokeks.org>:

In http://docs.python.org/library/stdtypes.html#mutable-sequence-types
s.pop([i]) is listed. Correct would be:
s.pop(i)

----------
assignee: georg.brandl
components: Documentation
messages: 90623
nosy: georg.brandl, mkesper
severity: normal
status: open
title: Python Docs: 6.6.4. Mutable Sequence Types
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6503>
_______________________________________

From report at bugs.python.org  Fri Jul 17 15:20:12 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 17 Jul 2009 13:20:12 +0000
Subject: [issue6503] Python Docs: 6.6.4. Mutable Sequence Types
In-Reply-To: <1247836476.38.0.640968840899.issue6503@psf.upfronthosting.co.za>
Message-ID: <1247836812.52.0.587097090027.issue6503@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The [] here mean that i is optional, the note (6) clarifies that its
default value is -1. Closing as invalid.

----------
nosy: +ezio.melotti
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6503>
_______________________________________

From report at bugs.python.org  Fri Jul 17 15:29:05 2009
From: report at bugs.python.org (Michael Haubenwallner)
Date: Fri, 17 Jul 2009 13:29:05 +0000
Subject: [issue6163] [HP-UX] ld: Unrecognized argument: +s -L<dir>
In-Reply-To: <1243876859.78.0.253879711884.issue6163@psf.upfronthosting.co.za>
Message-ID: <1247837345.87.0.108087023124.issue6163@psf.upfronthosting.co.za>


Michael Haubenwallner <michael.haubenwallner at salomon.at> added the comment:

While at it: gcc does not understand '+s', it does need '-Wl,+s'.

----------
nosy: +haubi
Added file: http://bugs.python.org/file14514/distutils_hpux_libdir_option-gcc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6163>
_______________________________________

From report at bugs.python.org  Fri Jul 17 16:18:24 2009
From: report at bugs.python.org (James Broadhead)
Date: Fri, 17 Jul 2009 14:18:24 +0000
Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
Message-ID: <1247840304.94.0.809495306979.issue1424152@psf.upfronthosting.co.za>


James Broadhead <jamesbroadhead at gmail.com> added the comment:

+1 to the above. 

(imo, this is a bugfix, not a new feature)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1424152>
_______________________________________

From report at bugs.python.org  Fri Jul 17 17:36:09 2009
From: report at bugs.python.org (kai zhu)
Date: Fri, 17 Jul 2009 15:36:09 +0000
Subject: [issue6504] infinite recursion from calling builtins.open()
In-Reply-To: <1247844969.58.0.287534577391.issue6504@psf.upfronthosting.co.za>
Message-ID: <1247844969.58.0.287534577391.issue6504@psf.upfronthosting.co.za>


New submission from kai zhu <kaizhu256 at gmail.com>:

# copy this to test.py
# > touch foo.txt
# > python3.1 -c "import test; import collections"
# > ...
# >   File "test.py", line 5, in find_module
# >     def find_module(self, mname, path = None): open("foo.txt")
# >   File "test.py", line 5, in find_module
# >     def find_module(self, mname, path = None): open("foo.txt")
# >   File "test.py", line 5, in find_module
# >     def find_module(self, mname, path = None): open("foo.txt")
# >   File "test.py", line 5, in find_module
# >     def find_module(self, mname, path = None): open("foo.txt")
# > RuntimeError: maximum recursion depth exceeded while calling a
# > Python object
class importer(object):
  def find_module(self, mname, path = None): open("foo.txt")
import sys; sys.meta_path.append(importer)

***

# note recursion behavior stops if we don't call open()
class importer(object):
  def find_module(self, mname, path = None): pass
import sys; sys.meta_path.append(importer)

----------
components: IO, Interpreter Core
messages: 90627
nosy: kaizhu
severity: normal
status: open
title: infinite recursion from calling builtins.open()
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6504>
_______________________________________

From report at bugs.python.org  Fri Jul 17 17:39:10 2009
From: report at bugs.python.org (csmayfield)
Date: Fri, 17 Jul 2009 15:39:10 +0000
Subject: [issue6505] Minor typos in tutorial (i/o chapter)
In-Reply-To: <1247845150.31.0.529218461562.issue6505@psf.upfronthosting.co.za>
Message-ID: <1247845150.31.0.529218461562.issue6505@psf.upfronthosting.co.za>


New submission from csmayfield <csmayfield at gmail.com>:

In tutorial/inputoutput.html:
"This also greater control over how the value is formatted. The 
following example truncates the Pi to three places after the decimal."

Should be:
"This allows greater control over how the value is formatted. The 
following example truncates pi to three places after the decimal."

Next subsection:
"However, because this old style of formatting will eventually removed 
from the language str.format() should generally be used."

Should be:
"However, because this old style of formatting will eventually be 
removed from the language, str.format() should generally be used."

----------
assignee: georg.brandl
components: Documentation
messages: 90628
nosy: csmayfield, georg.brandl
severity: normal
status: open
title: Minor typos in tutorial (i/o chapter)
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6505>
_______________________________________

From report at bugs.python.org  Fri Jul 17 19:19:15 2009
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 17 Jul 2009 17:19:15 +0000
Subject: [issue6449] Improve/update python.org/dev/
In-Reply-To: <1247819522.85.0.1447873598.issue6449@psf.upfronthosting.co.za>
Message-ID: <bbaeab100907171018i35246a74t781f35516a6ffe45@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Fri, Jul 17, 2009 at 01:32, Ezio Melotti <report at bugs.python.org> wrote:

>
> Ezio Melotti <ezio.melotti at gmail.com> added the comment:
>
> Thanks to you for fixing it!
> However on http://www.python.org/dev/buildbot/ now there's 3.w (maybe
> you missed the '2' key?).

I did, but Aahz has already fixed it.

>
> About the IRC stuff, at least #python-dev (and probably #python-docs
> too) are under our control (even if Freenode is not under our control,
> these channels are used and managed by Python developers).

Well, they are under our control as long as someone sits in them, but the
PSF is not a registered owner of any of the channels (I submitted our
application ages ago to help out with the German Python channel and still
have not heard back). And hardly anyone sits in #python-dev except on bug
days. I still don't feel comfortable mentioning them.

----------
Added file: http://bugs.python.org/file14515/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6449>
_______________________________________
-------------- next part --------------
<br><br><div class="gmail_quote">On Fri, Jul 17, 2009 at 01:32, Ezio Melotti <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
Ezio Melotti &lt;<a href="mailto:ezio.melotti at gmail.com">ezio.melotti at gmail.com</a>&gt; added the comment:<br>
<br>
Thanks to you for fixing it!<br>
However on <a href="http://www.python.org/dev/buildbot/" target="_blank">http://www.python.org/dev/buildbot/</a> now there&#39;s 3.w (maybe<br>
you missed the &#39;2&#39; key?).</blockquote><div><br></div><div>I did, but Aahz has already fixed it.</div><div>??</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
About the IRC stuff, at least #python-dev (and probably #python-docs<br>
too) are under our control (even if Freenode is not under our control,<br>
these channels are used and managed by Python developers).</blockquote><div><br></div><div>Well, they are under our control as long as someone sits in them, but the PSF is not a registered owner of any of the channels (I submitted our application ages ago to help out with the German Python channel and still have not heard back). And hardly anyone sits in #python-dev except on bug days. I still don&#39;t feel comfortable mentioning them.</div>

</div>

From report at bugs.python.org  Fri Jul 17 19:20:26 2009
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 17 Jul 2009 17:20:26 +0000
Subject: [issue6415] warnings.warn segfaults on bad formatted string
In-Reply-To: <1247814203.77.0.0434002746008.issue6415@psf.upfronthosting.co.za>
Message-ID: <bbaeab100907171020xbeb67fbo9d8e50bd8239eafb@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Fri, Jul 17, 2009 at 00:03, Hirokazu Yamamoto <report at bugs.python.org>wrote:

>
> Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:
>
> I've committed in r74040(trunk), r74043(release26-maint), r74046(py3k),
> r74047(release31-maint). Is release30-maint still active?
>

No, 3.0 is dead.

Thanks, Hirokazu!

----------
Added file: http://bugs.python.org/file14516/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6415>
_______________________________________
-------------- next part --------------
<br><br><div class="gmail_quote">On Fri, Jul 17, 2009 at 00:03, Hirokazu Yamamoto <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
Hirokazu Yamamoto &lt;<a href="mailto:ocean-city at m2.ccsnet.ne.jp">ocean-city at m2.ccsnet.ne.jp</a>&gt; added the comment:<br>
<br>
I&#39;ve committed in r74040(trunk), r74043(release26-maint), r74046(py3k),<br>
r74047(release31-maint). Is release30-maint still active?<br>
</blockquote><div><br></div><div>No, 3.0 is dead.</div><div><br></div><div>Thanks, Hirokazu!</div></div>

From report at bugs.python.org  Fri Jul 17 19:26:36 2009
From: report at bugs.python.org (Eric Promislow)
Date: Fri, 17 Jul 2009 17:26:36 +0000
Subject: [issue6496] 2to3 generates "from urllib.parse import pathname2url"
In-Reply-To: <1247777987.6.0.0614003313413.issue6496@psf.upfronthosting.co.za>
Message-ID: <1247851596.0.0.181821464926.issue6496@psf.upfronthosting.co.za>


Eric Promislow <ericp at activestate.com> added the comment:

Not in Sridar's patch, but 'pathname2url' is also misspelled
as 'pahtname2url' in the MAPPING struct.

----------
nosy: +ericp

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6496>
_______________________________________

From report at bugs.python.org  Fri Jul 17 19:39:45 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Jul 2009 17:39:45 +0000
Subject: [issue6449] Improve/update python.org/dev/
In-Reply-To: <1247165034.18.0.173554225695.issue6449@psf.upfronthosting.co.za>
Message-ID: <1247852385.66.0.136761545738.issue6449@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Enzio, Georg, Antoine, Benjamin, Barry, and I, just to name a few, hang
out in #python-dev regularly (as in daily, for some of us).  (Well,
Barry doesn't actively monitor the channel, but if you mention his name
he often wakes up.)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6449>
_______________________________________

From report at bugs.python.org  Fri Jul 17 19:49:12 2009
From: report at bugs.python.org (Hans Lellelid)
Date: Fri, 17 Jul 2009 17:49:12 +0000
Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
Message-ID: <1247852952.47.0.0590422790706.issue1424152@psf.upfronthosting.co.za>


Hans Lellelid <hans at velum.net> added the comment:

Personally, I also think that this is a bugfix, though I realize that in
order to fix the bug an API addition had to be made.  So +1 from me on
rolling into 2.6 (though my opinion is simply that of someone who's
eager to see it fixed).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1424152>
_______________________________________

From report at bugs.python.org  Fri Jul 17 19:53:36 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 17 Jul 2009 17:53:36 +0000
Subject: [issue6496] 2to3 generates "from urllib.parse import pathname2url"
In-Reply-To: <1247777987.6.0.0614003313413.issue6496@psf.upfronthosting.co.za>
Message-ID: <1247853216.47.0.646357702377.issue6496@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r74065.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6496>
_______________________________________

From report at bugs.python.org  Fri Jul 17 19:54:19 2009
From: report at bugs.python.org (Eric Promislow)
Date: Fri, 17 Jul 2009 17:54:19 +0000
Subject: [issue6506] lib2to3 fails to convert 'thread' when not followed by a
	period
In-Reply-To: <1247853259.26.0.126472143198.issue6506@psf.upfronthosting.co.za>
Message-ID: <1247853259.26.0.126472143198.issue6506@psf.upfronthosting.co.za>


New submission from Eric Promislow <ericp at activestate.com>:

Given this code:

import thread
print thread

$ python
ActivePython 2.6.1.1 (ActiveState Software Inc.) based on
Python 2.6.1 (r261:67515, Dec  5 2008, 13:58:38) [MSC v.1500 32 bit
(Intel)] on
win32
>>> from lib2to3.main import main
>>> print open("flip2.py").read()
import thread
print thread

>>> main('lib2to3.fixes', ['flip2.py'])
RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: set_literal
RefactoringTool: Skipping implicit fixer: ws_comma
--- flip2.py (original)
+++ flip2.py (refactored)
@@ -1,2 +1,2 @@
-import thread
-print thread
+import _thread
+print(thread)
RefactoringTool: Files that need to be modified:
RefactoringTool: flip2.py
0

Note how "thread" in the print statement is not converted.

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 90635
nosy: ericp
severity: normal
status: open
title: lib2to3 fails to convert 'thread' when not followed by a period
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6506>
_______________________________________

From report at bugs.python.org  Fri Jul 17 20:49:49 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Jul 2009 18:49:49 +0000
Subject: [issue6506] lib2to3 fails to convert 'thread' when not followed by a
	period
In-Reply-To: <1247853259.26.0.126472143198.issue6506@psf.upfronthosting.co.za>
Message-ID: <1247856589.46.0.81407723951.issue6506@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +benjamin.peterson
priority:  -> normal
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6506>
_______________________________________

From report at bugs.python.org  Fri Jul 17 20:58:12 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 17 Jul 2009 18:58:12 +0000
Subject: [issue6506] lib2to3 fails to convert 'thread' when not followed by a
	period
In-Reply-To: <1247853259.26.0.126472143198.issue6506@psf.upfronthosting.co.za>
Message-ID: <1247857092.89.0.628407933089.issue6506@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

This is purposeful. Otherwise random variables, functions, or classes,
with the same name as a module which people were using could be changed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6506>
_______________________________________

From report at bugs.python.org  Fri Jul 17 21:06:15 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 17 Jul 2009 19:06:15 +0000
Subject: [issue6507] Enhance dis.dis to autocompile codestrings
In-Reply-To: <1247857575.21.0.389925271165.issue6507@psf.upfronthosting.co.za>
Message-ID: <1247857575.21.0.389925271165.issue6507@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

dis.dis(ob) currently accepts "a module, a class, a method, a function,
or a code object." But for most uses I have seen on python-list, people
start with a code snippet. They must then wrap that in a function or
remember (or lookup) a call such as compile(code, '', 'exec') to make a
code object. I propose that dis do the latter automatically. Dis already
has to branch on the input class, so I assume adding another branch
should not be difficult.

On the Python ideas list, Steven D'Aprano raised the issue of 'exec'
versus 'single' versus 'eval'. As far as dis is concerned, there seems
to be no difference between 'exec' and 'single'.

>>> dis(compile('x = x+1', '', 'single'))
  1           0 LOAD_NAME                0 (x) 
              3 LOAD_CONST               0 (1) 
              6 BINARY_ADD           
              7 STORE_NAME               0 (x) 
             10 LOAD_CONST               1 (None) 
             13 RETURN_VALUE         

>>> dis(compile('x = x+1', '', 'exec'))
  1           0 LOAD_NAME                0 (x) 
              3 LOAD_CONST               0 (1) 
              6 BINARY_ADD           
              7 STORE_NAME               0 (x) 
             10 LOAD_CONST               1 (None) 
             13 RETURN_VALUE         

Using 'exec' instead of 'eval' adds two spurious, but easily ignored, lines.

>>> dis(compile('x+1','', 'eval'))
  1           0 LOAD_NAME                0 (x) 
              3 LOAD_CONST               0 (1) 
              6 BINARY_ADD           
              7 RETURN_VALUE    
     
>>> dis(compile('x+1', '', 'exec'))
  1           0 LOAD_NAME                0 (x) 
              3 LOAD_CONST               0 (1) 
              6 BINARY_ADD           
              7 POP_TOP              
              8 LOAD_CONST               1 (None) 
             11 RETURN_VALUE         

Between the current doc sentences "For a single code sequence, it prints
one line per bytecode instruction." and "If no object is provided, it
disassembles the last traceback." I propose adding the following two
sentences.

"Strings are first compiled as statements to code objects with
compile(string,'','exec'). For expressions, this adds a spurious POP_TOP
and LOAD_CONST at the end."

'compile' should be cross-referenced to its listing under built-in
functions.

----------
components: Library (Lib)
messages: 90637
nosy: tjreedy
severity: normal
status: open
title: Enhance dis.dis to autocompile codestrings
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6507>
_______________________________________

From report at bugs.python.org  Fri Jul 17 21:07:49 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 17 Jul 2009 19:07:49 +0000
Subject: [issue6507] Enhance dis.dis to autocompile codestrings
In-Reply-To: <1247857575.21.0.389925271165.issue6507@psf.upfronthosting.co.za>
Message-ID: <1247857669.16.0.187193587501.issue6507@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
priority:  -> low
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6507>
_______________________________________

From report at bugs.python.org  Fri Jul 17 21:14:54 2009
From: report at bugs.python.org (Eric Promislow)
Date: Fri, 17 Jul 2009 19:14:54 +0000
Subject: [issue6506] lib2to3 fails to convert 'thread' when not followed by a
	period
In-Reply-To: <1247853259.26.0.126472143198.issue6506@psf.upfronthosting.co.za>
Message-ID: <1247858094.18.0.748960464156.issue6506@psf.upfronthosting.co.za>


Eric Promislow <ericp at activestate.com> added the comment:

Understood.  Could the tool emit a warning when it encounters
something like this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6506>
_______________________________________

From report at bugs.python.org  Fri Jul 17 21:21:13 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 17 Jul 2009 19:21:13 +0000
Subject: [issue6506] lib2to3 fails to convert 'thread' when not followed by a
	period
In-Reply-To: <1247858094.18.0.748960464156.issue6506@psf.upfronthosting.co.za>
Message-ID: <1afaf6160907171221n6391e978md4ba5c32591a08b1@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2009/7/17 Eric Promislow <report at bugs.python.org>:
>
> Eric Promislow <ericp at activestate.com> added the comment:
>
> Understood. ?Could the tool emit a warning when it encounters
> something like this?

Perhaps, but I think you could find this out just as well by running a
tool like Pylint over your code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6506>
_______________________________________

From report at bugs.python.org  Fri Jul 17 21:22:30 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 17 Jul 2009 19:22:30 +0000
Subject: [issue6506] lib2to3 fails to convert 'thread' when not followed by a
	period
In-Reply-To: <1247853259.26.0.126472143198.issue6506@psf.upfronthosting.co.za>
Message-ID: <1247858550.61.0.251691618507.issue6506@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6506>
_______________________________________

From report at bugs.python.org  Fri Jul 17 22:50:38 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 17 Jul 2009 20:50:38 +0000
Subject: [issue6501] Fatal LookupError: unknown encoding: cp0 on Windows
	embedded startup.
In-Reply-To: <1247826105.17.0.941734297485.issue6501@psf.upfronthosting.co.za>
Message-ID: <1247863838.91.0.0227981356191.issue6501@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

On a Western Windows, I suggest
    PYTHONIOENCODING=cp1252:backslashreplace

But 
    PYTHONIOENCODING=mbcs
is also OK, except that characters outside the Windows code page will be 
replaced with '?'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6501>
_______________________________________

From report at bugs.python.org  Sat Jul 18 00:21:06 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 17 Jul 2009 22:21:06 +0000
Subject: [issue6477] Pickling of NoneType raises PicklingError
In-Reply-To: <1247505641.96.0.188774248495.issue6477@psf.upfronthosting.co.za>
Message-ID: <1247869266.89.0.631175770643.issue6477@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Given that dumps(type(Ellipsis)) and dumps(type(NotImplemented)) don't
work either, I am reclassifying this as a documentation bug.

The thing about the types of these three objects (None, Ellipsis,
NotImplemented) is that they are all designed to be singletons and they
all disallow creation of new instances of them.

>>> type(None)()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: cannot create 'NoneType' instances
>>> type(NotImplemented)()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: cannot create 'NotImplementedType' instances
>>> type(Ellipsis)()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: cannot create 'ellipsis' instances

This does mean None has to be special cased if pickling "(object,
type(object))" pairs, but passing types through pickle strikes me as a
dubious enough exercise that it would take a fairly convincing use case
to accept an RFE to make NoneType pickleable (note that any such patch
would have to make sure that doing loads() on such a pickle didn't
manage to create a second copy of NoneType or None).

----------
assignee:  -> georg.brandl
components: +Documentation -Library (Lib)
nosy: +georg.brandl, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6477>
_______________________________________

From report at bugs.python.org  Sat Jul 18 00:25:32 2009
From: report at bugs.python.org (Travis H.)
Date: Fri, 17 Jul 2009 22:25:32 +0000
Subject: [issue6508] expose setresuid
In-Reply-To: <1247869532.62.0.249757468331.issue6508@psf.upfronthosting.co.za>
Message-ID: <1247869532.62.0.249757468331.issue6508@psf.upfronthosting.co.za>


New submission from Travis H. <travis+w-python.org at subspacefield.org>:

Python should expose setresuid in the same module that exposes setuid.

The reason why is complicated, but is best explained here:

http://www.eecs.berkeley.edu/~daw/papers/setuid-usenix02.pdf

I might work on a patch to implement this.

----------
components: Extension Modules
messages: 90642
nosy: solinym
severity: normal
status: open
title: expose setresuid
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6508>
_______________________________________

From report at bugs.python.org  Sat Jul 18 00:31:54 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 17 Jul 2009 22:31:54 +0000
Subject: [issue6461] multiprocessing: freezing apps on Windows
In-Reply-To: <1247292508.31.0.803162103646.issue6461@psf.upfronthosting.co.za>
Message-ID: <1247869914.19.0.365368571999.issue6461@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
assignee:  -> jnoller
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6461>
_______________________________________

From report at bugs.python.org  Sat Jul 18 00:34:45 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 17 Jul 2009 22:34:45 +0000
Subject: [issue6465] email.feedparser regular expression bug (NLCRE_crack)
In-Reply-To: <1247342320.74.0.342668726051.issue6465@psf.upfronthosting.co.za>
Message-ID: <1247870085.56.0.687246001133.issue6465@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I believe both 2.4 and 3.0 are no longer maintained. 2.5 only gets
security fixes. On the otherhand, fix should go into 3.2 ;-).

----------
nosy: +tjreedy
versions: +Python 3.2 -Python 2.4, Python 2.5, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6465>
_______________________________________

From report at bugs.python.org  Sat Jul 18 00:39:43 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 17 Jul 2009 22:39:43 +0000
Subject: [issue6467] raw_input() doesn't work as expected when it gets
	multiple ^D
In-Reply-To: <1247399845.7.0.918611986455.issue6467@psf.upfronthosting.co.za>
Message-ID: <1247870383.36.0.251960469792.issue6467@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Confirmed - it's actually pressing "Ctrl-D" after entering text on the
line that seems to cause strange behaviour. For example, in the
following, the only letters I typed were "test" and then I just pressed
"Ctrl-D" 4 times and got the output seen below:

$ ./python raw_input_test.py
testtes
Traceback (most recent call last):
  File "raw_input_test.py", line 3, in <module>
    c = raw_input()
EOFError

The "test" appeared as typed, the "tes\n" appeared after pressing Ctrl-D
three times, then the 4th Ctrl-D on its own line correctly triggered
EOFError.

(This with 2.7a0 on Ubuntu 8.04)

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6467>
_______________________________________

From report at bugs.python.org  Sat Jul 18 00:47:22 2009
From: report at bugs.python.org (Travis H.)
Date: Fri, 17 Jul 2009 22:47:22 +0000
Subject: [issue6508] expose setresuid
In-Reply-To: <1247869532.62.0.249757468331.issue6508@psf.upfronthosting.co.za>
Message-ID: <1247870842.41.0.701233891602.issue6508@psf.upfronthosting.co.za>


Travis H. <travis+w-python.org at subspacefield.org> added the comment:

should also expose setresgid for same reason.

Paper also defines a higher-level API in section 8.2.1 that would
probably be worth implementing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6508>
_______________________________________

From report at bugs.python.org  Sat Jul 18 00:49:36 2009
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 17 Jul 2009 22:49:36 +0000
Subject: [issue6461] multiprocessing: freezing apps on Windows
In-Reply-To: <1247292508.31.0.803162103646.issue6461@psf.upfronthosting.co.za>
Message-ID: <1247870976.95.0.497738346028.issue6461@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Thanks for noticing this. Unfortunately, I don't know enough about 
py2exe/windows to dig into that part. I can fix the low hanging fruit 
though

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6461>
_______________________________________

From report at bugs.python.org  Sat Jul 18 00:57:54 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 17 Jul 2009 22:57:54 +0000
Subject: [issue6507] Enhance dis.dis to autocompile codestrings
In-Reply-To: <1247857575.21.0.389925271165.issue6507@psf.upfronthosting.co.za>
Message-ID: <1247871474.95.0.158161013614.issue6507@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Copying my suggestion (minus examples) over from the python-ideas thread:

We could define it as trying the three modes in order (first 'eval',
then 'single', then 'exec') moving on to the next option if it raises
syntax error:

from dis import dis
def dis_str(source):
  modes = ('eval', 'single', 'exec')
  for mode in modes:
    try:
      c = compile(source, '', mode)
      break
    except SyntaxError:
      if mode is modes[-1]:
        raise
  return dis(c)

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6507>
_______________________________________

From report at bugs.python.org  Sat Jul 18 00:58:46 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Fri, 17 Jul 2009 22:58:46 +0000
Subject: [issue6477] Pickling of NoneType raises PicklingError
In-Reply-To: <1247505641.96.0.188774248495.issue6477@psf.upfronthosting.co.za>
Message-ID: <1247871526.85.0.217019057294.issue6477@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

I agree with Nick.

And if you really want to, you could hack a Pickler subclass to support
NoneType:

import io
import pickle

class XPickler(pickle.Pickler):
  def persistent_id(self, obj):
    if obj is type(None):
      return "NoneType"
    return None

class XUnpickler(pickle.Unpickler):
  def persistent_load(self, persistent_id):
    if persistent_id == "NoneType":
      return type(None)

def dumps(obj):
    f = io.BytesIO()
    XPickler(f).dump(obj)
    return f.getvalue()

def loads(s):
    return XUnpickler(io.BytesIO(s)).load()

Not super elegant, but it works:

>>> loads(dumps([type(None), None]))
[<type 'NoneType'>, None]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6477>
_______________________________________

From report at bugs.python.org  Sat Jul 18 01:12:36 2009
From: report at bugs.python.org (kai zhu)
Date: Fri, 17 Jul 2009 23:12:36 +0000
Subject: [issue6504] infinite recursion from calling builtins.open()
In-Reply-To: <1247844969.58.0.287534577391.issue6504@psf.upfronthosting.co.za>
Message-ID: <1247872356.4.0.582009817211.issue6504@psf.upfronthosting.co.za>


kai zhu <kaizhu256 at gmail.com> added the comment:

recursion also goes away if we open as raw bytes: open("foo.txt", "rb"). modes "r+" & "w" also give infinite recursion, while "rb+" & "wb" do not.

note found another bug:
instance method find_module should raise exception anyway, since its 
class was uninstantiated in sys.meta_path (proper behavior in python2.6)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6504>
_______________________________________

From report at bugs.python.org  Sat Jul 18 02:27:26 2009
From: report at bugs.python.org (kai zhu)
Date: Sat, 18 Jul 2009 00:27:26 +0000
Subject: [issue6509] re.py - <compiled byte-object regular expr> encounter
	unexpected str-object
In-Reply-To: <1247876846.09.0.430669746251.issue6509@psf.upfronthosting.co.za>
Message-ID: <1247876846.09.0.430669746251.issue6509@psf.upfronthosting.co.za>


New submission from kai zhu <kaizhu256 at gmail.com>:

>>> import re
>>> compiled = re.compile(b"a(\w)")
>>> s = b"aa"
>>> s = compiled.sub(b"a\\1", s)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File ".../lib/python3.1/re.py", line 303, in filter
    return sre_parse.expand_template(template, match)
  File ".../lib/python3.1/sre_parse.py", line 810, in expand_template
    return sep.join(literals)
TypeError: sequence item 0: expected bytes, str found

----------
components: Library (Lib)
messages: 90650
nosy: kaizhu
severity: normal
status: open
title: re.py - <compiled byte-object regular expr> encounter unexpected str-object
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6509>
_______________________________________

From report at bugs.python.org  Sat Jul 18 02:28:27 2009
From: report at bugs.python.org (kai zhu)
Date: Sat, 18 Jul 2009 00:28:27 +0000
Subject: [issue6509] re.py - <compiled byte-object regular expr> encounter
	unexpected str-object
In-Reply-To: <1247876846.09.0.430669746251.issue6509@psf.upfronthosting.co.za>
Message-ID: <1247876907.42.0.335738643357.issue6509@psf.upfronthosting.co.za>


Changes by kai zhu <kaizhu256 at gmail.com>:


----------
components: +Regular Expressions

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6509>
_______________________________________

From report at bugs.python.org  Sat Jul 18 03:40:54 2009
From: report at bugs.python.org (kai zhu)
Date: Sat, 18 Jul 2009 01:40:54 +0000
Subject: [issue6509] re.py - <compiled byte-object regular expr> encounter
	unexpected str-object
In-Reply-To: <1247876846.09.0.430669746251.issue6509@psf.upfronthosting.co.za>
Message-ID: <1247881254.19.0.244856948962.issue6509@psf.upfronthosting.co.za>


kai zhu <kaizhu256 at gmail.com> added the comment:

traced culprit to sre_parse.py <line 711> (where literal is always str):

...
def parse_template(source, pattern):
    # parse 're' replacement string into list of literals and
    # group references
    s = Tokenizer(source)
    sget = s.get
    p = []
    a = p.append
    def literal(literal, p=p, pappend=a):
        if p and p[-1][0] is LITERAL:
            p[-1] = LITERAL, p[-1][1] + literal
        else:
            pappend((LITERAL, literal))
...

a possible hack-around is <line 717>:

...
    a = p.append
    def literal(literal, p=p, pappend=a):
        if isinstance(source, (bytes, bytearray)): # hack
            literal = literal.encode()             # hack str->bytes
        if p and p[-1][0] is LITERAL:
...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6509>
_______________________________________

From report at bugs.python.org  Sat Jul 18 03:54:03 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Sat, 18 Jul 2009 01:54:03 +0000
Subject: [issue6510] zipfile: OSError File exists
In-Reply-To: <1247882043.78.0.940486778067.issue6510@psf.upfronthosting.co.za>
Message-ID: <1247882043.78.0.940486778067.issue6510@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

sridharr at whymac:/tmp/i > wget http://google-chartwrapper.googlecode.com/
files/GChartWrapper-0.8.osx-10.5.zip
Saving to: `GChartWrapper-0.8.osx-10.5.zip'
sridharr at whymac:/tmp/i > apy -c "import zipfile; zipfile.ZipFile
('GChartWrapper-0.8.osx-10.5.zip').extractall()"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/
zipfile.py", line 935, in extractall
    self.extract(zipinfo, path, pwd)
  File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/
zipfile.py", line 923, in extract
    return self._extract_member(member, path, pwd)
  File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/
zipfile.py", line 960, in _extract_member
    os.mkdir(targetpath)
OSError: [Errno 17] File exists: '/private/tmp/i/GChartWrapper/charts/
templatetags'
sridharr at whymac:/tmp/i >

----------
components: Library (Lib)
messages: 90652
nosy: srid
severity: normal
status: open
title: zipfile: OSError File exists
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6510>
_______________________________________

From report at bugs.python.org  Sat Jul 18 05:05:25 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Sat, 18 Jul 2009 03:05:25 +0000
Subject: [issue6511] zipfile: Invalid argument when opening zero-sized files
In-Reply-To: <1247886325.93.0.371232374153.issue6511@psf.upfronthosting.co.za>
Message-ID: <1247886325.93.0.371232374153.issue6511@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

Ideally, zipfile.BadZipFile should be thrown when trying to open files 
that are zero-sized.

sridharr at whymac:/tmp/i > apy -c "import zipfile; zipfile.ZipFile
('empty.zip').extractall()"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/
zipfile.py", line 693, in __init__
    self._GetContents()
  File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/
zipfile.py", line 713, in _GetContents
    self._RealGetContents()
  File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/
zipfile.py", line 723, in _RealGetContents
    endrec = _EndRecData(fp)
  File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/
zipfile.py", line 189, in _EndRecData
    fpin.seek(-sizeEndCentDir, 2)
IOError: [Errno 22] Invalid argument
sridharr at whymac:/tmp/i >

----------
components: Library (Lib)
messages: 90653
nosy: srid
severity: normal
status: open
title: zipfile: Invalid argument when opening zero-sized files
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6511>
_______________________________________

From report at bugs.python.org  Sat Jul 18 05:05:50 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Sat, 18 Jul 2009 03:05:50 +0000
Subject: [issue6511] zipfile: Invalid argument when opening zero-sized files
In-Reply-To: <1247886325.93.0.371232374153.issue6511@psf.upfronthosting.co.za>
Message-ID: <1247886350.96.0.463793188016.issue6511@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Also repros on python-3.1

----------
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6511>
_______________________________________

From report at bugs.python.org  Sat Jul 18 05:06:41 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Sat, 18 Jul 2009 03:06:41 +0000
Subject: [issue6511] zipfile: Invalid argument when opening zero-sized files
In-Reply-To: <1247886325.93.0.371232374153.issue6511@psf.upfronthosting.co.za>
Message-ID: <1247886401.29.0.179923257848.issue6511@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Note: empty.zip is nothing but an empty file created using the 'touch' 
command.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6511>
_______________________________________

From report at bugs.python.org  Sat Jul 18 10:00:20 2009
From: report at bugs.python.org (Winfried Plappert)
Date: Sat, 18 Jul 2009 08:00:20 +0000
Subject: [issue6512] UnicodeDecodeError: 'utf8' codec can't decode bytes in
	position 0-1: illegal encoding
In-Reply-To: <1247904020.39.0.783448767489.issue6512@psf.upfronthosting.co.za>
Message-ID: <1247904020.39.0.783448767489.issue6512@psf.upfronthosting.co.za>


New submission from Winfried Plappert <Winfried.Plappert at gmx.de>:

When running the attached program, it will fail with above message on
Control-2 only! All other control keys work happily.

The same program under MS-Windows seems to work (I am under Linux, so I
can't switch easily). 

My version of Python:
Python 3.1 (r31:73572, Jul 18 2009, 08:33:59) 
[GCC 4.3.3] on linux2

uname -a: Linux lin-wpl 2.6.28-13-generic #45-Ubuntu SMP Tue Jun 30
19:49:51 UTC 2009 i686 GNU/Linux

Do I have to replace the line:  
            self.c.bind('<Control-Key-' + str(i) + '>',
                lambda x=str(i): self.key_control_num(x))

with something different? str->unicode, bytes???

This does not help either:
bytes("<Control-Key-" + str(i) + ">", 'utf-8')

This program has been converted via 2to3.

----------
components: Tkinter
files: tkpy_70.py
messages: 90656
nosy: wplappert
severity: normal
status: open
title: UnicodeDecodeError: 'utf8' codec can't decode bytes in position 0-1: illegal encoding
versions: Python 3.1
Added file: http://bugs.python.org/file14517/tkpy_70.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6512>
_______________________________________

From report at bugs.python.org  Sat Jul 18 10:01:45 2009
From: report at bugs.python.org (Winfried Plappert)
Date: Sat, 18 Jul 2009 08:01:45 +0000
Subject: [issue6512] UnicodeDecodeError: 'utf8' codec can't decode bytes in
	position 0-1: illegal encoding
In-Reply-To: <1247904020.39.0.783448767489.issue6512@psf.upfronthosting.co.za>
Message-ID: <1247904105.91.0.976221818935.issue6512@psf.upfronthosting.co.za>


Changes by Winfried Plappert <Winfried.Plappert at gmx.de>:


Removed file: http://bugs.python.org/file14517/tkpy_70.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6512>
_______________________________________

From report at bugs.python.org  Sat Jul 18 10:03:12 2009
From: report at bugs.python.org (Winfried Plappert)
Date: Sat, 18 Jul 2009 08:03:12 +0000
Subject: [issue6512] UnicodeDecodeError: 'utf8' codec can't decode bytes in
	position 0-1: illegal encoding
In-Reply-To: <1247904020.39.0.783448767489.issue6512@psf.upfronthosting.co.za>
Message-ID: <1247904192.45.0.871525926079.issue6512@psf.upfronthosting.co.za>


Changes by Winfried Plappert <Winfried.Plappert at gmx.de>:


Added file: http://bugs.python.org/file14518/tkpy_70.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6512>
_______________________________________

From report at bugs.python.org  Sat Jul 18 10:03:36 2009
From: report at bugs.python.org (Winfried Plappert)
Date: Sat, 18 Jul 2009 08:03:36 +0000
Subject: [issue6512] UnicodeDecodeError: 'utf8' codec can't decode bytes in
	position 0-1: illegal encoding
In-Reply-To: <1247904020.39.0.783448767489.issue6512@psf.upfronthosting.co.za>
Message-ID: <1247904216.72.0.200509865517.issue6512@psf.upfronthosting.co.za>


Changes by Winfried Plappert <Winfried.Plappert at gmx.de>:


Removed file: http://bugs.python.org/file14518/tkpy_70.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6512>
_______________________________________

From report at bugs.python.org  Sat Jul 18 10:04:08 2009
From: report at bugs.python.org (Winfried Plappert)
Date: Sat, 18 Jul 2009 08:04:08 +0000
Subject: [issue6512] UnicodeDecodeError: 'utf8' codec can't decode bytes in
	position 0-1: illegal encoding
In-Reply-To: <1247904020.39.0.783448767489.issue6512@psf.upfronthosting.co.za>
Message-ID: <1247904248.48.0.748625324658.issue6512@psf.upfronthosting.co.za>


Changes by Winfried Plappert <Winfried.Plappert at gmx.de>:


Added file: http://bugs.python.org/file14519/tkpy_70.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6512>
_______________________________________

From report at bugs.python.org  Sat Jul 18 10:20:02 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 18 Jul 2009 08:20:02 +0000
Subject: [issue6512] UnicodeDecodeError: 'utf8' codec can't decode bytes in
	position 0-1: illegal encoding
In-Reply-To: <1247904020.39.0.783448767489.issue6512@psf.upfronthosting.co.za>
Message-ID: <1247905202.57.0.323069752439.issue6512@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Can you paste the full traceback?
I tried to run the script on Windows and nothing happened when I pressed
Ctrl+[0..9].

----------
nosy: +ezio.melotti
priority:  -> low
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6512>
_______________________________________

From report at bugs.python.org  Sat Jul 18 10:23:43 2009
From: report at bugs.python.org (Jason Tiller)
Date: Sat, 18 Jul 2009 08:23:43 +0000
Subject: [issue6513] Standard Library, Warnings, 28.5.4, example fails
In-Reply-To: <1247905423.14.0.152000712905.issue6513@psf.upfronthosting.co.za>
Message-ID: <1247905423.14.0.152000712905.issue6513@psf.upfronthosting.co.za>


New submission from Jason Tiller <jason at sonos.org>:

The example provided in section 28.5.4 (warnings) of the Standard
Library documentation fails.  This example assumes that the context
manager instance ('w' in "warnings.catch_warnings(record=True) as w")
supplies a list of objects, each of which has a data attribute
'.category' that is an instance.  However, the '.category' data
attribute is actually a class.

The example code fails in this way on 2.6.2:

-----
Traceback (most recent call last):
  File "bob.py", line 14, in <module>
    assert isinstance(w[-1].category, DeprecationWarning)
AssertionError
-----

Replacing 'isinstance' with 'issubclass' appears to satisfy the assertion.

----------
assignee: georg.brandl
components: Documentation
messages: 90658
nosy: georg.brandl, jasontiller
severity: normal
status: open
title: Standard Library, Warnings, 28.5.4, example fails
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6513>
_______________________________________

From report at bugs.python.org  Sat Jul 18 10:27:26 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 18 Jul 2009 08:27:26 +0000
Subject: [issue6509] re.py - <compiled byte-object regular expr> encounter
	unexpected str-object
In-Reply-To: <1247876846.09.0.430669746251.issue6509@psf.upfronthosting.co.za>
Message-ID: <1247905646.11.0.234257944795.issue6509@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6509>
_______________________________________

From report at bugs.python.org  Sat Jul 18 10:39:42 2009
From: report at bugs.python.org (Winfried Plappert)
Date: Sat, 18 Jul 2009 08:39:42 +0000
Subject: [issue6512] UnicodeDecodeError: 'utf8' codec can't decode bytes in
	position 0-1: illegal encoding
In-Reply-To: <1247904020.39.0.783448767489.issue6512@psf.upfronthosting.co.za>
Message-ID: <1247906382.01.0.867757266155.issue6512@psf.upfronthosting.co.za>


Winfried Plappert <Winfried.Plappert at gmx.de> added the comment:

As I said, it does work on Windows, but NOT on Linux!

Her is the full traceback:
wplapper at lin-wpl:~/sudoku/version3.0/tk_test/python3$ python3 tkpy_70.py
key_control_num 1  (# I pressed Control-1)
Traceback (most recent call last):
  File "tkpy_70.py", line 27, in <module>
    app.mainloop()
  File "/usr/local/lib/python3.1/tkinter/__init__.py", line 1009, in
mainloop
    self.tk.mainloop(n)
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 0-1:
illegal encoding

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6512>
_______________________________________

From report at bugs.python.org  Sat Jul 18 11:03:42 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 18 Jul 2009 09:03:42 +0000
Subject: [issue6513] Standard Library, Warnings, 28.5.4, example fails
In-Reply-To: <1247905423.14.0.152000712905.issue6513@psf.upfronthosting.co.za>
Message-ID: <1247907822.97.0.517910602265.issue6513@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r74074.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6513>
_______________________________________

From report at bugs.python.org  Sat Jul 18 11:06:41 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 18 Jul 2009 09:06:41 +0000
Subject: [issue6505] Minor typos in tutorial (i/o chapter)
In-Reply-To: <1247845150.31.0.529218461562.issue6505@psf.upfronthosting.co.za>
Message-ID: <1247908001.79.0.606957557121.issue6505@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r74075.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6505>
_______________________________________

From report at bugs.python.org  Sat Jul 18 11:08:01 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 18 Jul 2009 09:08:01 +0000
Subject: [issue6502] documentation error: missing comma between kwonlyargcount
	& nlocals
In-Reply-To: <1247830022.67.0.951938723623.issue6502@psf.upfronthosting.co.za>
Message-ID: <1247908081.42.0.937997493637.issue6502@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r74076.

----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6502>
_______________________________________

From report at bugs.python.org  Sat Jul 18 11:16:16 2009
From: report at bugs.python.org (Winfried Plappert)
Date: Sat, 18 Jul 2009 09:16:16 +0000
Subject: [issue6512] UnicodeDecodeError: 'utf8' codec can't decode bytes in
	position 0-1: illegal encoding
In-Reply-To: <1247904020.39.0.783448767489.issue6512@psf.upfronthosting.co.za>
Message-ID: <1247908576.23.0.0607906568159.issue6512@psf.upfronthosting.co.za>


Winfried Plappert <Winfried.Plappert at gmx.de> added the comment:

Is it possible that this issue is related to issue6144?

BTW: I have to handcomile my python 3.1 :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6512>
_______________________________________

From report at bugs.python.org  Sat Jul 18 11:34:11 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 18 Jul 2009 09:34:11 +0000
Subject: [issue6512] UnicodeDecodeError: 'utf8' codec can't decode bytes in
	position 0-1: illegal encoding
In-Reply-To: <1247904020.39.0.783448767489.issue6512@psf.upfronthosting.co.za>
Message-ID: <1247909651.45.0.430107404947.issue6512@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The same problems (ctrl+space and ctrl+2) were reported in #1028.
Closing this as duplicate.

----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6512>
_______________________________________

From report at bugs.python.org  Sat Jul 18 11:34:57 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 18 Jul 2009 09:34:57 +0000
Subject: [issue1028] Tkinter binding involving Control-spacebar raises unicode
	error
In-Reply-To: <1188161311.7.0.864205774814.issue1028@psf.upfronthosting.co.za>
Message-ID: <1247909697.24.0.968942424705.issue1028@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

More users reported this problem in #6144 and #6512.

----------
nosy: +ezio.melotti
priority:  -> normal
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1028>
_______________________________________

From report at bugs.python.org  Sat Jul 18 11:36:32 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 18 Jul 2009 09:36:32 +0000
Subject: [issue1028] Tkinter binding involving Control-spacebar raises unicode
	error
In-Reply-To: <1188161311.7.0.864205774814.issue1028@psf.upfronthosting.co.za>
Message-ID: <1247909792.98.0.483761473339.issue1028@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
superseder:  -> [IDLE] UnicodeDecodeError when invoking force-open-completions

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1028>
_______________________________________

From report at bugs.python.org  Sat Jul 18 11:38:41 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 18 Jul 2009 09:38:41 +0000
Subject: [issue1028] Tkinter binding involving Control-spacebar raises unicode
	error
In-Reply-To: <1188161311.7.0.864205774814.issue1028@psf.upfronthosting.co.za>
Message-ID: <1247909921.39.0.422993522376.issue1028@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
superseder: [IDLE] UnicodeDecodeError when invoking force-open-completions -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1028>
_______________________________________

From report at bugs.python.org  Sat Jul 18 11:39:36 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 18 Jul 2009 09:39:36 +0000
Subject: [issue6144] [IDLE] UnicodeDecodeError when invoking
	force-open-completions
In-Reply-To: <1243631472.83.0.652127430893.issue6144@psf.upfronthosting.co.za>
Message-ID: <1247909976.44.0.748478030242.issue6144@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This was already reported in #1028.
Closing as duplicate.

----------
nosy: +ezio.melotti
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Tkinter binding involving Control-spacebar raises unicode error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6144>
_______________________________________

From report at bugs.python.org  Sat Jul 18 11:39:51 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 18 Jul 2009 09:39:51 +0000
Subject: [issue6512] UnicodeDecodeError: 'utf8' codec can't decode bytes in
	position 0-1: illegal encoding
In-Reply-To: <1247904020.39.0.783448767489.issue6512@psf.upfronthosting.co.za>
Message-ID: <1247909991.7.0.975640637253.issue6512@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
superseder:  -> Tkinter binding involving Control-spacebar raises unicode error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6512>
_______________________________________

From report at bugs.python.org  Sat Jul 18 11:43:48 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 18 Jul 2009 09:43:48 +0000
Subject: [issue6489] Documentation of ElementTree.Element.getiterator implies
	element will always be included
In-Reply-To: <1247623340.07.0.957339027178.issue6489@psf.upfronthosting.co.za>
Message-ID: <1247910228.72.0.864161554809.issue6489@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r74077.

----------
assignee: effbot -> georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6489>
_______________________________________

From report at bugs.python.org  Sat Jul 18 11:58:56 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sat, 18 Jul 2009 09:58:56 +0000
Subject: [issue6499] Can't import xmlrpclib,
	DocXMLRPCServer and SimpleXMLRPCServer when zlib is not available
In-Reply-To: <1247797208.72.0.744238846554.issue6499@psf.upfronthosting.co.za>
Message-ID: <1247911136.87.0.0485100251782.issue6499@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

I thought zlib was a builtin module?  Why isn't it available?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6499>
_______________________________________

From report at bugs.python.org  Sat Jul 18 12:17:56 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 18 Jul 2009 10:17:56 +0000
Subject: [issue6504] infinite recursion from calling builtins.open()
In-Reply-To: <1247844969.58.0.287534577391.issue6504@psf.upfronthosting.co.za>
Message-ID: <1247912276.95.0.816433359124.issue6504@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

First, the second bug isn't a bug since that restriction has been lifted
in Python 3.

The original issue occurs because open() for text modes imports the
"locale" module. This is kind of nasty, because calling open() is well
within what a find_module() implementation should be able to do. Antoine?

----------
assignee:  -> pitrou
nosy: +georg.brandl, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6504>
_______________________________________

From report at bugs.python.org  Sat Jul 18 12:19:53 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 18 Jul 2009 10:19:53 +0000
Subject: [issue6507] Enhance dis.dis to autocompile codestrings
In-Reply-To: <1247857575.21.0.389925271165.issue6507@psf.upfronthosting.co.za>
Message-ID: <1247912393.98.0.350349625917.issue6507@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

As I explained on python-ideas, 'single' should not be tried.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6507>
_______________________________________

From report at bugs.python.org  Sat Jul 18 12:20:20 2009
From: report at bugs.python.org (Winfried Plappert)
Date: Sat, 18 Jul 2009 10:20:20 +0000
Subject: [issue6512] UnicodeDecodeError: 'utf8' codec can't decode bytes in
	position 0-1: illegal encoding
In-Reply-To: <1247904020.39.0.783448767489.issue6512@psf.upfronthosting.co.za>
Message-ID: <1247912420.75.0.0264555781896.issue6512@psf.upfronthosting.co.za>


Winfried Plappert <Winfried.Plappert at gmx.de> added the comment:

I have verified that the problem goes away when you switch from
tcl/tk8.4 to tcl/tk8.5 . Luckily my Ubuntu 9.04 has the 8.5-version
available for install. Thanks for the quick help!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6512>
_______________________________________

From report at bugs.python.org  Sat Jul 18 12:27:00 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 18 Jul 2009 10:27:00 +0000
Subject: [issue6509] re.py - <compiled byte-object regular expr> encounter
	unexpected str-object
In-Reply-To: <1247876846.09.0.430669746251.issue6509@psf.upfronthosting.co.za>
Message-ID: <1247912820.68.0.938571559932.issue6509@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
priority: normal -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6509>
_______________________________________

From report at bugs.python.org  Sat Jul 18 12:48:21 2009
From: report at bugs.python.org (kai zhu)
Date: Sat, 18 Jul 2009 10:48:21 +0000
Subject: [issue6504] infinite recursion from calling builtins.open()
In-Reply-To: <1247844969.58.0.287534577391.issue6504@psf.upfronthosting.co.za>
Message-ID: <1247914101.81.0.740874717336.issue6504@psf.upfronthosting.co.za>


kai zhu <kaizhu256 at gmail.com> added the comment:

current hack-around, then is to pre-import locale, which is verified to 
work:

# beg test.py
class importer(object):
  def find_module(self, mname, path = None): open("foo.txt")
import sys, locale; sys.meta_path.append(importer)
import collections # no recursion
# end test.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6504>
_______________________________________

From report at bugs.python.org  Sat Jul 18 14:13:18 2009
From: report at bugs.python.org (Walter Arrighetti)
Date: Sat, 18 Jul 2009 12:13:18 +0000
Subject: [issue6497] Support for digital Cinema/film DPX and Kodak Cineon
	image file formats in imghdr module
In-Reply-To: <1247818784.63.0.14841797754.issue6497@psf.upfronthosting.co.za>
Message-ID: <383587e50907180513q2102db3pe90f3121b52ffe24@mail.gmail.com>


Walter Arrighetti <riemann.chaos at gmail.com> added the comment:

DPX and Kodak Cineon are the two professional raster image formats used in
digital cinema/film post-production facilities to professionally store video
frames, usually using RGB, YUV or XYZ colour-spaces with 10,12,16 or 32 bits
per channel. They have two functions:

   1. They store complete colorimetry information in order to guarantee
   perfect colour reproduction across different media (monitors, projectors,
   paper and film stock). In particular they are used when conversions between
   original negative film to print film (for theatrical releases) require
   colours stored as film density, which is a nonlinear function compared to
   linear colour spaces used for video
   2. They are to cinema like RAW images are to photography: using such high
   color depths it is possible to store even the slightest lightness/colour
   differences in order for post-production to better manage color corrections
   and VFXs

Thanks for the support: it is my first post here. I'll read the patches
section and send a diff file for the original imghdr.py module.

I apologize for mixed tab/space indents: I checked for them (I use \t's) but
apparently missed some. As far as h and f they are pretty useless names for
me too, but was just adapting to the names in the core imghdr.py module
(which also imports modules within the functions).

----------
Added file: http://bugs.python.org/file14520/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6497>
_______________________________________
-------------- next part --------------
DPX and Kodak Cineon are the two professional raster image formats used in digital cinema/film post-production facilities to professionally store video frames, usually using RGB, YUV or XYZ colour-spaces with 10,12,16 or 32 bits per channel. They have two functions:<br>
<ol><li>They store complete colorimetry information in order to guarantee perfect colour reproduction across different media (monitors, projectors, paper and film stock). In particular they are used when conversions between original negative
film to print film (for theatrical releases) require colours stored as
film density, which is a nonlinear function compared to linear colour
spaces used for video</li><li>They are to cinema like RAW images are to photography: using such high color depths it is possible to store even the slightest lightness/colour differences in order for post-production to better manage color corrections and VFXs<br>
</li></ol><br>Thanks for the support: it is my first post here. I&#39;ll read the patches section and send a diff file for the original imghdr.py module.<br><br>I apologize for mixed tab/space indents: I checked for them (I use \t&#39;s) but apparently missed some. As far as h and f they are pretty useless names for me too, but was just adapting to the names in the core imghdr.py module (which also imports modules within the functions).<br>

From report at bugs.python.org  Sat Jul 18 14:15:50 2009
From: report at bugs.python.org (Winfried Plappert)
Date: Sat, 18 Jul 2009 12:15:50 +0000
Subject: [issue6512] UnicodeDecodeError: 'utf8' codec can't decode bytes in
	position 0-1: illegal encoding
In-Reply-To: <1247904020.39.0.783448767489.issue6512@psf.upfronthosting.co.za>
Message-ID: <1247919350.19.0.0119988560705.issue6512@psf.upfronthosting.co.za>


Winfried Plappert <Winfried.Plappert at gmx.de> added the comment:

wplapper at lin-wpl:~/sudoku/version3.0/tk_test/python3$ python3
Python 3.1 (r31:73572, Jul 18 2009, 11:13:40) 
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import tkinter
>>> print(tkinter.Tcl().tk.call('info', 'patchlevel'))
8.5.6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6512>
_______________________________________

From report at bugs.python.org  Sat Jul 18 15:48:55 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 18 Jul 2009 13:48:55 +0000
Subject: [issue6507] Enhance dis.dis to autocompile codestrings
In-Reply-To: <1247857575.21.0.389925271165.issue6507@psf.upfronthosting.co.za>
Message-ID: <1247924935.25.0.665989584376.issue6507@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

As per Georg's suggestion, a better approach would look like:

from dis import dis
def dis_str(source):
  try:
    c = compile(source, '', 'eval')
  except SyntaxError:
    c = compile(source, '', 'exec')
  return dis(c)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6507>
_______________________________________

From report at bugs.python.org  Sat Jul 18 15:50:04 2009
From: report at bugs.python.org (Tomalak)
Date: Sat, 18 Jul 2009 13:50:04 +0000
Subject: [issue5752] xml.dom.minidom does not escape CR,
	LF and TAB characters within attribute values
In-Reply-To: <1239707588.77.0.33795755364.issue5752@psf.upfronthosting.co.za>
Message-ID: <1247925004.28.0.762949817699.issue5752@psf.upfronthosting.co.za>


Tomalak <M8R-t1tut01 at mailinator.com> added the comment:

@devon: Thanks for pointing & linking back here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5752>
_______________________________________

From report at bugs.python.org  Sat Jul 18 16:03:42 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 18 Jul 2009 14:03:42 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1247925822.78.0.979394763407.issue1578269@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Now that Python 3.1 is released, can we talk about integrating this into
the 3.1.1 release?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Sat Jul 18 16:30:33 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 18 Jul 2009 14:30:33 +0000
Subject: [issue6499] Can't import xmlrpclib,
	DocXMLRPCServer and SimpleXMLRPCServer when zlib is not available
In-Reply-To: <1247797208.72.0.744238846554.issue6499@psf.upfronthosting.co.za>
Message-ID: <1247927433.87.0.843653988827.issue6499@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I don't know why it's not installed here, but I didn't remove it
intentionally.
"here" is a Linux machine with Ubuntu 8.04.3 (hardy) LTS.
One reason might be that I just have a limited number of program
installed and zlib is probably a dependency of some popular packages and
hence it's found in most of the machines.

When I compiled Python I got this message, so I think that Python
expects zlib to be already there:
Python build finished, but the necessary bits to build these modules
were not found: _dbm _gdbm _hashlib _sqlite3 _ssl _tkinter bz2 zlib

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6499>
_______________________________________

From report at bugs.python.org  Sat Jul 18 16:43:37 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 18 Jul 2009 14:43:37 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1247928217.29.0.622167527449.issue1578269@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Standard policy is that new features only go into the next version (3.2
in this case).  3.1 will only get bug fixes now that it has been released.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Sat Jul 18 16:47:19 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 18 Jul 2009 14:47:19 +0000
Subject: [issue6431] Fraction fails equality test with a user-defined type
In-Reply-To: <1246945296.27.0.280023368175.issue6431@psf.upfronthosting.co.za>
Message-ID: <1247928439.37.0.754534963868.issue6431@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Applied in r74078 (py3k), r74079 (release31-maint).  I'll backport to 2.x.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6431>
_______________________________________

From report at bugs.python.org  Sat Jul 18 16:51:26 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sat, 18 Jul 2009 14:51:26 +0000
Subject: [issue6514] "python -m unittest <testmodule>" does not run any tests
In-Reply-To: <1247928686.78.0.475658449787.issue6514@psf.upfronthosting.co.za>
Message-ID: <1247928686.78.0.475658449787.issue6514@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

exarkun at boson:~$ cat > test_foo.py
from unittest import TestCase

class SomeTests(TestCase):
    def test_foo(self):
        pass
exarkun at boson:~$ python -m unittest test_foo

----------------------------------------------------------------------
Ran 0 tests in 0.000s

OK
exarkun at boson:~$ python -m unittest test_foo.SomeTests
Traceback (most recent call last):
  File "/usr/lib/python2.5/runpy.py", line 95, in run_module
    filename, loader, alter_sys)
  File "/usr/lib/python2.5/runpy.py", line 52, in _run_module_code
    mod_name, mod_fname, mod_loader)
  File "/usr/lib/python2.5/runpy.py", line 32, in _run_code
    exec code in run_globals
  File "/usr/lib/python2.5/unittest.py", line 816, in <module>
    main(module=None)
  File "/usr/lib/python2.5/unittest.py", line 767, in __init__
    self.parseArgs(argv)
  File "/usr/lib/python2.5/unittest.py", line 794, in parseArgs
    self.createTests()
  File "/usr/lib/python2.5/unittest.py", line 800, in createTests
    self.module)
  File "/usr/lib/python2.5/unittest.py", line 565, in loadTestsFromNames
    suites = [self.loadTestsFromName(name, module) for name in names]
  File "/usr/lib/python2.5/unittest.py", line 553, in loadTestsFromName
    test = obj()
  File "/usr/lib/python2.5/unittest.py", line 209, in __init__
    (self.__class__, methodName)
ValueError: no such test method in <class 'test_foo.SomeTests'>: runTest
exarkun at boson:~$ python -m unittest test_foo.SomeTests.test_foo
.
----------------------------------------------------------------------
Ran 1 test in 0.000s

OK
exarkun at boson:~$ 

I don't really know what's happening in the middle case.  The first case
seems to fail because the test loader goes around looking for subclasses
of __main__.TestCase.  It only finds subclasses of unittest.TestCase,
though, which it rejects.

----------
components: Library (Lib)
messages: 90681
nosy: exarkun
severity: normal
status: open
title: "python -m unittest <testmodule>" does not run any tests
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6514>
_______________________________________

From report at bugs.python.org  Sat Jul 18 17:11:12 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sat, 18 Jul 2009 15:11:12 +0000
Subject: [issue6515]
	http://docs.python.org/dev/library/unittest.html#load-tests-protocol
	doesn't make it clear when load_tests support was introduced
In-Reply-To: <1247929872.52.0.506618276219.issue6515@psf.upfronthosting.co.za>
Message-ID: <1247929872.52.0.506618276219.issue6515@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

The load_tests feature will be new in 2.7.  Earlier in the unittest
documentation, there's a mention that loadTestsFromModule was changed in
2.7 to add support for load_tests.  However, the main documentation for
load_tests doesn't say anything about this.  It would be good to have a
note in section 26.3.7.3.1 saying load_tests was introduced in 2.7.

----------
assignee: georg.brandl
components: Documentation
messages: 90682
nosy: exarkun, georg.brandl
severity: normal
status: open
title: http://docs.python.org/dev/library/unittest.html#load-tests-protocol doesn't make it clear when load_tests support was introduced
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6515>
_______________________________________

From report at bugs.python.org  Sat Jul 18 17:22:02 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 18 Jul 2009 15:22:02 +0000
Subject: [issue6431] Fraction fails equality test with a user-defined type
In-Reply-To: <1246945296.27.0.280023368175.issue6431@psf.upfronthosting.co.za>
Message-ID: <1247930522.28.0.345045011415.issue6431@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Backported to trunk in r74080.  I don't think it's worth fixing this in 
2.6:  it seems unlikely that the changed comparison behaviour would cause 
breakage, but I don't want to take the chance.

Thanks Case for the report and patches!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6431>
_______________________________________

From report at bugs.python.org  Sat Jul 18 17:25:03 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 18 Jul 2009 15:25:03 +0000
Subject: [issue6515]
	http://docs.python.org/dev/library/unittest.html#load-tests-protocol
	doesn't make it clear when load_tests support was introduced
In-Reply-To: <1247929872.52.0.506618276219.issue6515@psf.upfronthosting.co.za>
Message-ID: <1247930703.69.0.524936066223.issue6515@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee: georg.brandl -> michael.foord
nosy: +michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6515>
_______________________________________

From report at bugs.python.org  Sat Jul 18 17:29:21 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 18 Jul 2009 15:29:21 +0000
Subject: [issue6512] UnicodeDecodeError: 'utf8' codec can't decode bytes in
	position 0-1: illegal encoding
In-Reply-To: <1247904020.39.0.783448767489.issue6512@psf.upfronthosting.co.za>
Message-ID: <1247930961.66.0.795787672126.issue6512@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Do you know what 8.5.x version were you running before?
You should report it to #1028, apparently they were trying to find out
the affected versions there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6512>
_______________________________________

From report at bugs.python.org  Sat Jul 18 18:10:41 2009
From: report at bugs.python.org (Till Maas)
Date: Sat, 18 Jul 2009 16:10:41 +0000
Subject: [issue1886] Permit to easily use distutils "--formats=tar, gztar,
	bztar" on all systems
In-Reply-To: <1200950920.27.0.810221024065.issue1886@psf.upfronthosting.co.za>
Message-ID: <1247933441.78.0.903382652963.issue1886@psf.upfronthosting.co.za>


Changes by Till Maas <opensource at till.name>:


----------
nosy: +till

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1886>
_______________________________________

From report at bugs.python.org  Sat Jul 18 18:14:59 2009
From: report at bugs.python.org (Till Maas)
Date: Sat, 18 Jul 2009 16:14:59 +0000
Subject: [issue6516] reset owner/group to root for distutils tarballs
In-Reply-To: <1247933699.76.0.278346370296.issue6516@psf.upfronthosting.co.za>
Message-ID: <1247933699.76.0.278346370296.issue6516@psf.upfronthosting.co.za>


New submission from Till Maas <opensource at till.name>:

Please allow to create tarballs with owner/group of files be set to root.

One possible fix is to change cmd in distutils/archive_util.py to this:

cmd = ["tar", "-cf", archive_name, "--owner=root", "--group=root", base_dir]

----------
assignee: tarek
components: Distutils
messages: 90685
nosy: tarek, till
severity: normal
status: open
title: reset owner/group to root for distutils tarballs
type: feature request
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6516>
_______________________________________

From report at bugs.python.org  Sat Jul 18 19:13:16 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 18 Jul 2009 17:13:16 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1247937196.31.0.232374228504.issue1578269@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

In many ways, this is a bug fix and not a new feature.  os.islink is
already in the ntpath module, but simply doesn't perform its intended
purpose. Similarly, os.symlink exists and is defined for unix platforms,
but is just absent on the Windows platform.  In other words, this patch
doesn't implement new features, but simply expands the platform support
for existing features.  Therefore, I believe this is a strong candidate
for a 3.1.1 target.

That said, if the maintainers would prefer to defer this capability to
3.2, then I would like to move forward with that effort.

Whatever the recommended approach, this effort is ready to move onto the
next step.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Sat Jul 18 19:38:58 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 18 Jul 2009 17:38:58 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1247938738.43.0.704518813593.issue1578269@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm inclined to agree with you.

----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Sat Jul 18 21:58:14 2009
From: report at bugs.python.org (Michele Dionisio)
Date: Sat, 18 Jul 2009 19:58:14 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1247947094.19.0.945640940448.issue4753@psf.upfronthosting.co.za>


Michele Dionisio <michele.dionisio at gmail.com> added the comment:

I have patch the code of python3.1 to use computed goto tecnique also
with Visual Studio. The performance result is not good (I really don't
know why). But it is a good work-araound for use the computed goto also
on windows.
The only diffentes is that the opcode_targets vector is filled at run-time.

----------
nosy: +mdionisio
versions: +Python 3.1 -Python 2.7
Added file: http://bugs.python.org/file14521/newfile.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Sat Jul 18 22:36:40 2009
From: report at bugs.python.org (Till Maas)
Date: Sat, 18 Jul 2009 20:36:40 +0000
Subject: [issue6517] configparser: add possibility to escape formatstrings
In-Reply-To: <1247949399.94.0.0752877480689.issue6517@psf.upfronthosting.co.za>
Message-ID: <1247949399.94.0.0752877480689.issue6517@psf.upfronthosting.co.za>


New submission from Till Maas <opensource at till.name>:

There seems to be no way to add a config item with a value containing a
formatstring without this formatstring beeing handled by configparser.

A possible way to escape the formatstrings could be to double the
%-sign, e.g.:

[foo]
bar = %%(string)s

The value of the bar item should then be "%(string)s".

----------
components: Library (Lib)
messages: 90689
nosy: till
severity: normal
status: open
title: configparser: add possibility to escape formatstrings
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6517>
_______________________________________

From report at bugs.python.org  Sat Jul 18 23:13:47 2009
From: report at bugs.python.org (Stuart Mentzer)
Date: Sat, 18 Jul 2009 21:13:47 +0000
Subject: [issue6461] multiprocessing: freezing apps on Windows
In-Reply-To: <1247292508.31.0.803162103646.issue6461@psf.upfronthosting.co.za>
Message-ID: <1247951627.11.0.366569424595.issue6461@psf.upfronthosting.co.za>


Stuart Mentzer <sgm at objexx.com> added the comment:

Thanks Jesse. If you make broader changes that my patch I am happy to
test on Windows and with py2exe if that is helpful.

I will try to get the py2exe folks to look at the broader
multiprocessing issues I describe as well. If multiprocessing supports
freezing on Windows then it would be nice if its docs had a short primer
on what you'll actually need to do to get that working with freeze tools.

Stuart

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6461>
_______________________________________

From report at bugs.python.org  Sat Jul 18 23:16:16 2009
From: report at bugs.python.org (Jesse Noller)
Date: Sat, 18 Jul 2009 21:16:16 +0000
Subject: [issue6461] multiprocessing: freezing apps on Windows
In-Reply-To: <1247292508.31.0.803162103646.issue6461@psf.upfronthosting.co.za>
Message-ID: <1247951776.32.0.475761207155.issue6461@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Sounds good - I've personally never used freeze on windows, so having some 
docs and a patch to help make it better for those that do is a definite 
plus

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6461>
_______________________________________

From report at bugs.python.org  Sat Jul 18 23:34:08 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 18 Jul 2009 21:34:08 +0000
Subject: [issue6415] warnings.warn segfaults on bad formatted string
In-Reply-To: <1246702444.15.0.967525803194.issue6415@psf.upfronthosting.co.za>
Message-ID: <1247952848.24.0.432487188944.issue6415@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The backport to 2.6 needs adjustment.  The test fails:

Traceback (most recent call last):
  File
"/home/rdmurray/python/release26-maint/Lib/test/test_warnings.py", line
350, in test_bad_str
    with self.assertRaises(ValueError):
TypeError: failUnlessRaises() takes at least 3 arguments (2 given)

assertRaises can't be used as a context manager in 2.6.

----------
nosy: +r.david.murray
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6415>
_______________________________________

From report at bugs.python.org  Sat Jul 18 23:44:57 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 18 Jul 2009 21:44:57 +0000
Subject: [issue6517] configparser: add possibility to escape formatstrings
In-Reply-To: <1247949399.94.0.0752877480689.issue6517@psf.upfronthosting.co.za>
Message-ID: <1247953497.96.0.0259917797452.issue6517@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The formatstring is a Python % formatting code, and doubling the %% is
the way to escape one, so what you suggest is in fact the way it works.
 Do you have a test case demonstrating that it doesn't work as
documented (it works for me)?

----------
nosy: +r.david.murray
resolution:  -> works for me
stage:  -> committed/rejected
status: open -> pending
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6517>
_______________________________________

From report at bugs.python.org  Sun Jul 19 00:03:07 2009
From: report at bugs.python.org (Till Maas)
Date: Sat, 18 Jul 2009 22:03:07 +0000
Subject: [issue6517] configparser: add possibility to escape formatstrings
In-Reply-To: <1247949399.94.0.0752877480689.issue6517@psf.upfronthosting.co.za>
Message-ID: <1247954587.36.0.855323202841.issue6517@psf.upfronthosting.co.za>


Till Maas <opensource at till.name> added the comment:

Afacs it is not documented to work. Here is the testcase:

#!/usr/bin/python
# vim: fileencoding=utf8

import ConfigParser
import tempfile

file = tempfile.TemporaryFile(mode='rw+b')
file.write("[s]\nf=%%(b)s\n")
file.seek(0)
config = ConfigParser.ConfigParser()

config.readfp(file)

print config.get("s", "f")

file.close()

----------
status: pending -> open
Added file: http://bugs.python.org/file14522/test-configparse.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6517>
_______________________________________

From report at bugs.python.org  Sun Jul 19 01:09:00 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 18 Jul 2009 23:09:00 +0000
Subject: [issue6517] configparser: add possibility to escape formatstrings
In-Reply-To: <1247949399.94.0.0752877480689.issue6517@psf.upfronthosting.co.za>
Message-ID: <1247958540.58.0.409778557438.issue6517@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Ah, that's because you aren't using SafeConfigParser (which the docs
recommend that you do unless you have to use ConfigParser for backward
compatibility reasons).  Your test case works with SafeConfigParser.

You are correct that it is not explicitly documented in the ConfigParser
docs.  It is implied by the fact that the magic substitution is
documented to be a standard format string, and by the recommendation to
use SafeConfigParser because ConfigParser's handling of formatstrings is
broken.

To make this all explicit, I've attached a doc patch to make the
motivation for using SafeConfigParser clearer, using this as the
example.  Let me know what you think.

Georg, Raymond, I added you as nosy to ask for a style/content opinion.
 Should we instead rewrite the section to put SafeConfigParser first,
and perhaps even deprecate ConfigParser?

----------
assignee:  -> r.david.murray
components: +Documentation -Library (Lib)
keywords: +patch
nosy: +georg.brandl, rhettinger
priority:  -> normal
resolution: works for me -> 
stage: committed/rejected -> patch review
versions: +Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14523/issue6517.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6517>
_______________________________________

From report at bugs.python.org  Sun Jul 19 01:37:36 2009
From: report at bugs.python.org (Till Maas)
Date: Sat, 18 Jul 2009 23:37:36 +0000
Subject: [issue6517] configparser: add possibility to escape formatstrings
In-Reply-To: <1247949399.94.0.0752877480689.issue6517@psf.upfronthosting.co.za>
Message-ID: <1247960256.95.0.145322883531.issue6517@psf.upfronthosting.co.za>


Till Maas <opensource at till.name> added the comment:

It would be nice if you could expand the patch to also use only one name
for the support of format strings.

In the beginning it is introduced as "reference expansion", but later in
the document, several variatons of interpolation are used: "magical
interpolation", "string interpolation", "%" interpolation is used.
Therefore I guess it should also be introduced as interpolation.

Another nice improvement would also be to move the ConfigParser to a
"deprecated classes" section at the end like it is done for some methods
in the string module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6517>
_______________________________________

From report at bugs.python.org  Sun Jul 19 03:07:46 2009
From: report at bugs.python.org (Jerzy Jalocha N)
Date: Sun, 19 Jul 2009 01:07:46 +0000
Subject: [issue6518] Enable 'with' statement in ossaudiodev module
In-Reply-To: <1247965666.73.0.755368316919.issue6518@psf.upfronthosting.co.za>
Message-ID: <1247965666.73.0.755368316919.issue6518@psf.upfronthosting.co.za>


New submission from Jerzy Jalocha N <jjalocha at gmail.com>:

Actually, it is not possible to use the 'with' statement in the
ossaudiodev module:

>>> import ossaudiodev
>>> with ossaudiodev.open('/dev/dsp', 'r') as device:
...     pass
...
Traceback (most recent call last):
  File "<stdin>", line 1 in <module>
AttributeError: 'ossaudodev.oss_audio_device' object has no attribute
'__exit__'

In order to provide a similar interface as standard Python files, and
encourage safe coding practices, the 'with' statement should be
supported in the ossaudiodev module.

Thanks.

----------
components: Extension Modules
messages: 90697
nosy: jjalocha
severity: normal
status: open
title: Enable 'with' statement in ossaudiodev module
type: feature request
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6518>
_______________________________________

From report at bugs.python.org  Sun Jul 19 03:19:29 2009
From: report at bugs.python.org (Jerzy Jalocha N)
Date: Sun, 19 Jul 2009 01:19:29 +0000
Subject: [issue6519] Reorder 'with' statement for files in Python Tutorial
In-Reply-To: <1247966369.75.0.40232300258.issue6519@psf.upfronthosting.co.za>
Message-ID: <1247966369.75.0.40232300258.issue6519@psf.upfronthosting.co.za>


New submission from Jerzy Jalocha N <jjalocha at gmail.com>:

Actually, the Python Tutorial recommends the use of the 'with' statement
in Section 7.2.1. "Methods of File Objects":

> It is good practice to use the with keyword when dealing with file
> objects. [etc.]

But the example and description are at the very bottom of this very
large section, and are easily missed by new Python users.

If this suggestion is to be taken seriously, I suggest putting this
information at a more prominent place, somewhere at the top of the short
section 7.2. "Reading and Writing Files".

----------
assignee: georg.brandl
components: Documentation
messages: 90698
nosy: georg.brandl, jjalocha
severity: normal
status: open
title: Reorder 'with' statement for files in Python Tutorial
type: feature request
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6519>
_______________________________________

From report at bugs.python.org  Sun Jul 19 04:29:28 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 19 Jul 2009 02:29:28 +0000
Subject: [issue6070] Python 2.6 makes .pyc/.pyo bytecode files executable
In-Reply-To: <1242817129.44.0.860392010944.issue6070@psf.upfronthosting.co.za>
Message-ID: <1247970568.6.0.32338545761.issue6070@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Committed to 2.6 in r74085, py3k in r74058 (by alexandre vassalotti),
and 3.1 in r74086.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6070>
_______________________________________

From report at bugs.python.org  Sun Jul 19 04:44:44 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 19 Jul 2009 02:44:44 +0000
Subject: [issue5230] pydoc reports misleading failure if target module raises
	an ImportError
In-Reply-To: <1234473388.92.0.353382315269.issue5230@psf.upfronthosting.co.za>
Message-ID: <1247971484.14.0.393964365927.issue5230@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Benjamin merged this to py3k/3.1 as part of r73623/r73625.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5230>
_______________________________________

From report at bugs.python.org  Sun Jul 19 04:46:19 2009
From: report at bugs.python.org (Senthil)
Date: Sun, 19 Jul 2009 02:46:19 +0000
Subject: [issue5102] urllib2.py timeouts do not propagate across redirects for
	2.6.1 (and 3.x?)
In-Reply-To: <1233268501.09.0.849179242722.issue5102@psf.upfronthosting.co.za>
Message-ID: <1247971579.12.0.453966935512.issue5102@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

Fixed and committed in revision 74089 and revision 74090.
Should this be backported?

----------
resolution:  -> fixed
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5102>
_______________________________________

From report at bugs.python.org  Sun Jul 19 04:50:09 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 19 Jul 2009 02:50:09 +0000
Subject: [issue5102] urllib2.py timeouts do not propagate across redirects for
	2.6.1 (and 3.x?)
In-Reply-To: <1233268501.09.0.849179242722.issue5102@psf.upfronthosting.co.za>
Message-ID: <1247971809.97.0.608479153832.issue5102@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It's hard to imagine anyone depending on the broken behavior, so I'd
vote yes.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5102>
_______________________________________

From report at bugs.python.org  Sun Jul 19 04:52:21 2009
From: report at bugs.python.org (Senthil)
Date: Sun, 19 Jul 2009 02:52:21 +0000
Subject: [issue6520] urllib.urlopen does not have timeout parameter where as
	urllib2.urlopen has
In-Reply-To: <1247971941.19.0.568398315734.issue6520@psf.upfronthosting.co.za>
Message-ID: <1247971941.19.0.568398315734.issue6520@psf.upfronthosting.co.za>


New submission from Senthil <orsenthil at gmail.com>:

Just noticed this while fixing another bug issue5102. 
Need to figure out why urllib.urlopen does not have timeout in the first
account and if it was due to some overlook, then:

1) add timeout parameter to urllib.urlopen
2) propage it across redirects.

It may not have high implications in Py2.x, but might lead us to
problems in future in Py3.x where urlopen is a combined function.

----------
assignee: orsenthil
components: Library (Lib)
keywords: easy
messages: 90703
nosy: orsenthil
priority: normal
severity: normal
status: open
title: urllib.urlopen does not have timeout parameter where as urllib2.urlopen has
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6520>
_______________________________________

From report at bugs.python.org  Sun Jul 19 04:52:52 2009
From: report at bugs.python.org (Senthil)
Date: Sun, 19 Jul 2009 02:52:52 +0000
Subject: [issue5102] urllib2.py timeouts do not propagate across redirects for
	2.6.1 (and 3.x?)
In-Reply-To: <1233268501.09.0.849179242722.issue5102@psf.upfronthosting.co.za>
Message-ID: <1247971972.68.0.125460583947.issue5102@psf.upfronthosting.co.za>


Changes by Senthil <orsenthil at gmail.com>:


----------
versions: +Python 2.7 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5102>
_______________________________________

From report at bugs.python.org  Sun Jul 19 05:41:56 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 19 Jul 2009 03:41:56 +0000
Subject: [issue6415] warnings.warn segfaults on bad formatted string
In-Reply-To: <1246702444.15.0.967525803194.issue6415@psf.upfronthosting.co.za>
Message-ID: <1247974916.0.0.920753388808.issue6415@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Thank you, I've fixed it in r74091. I should have checked test results 
on all branches.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6415>
_______________________________________

From report at bugs.python.org  Sun Jul 19 06:22:04 2009
From: report at bugs.python.org (Senthil)
Date: Sun, 19 Jul 2009 04:22:04 +0000
Subject: [issue5102] urllib2.py timeouts do not propagate across redirects for
	2.6.1 (and 3.x?)
In-Reply-To: <1233268501.09.0.849179242722.issue5102@psf.upfronthosting.co.za>
Message-ID: <1247977324.93.0.585610815221.issue5102@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

backported to release26-maint in the revision 74093
and release31-maint in the revision 74092
Closing this issue.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5102>
_______________________________________

From report at bugs.python.org  Sun Jul 19 06:22:18 2009
From: report at bugs.python.org (Senthil)
Date: Sun, 19 Jul 2009 04:22:18 +0000
Subject: [issue5102] urllib2.py timeouts do not propagate across redirects for
	2.6.1 (and 3.x?)
In-Reply-To: <1233268501.09.0.849179242722.issue5102@psf.upfronthosting.co.za>
Message-ID: <1247977338.31.0.630841204139.issue5102@psf.upfronthosting.co.za>


Changes by Senthil <orsenthil at gmail.com>:


----------
versions: +Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5102>
_______________________________________

From report at bugs.python.org  Sun Jul 19 07:47:48 2009
From: report at bugs.python.org (Garrett Cooper)
Date: Sun, 19 Jul 2009 05:47:48 +0000
Subject: [issue1006238] cross compile patch
Message-ID: <1247982468.39.0.918389003968.issue1006238@psf.upfronthosting.co.za>


Garrett Cooper <yanegomi at gmail.com> added the comment:

Coming back to this issue, I really want to resolve it on TRUNK and for
it to make its way into 2.6.3 and 2.x trunk, as well as 3.0.2 and 3.x
trunk. I am more than happy to sign a contributor agreement if this will
push things along quicker.

Thanks,
-Garrett

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1006238>
_______________________________________

From report at bugs.python.org  Sun Jul 19 09:19:42 2009
From: report at bugs.python.org (Winfried Plappert)
Date: Sun, 19 Jul 2009 07:19:42 +0000
Subject: [issue1028] Tkinter binding involving Control-spacebar raises unicode
	error
In-Reply-To: <1188161311.7.0.864205774814.issue1028@psf.upfronthosting.co.za>
Message-ID: <1247987982.25.0.386531240286.issue1028@psf.upfronthosting.co.za>


Winfried Plappert <Winfried.Plappert at gmx.de> added the comment:

I have the problem described in issue6512 and here is some information 

Python version - hand compiled on Ubuntu 9.04:
Python 3.1 (r31:73572, Jul 18 2009, 11:13:40) 
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import tkinter
>>> print(tkinter.Tcl().tk.call('info', 'patchlevel'))
8.5.6

The previous Tcl/Tk version I had initially installed was a 8.4.x
version - which fails on Control-2 error described in detail in issue6512. 
- I decided to upgrade Tcl/Tk to version 8.5. 
- So I made a "make distclean" 
- copied the contents of /usr/include/tcl85 one level higher, so Python
could access the necessary tk.h and tcl.h files
- cd to my Python 3.1 source
- ./configure
- make 
- sudo make install

and tested again and my test program is now happily responding to a
Control-2 keystroke.

----------
nosy: +wplappert
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1028>
_______________________________________

From report at bugs.python.org  Sun Jul 19 12:23:27 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 19 Jul 2009 10:23:27 +0000
Subject: [issue6504] infinite recursion from calling builtins.open()
In-Reply-To: <1247844969.58.0.287534577391.issue6504@psf.upfronthosting.co.za>
Message-ID: <1247999007.5.0.741332807082.issue6504@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Yes, we conditionally import the "locale" module in order to guess the
encoding when it is not specified by the caller. We can't import it at
module initialization time because it would cause bootstrapping issues.

The Python equivalent of the logic expressed in C code in the _io module
can be found here:
http://code.python.org/hg/branches/py3k/file/51117227ac82/Lib/_pyio.py#l1410

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6504>
_______________________________________

From report at bugs.python.org  Sun Jul 19 12:28:54 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 19 Jul 2009 10:28:54 +0000
Subject: [issue6492] xml.etree does not escape CR,
	LF and TAB characters within attribute values
In-Reply-To: <1247696588.32.0.942237333428.issue6492@psf.upfronthosting.co.za>
Message-ID: <1247999334.87.0.288968066472.issue6492@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> effbot
nosy: +effbot

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6492>
_______________________________________

From report at bugs.python.org  Sun Jul 19 12:30:32 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 19 Jul 2009 10:30:32 +0000
Subject: [issue6499] Can't import xmlrpclib,
	DocXMLRPCServer and SimpleXMLRPCServer when zlib is not available
In-Reply-To: <1247797208.72.0.744238846554.issue6499@psf.upfronthosting.co.za>
Message-ID: <1247999432.8.0.761857267399.issue6499@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Kristj?n, zlib is only built when the required development headers (.h
files for the zlib library) are available.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6499>
_______________________________________

From report at bugs.python.org  Sun Jul 19 14:13:49 2009
From: report at bugs.python.org (Graham Dumpleton)
Date: Sun, 19 Jul 2009 12:13:49 +0000
Subject: [issue4200] atexit module not safe in Python 3.0 with multiple
	interpreters
In-Reply-To: <1224888355.2.0.82482284838.issue4200@psf.upfronthosting.co.za>
Message-ID: <1248005629.89.0.064677439988.issue4200@psf.upfronthosting.co.za>


Graham Dumpleton <Graham.Dumpleton at gmail.com> added the comment:

I know this issue is closed, but for this patch, the code:

+    modstate = get_atexitmodule_state(module);
+
+    if (modstate->ncallbacks == 0)
+        return;

was added.

Is there any condition under which modstate could be NULL.

Haven't touched Python 3.0 support in mod_wsgi for a long time and when 
revisiting code with final Python 3.0, I find that I get Py_Finalize() 
crashing on process shutdown. It is crashing because modstate above is 
NULL.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4200>
_______________________________________

From report at bugs.python.org  Sun Jul 19 15:09:22 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 19 Jul 2009 13:09:22 +0000
Subject: [issue6415] warnings.warn segfaults on bad formatted string
In-Reply-To: <1246702444.15.0.967525803194.issue6415@psf.upfronthosting.co.za>
Message-ID: <1248008962.53.0.837807903399.issue6415@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6415>
_______________________________________

From report at bugs.python.org  Sun Jul 19 15:19:41 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 19 Jul 2009 13:19:41 +0000
Subject: [issue6521] Contradictory documentation for email.mime.text.MIMEText
In-Reply-To: <1248009581.26.0.315231370095.issue6521@psf.upfronthosting.co.za>
Message-ID: <1248009581.26.0.315231370095.issue6521@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

It is not obvious whether encoding of an unicode argument will happen or
not:

? [...] No guessing or encoding is performed on the text data.

Changed in version 2.4: The previously deprecated _encoding argument has
been removed. Encoding happens implicitly based on the _charset argument. ?

http://docs.python.org/library/email.mime.html#email.mime.text.MIMEText

----------
assignee: georg.brandl
components: Documentation
messages: 90711
nosy: georg.brandl, pitrou
severity: normal
stage: needs patch
status: open
title: Contradictory documentation for email.mime.text.MIMEText
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6521>
_______________________________________

From report at bugs.python.org  Sun Jul 19 15:22:00 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 19 Jul 2009 13:22:00 +0000
Subject: [issue6521] Contradictory documentation for email.mime.text.MIMEText
In-Reply-To: <1248009581.26.0.315231370095.issue6521@psf.upfronthosting.co.za>
Message-ID: <1248009720.26.0.953937070871.issue6521@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Apparently it doesn't:

>>> message = MIMEText(u"h?h?", _charset="utf-8")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python2.6/email/mime/text.py", line 30, in __init__
    self.set_payload(_text, _charset)
  File "/usr/lib64/python2.6/email/message.py", line 224, in set_payload
    self.set_charset(charset)
  File "/usr/lib64/python2.6/email/message.py", line 266, in set_charset
    self._payload = charset.body_encode(self._payload)
  File "/usr/lib64/python2.6/email/charset.py", line 387, in body_encode
    return email.base64mime.body_encode(s)
  File "/usr/lib64/python2.6/email/base64mime.py", line 147, in encode
    enc = b2a_base64(s[i:i + max_unencoded])
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in
position 1: ordinal not in range(128)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6521>
_______________________________________

From report at bugs.python.org  Sun Jul 19 15:39:39 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 19 Jul 2009 13:39:39 +0000
Subject: [issue6521] Contradictory documentation for email.mime.text.MIMEText
In-Reply-To: <1248009581.26.0.315231370095.issue6521@psf.upfronthosting.co.za>
Message-ID: <1248010779.33.0.994010258918.issue6521@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee: georg.brandl -> barry
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6521>
_______________________________________

From report at bugs.python.org  Sun Jul 19 15:45:27 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 19 Jul 2009 13:45:27 +0000
Subject: [issue6509] re.py - <compiled byte-object regular expr> encounter
	unexpected str-object
In-Reply-To: <1247876846.09.0.430669746251.issue6509@psf.upfronthosting.co.za>
Message-ID: <1248011127.49.0.776272315957.issue6509@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +pitrou
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6509>
_______________________________________

From report at bugs.python.org  Sun Jul 19 18:33:22 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 19 Jul 2009 16:33:22 +0000
Subject: [issue4200] atexit module not safe in Python 3.0 with multiple
	interpreters
In-Reply-To: <1248005629.89.0.064677439988.issue4200@psf.upfronthosting.co.za>
Message-ID: <1afaf6160907190933p319adb80r5f98197a17f2695e@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2009/7/19 Graham Dumpleton <report at bugs.python.org>:
>
> Graham Dumpleton <Graham.Dumpleton at gmail.com> added the comment:
>
> I know this issue is closed, but for this patch, the code:
>
> + ? ?modstate = get_atexitmodule_state(module);
> +
> + ? ?if (modstate->ncallbacks == 0)
> + ? ? ? ?return;
>
> was added.
>
> Is there any condition under which modstate could be NULL.

The module is probably being deallocated before the callbacks are being called.

>
> Haven't touched Python 3.0 support in mod_wsgi for a long time and when
> revisiting code with final Python 3.0, I find that I get Py_Finalize()
> crashing on process shutdown. It is crashing because modstate above is
> NULL.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4200>
_______________________________________

From report at bugs.python.org  Sun Jul 19 20:40:04 2009
From: report at bugs.python.org (Alex Z.)
Date: Sun, 19 Jul 2009 18:40:04 +0000
Subject: [issue3244] multipart/form-data encoding
In-Reply-To: <1214849078.87.0.171093103517.issue3244@psf.upfronthosting.co.za>
Message-ID: <1248028804.71.0.220880022623.issue3244@psf.upfronthosting.co.za>


Changes by Alex Z. <mrzmanwiki at gmail.com>:


----------
nosy: +alexz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3244>
_______________________________________

From report at bugs.python.org  Mon Jul 20 00:39:36 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sun, 19 Jul 2009 22:39:36 +0000
Subject: [issue6499] Can't import xmlrpclib,
	DocXMLRPCServer and SimpleXMLRPCServer when zlib is not available
In-Reply-To: <1247797208.72.0.744238846554.issue6499@psf.upfronthosting.co.za>
Message-ID: <1248043176.17.0.487295486595.issue6499@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

submitted revision 74098 and revision 74099 which should fix your issue.
Oh, and revision 74100 and revision 74101 as well (insufficient testing 
on my part, tsk. tsk.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6499>
_______________________________________

From report at bugs.python.org  Mon Jul 20 00:45:18 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 19 Jul 2009 22:45:18 +0000
Subject: [issue6499] Can't import xmlrpclib,
	DocXMLRPCServer and SimpleXMLRPCServer when zlib is not available
In-Reply-To: <1247797208.72.0.744238846554.issue6499@psf.upfronthosting.co.za>
Message-ID: <1248043518.47.0.104487713326.issue6499@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Thanks, now all the tests pass.
However I had intermittent failures (with a really useful error message)
on test_docxmlrpc:

$ ./python Lib/test/regrtest.py -v test_docxmlrpc
test_docxmlrpc
test_autolink_dotted_methods (test.test_docxmlrpc.DocXMLRPCHTTPGETServer)
Test that selfdot values are made strong automatically in the ... ok
test_autolinking (test.test_docxmlrpc.DocXMLRPCHTTPGETServer)
Test that the server correctly automatically wraps references to PEPS ... ok
test_invalid_get_response (test.test_docxmlrpc.DocXMLRPCHTTPGETServer)
... ok
test_lambda (test.test_docxmlrpc.DocXMLRPCHTTPGETServer)
Test that lambda functionality stays the same.  The output produced ... ok
test_system_methods (test.test_docxmlrpc.DocXMLRPCHTTPGETServer)
Test the precense of three consecutive system.* methods. ... ok
test_valid_get_response (test.test_docxmlrpc.DocXMLRPCHTTPGETServer) ... ok

----------------------------------------------------------------------
Ran 6 tests in 0.392s

OK
1 test OK.
Unhandled exception in thread started by
Error in sys.excepthook:

Original exception was:

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6499>
_______________________________________

From report at bugs.python.org  Mon Jul 20 02:11:07 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 20 Jul 2009 00:11:07 +0000
Subject: [issue6026] test_(zipfile|zipimport|gzip|distutils|sqlite) fail if
	zlib is not available
In-Reply-To: <1242349106.59.0.466065396405.issue6026@psf.upfronthosting.co.za>
Message-ID: <1248048667.19.0.843517668371.issue6026@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Here's a new patch.

I added a could of @skipUnless in test_sqlite because two tests were
failing. 
I couldn't notice this before because I didn't have _sqlite3 and these
tests were skipped. Thanks to R. David Murray for reporting the problem.

In test_zipimport, the tests in 2/3 of the classes can be executed when
zlib is missing (and not only 1/3 as I initially thought). Removed zlib
= test_support.import_module('zlib') and added a @skipUnless(zlib,
"requires zlib"). Thanks again to David for this.

test_multiprocessing, test_xmplrpc and test_docxmlrpc were fixed in
#6499, so they are not part of this issue anymore.

----------
keywords:  -patch
title: test_(zipfile|zipimport|gzip|distutils|multiprocessing|xmlrpc|docxmlrpc) fail if zlib is not available -> test_(zipfile|zipimport|gzip|distutils|sqlite) fail if zlib is not available
Added file: http://bugs.python.org/file14524/issue6026-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6026>
_______________________________________

From report at bugs.python.org  Mon Jul 20 02:12:28 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 20 Jul 2009 00:12:28 +0000
Subject: [issue6026] test_(zipfile|zipimport|gzip|distutils|sqlite) fail if
	zlib is not available
In-Reply-To: <1242349106.59.0.466065396405.issue6026@psf.upfronthosting.co.za>
Message-ID: <1248048748.37.0.237753229035.issue6026@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6026>
_______________________________________

From report at bugs.python.org  Mon Jul 20 03:01:07 2009
From: report at bugs.python.org (Kevin Walzer)
Date: Mon, 20 Jul 2009 01:01:07 +0000
Subject: [issue5262] PythonLauncher considered harmfull
In-Reply-To: <1234638505.38.0.029039550018.issue5262@psf.upfronthosting.co.za>
Message-ID: <1248051667.1.0.74582860557.issue5262@psf.upfronthosting.co.za>


Kevin Walzer <wordtech at users.sourceforge.net> added the comment:

I disagree that this is a bad idea--it's helpful to be able to double-
click a GUI script and launch it automatically. I realize one can just 
fire up Terminal and go "python myscript.py," but I missed this 
functionality when it was broken and would be unhappy to see it removed.

----------
nosy: +wordtech

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5262>
_______________________________________

From report at bugs.python.org  Mon Jul 20 03:15:10 2009
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 20 Jul 2009 01:15:10 +0000
Subject: [issue6522] docs for unittest.expectedFailure do not syntactically
	show it's a decorator
In-Reply-To: <1248052510.55.0.186681984589.issue6522@psf.upfronthosting.co.za>
Message-ID: <1248052510.55.0.186681984589.issue6522@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

If you look at the docs for the unittest.expectedFailure decorator you 
will notice it shows a set of empty parentheses since it is set with a 
function directive. But since it's a decorator those empty parentheses 
are not accurate.

If you want to view the docs as showing common usage -- like the docs 
for the other decorators in unittest -- then those empty parentheses 
need to go. An @ should also probably be added as well.

But if you view it more as how the decorator is called -- like with 
importlib.util.module_for_loader does -- then it should have an argument 
for the callable being passed in. This would also mean that all the 
other decorators in unittest need a second set of parentheses taking a 
callable as their argument as well.

Perhaps it's time we added a decorator directive that adds the @ sign 
and does not insert empty parentheses?

----------
assignee: georg.brandl
components: Documentation
messages: 90718
nosy: brett.cannon, georg.brandl
priority: low
severity: normal
stage: needs patch
status: open
title: docs for unittest.expectedFailure do not syntactically show it's a decorator
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6522>
_______________________________________

From report at bugs.python.org  Mon Jul 20 03:28:33 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Mon, 20 Jul 2009 01:28:33 +0000
Subject: [issue6520] urllib.urlopen does not have timeout parameter where as
	urllib2.urlopen has
In-Reply-To: <1247971941.19.0.568398315734.issue6520@psf.upfronthosting.co.za>
Message-ID: <1248053313.14.0.492256946566.issue6520@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

I suspect that was a conscious decision.  Back when it was first written
urllib2 was supposed to eventually replace urllib I think.  Dunno if
that's still true, but if so I could see why this feature wasn't added
to urllib.urlopen.

----------
nosy: +skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6520>
_______________________________________

From report at bugs.python.org  Mon Jul 20 03:46:55 2009
From: report at bugs.python.org (Jubaraj Borgohain)
Date: Mon, 20 Jul 2009 01:46:55 +0000
Subject: [issue1436346] yday in datetime module
Message-ID: <1248054415.26.0.861402608351.issue1436346@psf.upfronthosting.co.za>


Jubaraj Borgohain <jubarajborgohain at gmail.com> added the comment:

I have completed the following two new features for the datetime module
(the changes are attached as a patch):
a. Added a method yday()
b. Added date.fromyday(year,yday), which returns a date object.
The other features requested are already available.
The tests for these two new features have also been added to
test_datetimemodule.py.
The patch has been only tested on trunk.(Python 2.7)

----------
keywords: +patch
nosy: +jborgohain
Added file: http://bugs.python.org/file14525/issue1436346.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1436346>
_______________________________________

From report at bugs.python.org  Mon Jul 20 07:12:45 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 20 Jul 2009 05:12:45 +0000
Subject: [issue6516] reset owner/group to root for distutils tarballs
In-Reply-To: <1247933699.76.0.278346370296.issue6516@psf.upfronthosting.co.za>
Message-ID: <1248066765.77.0.871574344471.issue6516@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

what would be the use case for that ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6516>
_______________________________________

From report at bugs.python.org  Mon Jul 20 07:16:58 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 20 Jul 2009 05:16:58 +0000
Subject: [issue6163] [HP-UX] ld: Unrecognized argument: +s -L<dir>
In-Reply-To: <1243876859.78.0.253879711884.issue6163@psf.upfronthosting.co.za>
Message-ID: <1248067018.9.0.881640411609.issue6163@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Michael, I am not sure how you patch applies, is "elif" meant to be "if" ?
e.g. a gcc compiler under hp-us case ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6163>
_______________________________________

From report at bugs.python.org  Mon Jul 20 08:12:19 2009
From: report at bugs.python.org (Leonard Kevin McGuire Jr)
Date: Mon, 20 Jul 2009 06:12:19 +0000
Subject: [issue6523] smtplib exception smtp.connect TypeError encode_plain
In-Reply-To: <1248070339.45.0.0640518982252.issue6523@psf.upfronthosting.co.za>
Message-ID: <1248070339.45.0.0640518982252.issue6523@psf.upfronthosting.co.za>


New submission from Leonard Kevin McGuire Jr <kmcguire at kmcguire.org>:

------ SYSTEM INFORMATION -----
module:     smtplib
system:     linux

python3.0 -V 
  Python 3.0.1+

----- TEST CASE PYTHON SOURCE -----
import smtplib
smtp = smtplib.SMTP()
smtp.connect('mail.myserver.org')
smtp.login('myusername', 'mypassword')

----- TEST CASE EXECUTION RESULTS -----
python3.0 testcase.py 
Traceback (most recent call last):
  File "testcase.py", line 4, in <module>
    smtp.login('myusername', 'mypassword')
  File "/home/kevin/Projects/ftpwatch/smtplib.py", line 580, in login
    AUTH_PLAIN + " " + encode_plain(user, password))
  File "/home/kevin/Projects/ftpwatch/smtplib.py", line 545, in encode_plain
    return encode_base64("\0%s\0%s" % (user, password))
  File "/usr/lib/python3.0/email/base64mime.py", line 96, in body_encode
    enc = b2a_base64(s[i:i + max_unencoded]).decode("ascii")
TypeError: b2a_base64() argument 1 must be bytes or buffer, not str

----------
components: Library (Lib), Unicode
messages: 90723
nosy: kmcguire
severity: normal
status: open
title: smtplib exception smtp.connect TypeError encode_plain
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6523>
_______________________________________

From report at bugs.python.org  Mon Jul 20 08:48:31 2009
From: report at bugs.python.org (Henrik ravn)
Date: Mon, 20 Jul 2009 06:48:31 +0000
Subject: [issue6524] tarfile module missing decompression support?
In-Reply-To: <1248072511.11.0.843825773543.issue6524@psf.upfronthosting.co.za>
Message-ID: <1248072511.11.0.843825773543.issue6524@psf.upfronthosting.co.za>


New submission from Henrik ravn <hravnx at gmail.com>:

When doing the following with python 2.6.2 on Windows Vista SP1:

>>> import tarfile
>>> tf = tarfile.TarFile("sometarfile.tar.bz2")

Traceback (most recent call last):
  File "<pyshell#2>", line 1, in <module>
    tf = tarfile.TarFile("sometarfile.tar.bz2")
  File "C:\Python26\lib\tarfile.py", line 1570, in __init__
    self.firstmember = self.next()
  File "C:\Python26\lib\tarfile.py", line 2322, in next
    raise ReadError(str(e))
ReadError: invalid header

This would, of course, suggest that the file was corrupted, but all 
archiving tools (tar, winrar and 7-zip) handle the file without 
problems. 

Also:

>>> tf = tarfile.TarFile("sometarfile.tar.bz2", "r:bz2")

Traceback (most recent call last):
  File "<pyshell#3>", line 1, in <module>
    tf = tarfile.TarFile("e:/mono/mono-2.4.2.2.tar.bz2", "r:bz2")
  File "C:\Python26\lib\tarfile.py", line 1510, in __init__
    raise ValueError("mode must be 'r', 'a' or 'w'")
ValueError: mode must be 'r', 'a' or 'w'

which suggests that the compression support is not compiled into the 
tarfile module.

----------
components: Library (Lib)
messages: 90724
nosy: hravnx
severity: normal
status: open
title: tarfile module missing decompression support?
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6524>
_______________________________________

From report at bugs.python.org  Mon Jul 20 09:03:28 2009
From: report at bugs.python.org (Henrik ravn)
Date: Mon, 20 Jul 2009 07:03:28 +0000
Subject: [issue6524] tarfile module missing decompression support?
In-Reply-To: <1248072511.11.0.843825773543.issue6524@psf.upfronthosting.co.za>
Message-ID: <1248073408.64.0.545075429885.issue6524@psf.upfronthosting.co.za>


Henrik ravn <hravnx at gmail.com> added the comment:

Nevermind - apparently I misunderstood the docs. Sorry.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6524>
_______________________________________

From report at bugs.python.org  Mon Jul 20 10:07:55 2009
From: report at bugs.python.org (LazyLogik)
Date: Mon, 20 Jul 2009 08:07:55 +0000
Subject: [issue5188] telnetlib process_rawq buffer handling is confused
In-Reply-To: <1234131372.15.0.372715702734.issue5188@psf.upfronthosting.co.za>
Message-ID: <1248077275.4.0.970099963404.issue5188@psf.upfronthosting.co.za>


LazyLogik <naimesh.thakkar at gmail.com> added the comment:

Hello,

I am also facing problems in using telnetlib. 

I think following changes are also required. e.g. on line 442 (if c!= 
IAC) should be replaced with (if c!= IAC[0]). Similarly line 465 (if cmd 
in (DO, DONT)) should be replaced with (if cmd in (DO[0], DONT[0]). 

I also get some errors while printing debug messages also if debug level 
is not zero. e.g. Line 466


Regards,
Naimesh

----------
nosy: +LazyLogik

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5188>
_______________________________________

From report at bugs.python.org  Mon Jul 20 11:29:08 2009
From: report at bugs.python.org (Michael Haubenwallner)
Date: Mon, 20 Jul 2009 09:29:08 +0000
Subject: [issue6163] [HP-UX] ld: Unrecognized argument: +s -L<dir>
In-Reply-To: <1243876859.78.0.253879711884.issue6163@psf.upfronthosting.co.za>
Message-ID: <1248082148.1.0.670475017454.issue6163@psf.upfronthosting.co.za>


Michael Haubenwallner <michael.haubenwallner at salomon.at> added the comment:

Ohw, indeed, this line was copied from 3 lines below, sorry!
The actual patch I'm using does not do { compiler[:3] == 'gcc' }, but {
compiler.find("gcc") }, to also work when CC=gcc-version, but this is a
different problem independent of hp-ux.

But exactly, his should be 'if', being gcc on hp-ux.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6163>
_______________________________________

From report at bugs.python.org  Mon Jul 20 13:25:18 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 20 Jul 2009 11:25:18 +0000
Subject: [issue6514] "python -m unittest <testmodule>" does not run any tests
In-Reply-To: <1247928686.78.0.475658449787.issue6514@psf.upfronthosting.co.za>
Message-ID: <1248089118.65.0.644024094861.issue6514@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> michael.foord
nosy: +michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6514>
_______________________________________

From report at bugs.python.org  Mon Jul 20 13:54:52 2009
From: report at bugs.python.org (Michael Foord)
Date: Mon, 20 Jul 2009 11:54:52 +0000
Subject: [issue6514] "python -m unittest <testmodule>" does not run any tests
In-Reply-To: <1247928686.78.0.475658449787.issue6514@psf.upfronthosting.co.za>
Message-ID: <1248090892.56.0.763161624811.issue6514@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

I can duplicate the problem - I wonder if this has to do with the
refactoring into a package? Anyway, thanks for catching this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6514>
_______________________________________

From report at bugs.python.org  Mon Jul 20 14:07:44 2009
From: report at bugs.python.org (Michael Foord)
Date: Mon, 20 Jul 2009 12:07:44 +0000
Subject: [issue6514] "python -m unittest <testmodule>" does not run any tests
In-Reply-To: <1247928686.78.0.475658449787.issue6514@psf.upfronthosting.co.za>
Message-ID: <1248091664.02.0.267393922675.issue6514@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Ha - no I can't reproduce it on trunk.

The python -m features are new in trunk and neither documented nor
working in 2.4-2.6.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6514>
_______________________________________

From report at bugs.python.org  Mon Jul 20 14:22:40 2009
From: report at bugs.python.org (Michael Foord)
Date: Mon, 20 Jul 2009 12:22:40 +0000
Subject: [issue6514] "python -m unittest <testmodule>" does not run any tests
In-Reply-To: <1247928686.78.0.475658449787.issue6514@psf.upfronthosting.co.za>
Message-ID: <1248092560.24.0.509687907364.issue6514@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

This isn't a bug - the command line message if you run "python -m
unittest" on Python 2.4-2.6 is just confusing. It has never worked.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6514>
_______________________________________

From report at bugs.python.org  Mon Jul 20 14:25:29 2009
From: report at bugs.python.org (djc)
Date: Mon, 20 Jul 2009 12:25:29 +0000
Subject: [issue6491] Improve --with-dbmliborder option
In-Reply-To: <1247678287.04.0.431591668248.issue6491@psf.upfronthosting.co.za>
Message-ID: <1248092729.31.0.515074460395.issue6491@psf.upfronthosting.co.za>


Changes by djc <dirkjan at ochtman.nl>:


----------
nosy: +djc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6491>
_______________________________________

From report at bugs.python.org  Mon Jul 20 14:42:53 2009
From: report at bugs.python.org (Graham Dumpleton)
Date: Mon, 20 Jul 2009 12:42:53 +0000
Subject: [issue4200] atexit module not safe in Python 3.0 with multiple
	interpreters
In-Reply-To: <1224888355.2.0.82482284838.issue4200@psf.upfronthosting.co.za>
Message-ID: <1248093773.05.0.6474262266.issue4200@psf.upfronthosting.co.za>


Graham Dumpleton <Graham.Dumpleton at gmail.com> added the comment:

This new problem I am seeing looks like it may be linked to where the 
'atexit' module is initialised/imported in a sub interpreter but never 
in the main interpreter. I can avoid the crash by having:

    PyImport_ImportModule("atexit");

    Py_Finalize();

At a guess, this is because:

    module = PyState_FindModule(&atexitmodule);
    if (module == NULL)
        return;

still returns a module for case where imported in a sub interpreter but 
not in main interpreter, but then:

    modstate = GET_ATEXIT_STATE(module);

    if (modstate->ncallbacks == 0)
        return;

returns NULL for modstate for the main interpreter as PyInit_atexit() 
had never been called for the main interpreter.

The fix would appear to be to check modstate for being NULL and return. 
Ie.,

    module = PyState_FindModule(&atexitmodule);
    if (module == NULL)
        return;
    modstate = GET_ATEXIT_STATE(module);

    if (modstate == NULL)
        return;

    if (modstate->ncallbacks == 0)
        return;

Does that make sense to anyone? If it does and I am correct, I'll create 
a new issue for it as original fix seems deficient.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4200>
_______________________________________

From report at bugs.python.org  Mon Jul 20 15:14:10 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 20 Jul 2009 13:14:10 +0000
Subject: [issue6522] docs for unittest.expectedFailure do not syntactically
	show it's a decorator
In-Reply-To: <1248052510.55.0.186681984589.issue6522@psf.upfronthosting.co.za>
Message-ID: <1248095650.56.0.676496503158.issue6522@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee: georg.brandl -> benjamin.peterson
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6522>
_______________________________________

From report at bugs.python.org  Mon Jul 20 15:27:50 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 20 Jul 2009 13:27:50 +0000
Subject: [issue6522] docs for unittest.expectedFailure do not syntactically
	show it's a decorator
In-Reply-To: <1248052510.55.0.186681984589.issue6522@psf.upfronthosting.co.za>
Message-ID: <1248096470.8.0.00927723512848.issue6522@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee: benjamin.peterson -> georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6522>
_______________________________________

From report at bugs.python.org  Mon Jul 20 16:47:33 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 20 Jul 2009 14:47:33 +0000
Subject: [issue6462] bsddb3 intermittent test failures
In-Reply-To: <1247329933.16.0.47150397.issue6462@psf.upfronthosting.co.za>
Message-ID: <1248101253.85.0.861737047104.issue6462@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Another buildbot intermittent failure, this one from

  http://www.python.org/dev/buildbot/all/x86%20XP-4%20trunk/builds/2332

ie: the x86 XP-4 buildbot:

Traceback (most recent call last):
  File
"E:\cygwin\home\db3l\buildarea\trunk.bolen-windows\build\lib\threading.py",
line 524, in __bootstrap_inner
    self.run()
  File
"E:\cygwin\home\db3l\buildarea\trunk.bolen-windows\build\lib\threading.py",
line 477, in run
    self.__target(*self.__args, **self.__kwargs)
  File
"E:\cygwin\home\db3l\buildarea\trunk.bolen-windows\build\lib\bsddb\test\test_thread.py",
line 306, in readerThread
    rec = dbutils.DeadlockWrap(c.next, max_retries=10)
  File
"E:\cygwin\home\db3l\buildarea\trunk.bolen-windows\build\lib\bsddb\dbutils.py",
line 68, in DeadlockWrap
    return function(*_args, **_kwargs)
DBLockDeadlockError: (-30994, 'DB_LOCK_DEADLOCK: Locker killed to
resolve a deadlock')

That run also shows the replication timeout error, which that buildbot
often produces.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6462>
_______________________________________

From report at bugs.python.org  Mon Jul 20 18:43:42 2009
From: report at bugs.python.org (Peter Landgren)
Date: Mon, 20 Jul 2009 16:43:42 +0000
Subject: [issue6525] Problem with string.lowercase in Windows XP
In-Reply-To: <1248108222.18.0.565207839087.issue6525@psf.upfronthosting.co.za>
Message-ID: <1248108222.18.0.565207839087.issue6525@psf.upfronthosting.co.za>


New submission from Peter Landgren <peter.talken at telia.com>:

string.lowercase is changed after locale.setlocale(locale.LC_ALL,'') in
Windows XP but not in Linux.
This little test script on Windows XP and Linux explains the problem:

import locale
import string
print string.lowercase
print locale.setlocale(locale.LC_ALL,'C')
print string.lowercase
print locale.setlocale(locale.LC_ALL,'')
print string.lowercase

Result on Win XP with Python 2.5.1:
abcdefghijklmnopqrstuvwxyz
C
abcdefghijklmnopqrstuvwxyz
Swedish_Sweden.1252
abcdefghijklmnopqrstuvwxyz??????????????????????????????????????

Result on Linux with Python 2.5.2:
abcdefghijklmnopqrstuvwxyz
C
abcdefghijklmnopqrstuvwxyz
sv_SE.UTF-8
abcdefghijklmnopqrstuvwxyz

----------
components: Extension Modules
messages: 90733
nosy: PeterL
severity: normal
status: open
title: Problem with string.lowercase in Windows XP
type: crash
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6525>
_______________________________________

From report at bugs.python.org  Mon Jul 20 19:18:57 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 20 Jul 2009 17:18:57 +0000
Subject: [issue6525] Problem with string.lowercase in Windows XP
In-Reply-To: <1248108222.18.0.565207839087.issue6525@psf.upfronthosting.co.za>
Message-ID: <1248110337.54.0.669831994894.issue6525@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
priority:  -> normal
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6525>
_______________________________________

From report at bugs.python.org  Mon Jul 20 19:35:19 2009
From: report at bugs.python.org (Peter Landgren)
Date: Mon, 20 Jul 2009 17:35:19 +0000
Subject: [issue6525] Problem with string.lowercase in Windows XP
In-Reply-To: <1248108222.18.0.565207839087.issue6525@psf.upfronthosting.co.za>
Message-ID: <1248111319.51.0.437300304706.issue6525@psf.upfronthosting.co.za>


Peter Landgren <peter.talken at telia.com> added the comment:

Thru, but later in the application code like this
a = u"qaz" + string.lowercase[26]

causes
   a = u"qaz" + string.lowercase[26]
UnicodeDecodeError: 'ascii' codec can't decode byte 0x83 in position 0:
ordinal not in range(128)

0x83 corresponds to ?.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6525>
_______________________________________

From report at bugs.python.org  Mon Jul 20 19:35:38 2009
From: report at bugs.python.org (Peter Landgren)
Date: Mon, 20 Jul 2009 17:35:38 +0000
Subject: [issue6525] Problem with string.lowercase in Windows XP
In-Reply-To: <1248108222.18.0.565207839087.issue6525@psf.upfronthosting.co.za>
Message-ID: <1248111338.77.0.245870512427.issue6525@psf.upfronthosting.co.za>


Peter Landgren <peter.talken at telia.com> added the comment:

True, but later in the application code like this
a = u"qaz" + string.lowercase[26]

causes
   a = u"qaz" + string.lowercase[26]
UnicodeDecodeError: 'ascii' codec can't decode byte 0x83 in position 0:
ordinal not in range(128)

0x83 corresponds to ?.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6525>
_______________________________________

From report at bugs.python.org  Mon Jul 20 19:59:51 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 20 Jul 2009 17:59:51 +0000
Subject: [issue6525] Problem with string.lowercase in Windows XP
In-Reply-To: <1248108222.18.0.565207839087.issue6525@psf.upfronthosting.co.za>
Message-ID: <1248112791.48.0.576382636173.issue6525@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

That's still not a crash...a crash is when the python interpreter fails.

2.5 isn't getting bug fixes any more.  Do you see the same problem in
2.6?  In 3.x this is a non-issue, since 3.x uses unicode internally.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6525>
_______________________________________

From report at bugs.python.org  Mon Jul 20 20:30:03 2009
From: report at bugs.python.org (Peter Landgren)
Date: Mon, 20 Jul 2009 18:30:03 +0000
Subject: [issue6525] Problem with string.lowercase in Windows XP
In-Reply-To: <1248108222.18.0.565207839087.issue6525@psf.upfronthosting.co.za>
Message-ID: <1248114603.17.0.539526088212.issue6525@psf.upfronthosting.co.za>


Peter Landgren <peter.talken at telia.com> added the comment:

OK about 2.5
Downloaded and installed Python 2.6.2 on my Win XP box and get the same
error as with Python 2.5.1.

Ok about Python 3, it will be nice when we have upgraded our
application, Gramps, to this version and get rid of all kind of coding
issues.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6525>
_______________________________________

From report at bugs.python.org  Mon Jul 20 20:45:23 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 20 Jul 2009 18:45:23 +0000
Subject: [issue6526] importlib.import_module affects permissions of .pyc files
	subsequently created by import
In-Reply-To: <1248115523.66.0.058614511154.issue6526@psf.upfronthosting.co.za>
Message-ID: <1248115523.66.0.058614511154.issue6526@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

In debugging an intermittent test failure we discovered that if '.' is
in the path and import_module is called, then what happens when
__import__ causes the creation of a .pyc file changes.  Without the
forgoing, the permissions of the .py file are copied to the .pyc file
(although the fix for issue 6070 removes the execute bits if set).  With
the forgoing, the write bit is set on the .pyc file even if it was not
set on the .py file.

The second behavior is how things always worked before 2.6. (Why it
changed in 2.6 I don't know, and I'm not convinced it was a change for
the better; see also issue 6074).

I will upload a test as soon as I create the issue and get an issue
number to label it with.

Note that this issue exists only 3.x, even though trunk uses the
backported import_module function from importlib.

----------
assignee: brett.cannon
components: Library (Lib)
messages: 90738
nosy: brett.cannon, r.david.murray
priority: low
severity: normal
stage: needs patch
status: open
title: importlib.import_module affects permissions of .pyc files subsequently created by import
type: behavior
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6526>
_______________________________________

From report at bugs.python.org  Mon Jul 20 20:47:02 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 20 Jul 2009 18:47:02 +0000
Subject: [issue6526] importlib.import_module affects permissions of .pyc files
	subsequently created by import
In-Reply-To: <1248115523.66.0.058614511154.issue6526@psf.upfronthosting.co.za>
Message-ID: <1248115622.29.0.9471463069.issue6526@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Test case.

----------
keywords: +patch
Added file: http://bugs.python.org/file14526/issue6526-test.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6526>
_______________________________________

From report at bugs.python.org  Mon Jul 20 21:09:17 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 20 Jul 2009 19:09:17 +0000
Subject: [issue6525] Problem with string.lowercase in Windows XP
In-Reply-To: <1248108222.18.0.565207839087.issue6525@psf.upfronthosting.co.za>
Message-ID: <1248116957.68.0.883823108448.issue6525@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Hmm.  I thought I remembered looking at this before.  See (closed) issue
1633600.  It looks like the linux issue is fixed in 2.7, but I'm not
sure when or how, nor can I reproduce my test or yours at the moment
since I seem to have a configuration problem on my linux system.

----------
versions: +Python 2.6, Python 2.7 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6525>
_______________________________________

From report at bugs.python.org  Mon Jul 20 23:30:25 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 20 Jul 2009 21:30:25 +0000
Subject: [issue6527] test_ttk_guionly buildbot test crash:
	Tcl_FinalizeNotifier: notifier pipe not initialized
In-Reply-To: <1248125424.97.0.178196969881.issue6527@psf.upfronthosting.co.za>
Message-ID: <1248125424.97.0.178196969881.issue6527@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

The buildbots occasionally crash in test_ttk_guionly with the following
output:

test_ttk_guionly
Tcl_FinalizeNotifier: notifier pipe not initialized
make: *** [buildbottest] Abort trap
program finished with exit code 2

Here is an example:

http://www.python.org/dev/buildbot/all/x86%20osx.5%203.x/builds/1209

----------
components: Library (Lib), Tests
messages: 90741
nosy: gpolo, r.david.murray
priority: normal
severity: normal
stage: test needed
status: open
title: test_ttk_guionly buildbot test crash: Tcl_FinalizeNotifier: notifier pipe not initialized
type: crash
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6527>
_______________________________________

From report at bugs.python.org  Mon Jul 20 23:39:31 2009
From: report at bugs.python.org (Freiddie)
Date: Mon, 20 Jul 2009 21:39:31 +0000
Subject: [issue6528] builtins colored as keyword at beginning of line
In-Reply-To: <1248125971.41.0.191814152476.issue6528@psf.upfronthosting.co.za>
Message-ID: <1248125971.41.0.191814152476.issue6528@psf.upfronthosting.co.za>


New submission from Freiddie <fei.yuanbw at gmail.com>:

I noticed in that whenever I enter "None" at the beginning of the line
in IDLE 3.1, the word is colored orange (for keywords) rather than
purple. If I insert a space right before the "None", it returns to its
normal purple color (for builtins), so it only seems to occur at the
beginning of a line. The same thing occurs to "True" and "False", but
not "list", "int", etc. This did not occur in 2.6.

----------
components: IDLE
messages: 90742
nosy: Freiddie
severity: normal
status: open
title: builtins colored as keyword at beginning of line
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6528>
_______________________________________

From report at bugs.python.org  Tue Jul 21 00:06:27 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 20 Jul 2009 22:06:27 +0000
Subject: [issue6528] builtins colored as keyword at beginning of line
In-Reply-To: <1248125971.41.0.191814152476.issue6528@psf.upfronthosting.co.za>
Message-ID: <1248127587.88.0.0331951857658.issue6528@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +gpolo
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6528>
_______________________________________

From report at bugs.python.org  Tue Jul 21 00:54:46 2009
From: report at bugs.python.org (Danek Duvall)
Date: Mon, 20 Jul 2009 22:54:46 +0000
Subject: [issue6529] get{pw,gr}{nam,[ug]id}() calls are not re-entrant
In-Reply-To: <1248130486.1.0.677109329447.issue6529@psf.upfronthosting.co.za>
Message-ID: <1248130486.1.0.677109329447.issue6529@psf.upfronthosting.co.za>


New submission from Danek Duvall <duvall at comfychair.org>:

In tracking down

        6861990 getgrnam_r() str2group() function makes decisions based
on return value before it's set

(viewable on bugs.opensolaris.org), I noted that the pwd and grp modules
don't use the MT-safe interfaces to the password and group name service
tables.  The _r() interfaces have been around for a long time, are
standard, and should be used if at all possible.  That said, I can't
imagine it's terribly likely that people will go to the lengths
necessary to actually put multiple calls in flight at the same time in
CPython, but should it ever become easy to put this code into concurrent
threads, it'll likely fall over.

----------
components: Library (Lib)
messages: 90743
nosy: dhduvall
severity: normal
status: open
title: get{pw,gr}{nam,[ug]id}() calls are not re-entrant
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6529>
_______________________________________

From report at bugs.python.org  Tue Jul 21 01:05:23 2009
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 20 Jul 2009 23:05:23 +0000
Subject: [issue6526] importlib.import_module affects permissions of .pyc files
	subsequently created by import
In-Reply-To: <1248115523.66.0.058614511154.issue6526@psf.upfronthosting.co.za>
Message-ID: <1248131123.4.0.670541975194.issue6526@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

import_module are implemented completely differently between 2.6 and 3.1, 
so the difference is not surprising.

As for the permission stuff, the files are simply created using open(..., 
'wb') so it has everything to do with what the system default for the 
executing user happens to be. What exactly are the permissions you are 
trying to set all bytecode files to?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6526>
_______________________________________

From report at bugs.python.org  Tue Jul 21 01:15:27 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 20 Jul 2009 23:15:27 +0000
Subject: [issue6526] importlib.import_module affects permissions of .pyc files
	subsequently created by import
In-Reply-To: <1248115523.66.0.058614511154.issue6526@psf.upfronthosting.co.za>
Message-ID: <1248131727.86.0.912016091497.issue6526@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

If you have a .py file with permissions r--r--r-- and you import it, the
pyc file will (in 2.6+ and 3.x) have permissions r--r--r--.  However, if
'.' is in the path and import_module has been used, the file will
instead have permissions rw--r--r-- (assuming the umask is 022).

Does that make the issue clearer?

As indicated, this is a low priority bug :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6526>
_______________________________________

From report at bugs.python.org  Tue Jul 21 01:25:36 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 20 Jul 2009 23:25:36 +0000
Subject: [issue6526] importlib.import_module affects permissions of .pyc files
	subsequently created by import
In-Reply-To: <1248115523.66.0.058614511154.issue6526@psf.upfronthosting.co.za>
Message-ID: <1248132336.74.0.887815780927.issue6526@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Oh, a bit of clarification: the call that creates the pyc file in both
the "normal" case and the error case is a call to the normal import
command (or __import__ in the test case). The call to import_module is a
prereq to producing the bug, but it doesn't matter what module it
imports (as long as it hasn't been previously imported).  The import
that shows the behavior imports a TESTFN module in the test case.

You might want to load up the test case and play with it.  I'm
completely mystified as to how import_module could be affecting the
regular import semantics...I'm guessing it is a subtle side effect of
something unexpected ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6526>
_______________________________________

From report at bugs.python.org  Tue Jul 21 01:28:24 2009
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 20 Jul 2009 23:28:24 +0000
Subject: [issue6526] importlib.import_module affects permissions of .pyc files
	subsequently created by import
In-Reply-To: <1248132336.74.0.887815780927.issue6526@psf.upfronthosting.co.za>
Message-ID: <bbaeab100907201628g7433b959rf73e836df1909daa@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Mon, Jul 20, 2009 at 16:25, R. David Murray <report at bugs.python.org>wrote:

>
> R. David Murray <rdmurray at bitdance.com> added the comment:
>
> Oh, a bit of clarification: the call that creates the pyc file in both
> the "normal" case and the error case is a call to the normal import
> command (or __import__ in the test case). The call to import_module is a
> prereq to producing the bug, but it doesn't matter what module it
> imports (as long as it hasn't been previously imported).  The import
> that shows the behavior imports a TESTFN module in the test case.
>
> You might want to load up the test case and play with it.  I'm
> completely mystified as to how import_module could be affecting the
> regular import semantics...I'm guessing it is a subtle side effect of
> something unexpected ;)

It's beyond mystifying as both importlib.__import__ and
importlib.import_module are thin wrappers that do nothing but splice strings
for the same function that does the heavy lifting. But I will see if I ever
find time to work on this.

----------
Added file: http://bugs.python.org/file14527/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6526>
_______________________________________
-------------- next part --------------
<br><br><div class="gmail_quote">On Mon, Jul 20, 2009 at 16:25, R. David Murray <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
R. David Murray &lt;<a href="mailto:rdmurray at bitdance.com">rdmurray at bitdance.com</a>&gt; added the comment:<br>
<br>
Oh, a bit of clarification: the call that creates the pyc file in both<br>
the &quot;normal&quot; case and the error case is a call to the normal import<br>
command (or __import__ in the test case). The call to import_module is a<br>
prereq to producing the bug, but it doesn&#39;t matter what module it<br>
imports (as long as it hasn&#39;t been previously imported). ??The import<br>
that shows the behavior imports a TESTFN module in the test case.<br>
<br>
You might want to load up the test case and play with it. ??I&#39;m<br>
completely mystified as to how import_module could be affecting the<br>
regular import semantics...I&#39;m guessing it is a subtle side effect of<br>
something unexpected ;)</blockquote><div><br></div><div>It&#39;s beyond mystifying as both importlib.__import__ and importlib.import_module are thin wrappers that do nothing but splice strings for the same function that does the heavy lifting. But I will see if I ever find time to work on this.??</div>

</div>

From report at bugs.python.org  Tue Jul 21 06:00:03 2009
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Tue, 21 Jul 2009 04:00:03 +0000
Subject: [issue6530] Regression on "python -Wi" crash
In-Reply-To: <1248148803.55.0.651976757693.issue6530@psf.upfronthosting.co.za>
Message-ID: <1248148803.55.0.651976757693.issue6530@psf.upfronthosting.co.za>


New submission from Kurt B. Kaiser <kbk at shore.net>:

Rev 73196

http://svn.python.org/
view?view=rev&revision=73196

Caused regression on

http://bugs.python.org/issue1503294

when running build.sh:

(gdb) r -Wi
Starting program: /home/neal/python/trunk/
python -Wi
warning: Unable to find dynamic linker 
breakpoint function.
GDB will be unable to debug shared library 
initializers
and track explicitly loaded dynamic code.
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 1190)]
Fatal Python error: PyThreadState_Get: no 
current thread

Program received signal SIGABRT, Aborted.
[Switching to Thread 16384 (LWP 1190)]
0xb7e80021 in kill () from /lib/libc.so.6
(gdb) bt
#0  0xb7e80021 in kill () from /lib/libc.so.6
#1  0xb7f9cce1 in pthread_kill () from /lib/
libpthread.so.0
#2  0xb7f9d05b in raise () from /lib/
libpthread.so.0
#3  0xb7e7fc54 in raise () from /lib/
libc.so.6
#4  0xb7e8140d in abort () from /lib/libc.so.6
#5  0x08112084 in Py_FatalError (
    msg=0x818d1c4 "PyThreadState_Get: no 
current 
thread")
    at Python/pythonrun.c:1660
#6  0x0810e56c in PyThreadState_Get () at 
Python/
pystate.c:310
#7  0x0808b5e4 in PyDict_GetItem 
(op=0xb7e19034, key=0xb7e18028)
    at Objects/dictobject.c:718
#8  0x080aa542 in PyString_InternInPlace 
(p=0xbffff900)
    at Objects/stringobject.c:5143
#9  0x0809df48 in PyString_FromString 
(str=0xbffffbc2 "i")
    at Objects/stringobject.c:163
#10 0x081180d5 in PySys_AddWarnOption 
(s=0xbffffbc2 "i")
    at Python/sysmodule.c:985
#11 0x08058b8c in Py_Main (argc=2, 
argv=0xbffffa84) at Modules/main.c:415
#12 0x0805811e in main (argc=2, 
argv=0xbffffa84) at Modules/python.c:23

----------
assignee: benjamin.peterson
components: Interpreter Core
keywords: needs review
messages: 90748
nosy: benjamin.peterson, kbk
priority: normal
severity: normal
status: open
title: Regression on "python -Wi" crash
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6530>
_______________________________________

From report at bugs.python.org  Tue Jul 21 08:24:26 2009
From: report at bugs.python.org (Peter Landgren)
Date: Tue, 21 Jul 2009 06:24:26 +0000
Subject: [issue6525] Problem with string.lowercase in Windows XP
In-Reply-To: <1248108222.18.0.565207839087.issue6525@psf.upfronthosting.co.za>
Message-ID: <1248157466.93.0.428005845392.issue6525@psf.upfronthosting.co.za>


Peter Landgren <peter.talken at telia.com> added the comment:

Just some more test. I compared the result of string.letters,
string.uppercase and string.lowercase in 2.5 and 2.6:

Python25:
Letters=
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz???????????????????
??????????????????????????????????????????????????????
Upper= ABCDEFGHIJKLMNOPQRSTUVWXYZ??????????????????????????????????
Lower= abcdefghijklmnopqrstuvwxyz???????????????????????????????????????

Python26:
Letters=
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz?SOZsozY???????????
??????????????????????????????????????????????????????
Upper= ABCDEFGHIJKLMNOPQRSTUVWXYZSOZY??????????????????????????????
Lower= abcdefghijklmnopqrstuvwxyz?soz???????????????????????????????????

They return different contents, but the length are the same!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6525>
_______________________________________

From report at bugs.python.org  Tue Jul 21 08:41:40 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 21 Jul 2009 06:41:40 +0000
Subject: [issue6525] Problem with string.lowercase in Windows XP
In-Reply-To: <1248108222.18.0.565207839087.issue6525@psf.upfronthosting.co.za>
Message-ID: <1248158500.14.0.0841086256805.issue6525@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6525>
_______________________________________

From report at bugs.python.org  Tue Jul 21 10:33:52 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 21 Jul 2009 08:33:52 +0000
Subject: [issue6528] builtins colored as keyword at beginning of line
In-Reply-To: <1248125971.41.0.191814152476.issue6528@psf.upfronthosting.co.za>
Message-ID: <1248165232.63.0.379280698607.issue6528@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

In Python 3, True, False and None are keywords, so the orange should be
correct. It should be orange also when you do "foo = True" though.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6528>
_______________________________________

From report at bugs.python.org  Tue Jul 21 10:44:54 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 21 Jul 2009 08:44:54 +0000
Subject: [issue6499] Can't import xmlrpclib,
	DocXMLRPCServer and SimpleXMLRPCServer when zlib is not available
In-Reply-To: <1247797208.72.0.744238846554.issue6499@psf.upfronthosting.co.za>
Message-ID: <1248165894.09.0.751169304707.issue6499@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

I found one problem in test_docxmlrpc.py, a missing "import socket" at 
the top (for the socket.timeout exception handler).
Please add that, and see what happens.

But there seems to be a problem with the error handing in your build.  
probably, sys.stderr is messed up somehow.  You could try putting a 
breakpoint in line 444 of threadmodule.c and get to the bottom of it.

But to short circuit that,  
try adding an "import sys" and then in the finally clause (around line 
54) add "sys.stderr = sys.__stderr__" and see if you get better error 
output.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6499>
_______________________________________

From report at bugs.python.org  Tue Jul 21 11:30:26 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 21 Jul 2009 09:30:26 +0000
Subject: [issue6510] zipfile: OSError File exists
In-Reply-To: <1247882043.78.0.940486778067.issue6510@psf.upfronthosting.co.za>
Message-ID: <1248168626.22.0.352334496177.issue6510@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This was already fixed with issue6050, and will be part of 2.6.3.
Thanks for the report

----------
nosy: +amaury.forgeotdarc
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6510>
_______________________________________

From report at bugs.python.org  Tue Jul 21 13:19:29 2009
From: report at bugs.python.org (Graham Dumpleton)
Date: Tue, 21 Jul 2009 11:19:29 +0000
Subject: [issue6531] atexit_callfuncs() crashing within Py_Finalize() when
	using multiple interpreters.
In-Reply-To: <1248175169.79.0.15962102552.issue6531@psf.upfronthosting.co.za>
Message-ID: <1248175169.79.0.15962102552.issue6531@psf.upfronthosting.co.za>


New submission from Graham Dumpleton <Graham.Dumpleton at gmail.com>:

I am seeing a crash within Py_Finalize() with Python 3.0 in mod_wsgi. It looks like the 
patches for issue-4200 were not adequate and that this wasn't picked up at the time.

This new problem I am seeing looks like it may be linked to where the 'atexit' module is 
initialised/imported in a sub interpreter but never imported in the main interpreter. I can 
avoid the crash by having:

    PyImport_ImportModule("atexit");

    Py_Finalize();

At a guess, the problem is because in atexit_callfuncs():

    module = PyState_FindModule(&atexitmodule);
    if (module == NULL)
        return;

still returns a module for case where imported in a sub interpreter but not in main 
interpreter, so doesn't return, but then code which follows:

    modstate = GET_ATEXIT_STATE(module);

    if (modstate->ncallbacks == 0)
        return;

returns NULL for modstate for the main interpreter as PyInit_atexit() had never been called 
for the main interpreter as the 'atexit' module was never imported within that interpreter.

The fix would appear to be to check modstate for being NULL and return. Ie.,

    module = PyState_FindModule(&atexitmodule);
    if (module == NULL)
        return;
    modstate = GET_ATEXIT_STATE(module);

    if (modstate == NULL)
        return;

    if (modstate->ncallbacks == 0)
        return;

The only thing I am uncertain about is why PyState_FindModule() would return an object. I 
cant find any documentation about that function so not entirely sure what it is meant to do. 
I would have thought it would be returning data specific to the interpreter, but if never 
imported in that interpreter, why would there still be an object recorded.

BTW, I have marked this as for Python 3.1 as well, but haven't tested it on that. The code in 
'atexit' module doesn't appear to have changed though so assuming it will die there as well.

For now am using the workaround in mod_wsgi.

----------
components: Interpreter Core
messages: 90753
nosy: grahamd
severity: normal
status: open
title: atexit_callfuncs() crashing within Py_Finalize() when using multiple interpreters.
type: crash
versions: Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6531>
_______________________________________

From report at bugs.python.org  Tue Jul 21 13:20:12 2009
From: report at bugs.python.org (Graham Dumpleton)
Date: Tue, 21 Jul 2009 11:20:12 +0000
Subject: [issue4200] atexit module not safe in Python 3.0 with multiple
	interpreters
In-Reply-To: <1224888355.2.0.82482284838.issue4200@psf.upfronthosting.co.za>
Message-ID: <1248175212.1.0.156493328281.issue4200@psf.upfronthosting.co.za>


Graham Dumpleton <Graham.Dumpleton at gmail.com> added the comment:

Have created issue6531 for my new issue related to this patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4200>
_______________________________________

From report at bugs.python.org  Tue Jul 21 14:17:58 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 21 Jul 2009 12:17:58 +0000
Subject: [issue6493] Can not set value for structure members larger than 32
	bits
In-Reply-To: <1247706719.26.0.735618414968.issue6493@psf.upfronthosting.co.za>
Message-ID: <1248178678.19.0.0675964069661.issue6493@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

One of the new tests in r74134 is failing on my box (Gentoo x86), and on
a number of the buildbots:

test test_ctypes failed -- Traceback (most recent call last):
  File "/home/rdmurray/python/trunk/Lib/ctypes/test/test_bitfields.py",
line 255, in test_uint64
    self.failUnlessEqual(x.a, 10)
AssertionError: 0L != 10

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6493>
_______________________________________

From report at bugs.python.org  Tue Jul 21 14:18:54 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 21 Jul 2009 12:18:54 +0000
Subject: [issue6493] Can not set value for structure members larger than 32
	bits
In-Reply-To: <1247706719.26.0.735618414968.issue6493@psf.upfronthosting.co.za>
Message-ID: <1248178734.58.0.730418976461.issue6493@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
priority:  -> normal
stage:  -> commit review
type:  -> behavior
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.5, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6493>
_______________________________________

From report at bugs.python.org  Tue Jul 21 14:21:41 2009
From: report at bugs.python.org (Thomas Heller)
Date: Tue, 21 Jul 2009 12:21:41 +0000
Subject: [issue6493] Can not set value for structure members larger than
	32	bits
In-Reply-To: <1248178678.19.0.0675964069661.issue6493@psf.upfronthosting.co.za>
Message-ID: <4A65B2D2.4020408@ctypes.org>


Thomas Heller <theller at ctypes.org> added the comment:

> One of the new tests in r74134 is failing on my box (Gentoo x86), and on
> a number of the buildbots:

I've seen that, but do not yet have a patch.

----------
title: Can not set value for structure members larger than 32 bits -> Can not set value for structure members larger than 32	bits

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6493>
_______________________________________

From report at bugs.python.org  Tue Jul 21 14:29:50 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 21 Jul 2009 12:29:50 +0000
Subject: [issue6531] atexit_callfuncs() crashing within Py_Finalize() when
	using multiple interpreters.
In-Reply-To: <1248175169.79.0.15962102552.issue6531@psf.upfronthosting.co.za>
Message-ID: <1248179390.22.0.0839434676676.issue6531@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I strongly recommend you move to 3.1.  3.0 will not be getting any more
bug patches.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6531>
_______________________________________

From report at bugs.python.org  Tue Jul 21 14:44:20 2009
From: report at bugs.python.org (Graham Dumpleton)
Date: Tue, 21 Jul 2009 12:44:20 +0000
Subject: [issue6531] atexit_callfuncs() crashing within Py_Finalize() when
	using multiple interpreters.
In-Reply-To: <1248175169.79.0.15962102552.issue6531@psf.upfronthosting.co.za>
Message-ID: <1248180260.22.0.402146899286.issue6531@psf.upfronthosting.co.za>


Graham Dumpleton <Graham.Dumpleton at gmail.com> added the comment:

As a provider of software that others use I am just making mod_wsgi usable 
with everything so users can use whatever they want. You telling me to use 
Python 3.1 isn't going to stop people from using Python 3.0 if that is 
what they happen to have installed. Just look at how many people still use 
really old Python 2.X versions. Ultimately I don't care which Python 
version it is fixed in as I have the work around anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6531>
_______________________________________

From report at bugs.python.org  Tue Jul 21 15:24:20 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 21 Jul 2009 13:24:20 +0000
Subject: [issue6531] atexit_callfuncs() crashing within Py_Finalize() when
	using multiple interpreters.
In-Reply-To: <1248175169.79.0.15962102552.issue6531@psf.upfronthosting.co.za>
Message-ID: <1248182660.0.0.299425281104.issue6531@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm sorry, I wasn't clear.  We are recommending that no one use Python
3.0 for production.  Python 3.1 fixed some significant performance
issues.  We are hoping that distribution packagers will not ship 3.0,
but will ship 3.1 instead.  But if you want to support 3.0, that's a
fine thing.

I should have just kept my mouth shut, especially since I don't have any
input on the bug itself ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6531>
_______________________________________

From report at bugs.python.org  Tue Jul 21 16:09:06 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 21 Jul 2009 14:09:06 +0000
Subject: [issue6530] Regression on "python -Wi" crash
In-Reply-To: <1248148803.55.0.651976757693.issue6530@psf.upfronthosting.co.za>
Message-ID: <1248185346.73.0.609442088103.issue6530@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r74139

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6530>
_______________________________________

From report at bugs.python.org  Tue Jul 21 16:25:25 2009
From: report at bugs.python.org (Wojciech Lichota)
Date: Tue, 21 Jul 2009 14:25:25 +0000
Subject: [issue6532] thread.get_ident() should return unsigned value
In-Reply-To: <1248186325.01.0.817161707988.issue6532@psf.upfronthosting.co.za>
Message-ID: <1248186325.01.0.817161707988.issue6532@psf.upfronthosting.co.za>


New submission from Wojciech Lichota <wojciech at lichota.pl>:

In glibc library (on linux) pthread_t is defined as:

typedef unsigned long int pthread_t;

But python thread module interprets this value as signed long. 

Reproduce:
>>> import thread
>>> thread.get_ident()
In some cases it returns negative value.
Checked in python 2.4, 2.5, 2.6

Proposal:
In my opinion code that cast value returned by pthread_self() should be
changed (see: Python/thread_pthread.h).

Other possibility is to change only returned value by get_ident
function. In this case it should use PyLong_FromUnsignedLong (see:
Modules/threadmodule.c).

Background:
logging module uses 'thread.get_ident()' to save thread_id in logs. If
the same application uses some C library that also writes in log file
some info with thread_id, in some situations this numbers are diffrent.
This complicate logs analyze.

----------
components: Library (Lib)
messages: 90761
nosy: sargo
severity: normal
status: open
title: thread.get_ident() should return unsigned value
versions: Python 2.4, Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6532>
_______________________________________

From report at bugs.python.org  Tue Jul 21 17:40:10 2009
From: report at bugs.python.org (nestor)
Date: Tue, 21 Jul 2009 15:40:10 +0000
Subject: [issue6236] os.popen causes illegal seek on AIX in Python 3.1rc
In-Reply-To: <1244427618.5.0.797941537993.issue6236@psf.upfronthosting.co.za>
Message-ID: <1248190810.98.0.00661958556669.issue6236@psf.upfronthosting.co.za>


nestor <nestornissen at gmail.com> added the comment:

Maybe this has something to do with it?

Python 3.1 (r31:73572, Jul  9 2009, 16:28:28) [C] on aix5
Type "help", "copyright", "credits" or "license" for more information.
>>> open("/dev/tty","a").seekable()
True
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6236>
_______________________________________

From report at bugs.python.org  Tue Jul 21 18:01:19 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 21 Jul 2009 16:01:19 +0000
Subject: [issue6533] Make test_xmlrpc_net functional in the absence of
	time.xmlrpc.com
In-Reply-To: <1248192079.14.0.84793941186.issue6533@psf.upfronthosting.co.za>
Message-ID: <1248192079.14.0.84793941186.issue6533@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

It seems like time.xmlrpc.com is gone (again?).  That service was
provided by userland.com, who have an xmlrpc server that they mention in
their documentation examples (see for example
http://frontier.userland.com/changes/kernel71) which argues that they
will probably keep the service alive.

The attached patch adds a second test to test_xmlrpc_net to access the
example service directly at userland, and changes both tests to raise
unittest.SkipTest if the service is not accessible.

----------
assignee: r.david.murray
components: Tests
files: test_xmlrpc_net.patch
keywords: easy, patch, patch
messages: 90763
nosy: r.david.murray
priority: low
severity: normal
stage: patch review
status: open
title: Make test_xmlrpc_net functional in the absence of time.xmlrpc.com
type: behavior
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14528/test_xmlrpc_net.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6533>
_______________________________________

From report at bugs.python.org  Tue Jul 21 19:03:23 2009
From: report at bugs.python.org (Luke-Jr)
Date: Tue, 21 Jul 2009 17:03:23 +0000
Subject: [issue6534] os.makedirs returns EACCES for "C:\"
In-Reply-To: <1248195802.84.0.161288296569.issue6534@psf.upfronthosting.co.za>
Message-ID: <1248195802.84.0.161288296569.issue6534@psf.upfronthosting.co.za>


New submission from Luke-Jr <luke-jr at users.sourceforge.net>:

Should return EEXIST or EISDIR provided C:\ actually exists

----------
components: Windows
messages: 90764
nosy: luke-jr
severity: normal
status: open
title: os.makedirs returns EACCES for "C:\"
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6534>
_______________________________________

From report at bugs.python.org  Tue Jul 21 19:27:01 2009
From: report at bugs.python.org (Thomas Heller)
Date: Tue, 21 Jul 2009 17:27:01 +0000
Subject: [issue6493] Can not set value for structure members larger than 32
	bits
In-Reply-To: <1247706719.26.0.735618414968.issue6493@psf.upfronthosting.co.za>
Message-ID: <1248197221.13.0.753232678278.issue6493@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

ctypes_workaround_2.patch from ocean-city seems to fix it so I'll apply
that.

----------
title: Can not set value for structure members larger than 32	bits -> Can not set value for structure members larger than 32 bits

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6493>
_______________________________________

From report at bugs.python.org  Tue Jul 21 20:26:09 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 21 Jul 2009 18:26:09 +0000
Subject: [issue5596] memory leaks in py3k
In-Reply-To: <1238336388.84.0.581148968517.issue5596@psf.upfronthosting.co.za>
Message-ID: <1248200769.7.0.676423233923.issue5596@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

With the py3k branch head (r74140):

test_urllib leaked [6, 4] references, sum=10
test_urllib2 leaked [227, 227] references, sum=454

----------
title: memory leaks in 3.1 -> memory leaks in py3k
versions: +Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5596>
_______________________________________

From report at bugs.python.org  Tue Jul 21 21:27:49 2009
From: report at bugs.python.org (Daniel Kaplun)
Date: Tue, 21 Jul 2009 19:27:49 +0000
Subject: [issue6535] optparse required field for Options
In-Reply-To: <1248204469.91.0.747237681609.issue6535@psf.upfronthosting.co.za>
Message-ID: <1248204469.91.0.747237681609.issue6535@psf.upfronthosting.co.za>


New submission from Daniel Kaplun <min at dvir.us>:

In the second example to allow usage of the required field for options,
it seems as if you already have all you need to implement the feature
into optparse. I modified it a bit to allow OptionGroups:

class Option(optparse.Option):
	ATTRS = optparse.Option.ATTRS + ['required']

	def _check_required(self):
		if self.required and not self.takes_value():
			raise OptionError(
				"required flag set for option that doesn't take a value",
				 self)

	# Make sure _check_required() is called from the constructor!
	CHECK_METHODS = optparse.Option.CHECK_METHODS + [_check_required]

	def process(self, opt, value, values, parser):
		optparse.Option.process(self, opt, value, values, parser)
		parser.option_seen[self] = 1

class OptionParser(optparse.OptionParser):
	def _init_parsing_state(self):
		optparse.OptionParser._init_parsing_state(self)
		self.option_seen = {}

	def check_values(self, values, args):
		for option in self.option_list + sum((optiongroup.option_list for
optiongroup in self.option_groups), []):
			if isinstance(option, Option) and option.required and not
self.option_seen.has_key(option):
				self.error("%s not supplied" % (option, ))
		return (values, args)

The question: why hasn't your existing example been merged with the
OptionParse code to allow the required field for options?

----------
components: Extension Modules
messages: 90767
nosy: mindvirus
severity: normal
status: open
title: optparse required field for Options
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6535>
_______________________________________

From report at bugs.python.org  Tue Jul 21 21:29:05 2009
From: report at bugs.python.org (Daniel Kaplun)
Date: Tue, 21 Jul 2009 19:29:05 +0000
Subject: [issue6535] optparse required field for Options
In-Reply-To: <1248204469.91.0.747237681609.issue6535@psf.upfronthosting.co.za>
Message-ID: <1248204545.54.0.277849029248.issue6535@psf.upfronthosting.co.za>


Changes by Daniel Kaplun <min at dvir.us>:


----------
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6535>
_______________________________________

From report at bugs.python.org  Tue Jul 21 21:44:28 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Jul 2009 19:44:28 +0000
Subject: [issue3311] block operation on closed socket/pipe for multiprocessing
In-Reply-To: <1215393520.85.0.811591651843.issue3311@psf.upfronthosting.co.za>
Message-ID: <1248205468.12.0.0420828203857.issue3311@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

ping? The bug is still open and valid.

----------
versions: +Python 2.7, Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3311>
_______________________________________

From report at bugs.python.org  Tue Jul 21 21:57:23 2009
From: report at bugs.python.org (Kurt McKee)
Date: Tue, 21 Jul 2009 19:57:23 +0000
Subject: [issue6536] urllib2 howto contains typo
In-Reply-To: <1248206243.89.0.549186072656.issue6536@psf.upfronthosting.co.za>
Message-ID: <1248206243.89.0.549186072656.issue6536@psf.upfronthosting.co.za>


New submission from Kurt McKee <contactme at kurtmckee.org>:

At <http://docs.python.org/dev/howto/urllib2.html>,
"HHTPBasicAuthHandler" should of course be "HTTP..."

----------
assignee: georg.brandl
components: Documentation
messages: 90769
nosy: georg.brandl, kurtmckee
severity: normal
status: open
title: urllib2 howto contains typo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6536>
_______________________________________

From report at bugs.python.org  Tue Jul 21 22:00:51 2009
From: report at bugs.python.org (Eric Promislow)
Date: Tue, 21 Jul 2009 20:00:51 +0000
Subject: [issue6537] string.split shouldn't split on non-breaking spaces
In-Reply-To: <1248206451.65.0.201066321826.issue6537@psf.upfronthosting.co.za>
Message-ID: <1248206451.65.0.201066321826.issue6537@psf.upfronthosting.co.za>


New submission from Eric Promislow <ericp at activestate.com>:

ActivePython 2.6.1.1 ...
>>> a = u"abc\x0adef"
>>> a.split()
[u'abc', u'def']
>>>

"\x0a" is a non-breaking space. This behavior means we can't
easily use split() to reflow text.

----------
components: Interpreter Core
messages: 90770
nosy: ericp
severity: normal
status: open
title: string.split shouldn't split on non-breaking spaces
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6537>
_______________________________________

From report at bugs.python.org  Tue Jul 21 22:04:43 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 21 Jul 2009 20:04:43 +0000
Subject: [issue6537] string.split shouldn't split on non-breaking spaces
In-Reply-To: <1248206451.65.0.201066321826.issue6537@psf.upfronthosting.co.za>
Message-ID: <1248206683.43.0.521954282814.issue6537@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

split() is usually used to split words. To reflow text, use the textwrap
module.

----------
nosy: +benjamin.peterson
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6537>
_______________________________________

From report at bugs.python.org  Tue Jul 21 22:19:52 2009
From: report at bugs.python.org (Eric Promislow)
Date: Tue, 21 Jul 2009 20:19:52 +0000
Subject: [issue6537] string.split shouldn't split on non-breaking spaces
In-Reply-To: <1248206451.65.0.201066321826.issue6537@psf.upfronthosting.co.za>
Message-ID: <1248207592.49.0.630079145443.issue6537@psf.upfronthosting.co.za>


Eric Promislow <ericp at activestate.com> added the comment:

Thanks.  For the record, I want

textwrap.TextWrapper(..., break_long_words=False)

or it will break after a non-breaking space if that
gives an optimum length.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6537>
_______________________________________

From report at bugs.python.org  Tue Jul 21 22:23:54 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 21 Jul 2009 20:23:54 +0000
Subject: [issue6536] urllib2 howto contains typo
In-Reply-To: <1248206243.89.0.549186072656.issue6536@psf.upfronthosting.co.za>
Message-ID: <1248207834.18.0.468476865215.issue6536@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee: georg.brandl -> ezio.melotti
nosy: +ezio.melotti
priority:  -> low
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6536>
_______________________________________

From report at bugs.python.org  Tue Jul 21 22:25:39 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 21 Jul 2009 20:25:39 +0000
Subject: [issue6537] string.split shouldn't split on non-breaking spaces
In-Reply-To: <1248206451.65.0.201066321826.issue6537@psf.upfronthosting.co.za>
Message-ID: <1248207939.01.0.0408848517295.issue6537@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6537>
_______________________________________

From report at bugs.python.org  Tue Jul 21 22:44:47 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 21 Jul 2009 20:44:47 +0000
Subject: [issue6535] optparse required field for Options
In-Reply-To: <1248204469.91.0.747237681609.issue6535@psf.upfronthosting.co.za>
Message-ID: <1248209087.57.0.57534332097.issue6535@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Feature requests can only go into releases under development.

No guarantees, but if you want to give this a better chance of getting
in a patch against trunk including tests would be a minimum prerequisite.

Alternatively or in addition you could help review argparse for
inclusion into the stdlib (see issue 6247; I know the issue is closed
but it could still be moved forward if enough interest is expressed).

----------
components: +Library (Lib) -Extension Modules
keywords: +easy
nosy: +r.david.murray
priority:  -> normal
stage:  -> test needed
versions:  -Python 2.4, Python 2.5, Python 2.6, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6535>
_______________________________________

From report at bugs.python.org  Tue Jul 21 23:21:47 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 21 Jul 2009 21:21:47 +0000
Subject: [issue6536] urllib2 howto contains typo
In-Reply-To: <1248206243.89.0.549186072656.issue6536@psf.upfronthosting.co.za>
Message-ID: <1248211307.75.0.40004081944.issue6536@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed in r74148 (trunk) and r74149 (py3k).
Thanks!

----------
resolution: accepted -> fixed
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6536>
_______________________________________

From report at bugs.python.org  Tue Jul 21 23:21:58 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 21 Jul 2009 21:21:58 +0000
Subject: [issue6536] urllib2 howto contains typo
In-Reply-To: <1248206243.89.0.549186072656.issue6536@psf.upfronthosting.co.za>
Message-ID: <1248211318.44.0.56821565896.issue6536@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6536>
_______________________________________

From report at bugs.python.org  Tue Jul 21 23:37:43 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 21 Jul 2009 21:37:43 +0000
Subject: [issue6534] os.makedirs returns EACCES for "C:\"
In-Reply-To: <1248195802.84.0.161288296569.issue6534@psf.upfronthosting.co.za>
Message-ID: <1248212263.86.0.999635938369.issue6534@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

EACCESS is the error code returned by the underlying mkdir system call.
os.mkdir won't change this, as long as an OSError is raised.

You should use another way to check that the directory exists, like 
os.path.isdir("c:\\")

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6534>
_______________________________________

From report at bugs.python.org  Wed Jul 22 00:08:39 2009
From: report at bugs.python.org (Daniel Kaplun)
Date: Tue, 21 Jul 2009 22:08:39 +0000
Subject: [issue6535] optparse required field for Options
In-Reply-To: <1248204469.91.0.747237681609.issue6535@psf.upfronthosting.co.za>
Message-ID: <1248214119.18.0.976927215125.issue6535@psf.upfronthosting.co.za>


Changes by Daniel Kaplun <min at dvir.us>:


----------
keywords: +patch
Added file: http://bugs.python.org/file14529/optparse.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6535>
_______________________________________

From report at bugs.python.org  Wed Jul 22 00:09:09 2009
From: report at bugs.python.org (Daniel Kaplun)
Date: Tue, 21 Jul 2009 22:09:09 +0000
Subject: [issue6535] optparse required field for Options
In-Reply-To: <1248204469.91.0.747237681609.issue6535@psf.upfronthosting.co.za>
Message-ID: <1248214149.83.0.593134081483.issue6535@psf.upfronthosting.co.za>


Changes by Daniel Kaplun <min at dvir.us>:


Added file: http://bugs.python.org/file14530/testcase.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6535>
_______________________________________

From report at bugs.python.org  Wed Jul 22 00:29:23 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 21 Jul 2009 22:29:23 +0000
Subject: [issue6538] MatchObject is not a hyperlink in the 're' module
	documentation
In-Reply-To: <1248215363.5.0.63292386695.issue6538@psf.upfronthosting.co.za>
Message-ID: <1248215363.5.0.63292386695.issue6538@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

In the re documentation MatchObject is marked up as a class, but since
there's no declaration of it as a class (it's a section instead) it
doesn't get turned into a hyperlink.  It would be useful if it did link
to the appropriate section.

----------
assignee: georg.brandl
components: Documentation
keywords: easy
messages: 90776
nosy: georg.brandl, r.david.murray
priority: low
severity: normal
stage: needs patch
status: open
title: MatchObject is not a hyperlink in the 're' module documentation
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6538>
_______________________________________

From report at bugs.python.org  Wed Jul 22 00:57:56 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 21 Jul 2009 22:57:56 +0000
Subject: [issue6535] optparse required field for Options
In-Reply-To: <1248204469.91.0.747237681609.issue6535@psf.upfronthosting.co.za>
Message-ID: <1248217076.51.0.599663884204.issue6535@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

What we are looking for in the way of tests is unit tests to add to
test_optparse.  Another piece that I forgot about that we'll need is a
documentation patch.

Finally, it will be easier to review the patch if you don't make other
changes in the patch.  Your PEP 8 changes are good in principle, but
they make it harder to review the patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6535>
_______________________________________

From report at bugs.python.org  Wed Jul 22 01:08:18 2009
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Tue, 21 Jul 2009 23:08:18 +0000
Subject: [issue6539] unittest dir not created during install
In-Reply-To: <1248217698.37.0.436469328297.issue6539@psf.upfronthosting.co.za>
Message-ID: <1248217698.37.0.436469328297.issue6539@psf.upfronthosting.co.za>


New submission from Kurt B. Kaiser <kbk at shore.net>:

rev 74095
http://svn.python.org/view?view=rev&revision=74095

didn't create the unittest dir during installation.

unittest isn't installed in its final location.

----------
assignee: benjamin.peterson
components: Build
files: Makefile.pre.in.patch
keywords: needs review, patch
messages: 90778
nosy: benjamin.peterson, kbk
priority: high
severity: normal
stage: patch review
status: open
title: unittest dir not created during install
versions: Python 2.7
Added file: http://bugs.python.org/file14531/Makefile.pre.in.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6539>
_______________________________________

From report at bugs.python.org  Wed Jul 22 01:08:53 2009
From: report at bugs.python.org (Luke-Jr)
Date: Tue, 21 Jul 2009 23:08:53 +0000
Subject: [issue6534] os.makedirs returns EACCES for "C:\"
In-Reply-To: <1248195802.84.0.161288296569.issue6534@psf.upfronthosting.co.za>
Message-ID: <1248217733.18.0.819114507513.issue6534@psf.upfronthosting.co.za>


Luke-Jr <luke-jr at users.sourceforge.net> added the comment:

At least fix the documentation, then...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6534>
_______________________________________

From report at bugs.python.org  Wed Jul 22 01:14:01 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 21 Jul 2009 23:14:01 +0000
Subject: [issue6539] unittest dir not created during install
In-Reply-To: <1248217698.37.0.436469328297.issue6539@psf.upfronthosting.co.za>
Message-ID: <1248218041.08.0.996743532878.issue6539@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r74150.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6539>
_______________________________________

From report at bugs.python.org  Wed Jul 22 01:24:45 2009
From: report at bugs.python.org (Daniel Kaplun)
Date: Tue, 21 Jul 2009 23:24:45 +0000
Subject: [issue6535] optparse required field for Options
In-Reply-To: <1248204469.91.0.747237681609.issue6535@psf.upfronthosting.co.za>
Message-ID: <1248218685.92.0.930180950619.issue6535@psf.upfronthosting.co.za>


Daniel Kaplun <min at dvir.us> added the comment:

I have not a single clue how to unit test.

What do you mean by documentation patch? Do you want me to update the
documentation within the file to reflect changes?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6535>
_______________________________________

From report at bugs.python.org  Wed Jul 22 01:52:26 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 21 Jul 2009 23:52:26 +0000
Subject: [issue6499] Can't import xmlrpclib,
	DocXMLRPCServer and SimpleXMLRPCServer when zlib is not available
In-Reply-To: <1247797208.72.0.744238846554.issue6499@psf.upfronthosting.co.za>
Message-ID: <1248220346.55.0.435353920981.issue6499@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

sys.stderr looks ok, I tried what you said and I also tried to put some
"assert sys.stderr == sys.__stderr__" here and there and nothing changed.
I commented out the tests one by one and I found out that the first test
alone (test_valid_get_response) is enough to have that error message
(the second alone doesn't seem to show any error).
There's also a comment that says that response.read() is necessary but
nothing changes if I remove that line.
I also noticed that if I put a print at the end of the finally block the
error message doesn't appear anymore.
I didn't tried to debug threadmodule.c.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6499>
_______________________________________

From report at bugs.python.org  Wed Jul 22 02:03:23 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 22 Jul 2009 00:03:23 +0000
Subject: [issue6535] optparse required field for Options
In-Reply-To: <1248204469.91.0.747237681609.issue6535@psf.upfronthosting.co.za>
Message-ID: <1248221003.86.0.874256134549.issue6535@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, if you get check out the current trunk via svn (as described in
the developer's faq linked from http://www.python.org/dev) and you look
at what Lib/test/test_optparse.py currently does, you might find it is
not too hard to add some new cases to test the new code.  Then in
Doc/library/optparse.rst, you make appropriate changes to the
documentation RestructuredTest source code, and post everything in a
single patch.

If you don't want to do all this that's fine, the ticket will sit here
until someone comes along who wants to move it forward ;)

Thanks for taking an interest in this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6535>
_______________________________________

From report at bugs.python.org  Wed Jul 22 02:10:53 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 22 Jul 2009 00:10:53 +0000
Subject: [issue6499] Can't import xmlrpclib,
	DocXMLRPCServer and SimpleXMLRPCServer when zlib is not available
In-Reply-To: <1247797208.72.0.744238846554.issue6499@psf.upfronthosting.co.za>
Message-ID: <1248221453.68.0.887710955748.issue6499@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Well, I think the only way to move forward with this is to try to 
figure out what the actual error is.  Something is wrong in printing it 
out to stderr, and it would be helpful to understand why it is not 
being output.  Perhaps this is some buffering issue.  You could try to 
redirect stderr to a file, using something like this i the finally 
clause:
sys.stderr = open("/tmp/err.txt", "w", 0)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6499>
_______________________________________

From report at bugs.python.org  Wed Jul 22 02:13:12 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 22 Jul 2009 00:13:12 +0000
Subject: [issue6534] os.makedirs returns EACCES for "C:\"
In-Reply-To: <1248195802.84.0.161288296569.issue6534@psf.upfronthosting.co.za>
Message-ID: <1248221592.98.0.221683173704.issue6534@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The documentation carefully don't specify the possible values of errno of 
the exceptions. What do you want to fix?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6534>
_______________________________________

From report at bugs.python.org  Wed Jul 22 02:14:53 2009
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Jul 2009 00:14:53 +0000
Subject: [issue6540] bytearray.translate(): error in error handling
In-Reply-To: <1248221692.97.0.916983162972.issue6540@psf.upfronthosting.co.za>
Message-ID: <1248221692.97.0.916983162972.issue6540@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

bytearray.translate() crash if:
 * first argument was converted to a buffer but the buffer length is not 256
bytes
 * first argument is valid, but the second argument can not be converted to a
buffer

The crash occurs because PyBuffer_Release(&vdel) is called whereas vdel
buffer is not initialized.

Example with Python3:

lisa$ ./python
Python 3.2a0 (py3k:74029M, Jul 17 2009, 02:29:48)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> x=bytearray(b'xyz')
>>> x.translate(b'x', 1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: translation table must be 256 characters long
>>> x.translate(b'x', 1)
Erreur de segmentation

Attached patch fixes the two cases and add an unit test for the first case. As
you can see in the example, it's an Heisenbug :-) (compile in debug bug to get
reproductible crash)

----------
components: Interpreter Core
files: bytearray.patch
keywords: patch
messages: 90786
nosy: haypo
severity: normal
status: open
title: bytearray.translate(): error in error handling
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14532/bytearray.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6540>
_______________________________________

From report at bugs.python.org  Wed Jul 22 02:22:01 2009
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Jul 2009 00:22:01 +0000
Subject: [issue6540] bytearray.translate(): error in error handling
In-Reply-To: <1248221692.97.0.916983162972.issue6540@psf.upfronthosting.co.za>
Message-ID: <1248222121.01.0.850987441364.issue6540@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file14532/bytearray.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6540>
_______________________________________

From report at bugs.python.org  Wed Jul 22 02:22:54 2009
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Jul 2009 00:22:54 +0000
Subject: [issue6540] bytearray.translate(): error in error handling
In-Reply-To: <1248221692.97.0.916983162972.issue6540@psf.upfronthosting.co.za>
Message-ID: <1248222174.73.0.813885799284.issue6540@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oops, my first patch was broken (redefine "test_bin", instead of using a
different method name). The name patch tests both cases (the two crashs).

----------
Added file: http://bugs.python.org/file14533/bytearray-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6540>
_______________________________________

From report at bugs.python.org  Wed Jul 22 02:24:11 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 22 Jul 2009 00:24:11 +0000
Subject: [issue6499] Can't import xmlrpclib,
	DocXMLRPCServer and SimpleXMLRPCServer when zlib is not available
In-Reply-To: <1247797208.72.0.744238846554.issue6499@psf.upfronthosting.co.za>
Message-ID: <1248222251.02.0.0894253185346.issue6499@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Same message in the terminal and nothing in the file.

Can you reproduce it if you run the test several times? Some times I
have to run "./python Lib/test/regrtest.py -v test_docxmlrpc" 15-20 or
even more times before the message appears.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6499>
_______________________________________

From report at bugs.python.org  Wed Jul 22 02:27:19 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 22 Jul 2009 00:27:19 +0000
Subject: [issue6540] bytearray.translate(): error in error handling
In-Reply-To: <1248221692.97.0.916983162972.issue6540@psf.upfronthosting.co.za>
Message-ID: <1248222439.98.0.510013884426.issue6540@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
priority:  -> critical
stage:  -> patch review
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6540>
_______________________________________

From report at bugs.python.org  Wed Jul 22 03:54:23 2009
From: report at bugs.python.org (Leon Matthews)
Date: Wed, 22 Jul 2009 01:54:23 +0000
Subject: [issue6541] SpooledTemporaryFile operates differently to TemporaryFile
In-Reply-To: <1248227663.52.0.385641131196.issue6541@psf.upfronthosting.co.za>
Message-ID: <1248227663.52.0.385641131196.issue6541@psf.upfronthosting.co.za>


New submission from Leon Matthews <leon at lost.co.nz>:

According the docs for the tempfile module, SpooledTemporaryFile()
should operate "exactly as TemporaryFile() does".  However, while
playing around trying to learn the module I found a couple of places
where this is not the case: 

import tempfile

hello = bytes('Hello World!', encoding='utf-8')
tf = tempfile.TemporaryFile()
stf = tempfile.SpooledTemporaryFile()

tf.write(hello)
stf.write(hello)

# (1) Read after write behaviour differs...
>>> print(tf.read())  
b'Hello World'
>>> print(stf.read())
b''

# ...unless you seek first
>>> tf.seek(0)
>>> stf.seek(0)
>>> print(tf.read())
b'Hello World'
>>> print(stf.read())
b'Hello World'


# (2) Name attribute is fragile...
>>> print(tf.name)
3
print(stf.name)
AttributeError: '_io.BytesIO' object has no attribute 'name'

# ...until StringIO object replaced
stf.rollover()
print(stf.name)   # 4

I'm not sure if this should be categorised as a documentation or code
issue. In either case please be gentle -- I'm still just learning Python
(evaluating it as a [now likely] replacement for PHP for web application
development in our company).  I'm filing this bug because, as a
beginner, I was confused by the inconsistency between the docs and the
actual behaviour.

I'd be happy to try and write documentation and/or unit tests about
this, if somebody would be willing to review them for me... :-)

----------
components: Library (Lib)
messages: 90789
nosy: leonov
severity: normal
status: open
title: SpooledTemporaryFile operates differently to TemporaryFile
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6541>
_______________________________________

From report at bugs.python.org  Wed Jul 22 04:26:57 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Wed, 22 Jul 2009 02:26:57 +0000
Subject: [issue6242] Fix reference leak in io.StringIO
In-Reply-To: <1244490696.88.0.117703122021.issue6242@psf.upfronthosting.co.za>
Message-ID: <1248229617.05.0.342629865116.issue6242@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Patch committed in r74155 (branches/py3k).

----------
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6242>
_______________________________________

From report at bugs.python.org  Wed Jul 22 04:32:04 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 22 Jul 2009 02:32:04 +0000
Subject: [issue6542] test_os TestInvalidFD.test_closerange causes test_pipes
	hang in certain circumstances on linux
In-Reply-To: <1248229924.23.0.0654995179292.issue6542@psf.upfronthosting.co.za>
Message-ID: <1248229924.23.0.0654995179292.issue6542@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

The test sequence "test_ttk_guionly test_os test_pipes" hangs almost
every time when run on Gentoo x86 and Ubuntu x86_64 (at least).  Note
that this is without the gui resource, so the ttk tests aren't being run.

Commenting out test_closerange in TestInvalidFD in test_os clears the
hang.  Playing around with which module imports are commented out in
test_ttk_guionly can clear the hang, but test_pipes then produces the
following errors:

======================================================================
ERROR: testSimplePipe1 (test.test_pipes.SimplePipeTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/rdmurray/python/py3k/Lib/test/test_pipes.py", line 23, in
testSimplePipe1
    f = t.open(TESTFN, 'w')
  File "/home/rdmurray/python/py3k/Lib/pipes.py", line 148, in open
    return self.open_w(file)
  File "/home/rdmurray/python/py3k/Lib/pipes.py", line 168, in open_w
    return os.popen(cmd, 'w')
  File "/home/rdmurray/python/py3k/Lib/os.py", line 636, in popen
    bufsize=buffering)
  File "/home/rdmurray/python/py3k/Lib/subprocess.py", line 646, in __init__
    errread, errwrite)
  File "/home/rdmurray/python/py3k/Lib/subprocess.py", line 1138, in
_execute_child
    os.close(errpipe_read)
OSError: [Errno 9] Bad file descriptor

======================================================================
FAIL: testSimplePipe2 (test.test_pipes.SimplePipeTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/rdmurray/python/py3k/Lib/test/test_pipes.py", line 33, in
testSimplePipe2
    self.assertEqual(open(TESTFN2).read(), 'HELLO WORLD #2')
AssertionError: '' != 'HELLO WORLD #2'


The first of these appears almost every time, the second one seldom. 
Occasinally both tests pass.

----------
components: Tests
messages: 90791
nosy: r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: test_os TestInvalidFD.test_closerange causes test_pipes hang in certain circumstances on linux
type: behavior
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6542>
_______________________________________

From report at bugs.python.org  Wed Jul 22 04:33:01 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Wed, 22 Jul 2009 02:33:01 +0000
Subject: [issue6360] Simplify string decoding in xmlrpc.client.
In-Reply-To: <1246234237.97.0.0894396904771.issue6360@psf.upfronthosting.co.za>
Message-ID: <1248229981.16.0.589615554727.issue6360@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Patch committed in r74156 (branches/py3k).

----------
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6360>
_______________________________________

From report at bugs.python.org  Wed Jul 22 04:45:16 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 22 Jul 2009 02:45:16 +0000
Subject: [issue6542] test_os TestInvalidFD.test_closerange causes test_pipes
	hang in certain circumstances on linux
In-Reply-To: <1248229924.23.0.0654995179292.issue6542@psf.upfronthosting.co.za>
Message-ID: <1248230716.74.0.789548223629.issue6542@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It appears that TestInvalidFD.test_closerange is in fact closing a valid
file descriptor in this case.  I'm not sure how to fix the test...nor
why the close produced the results it does.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6542>
_______________________________________

From report at bugs.python.org  Wed Jul 22 04:52:45 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 22 Jul 2009 02:52:45 +0000
Subject: [issue6423] The cgi docs should advertize using "in" instead of
	"has_key"
In-Reply-To: <1246809932.04.0.15312988227.issue6423@psf.upfronthosting.co.za>
Message-ID: <1248231165.27.0.766666496247.issue6423@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I rephrased the doc and removed has_key at all, fixed the rst markup for
'in' and improved a little the example.
If the attached patch is ok I'll commit it.

The py3 doc is slightly different, they should probably be the same (I
prefer 'in' over '__contains__' and my version of the example, the text
is pretty much the same in both).

Georg?

----------
keywords: +needs review
stage:  -> patch review
Added file: http://bugs.python.org/file14534/issue6423.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6423>
_______________________________________

From report at bugs.python.org  Wed Jul 22 05:07:59 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Wed, 22 Jul 2009 03:07:59 +0000
Subject: [issue6241] Better type checking for the arguments of io.StringIO
In-Reply-To: <1244490422.03.0.396715163252.issue6241@psf.upfronthosting.co.za>
Message-ID: <1248232079.47.0.91362609457.issue6241@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Committed in r74157 (branches/py3k).

----------
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6241>
_______________________________________

From report at bugs.python.org  Wed Jul 22 05:10:24 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 22 Jul 2009 03:10:24 +0000
Subject: [issue6542] test_os TestInvalidFD.test_closerange causes test_pipes
	hang in certain circumstances on linux
In-Reply-To: <1248229924.23.0.0654995179292.issue6542@psf.upfronthosting.co.za>
Message-ID: <1248232224.39.0.398434418951.issue6542@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Here's another buildbot failure that's probably the same thing:

http://www.python.org/dev/buildbot/all/x86%20osx.5%203.x/builds/1220

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6542>
_______________________________________

From report at bugs.python.org  Wed Jul 22 05:25:05 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Wed, 22 Jul 2009 03:25:05 +0000
Subject: [issue6218] Make io.BytesIO and io.StringIO picklable.
In-Reply-To: <1244254875.51.0.0941712294298.issue6218@psf.upfronthosting.co.za>
Message-ID: <1248233105.29.0.975385312981.issue6218@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Committed in r74158 (branches/py3k).

----------
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6218>
_______________________________________

From report at bugs.python.org  Wed Jul 22 05:28:01 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 22 Jul 2009 03:28:01 +0000
Subject: [issue6423] The cgi docs should advertize using "in" instead of
	"has_key"
In-Reply-To: <1246809932.04.0.15312988227.issue6423@psf.upfronthosting.co.za>
Message-ID: <1248233281.7.0.320692044864.issue6423@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Your patch looks good.  I was going to opine that mentioning
__contains__ was good because it would lead the reader to understand how
'in' is supported, but since the len function is referenced but that
doesn't let you learn about __len__, you might as well be consistent and
talk about in and not __contains__.  So I'd vote for changing the 3.x
docs to match.

I agree with you about the example.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6423>
_______________________________________

From report at bugs.python.org  Wed Jul 22 05:40:01 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 22 Jul 2009 03:40:01 +0000
Subject: [issue6542] test_os TestInvalidFD.test_closerange causes test_pipes
	hang in certain circumstances on linux
In-Reply-To: <1248229924.23.0.0654995179292.issue6542@psf.upfronthosting.co.za>
Message-ID: <1248234001.14.0.124617813996.issue6542@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Patch to skip test if it can't get a range of invalid file descriptors
to test.  The test sequence passes with this patch in place.

----------
assignee:  -> r.david.murray
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file14535/issue6542.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6542>
_______________________________________

From report at bugs.python.org  Wed Jul 22 05:57:43 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Wed, 22 Jul 2009 03:57:43 +0000
Subject: [issue6151] Make PyDescr_COMMON conform to standard C
In-Reply-To: <1243725945.44.0.74609777501.issue6151@psf.upfronthosting.co.za>
Message-ID: <1248235063.46.0.974062589548.issue6151@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Committed in r74159 (branches/py3k).

----------
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6151>
_______________________________________

From report at bugs.python.org  Wed Jul 22 06:07:40 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Wed, 22 Jul 2009 04:07:40 +0000
Subject: [issue6542] test_os TestInvalidFD.test_closerange causes test_pipes
	hang in certain circumstances on linux
In-Reply-To: <1248229924.23.0.0654995179292.issue6542@psf.upfronthosting.co.za>
Message-ID: <1248235660.34.0.860471886448.issue6542@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Oh, nice catch. That patch looks fine. However, I would probably add a
comment why the fstat checks are required.

----------
nosy: +alexandre.vassalotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6542>
_______________________________________

From report at bugs.python.org  Wed Jul 22 06:15:24 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Wed, 22 Jul 2009 04:15:24 +0000
Subject: [issue4509] bugs in array.array with exports (buffer protocol)
In-Reply-To: <1228341998.62.0.651194722962.issue4509@psf.upfronthosting.co.za>
Message-ID: <1248236124.89.0.436371861808.issue4509@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Closing as I don't see any other bugs in this issue to fix.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4509>
_______________________________________

From report at bugs.python.org  Wed Jul 22 09:31:56 2009
From: report at bugs.python.org (Fan Decheng)
Date: Wed, 22 Jul 2009 07:31:56 +0000
Subject: [issue6543] traceback presented in wrong encoding
In-Reply-To: <1248247915.99.0.198197502387.issue6543@psf.upfronthosting.co.za>
Message-ID: <1248247915.99.0.198197502387.issue6543@psf.upfronthosting.co.za>


New submission from Fan Decheng <fandecheng at gmail.com>:

traceback information is wrongly encoded.
Steps to reproduce:
1. Use a version of Windows that supports CP936 (Simplified Chinese) as 
the default encoding.
2. Create a directory containing Chinese characters. Such as C:\??
3. In the directory create a python file such as C:\??\test.py
4. In the python file enter the following lines
import traceback
try:
    aaa # create a non-existent name
except Exception as ex:
    traceback.print_exc()
5. Run the program with this command line (remember to use full path to 
the test.py file):
C:\Python31\python.exe C:\??\test.py
6. See the output.

Expected result:
There is correct output without encoding problems. Such as:

Traceback (most recent call last):
  File "C:\??\test.py", line 3, in <module>
NameError: name 'aaa' is not defined

Actual result:
UTF-8 encoded string is decoded using CP936 so the output is incorrect.

Traceback (most recent call last):
  File "C:\???\test.py", line 3, in <module>
NameError: name 'aaa' is not defined

Additional information:
In Python 3.0, such test would generate:
File "<decoding error>", line 221, in main
In Python 3.1, the test generates the output mentioned in the repro 
steps.  As I tried traceback.format_exc(), it seems the original 
characters ?? have become three Unicode characters when returned by 
format_exc().

----------
components: Interpreter Core
messages: 90803
nosy: r_mosaic
severity: normal
status: open
title: traceback presented in wrong encoding
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6543>
_______________________________________

From report at bugs.python.org  Wed Jul 22 09:52:47 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 22 Jul 2009 07:52:47 +0000
Subject: [issue6544] Fix refleak in kqueue implementation
In-Reply-To: <1248249167.8.0.187501055293.issue6544@psf.upfronthosting.co.za>
Message-ID: <1248249167.8.0.187501055293.issue6544@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

This patch should fix leaking "it" in some error conditions.  Christian,
can you please review?

----------
assignee: christian.heimes
components: Extension Modules
files: select-refleak.diff
keywords: patch
messages: 90804
nosy: christian.heimes, georg.brandl
severity: normal
status: open
title: Fix refleak in kqueue implementation
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14536/select-refleak.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6544>
_______________________________________

From report at bugs.python.org  Wed Jul 22 10:41:39 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 22 Jul 2009 08:41:39 +0000
Subject: [issue6423] The cgi docs should advertize using "in" instead of
	"has_key"
In-Reply-To: <1246809932.04.0.15312988227.issue6423@psf.upfronthosting.co.za>
Message-ID: <1248252099.45.0.189737300103.issue6423@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Metoo :) Go ahead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6423>
_______________________________________

From report at bugs.python.org  Wed Jul 22 10:51:31 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 22 Jul 2009 08:51:31 +0000
Subject: [issue6545] test fails in distutils.tests.test_extensions if -O is
	used
In-Reply-To: <1248252691.19.0.260657402484.issue6545@psf.upfronthosting.co.za>
Message-ID: <1248252691.19.0.260657402484.issue6545@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

That's because the Extension class has some assert statement, I'll
remove them.

----------
assignee: tarek
components: Distutils
messages: 90806
nosy: tarek
severity: normal
status: open
title: test fails in distutils.tests.test_extensions if -O is used
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6545>
_______________________________________

From report at bugs.python.org  Wed Jul 22 11:04:36 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 22 Jul 2009 09:04:36 +0000
Subject: [issue6545] test fails in distutils.tests.test_extensions if -O is
	used
In-Reply-To: <1248252691.19.0.260657402484.issue6545@psf.upfronthosting.co.za>
Message-ID: <1248253476.76.0.173068528199.issue6545@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Fixed in r74163, r74164, r74165.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6545>
_______________________________________

From report at bugs.python.org  Wed Jul 22 12:00:40 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 22 Jul 2009 10:00:40 +0000
Subject: [issue6499] Can't import xmlrpclib,
	DocXMLRPCServer and SimpleXMLRPCServer when zlib is not available
In-Reply-To: <1247797208.72.0.744238846554.issue6499@psf.upfronthosting.co.za>
Message-ID: <1248256840.29.0.143256798074.issue6499@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

I can't reproduce this, no.  I only have access to a windows machine 
and you appear to have a custom build (no zlib).  I need your help to 
get the error message, so you need to try harder.  (there are probably 
at least two problems, one causing an exeption and one causing the 
error output to fail)

Try adding something like this into the file, after the except 
socket.timeout clause:
    except:
        import traceback
        traceback.print_exc(100, open(r"c:/tmp/err.txt", "a", 0))
        raise

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6499>
_______________________________________

From report at bugs.python.org  Wed Jul 22 13:39:33 2009
From: report at bugs.python.org (Eric Devolder)
Date: Wed, 22 Jul 2009 11:39:33 +0000
Subject: [issue2698] Extension module build fails for MinGW: missing
	vcvarsall.bat
In-Reply-To: <1209230424.66.0.154562223128.issue2698@psf.upfronthosting.co.za>
Message-ID: <1248262773.71.0.360983896079.issue2698@psf.upfronthosting.co.za>


Changes by Eric Devolder <eric.devolder at gmail.com>:


----------
nosy: +keldonin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2698>
_______________________________________

From report at bugs.python.org  Wed Jul 22 13:45:10 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 22 Jul 2009 11:45:10 +0000
Subject: [issue6525] Problem with string.lowercase in Windows XP
In-Reply-To: <1248108222.18.0.565207839087.issue6525@psf.upfronthosting.co.za>
Message-ID: <1248263110.31.0.154299212078.issue6525@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This behavior is not a bug - when setting the locale, string.lowercase
and friends are augmented by whatever the locale considers uppercase and
lowercase letters, as byte strings.  This will lead to decoding errors
when these strings are combined with Unicode strings.

Either you use string.ascii_lowercase and friends, or you make sure you
know what encoding the strings will be in, and decode accordingly.

----------
nosy: +georg.brandl
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6525>
_______________________________________

From report at bugs.python.org  Wed Jul 22 13:57:28 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 22 Jul 2009 11:57:28 +0000
Subject: [issue6540] bytearray.translate(): error in error handling
In-Reply-To: <1248221692.97.0.916983162972.issue6540@psf.upfronthosting.co.za>
Message-ID: <1248263848.34.0.791692299725.issue6540@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r74167.

----------
nosy: +georg.brandl
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6540>
_______________________________________

From report at bugs.python.org  Wed Jul 22 14:01:15 2009
From: report at bugs.python.org (Peter Landgren)
Date: Wed, 22 Jul 2009 12:01:15 +0000
Subject: [issue6525] Problem with string.lowercase in Windows XP
In-Reply-To: <1248263110.31.0.154299212078.issue6525@psf.upfronthosting.co.za>
Message-ID: <200907221403.35476.peter.talken@telia.com>


Peter Landgren <peter.talken at telia.com> added the comment:

OK,
Agreed for 2.6.

But for 2.5 many of the characters returned by string.lowercase:
?????????????????????????????????????? 
are not lowercase letters at all, but that is history now, as 2.5 is history.
We solved it by using ascii_lowercase.
Thanks,
Peter Landgren

> Georg Brandl <georg at python.org> added the comment:
>
> This behavior is not a bug - when setting the locale, string.lowercase
> and friends are augmented by whatever the locale considers uppercase and
> lowercase letters, as byte strings.  This will lead to decoding errors
> when these strings are combined with Unicode strings.
>
> Either you use string.ascii_lowercase and friends, or you make sure you
> know what encoding the strings will be in, and decode accordingly.
>
> ----------
> nosy: +georg.brandl
> resolution:  -> wont fix
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue6525>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6525>
_______________________________________

From report at bugs.python.org  Wed Jul 22 14:08:00 2009
From: report at bugs.python.org (Eric Devolder)
Date: Wed, 22 Jul 2009 12:08:00 +0000
Subject: [issue2698] Extension module build fails for MinGW: missing
	vcvarsall.bat
In-Reply-To: <1209230424.66.0.154562223128.issue2698@psf.upfronthosting.co.za>
Message-ID: <1248264480.94.0.646851709056.issue2698@psf.upfronthosting.co.za>


Eric Devolder <eric.devolder at gmail.com> added the comment:

Same problem under WinXP, using mingw compiler. Works for my package
under Python 3.0, ceases functioning under 3.1, with same error message.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2698>
_______________________________________

From report at bugs.python.org  Wed Jul 22 14:15:34 2009
From: report at bugs.python.org (Graham Dumpleton)
Date: Wed, 22 Jul 2009 12:15:34 +0000
Subject: [issue6501] Fatal LookupError: unknown encoding: cp0 on Windows
	embedded startup.
In-Reply-To: <1247826105.17.0.941734297485.issue6501@psf.upfronthosting.co.za>
Message-ID: <1248264934.06.0.302530443055.issue6501@psf.upfronthosting.co.za>


Graham Dumpleton <Graham.Dumpleton at gmail.com> added the comment:

The workaround of using:

#if defined(WIN32) && PY_MAJOR_VERSION >= 3
        _wputenv(L"PYTHONIOENCODING=cp1252:backslashreplace");
#endif

        Py_Initialize();

gets around the crash on startup.

I haven't done sufficient testing to know if this may introduce any other 
problems given that one is overriding default I/O encoding for whole 
process.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6501>
_______________________________________

From report at bugs.python.org  Wed Jul 22 16:06:56 2009
From: report at bugs.python.org (OG7)
Date: Wed, 22 Jul 2009 14:06:56 +0000
Subject: [issue6546] [Distutils][PATCH] Add bdist_rpm option to select the
	name of the resulting package
In-Reply-To: <1248271616.22.0.938348287661.issue6546@psf.upfronthosting.co.za>
Message-ID: <1248271616.22.0.938348287661.issue6546@psf.upfronthosting.co.za>


New submission from OG7 <onyxg7 at users.sourceforge.net>:

This simple Distutils patch allows choosing the name of the rpm built by
bdist_rpm.
It leaves the name of the source tarball alone, and changes the name of
the resulting spec file and rpm.

It was tested with distutils nightlies, and applies to at least python
2.5 through 2.7dev .

----------
assignee: tarek
components: Distutils
files: 0001-Add-bdist_rpm-option-to-select-the-name-of-the-resul.patch
keywords: patch
messages: 90814
nosy: OG7, tarek
severity: normal
status: open
title: [Distutils][PATCH] Add bdist_rpm option to select the name of the resulting package
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file14537/0001-Add-bdist_rpm-option-to-select-the-name-of-the-resul.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6546>
_______________________________________

From report at bugs.python.org  Wed Jul 22 17:04:20 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 22 Jul 2009 15:04:20 +0000
Subject: [issue6543] traceback presented in wrong encoding
In-Reply-To: <1248247915.99.0.198197502387.issue6543@psf.upfronthosting.co.za>
Message-ID: <1248275060.78.0.416323595668.issue6543@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This also happens on a Western Windows (cp437, mbcs==cp1252) with a
filename like "caf?.py".

The attached patch corrects three problems:

- in compile.c, the c_filename member has utf8 encoding, and must not be
decoded with PyUnicode_DecodeFSDefault. This is the reported issue.

- Same thing in pythonrun.c, if you want "print(__file__)" to work.

- in traceback.c, the content of the file is not shown.


Tested with this script:
=====================================================
print("file name:", __file__)
import traceback
try:
    aaa
except:
    traceback.print_exc()
    raise
=====================================================

The output should be:
=====================================================
file name: c:\temp\caf?.py
Traceback (most recent call last):
  File "c:\temp\caf?.py", line 4, in <module>
    aaa
NameError: name 'aaa' is not defined
Traceback (most recent call last):
  File "c:\temp\caf?.py", line 4, in <module>
    aaa
NameError: name 'aaa' is not defined
=====================================================

----------
keywords: +patch
nosy: +amaury.forgeotdarc
Added file: http://bugs.python.org/file14538/traceback-encoding.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6543>
_______________________________________

From report at bugs.python.org  Wed Jul 22 17:04:29 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 22 Jul 2009 15:04:29 +0000
Subject: [issue6543] traceback presented in wrong encoding
In-Reply-To: <1248247915.99.0.198197502387.issue6543@psf.upfronthosting.co.za>
Message-ID: <1248275069.64.0.414664920626.issue6543@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
keywords: +needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6543>
_______________________________________

From report at bugs.python.org  Wed Jul 22 17:33:44 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 22 Jul 2009 15:33:44 +0000
Subject: [issue6542] test_os TestInvalidFD.test_closerange causes test_pipes
	hang in certain circumstances on linux
In-Reply-To: <1248229924.23.0.0654995179292.issue6542@psf.upfronthosting.co.za>
Message-ID: <1248276824.4.0.494665815559.issue6542@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Applied in r74171 to py3k and r74172 to 3.1.

It occurs to me that I should backport this to trunk, so I'm leaving the
issue open until I do that.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
versions: +Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6542>
_______________________________________

From report at bugs.python.org  Wed Jul 22 17:58:31 2009
From: report at bugs.python.org (Travis H.)
Date: Wed, 22 Jul 2009 15:58:31 +0000
Subject: [issue5210] zlib does not indicate end of compressed stream properly
In-Reply-To: <1234295180.57.0.273384677161.issue5210@psf.upfronthosting.co.za>
Message-ID: <1248278311.92.0.790154297362.issue5210@psf.upfronthosting.co.za>


Travis H. <travis+w-python.org at subspacefield.org> added the comment:

What kind of tests did you have in mind?

Unit tests in python, or something else?

----------
nosy: +solinym

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5210>
_______________________________________

From report at bugs.python.org  Wed Jul 22 20:30:54 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 22 Jul 2009 18:30:54 +0000
Subject: [issue6542] test_os TestInvalidFD.test_closerange causes test_pipes
	hang in certain circumstances on linux
In-Reply-To: <1248229924.23.0.0654995179292.issue6542@psf.upfronthosting.co.za>
Message-ID: <1248287454.28.0.78688375718.issue6542@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Backported to trunk in r74175, and 2.6 in r74176.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6542>
_______________________________________

From report at bugs.python.org  Wed Jul 22 22:07:34 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 22 Jul 2009 20:07:34 +0000
Subject: [issue3754] minimal cross-compilation support for configure
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1248293254.33.0.650596531336.issue3754@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


Added file: http://bugs.python.org/file14539/python-trunk-20090722-CROSS.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3754>
_______________________________________

From report at bugs.python.org  Wed Jul 22 22:08:12 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 22 Jul 2009 20:08:12 +0000
Subject: [issue3754] minimal cross-compilation support for configure
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1248293292.22.0.601744057049.issue3754@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


Removed file: http://bugs.python.org/file12677/python-trunk.patch-CROSS-20090110

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3754>
_______________________________________

From report at bugs.python.org  Wed Jul 22 22:08:22 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 22 Jul 2009 20:08:22 +0000
Subject: [issue3754] minimal cross-compilation support for configure
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1248293302.06.0.180592260866.issue3754@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


Removed file: http://bugs.python.org/file13692/python-trunk-20090415-CROSS.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3754>
_______________________________________

From report at bugs.python.org  Wed Jul 22 22:08:29 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 22 Jul 2009 20:08:29 +0000
Subject: [issue3754] minimal cross-compilation support for configure
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1248293309.02.0.562773046219.issue3754@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


Removed file: http://bugs.python.org/file14277/python-trunk-20090612-CROSS.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3754>
_______________________________________

From report at bugs.python.org  Wed Jul 22 22:08:53 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 22 Jul 2009 20:08:53 +0000
Subject: [issue3754] minimal cross-compilation support for configure
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1248293333.37.0.876817499494.issue3754@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


----------
components: +Build
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3754>
_______________________________________

From report at bugs.python.org  Wed Jul 22 22:10:12 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 22 Jul 2009 20:10:12 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1248293412.53.0.0197313908076.issue3871@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


Added file: http://bugs.python.org/file14540/python-trunk-20090722-MINGW.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Wed Jul 22 22:10:19 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 22 Jul 2009 20:10:19 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1248293419.92.0.851792520741.issue3871@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


Removed file: http://bugs.python.org/file13089/python-trunk-20090214-MINGW.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Wed Jul 22 22:10:25 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 22 Jul 2009 20:10:25 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1248293425.26.0.310503682243.issue3871@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


Removed file: http://bugs.python.org/file13694/python-trunk-20090416-MINGW.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Wed Jul 22 22:10:31 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 22 Jul 2009 20:10:31 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1248293431.17.0.0348713292261.issue3871@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


Removed file: http://bugs.python.org/file14279/python-trunk-20090612-MINGW.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Wed Jul 22 22:12:23 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 22 Jul 2009 20:12:23 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1248293543.64.0.892753878022.issue3871@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

The last patch is updated to support build with GNU C Compiler v 4.4.0
for windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Wed Jul 22 22:35:22 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 22 Jul 2009 20:35:22 +0000
Subject: [issue5210] zlib does not indicate end of compressed stream properly
In-Reply-To: <1234295180.57.0.273384677161.issue5210@psf.upfronthosting.co.za>
Message-ID: <1248294922.37.0.00336862135593.issue5210@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Yes, I think that the right place where to add the tests is
Lib/test/test_zlib.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5210>
_______________________________________

From report at bugs.python.org  Wed Jul 22 22:50:24 2009
From: report at bugs.python.org (Timothee Besset)
Date: Wed, 22 Jul 2009 20:50:24 +0000
Subject: [issue6547] shutil.copytree fails on dangling symlinks
In-Reply-To: <1248295823.71.0.624674043377.issue6547@psf.upfronthosting.co.za>
Message-ID: <1248295823.71.0.624674043377.issue6547@psf.upfronthosting.co.za>


New submission from Timothee Besset <ttimo at idsoftware.com>:

shutil.copytree fails if there is a dangling symlink and symlink is set
to False (which is the default). It will raise an exception when trying
to get to the content of the symlink.

Tested on Debian Etch amd64, python 2.5.2

  File "/usr/lib/python2.5/shutil.py", line 138, in copytree
    raise Error, errors
shutil.Error: [('/opt/daemons/gameslave/.#fabfile.py',
'/tmp/tmphxInsp/gameslave/.#fabfile.py', "[Errno 2] No such file or
directory: '/opt/daemons/gameslave/.#fabfile.py'")]

$ ls -1l /opt/daemons/gameslave/.#fabfile.py
lrwxrwxrwx 1 timo quakelive 20 Jul 22 14:32
/opt/daemons/gameslave/.#fabfile.py -> timo at localhost.12341

(the link is created by emacs - means file being edited I'm guessing)

----------
components: Library (Lib)
messages: 90821
nosy: TTimo
severity: normal
status: open
title: shutil.copytree fails on dangling symlinks
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6547>
_______________________________________

From report at bugs.python.org  Wed Jul 22 23:21:27 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 22 Jul 2009 21:21:27 +0000
Subject: [issue6423] The cgi docs should advertize using "in" instead of
	"has_key"
In-Reply-To: <1246809932.04.0.15312988227.issue6423@psf.upfronthosting.co.za>
Message-ID: <1248297687.09.0.304784770543.issue6423@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed in r74179 (trunk) and r74180 (py3k).
Thanks!

----------
keywords:  -needs review
resolution: accepted -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6423>
_______________________________________

From report at bugs.python.org  Wed Jul 22 23:43:32 2009
From: report at bugs.python.org (Craig Holmquist)
Date: Wed, 22 Jul 2009 21:43:32 +0000
Subject: [issue4997] xml.sax.saxutils.XMLGenerator should write to
	io.RawIOBase.
In-Reply-To: <1232361357.86.0.976302026477.issue4997@psf.upfronthosting.co.za>
Message-ID: <1248299012.36.0.766144727463.issue4997@psf.upfronthosting.co.za>


Craig Holmquist <craigholm at gmail.com> added the comment:

To clarify the specific problem:

- If the file object passed to XMLGenerator is opened in binary mode,
XMLGenerator raises TypeError as soon as it tries to write to it
- If the passed file object is opened in text mode, XMLGenerator writes
the prescribed encoding to the XML declaration but it actually uses the
file object's encoding when writing everything

----------
nosy: +craigh

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4997>
_______________________________________

From report at bugs.python.org  Wed Jul 22 23:54:58 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 22 Jul 2009 21:54:58 +0000
Subject: [issue6548] cmath documentation misleading: suggests existence of
	real() and imag() functions
In-Reply-To: <1248299698.0.0.920100025533.issue6548@psf.upfronthosting.co.za>
Message-ID: <1248299698.0.0.920100025533.issue6548@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

The wording of the first section of the cmath module documentation is 
confusing:  the displayed blocks seem to suggest that there are real() and 
imag() functions.

This first section really needs a serious rewrite.  While we're at it, it 
might also be nice to separate out the cmath functions into categories, in 
the same way that the math module documentation is organized.

Also, 'complex plain' -> 'complex plane'.

----------
assignee: marketdickinson
components: Documentation
messages: 90824
nosy: marketdickinson
priority: normal
severity: normal
status: open
title: cmath documentation misleading:  suggests existence of real() and imag() functions
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6548>
_______________________________________

From report at bugs.python.org  Wed Jul 22 23:56:23 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 22 Jul 2009 21:56:23 +0000
Subject: [issue6548] cmath documentation misleading: suggests existence of
	real() and imag() functions
In-Reply-To: <1248299698.0.0.920100025533.issue6548@psf.upfronthosting.co.za>
Message-ID: <1248299783.53.0.623999734007.issue6548@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

(Thanks Andrew Spott for pointing this out on #python IRC.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6548>
_______________________________________

From report at bugs.python.org  Thu Jul 23 00:02:26 2009
From: report at bugs.python.org (Craig Holmquist)
Date: Wed, 22 Jul 2009 22:02:26 +0000
Subject: [issue4997] xml.sax.saxutils.XMLGenerator should write to
	io.RawIOBase.
In-Reply-To: <1232361357.86.0.976302026477.issue4997@psf.upfronthosting.co.za>
Message-ID: <1248300146.38.0.0332306111131.issue4997@psf.upfronthosting.co.za>


Craig Holmquist <craigholm at gmail.com> added the comment:

Patch attached.  This patch doesn't actually restrict the output object
to RawIOBase (that wouldn't work well, since files opened as binary are
actually derived from BufferedIOBase).  Instead, it just assumes the
output object has a 'write' method that accepts a single bytes argument.
 Also, XMLGenerator no longer needs to check if the input is str or unicode.

----------
keywords: +patch
Added file: http://bugs.python.org/file14541/xmlgen.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4997>
_______________________________________

From report at bugs.python.org  Thu Jul 23 00:10:51 2009
From: report at bugs.python.org (Mark Roseman)
Date: Wed, 22 Jul 2009 22:10:51 +0000
Subject: [issue6549] ttk.Style not translating some Tcl options
In-Reply-To: <1248300651.32.0.979739193906.issue6549@psf.upfronthosting.co.za>
Message-ID: <1248300651.32.0.979739193906.issue6549@psf.upfronthosting.co.za>


New submission from Mark Roseman <mark at markroseman.com>:

Just a couple of minor things which this terminal session points out


s = ttk.Style()
s.element_options('Button.label')
('-compound', '-space', '-text', '-font', '-foreground', '-underline',
'-width', '-anchor', '-justify', '-wraplength', '-embossed', '-image',
'-stipple', '-background')
s.configure('TButton', font='helvetica 24')
{}
b = ttk.Button(root)
b.configure(text='blah')



The 'element_options' call presumably shouldn't include the dashes, i.e.
'compound' rather than '-compound'

The configure call shouldn't be returning anything, akin to how configuring
a button works.

Again, just little things..

----------
components: Tkinter
messages: 90827
nosy: gpolo, markroseman
severity: normal
status: open
title: ttk.Style not translating some Tcl options
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6549>
_______________________________________

From report at bugs.python.org  Thu Jul 23 00:27:38 2009
From: report at bugs.python.org (Leon Matthews)
Date: Wed, 22 Jul 2009 22:27:38 +0000
Subject: [issue6541] SpooledTemporaryFile operates differently to TemporaryFile
In-Reply-To: <1248227663.52.0.385641131196.issue6541@psf.upfronthosting.co.za>
Message-ID: <1248301658.9.0.0550967830695.issue6541@psf.upfronthosting.co.za>


Leon Matthews <leon at lost.co.nz> added the comment:

I've attached a patch to SpooledTemporaryFile (and its test class) to
remove the suprising exceptions.

SpooledTemporaryFile uses a io.StringIO for storage (in self._file)
until it reaches a certain size (or rollover() is called), at which
point it switches to a file object (or _TemporaryFileWrapper on
non-posix platforms).  This implementation detail should be abstracted
away from the user.

The interface mismatch there which caused an AttributeError to be thrown
-- but only if the file size was new, or below a certain size.

----------
keywords: +patch
Added file: http://bugs.python.org/file14542/SpooledTemporaryFile.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6541>
_______________________________________

From report at bugs.python.org  Thu Jul 23 00:30:13 2009
From: report at bugs.python.org (Leon Matthews)
Date: Wed, 22 Jul 2009 22:30:13 +0000
Subject: [issue6541] SpooledTemporaryFile Cleanups
In-Reply-To: <1248227663.52.0.385641131196.issue6541@psf.upfronthosting.co.za>
Message-ID: <1248301813.72.0.635425951855.issue6541@psf.upfronthosting.co.za>


Changes by Leon Matthews <leon at lost.co.nz>:


----------
title: SpooledTemporaryFile operates differently to TemporaryFile -> SpooledTemporaryFile Cleanups

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6541>
_______________________________________

From report at bugs.python.org  Thu Jul 23 00:35:27 2009
From: report at bugs.python.org (Craig Holmquist)
Date: Wed, 22 Jul 2009 22:35:27 +0000
Subject: [issue4997] xml.sax.saxutils.XMLGenerator should write to
	io.RawIOBase.
In-Reply-To: <1232361357.86.0.976302026477.issue4997@psf.upfronthosting.co.za>
Message-ID: <1248302127.89.0.496967858205.issue4997@psf.upfronthosting.co.za>


Craig Holmquist <craigholm at gmail.com> added the comment:

Actually, that patch may not work so well either... out defaults to
sys.stdout, but that can't accept bytes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4997>
_______________________________________

From report at bugs.python.org  Thu Jul 23 00:37:47 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 22 Jul 2009 22:37:47 +0000
Subject: [issue6026] test_(zipfile|zipimport|gzip|distutils|sqlite) fail if
	zlib is not available
In-Reply-To: <1242349106.59.0.466065396405.issue6026@psf.upfronthosting.co.za>
Message-ID: <1248302267.65.0.777768535808.issue6026@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
dependencies:  -Can't import xmlrpclib, DocXMLRPCServer and SimpleXMLRPCServer when zlib is not available

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6026>
_______________________________________

From report at bugs.python.org  Thu Jul 23 00:42:51 2009
From: report at bugs.python.org (Nir Soffer)
Date: Wed, 22 Jul 2009 22:42:51 +0000
Subject: [issue6550] asyncore incorrect failure when connection is refused and
	using async_chat channel
In-Reply-To: <1248302571.21.0.910158552759.issue6550@psf.upfronthosting.co.za>
Message-ID: <1248302571.21.0.910158552759.issue6550@psf.upfronthosting.co.za>


New submission from Nir Soffer <nirsof at gmail.com>:

When using asynchat.async_chat channel, and connection is refused, 
asyncore fail incorrectly.

First, instead of ECONNREFUSED, you get EPIPE, second, you also get a 
EBADF exception, and finally, the channel handle_close is called  twice.

The problem is the way asyncore detect a connect event. On the first 
read event, asyncore set the connected flag to true, and invoke the 
channel handle_connect method. Typically, the channel will try to push 
something to the remote endpoint at this point. Since "connected" is 
true, push() will try to send to the socket, and fail with EPIPE, 
because the socket is not connected.

The socket error in push will invoke the channel handle_error, which 
typically will call handle_close to close the socket. 
handle_connect_event will return without any error, because the error 
was handled inside push.

Now asyncore will invoke the channel handle_read method, which fails 
with bad file descriptor, since the channel closed the socket on the 
previous error.

How should this work correctly?

1. We want to get a connection refused error in this case
2. The failure should cause only single exception
3. The channel should be close once

I added these test to test_asyncore.py, and all of them fail with 
current code.

Turns out that single line change fix all the failing tests: set the 
"connected" state after the call to handle_connect, just like it used to 
be in 2.5.

With this change, when the channel try to push something to the remote 
endpoint, it will keep it in the fifo, since connected is false. This is 
also correct, since we will know that we are connected only after 
handle_read is called. In handle_read, we fail with ECONNREFUSED and 
close the channel.

The fix is tested currently only on Mac OS X 10.5. I have seen this 
issue also on Ubuntu 9.04.

----------
components: Library (Lib)
files: asyncore-handle-connect-event.patch
keywords: patch
messages: 90830
nosy: nirs
severity: normal
status: open
title: asyncore incorrect failure when connection is refused and using async_chat channel
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14543/asyncore-handle-connect-event.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6550>
_______________________________________

From report at bugs.python.org  Thu Jul 23 00:53:28 2009
From: report at bugs.python.org (Craig Holmquist)
Date: Wed, 22 Jul 2009 22:53:28 +0000
Subject: [issue4997] xml.sax.saxutils.XMLGenerator should write to
	io.RawIOBase.
In-Reply-To: <1232361357.86.0.976302026477.issue4997@psf.upfronthosting.co.za>
Message-ID: <1248303208.29.0.528848992077.issue4997@psf.upfronthosting.co.za>


Craig Holmquist <craigholm at gmail.com> added the comment:

This new patch removes the "default to stdout" behavior.

----------
Added file: http://bugs.python.org/file14544/xmlgen2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4997>
_______________________________________

From report at bugs.python.org  Thu Jul 23 00:54:25 2009
From: report at bugs.python.org (Craig Holmquist)
Date: Wed, 22 Jul 2009 22:54:25 +0000
Subject: [issue4997] xml.sax.saxutils.XMLGenerator should write to
	io.RawIOBase.
In-Reply-To: <1232361357.86.0.976302026477.issue4997@psf.upfronthosting.co.za>
Message-ID: <1248303265.03.0.733337845663.issue4997@psf.upfronthosting.co.za>


Craig Holmquist <craigholm at gmail.com> added the comment:

Patch for documentation.

----------
Added file: http://bugs.python.org/file14545/xmlgen-doc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4997>
_______________________________________

From report at bugs.python.org  Thu Jul 23 00:56:09 2009
From: report at bugs.python.org (Craig Holmquist)
Date: Wed, 22 Jul 2009 22:56:09 +0000
Subject: [issue4997] xml.sax.saxutils.XMLGenerator should write to
	io.RawIOBase.
In-Reply-To: <1232361357.86.0.976302026477.issue4997@psf.upfronthosting.co.za>
Message-ID: <1248303369.29.0.702587807914.issue4997@psf.upfronthosting.co.za>


Changes by Craig Holmquist <craigholm at gmail.com>:


Removed file: http://bugs.python.org/file14541/xmlgen.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4997>
_______________________________________

From report at bugs.python.org  Thu Jul 23 00:59:09 2009
From: report at bugs.python.org (Leon Matthews)
Date: Wed, 22 Jul 2009 22:59:09 +0000
Subject: [issue6541] SpooledTemporaryFile cleanups
In-Reply-To: <1248227663.52.0.385641131196.issue6541@psf.upfronthosting.co.za>
Message-ID: <1248303549.73.0.10498587889.issue6541@psf.upfronthosting.co.za>


Changes by Leon Matthews <leon at lost.co.nz>:


----------
title: SpooledTemporaryFile Cleanups -> SpooledTemporaryFile cleanups

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6541>
_______________________________________

From report at bugs.python.org  Thu Jul 23 01:05:38 2009
From: report at bugs.python.org (Leon Matthews)
Date: Wed, 22 Jul 2009 23:05:38 +0000
Subject: [issue6541] SpooledTemporaryFile cleanups
In-Reply-To: <1248227663.52.0.385641131196.issue6541@psf.upfronthosting.co.za>
Message-ID: <1248303938.8.0.0396452746091.issue6541@psf.upfronthosting.co.za>


Leon Matthews <leon at lost.co.nz> added the comment:

Some properties seem to be broken no matter if the underlying storage
system is file or StringIO.

Properties: encoding, newlines, and softspace

And the method: xreadlines()

I'm not sure what the correct behaviour should be (although I'm pretty
sure xreadlines() should just be deleted -- but when?), so I haven't
tried to patch the code.  The attached patch is a just (a beginners idea
of a) test to confirm the problem.

----------
Added file: http://bugs.python.org/file14546/really-broken-properties-methods.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6541>
_______________________________________

From report at bugs.python.org  Thu Jul 23 01:08:10 2009
From: report at bugs.python.org (Leon Matthews)
Date: Wed, 22 Jul 2009 23:08:10 +0000
Subject: [issue6541] SpooledTemporaryFile breakages
In-Reply-To: <1248227663.52.0.385641131196.issue6541@psf.upfronthosting.co.za>
Message-ID: <1248304090.06.0.489457622089.issue6541@psf.upfronthosting.co.za>


Changes by Leon Matthews <leon at lost.co.nz>:


----------
title: SpooledTemporaryFile cleanups -> SpooledTemporaryFile breakages

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6541>
_______________________________________

From report at bugs.python.org  Thu Jul 23 01:17:04 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 22 Jul 2009 23:17:04 +0000
Subject: [issue6499] Can't import xmlrpclib,
	DocXMLRPCServer and SimpleXMLRPCServer when zlib is not available
In-Reply-To: <1247797208.72.0.744238846554.issue6499@psf.upfronthosting.co.za>
Message-ID: <1248304624.03.0.475825043675.issue6499@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I tried that too, with no results.

However using advanced debugging techniques I found something new. I
added 3 prints in the finally, one before serv.server_close(), one
after, and the last at the end, after evt.set().
The first two works, the third one sometimes doesn't (i.e. nothing is
printed), even if no errors are displayed.

I'm not 100% sure but at some point I think I saw the third message
being printed at the beginning, before the first. But now I can't
reproduce it anymore.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6499>
_______________________________________

From report at bugs.python.org  Thu Jul 23 01:42:54 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 22 Jul 2009 23:42:54 +0000
Subject: [issue6499] Can't import xmlrpclib,
	DocXMLRPCServer and SimpleXMLRPCServer when zlib is not available
In-Reply-To: <1247797208.72.0.744238846554.issue6499@psf.upfronthosting.co.za>
Message-ID: <1248306174.2.0.369162102747.issue6499@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I tried to remove the first two prints (I reverted the file and the only
difference with the original was the print after evt.set() (that here
didn't print anything)) and I got something better:

$ ./python Lib/test/regrtest.py -v test_docxmlrpc
test_docxmlrpc
test_valid_get_response (test.test_docxmlrpc.DocXMLRPCHTTPGETServer) ... ok

----------------------------------------------------------------------
Ran 1 test in 0.063s

OK
1 test OK.
Exception in thread Thread-1 (most likely raised during interpreter
shutdown):
Traceback (most recent call last):
  File "/home/wolf/python-trunk/Lib/threading.py", line 524, in
__bootstrap_inner
  File "/home/wolf/python-trunk/Lib/threading.py", line 477, in run
  File "/home/wolf/python-trunk/Lib/test/test_docxmlrpc.py", line 55, in
server
<type 'exceptions.AttributeError'>: 'NoneType' object has no attribute
'write'
Unhandled exception in thread started by
Error in sys.excepthook:

Original exception was:

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6499>
_______________________________________

From report at bugs.python.org  Thu Jul 23 02:08:46 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 23 Jul 2009 00:08:46 +0000
Subject: [issue6525] Problem with string.lowercase in Windows XP
In-Reply-To: <1248108222.18.0.565207839087.issue6525@psf.upfronthosting.co.za>
Message-ID: <1248307726.64.0.430170083912.issue6525@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I did some test as well and here is what I got:
Python2.4 WinXP:
>>> import locale
>>> import string
>>> locale.setlocale(locale.LC_ALL, '')
'Italian_Italy.1252'
>>> string.lowercase
'abcdefghijklmnopqrstuvwxyz\x83\x9a\x9c\x9e\xaa\xb5\xba\xdf\xe0\xe1\xe2\xe3\xe4\xe5\xe6\xe7\xe8\xe9\xea\xeb\xec\xed\xee\xef\xf0\xf1\xf2\xf3\xf4\xf5\xf6\xf8\xf9\xfa\xfb\xfc\xfd\xfe\xff'
>>> print string.lowercase
abcdefghijklmnopqrstuvwxyz???????????????????????????????????????
>>> import unicodedata
>>> set(map(unicodedata.category, string.lowercase.decode('windows-1252')))
set(['Ll'])

Python2.6 WinXP:
>>> import locale
>>> import string
>>> locale.setlocale(locale.LC_ALL, '')
'Italian_Italy.1252'
>>> string.lowercase
'abcdefghijklmnopqrstuvwxyz\x83\x9a\x9c\x9e\xaa\xb5\xba\xdf\xe0\xe1\xe2\xe3\xe4\xe5\xe6\xe7\xe8\xe9\xea\xeb\xec\xed\xee\xef\xf0\xf1\xf2\xf3\xf4\xf5\xf6\xf8\xf9\xfa\xfb\xfc\xfd\xfe\xff'
>>> print string.lowercase
abcdefghijklmnopqrstuvwxyz?soz???????????????????????????????????
>>> import unicodedata
>>> set(map(unicodedata.category, string.lowercase.decode('windows-1252')))
set(['Ll'])

As you can see both the strings are equivalent and all the chars
correctly belong to the Ll (letter, lowercase) Unicode category. For
some reason they look different only when they are printed.

If these chars are not added to string.lowercase on Linux when you
change the locale, then it's a bug.
Can you reproduce it with recent versions of Python?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6525>
_______________________________________

From report at bugs.python.org  Thu Jul 23 02:12:13 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 23 Jul 2009 00:12:13 +0000
Subject: [issue6548] cmath documentation misleading: suggests existence of
	real() and imag() functions
In-Reply-To: <1248299698.0.0.920100025533.issue6548@psf.upfronthosting.co.za>
Message-ID: <1248307933.66.0.743236325475.issue6548@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6548>
_______________________________________

From report at bugs.python.org  Thu Jul 23 07:31:08 2009
From: report at bugs.python.org (Peter Bray)
Date: Thu, 23 Jul 2009 05:31:08 +0000
Subject: [issue6029] FAIL: test_longdouble
	(ctypes.test.test_callbacks.Callbacks) [SPARC/64-bit]
In-Reply-To: <1242377349.19.0.984337506616.issue6029@psf.upfronthosting.co.za>
Message-ID: <1248327068.58.0.914193265388.issue6029@psf.upfronthosting.co.za>


Peter Bray <pdb_ml at yahoo.com.au> added the comment:

Sorry for the internet lifetime I've been away.

I have tested the patch provided against the released 3.1 distribution
and all tests pass without coredumping or failing on Solaris 10 Update 6
with gcc 4.1.2. The 3.1 distribution with the patch was built and tested
on both 32-bit and 64-bit SPARC and X86.

The patch was rejected by GNU patch, but applying by hand (copy/paste)
worked fine against 3.1.

Like the patch's author I can't say if this right approach to take, that
is for others to say but it does not break any of my builds.

Regards,
Peter

And sorry for the delay.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6029>
_______________________________________

From report at bugs.python.org  Thu Jul 23 07:55:54 2009
From: report at bugs.python.org (Martien Friedeman)
Date: Thu, 23 Jul 2009 05:55:54 +0000
Subject: [issue6552] Build Applet.app
In-Reply-To: <1248328554.77.0.248074125198.issue6552@psf.upfronthosting.co.za>
Message-ID: <1248328554.77.0.248074125198.issue6552@psf.upfronthosting.co.za>


New submission from Martien Friedeman <martien.friedeman at gmail.com>:

Hi Python maintainer!

I did not see a "Build Applet.app" in 
http://www.python.org/ftp/python/3.1/python-3.1.dmg.

Could you add one please? They're great to start programs with.

Cheers
Martien Friedeman

----------
assignee: ronaldoussoren
components: Macintosh
messages: 90839
nosy: MartienF, ronaldoussoren
severity: normal
status: open
title: Build Applet.app
type: feature request
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6552>
_______________________________________

From report at bugs.python.org  Thu Jul 23 05:17:06 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Thu, 23 Jul 2009 03:17:06 +0000
Subject: [issue6551] test_codecs fails when ran after test_zipimport and
	test_mailbox.
In-Reply-To: <1248318273.86.0.60176603488.issue6551@psf.upfronthosting.co.za>
Message-ID: <1248319026.63.0.62269987693.issue6551@psf.upfronthosting.co.za>


Changes by Alexandre Vassalotti <alexandre at peadrop.com>:


Added file: http://bugs.python.org/file14549/testcase3.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6551>
_______________________________________

From report at bugs.python.org  Thu Jul 23 05:17:45 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Thu, 23 Jul 2009 03:17:45 +0000
Subject: [issue6551] test_codecs fails when ran after test_zipimport and
	test_mailbox.
In-Reply-To: <1248318273.86.0.60176603488.issue6551@psf.upfronthosting.co.za>
Message-ID: <1248319065.93.0.0449516552193.issue6551@psf.upfronthosting.co.za>


Changes by Alexandre Vassalotti <alexandre at peadrop.com>:


Added file: http://bugs.python.org/file14550/testcase4.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6551>
_______________________________________

From report at bugs.python.org  Thu Jul 23 05:12:18 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Thu, 23 Jul 2009 03:12:18 +0000
Subject: [issue6551] test_codecs fails when ran after test_zipimport and
	test_mailbox.
In-Reply-To: <1248318273.86.0.60176603488.issue6551@psf.upfronthosting.co.za>
Message-ID: <1248318738.85.0.625893628168.issue6551@psf.upfronthosting.co.za>


Changes by Alexandre Vassalotti <alexandre at peadrop.com>:


Added file: http://bugs.python.org/file14547/testcase1.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6551>
_______________________________________

From report at bugs.python.org  Thu Jul 23 05:04:34 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Thu, 23 Jul 2009 03:04:34 +0000
Subject: [issue6551] test_codecs fails when ran after test_zipimport and
	test_mailbox.
In-Reply-To: <1248318273.86.0.60176603488.issue6551@psf.upfronthosting.co.za>
Message-ID: <1248318273.86.0.60176603488.issue6551@psf.upfronthosting.co.za>


New submission from Alexandre Vassalotti <alexandre at peadrop.com>:

For some yet unknown reason, test_codecs fails when it is run after
test_zipimport and subsequently test_mailbox:

./python Lib/test/regrtest.py -w test_zipimport test_mailbox test_codecs
[SNIP]
======================================================================
ERROR: test_basics (test.test_codecs.BasicUnicodeTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/alex/src/python.org/py3k/Lib/test/test_codecs.py", line
1360, in test_basics
    encodedresult += encoder.encode(c)
  File "/home/alex/src/python.org/py3k/Lib/encodings/ascii.py", line 22,
in encode
    return codecs.ascii_encode(input, self.errors)[0]
AttributeError: 'NoneType' object has no attribute 'ascii_encode'

======================================================================
ERROR: test_decoder_state (test.test_codecs.BasicUnicodeTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/alex/src/python.org/py3k/Lib/test/test_codecs.py", line
1445, in test_decoder_state
    self.check_state_handling_decode(encoding, u, u.encode(encoding))
  File "/home/alex/src/python.org/py3k/Lib/test/test_codecs.py", line
30, in check_state_handling_decode
    part1 = d.decode(s[:i])
  File "/home/alex/src/python.org/py3k/Lib/encodings/ascii.py", line 26,
in decode
    return codecs.ascii_decode(input, self.errors)[0]
AttributeError: 'NoneType' object has no attribute 'ascii_decode'

----------------------------------------------------------------------
Ran 121 tests in 0.204s

FAILED (errors=2)
test test_codecs failed -- errors occurred; run in verbose mode for details

----------
components: Tests
messages: 90837
nosy: alexandre.vassalotti
priority: normal
severity: normal
stage: needs patch
status: open
title: test_codecs fails when ran after test_zipimport and test_mailbox.
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6551>
_______________________________________

From report at bugs.python.org  Thu Jul 23 05:13:27 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Thu, 23 Jul 2009 03:13:27 +0000
Subject: [issue6551] test_codecs fails when ran after test_zipimport and
	test_mailbox.
In-Reply-To: <1248318273.86.0.60176603488.issue6551@psf.upfronthosting.co.za>
Message-ID: <1248318807.18.0.849985034117.issue6551@psf.upfronthosting.co.za>


Changes by Alexandre Vassalotti <alexandre at peadrop.com>:


Added file: http://bugs.python.org/file14548/testcase2.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6551>
_______________________________________

From report at bugs.python.org  Thu Jul 23 09:09:35 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 23 Jul 2009 07:09:35 +0000
Subject: [issue6548] cmath documentation misleading: suggests existence of
	real() and imag() functions
In-Reply-To: <1248299698.0.0.920100025533.issue6548@psf.upfronthosting.co.za>
Message-ID: <1248332975.37.0.156288232502.issue6548@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed the trivial stuff in r74184. Leaving open for the suggested rewrite.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6548>
_______________________________________

From report at bugs.python.org  Thu Jul 23 09:16:17 2009
From: report at bugs.python.org (Peter Landgren)
Date: Thu, 23 Jul 2009 07:16:17 +0000
Subject: [issue6525] Problem with string.lowercase in Windows XP
In-Reply-To: <1248307726.64.0.430170083912.issue6525@psf.upfronthosting.co.za>
Message-ID: <200907230918.46025.peter.talken@telia.com>


Peter Landgren <peter.talken at telia.com> added the comment:

Obviously, 2.5 and 2.6 decode the "string.lowercase"  when print is used and 2.6 seems to 
be the correct.

Yes. I get exactly the same result in both
Python 2.5.2 (r252:60911, Jan  8 2009, 12:17:37)
and
Python 2.6.2 (r262:71600, Jul 23 2009, 09:01:02)
showing that string.lowercase does NOT change with locale.

'sv_SE.UTF-8'
>>> a = string.lowercase
>>> len(a)
26
>>> a
'abcdefghijklmnopqrstuvwxyz'
>>> print a
abcdefghijklmnopqrstuvwxyz
>>> string.ascii_lowercase == string.lowercase
True
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6525>
_______________________________________

From report at bugs.python.org  Thu Jul 23 11:25:19 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 23 Jul 2009 09:25:19 +0000
Subject: [issue6548] cmath documentation misleading: suggests existence of
	real() and imag() functions
In-Reply-To: <1248299698.0.0.920100025533.issue6548@psf.upfronthosting.co.za>
Message-ID: <1248341119.91.0.0067765414999.issue6548@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a proposed rewrite, as a patch against the trunk documentation.  
Comments welcome!

----------
assignee: marketdickinson -> georg.brandl
keywords: +patch
Added file: http://bugs.python.org/file14551/cmath_rewrite.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6548>
_______________________________________

From report at bugs.python.org  Thu Jul 23 13:21:04 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 23 Jul 2009 11:21:04 +0000
Subject: [issue6548] cmath documentation misleading: suggests existence of
	real() and imag() functions
In-Reply-To: <1248299698.0.0.920100025533.issue6548@psf.upfronthosting.co.za>
Message-ID: <1248348064.16.0.766617851138.issue6548@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Looks good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6548>
_______________________________________

From report at bugs.python.org  Thu Jul 23 15:35:55 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 23 Jul 2009 13:35:55 +0000
Subject: [issue6551] test_codecs fails when ran after test_zipimport and
	test_mailbox.
In-Reply-To: <1248318273.86.0.60176603488.issue6551@psf.upfronthosting.co.za>
Message-ID: <1248356155.8.0.736843787687.issue6551@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

When the zipimport test is run, encodings.ascii is imported.  Then it is
removed from sys.modules by the test cleanup.  When the mailbox test is
run, it is reimported.  However, when the codecs test tries to use it,
the encodings.ascii module has been finalized (as if during interpreter
shutdown) by having all its globals set to None.  Thus the test failure.

I haven't figured out why this is happening yet, but it seems likely
that the issue is either with zipimport or with the zipimport test
cleanup.  I'm guessing that anything that triggers encodings.ascii to be
loaded before test_codecs tries to use it will trigger the bug, but I
haven't tested that theory yet.

----------
nosy: +r.david.murray
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6551>
_______________________________________

From report at bugs.python.org  Thu Jul 23 15:52:42 2009
From: report at bugs.python.org (irek)
Date: Thu, 23 Jul 2009 13:52:42 +0000
Subject: [issue6106] read_until
In-Reply-To: <1243267985.99.0.238483902734.issue6106@psf.upfronthosting.co.za>
Message-ID: <1248357162.79.0.0366089207231.issue6106@psf.upfronthosting.co.za>


irek <irczan at gmail.com> added the comment:

Hi, 
I head same problem on 3.0 and 3.1 versions
This was because of incompatibility of types in comparison 

My solution is to modify 
Lib/telnetlib.py   
line  462
cmd = self.iacseq[1]
 to 
cmd = self.iacseq[1:2]

Irek

----------
nosy: +irczan
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6106>
_______________________________________

From report at bugs.python.org  Thu Jul 23 15:59:28 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 23 Jul 2009 13:59:28 +0000
Subject: [issue6551] test_codecs fails when ran after test_zipimport and
	test_mailbox.
In-Reply-To: <1248318273.86.0.60176603488.issue6551@psf.upfronthosting.co.za>
Message-ID: <1248357568.42.0.6216850638.issue6551@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

A simple solution could be to import encodings.ascii in regrtest.py,
before it saves the list of modules.

Or, since codecs are stored in a global cache dictionary that cannot be
cleared (interp->codec_search_cache), avoid unloading modules from the
encodings package.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6551>
_______________________________________

From report at bugs.python.org  Thu Jul 23 17:15:19 2009
From: report at bugs.python.org (Patrick Strawderman)
Date: Thu, 23 Jul 2009 15:15:19 +0000
Subject: [issue6553] cPickle "binunicode" segmentation fault
In-Reply-To: <1248362119.25.0.536343582132.issue6553@psf.upfronthosting.co.za>
Message-ID: <1248362119.25.0.536343582132.issue6553@psf.upfronthosting.co.za>


New submission from Patrick Strawderman <patrick at zope.com>:

When reading from a file-like object (like StringIO), cPickle uses the
read_other function, which doesn't check that the number of bytes
requested is the actual number of bytes read (like the read_cStringIO
function does).

Functions like load_binunicode falsely assume that the number of bytes
specified after the BINUNICODE instruction are the actual number of
bytes read.  This can eventually lead to a segmentation fault, as
demonstrated in the following example:

import cPickle, StringIO

cPickle.Unpickler(StringIO.StringIO("X''.")).load()


I have tested and reproduced this on Python 2.4.6 (OS X 32-bit), 2.5.1
(OS X 32-bit), and 2.6.2 (Linux 64-bit).

I have not tested Python 3.x, but I believe this problem may be akin to
the one in issue4298.

----------
messages: 90847
nosy: boogenhagn
severity: normal
status: open
title: cPickle "binunicode" segmentation fault
versions: Python 2.4, Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6553>
_______________________________________

From report at bugs.python.org  Thu Jul 23 17:41:34 2009
From: report at bugs.python.org (jan matejek)
Date: Thu, 23 Jul 2009 15:41:34 +0000
Subject: [issue5103] ssl.SSLSocket timeout not working correctly when remote
	end is hanging
In-Reply-To: <1233269067.88.0.11384047057.issue5103@psf.upfronthosting.co.za>
Message-ID: <1248363694.83.0.916230989823.issue5103@psf.upfronthosting.co.za>


Changes by jan matejek <jmatejek at suse.cz>:


----------
nosy: +matejcik

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5103>
_______________________________________

From report at bugs.python.org  Thu Jul 23 18:44:09 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 23 Jul 2009 16:44:09 +0000
Subject: [issue6553] cPickle "binunicode" segmentation fault
In-Reply-To: <1248362119.25.0.536343582132.issue6553@psf.upfronthosting.co.za>
Message-ID: <1248367449.52.0.193999572102.issue6553@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Attached patch fixes the problem.

----------
assignee:  -> amaury.forgeotdarc
keywords: +patch
nosy: +amaury.forgeotdarc
Added file: http://bugs.python.org/file14552/pickle_badinput.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6553>
_______________________________________

From report at bugs.python.org  Thu Jul 23 18:44:47 2009
From: report at bugs.python.org (Pal Subbiah)
Date: Thu, 23 Jul 2009 16:44:47 +0000
Subject: [issue6106] read_until
In-Reply-To: <1243267985.99.0.238483902734.issue6106@psf.upfronthosting.co.za>
Message-ID: <1248367487.08.0.200440417738.issue6106@psf.upfronthosting.co.za>


Pal Subbiah <pal.subbiah at gmail.com> added the comment:

Thanks Irek. It works so well now after I modified the telnetlib.py as
you suggested. I also added decode('ascii') with read_until.

Pal Subbiah

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6106>
_______________________________________

From report at bugs.python.org  Thu Jul 23 20:28:35 2009
From: report at bugs.python.org (Patricio Mariano Molina)
Date: Thu, 23 Jul 2009 18:28:35 +0000
Subject: [issue6554] Do we have something like os.pid_exists()?
In-Reply-To: <1248373715.48.0.616687111663.issue6554@psf.upfronthosting.co.za>
Message-ID: <1248373715.48.0.616687111663.issue6554@psf.upfronthosting.co.za>


New submission from Patricio Mariano Molina <patriciomolina at gmail.com>:

I couldn't find anything like os.pid_exists() in Python 2.5/2.6, neither
in bugs.python.org (this *could* be a dupe)

Do we have something like that?

Right now I'm doing this:

try:
    os.kill(int(pid), 0)
    return True
except OSError:
    return False

I'd love to do the same without catching an exception (they're
expensive!), maybe in C?

Thanks!

----------
components: Library (Lib)
messages: 90850
nosy: pmolina
severity: normal
status: open
title: Do we have something like os.pid_exists()?
type: feature request
versions: Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6554>
_______________________________________

From report at bugs.python.org  Thu Jul 23 20:31:16 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 23 Jul 2009 18:31:16 +0000
Subject: [issue6554] Do we have something like os.pid_exists()?
In-Reply-To: <1248373715.48.0.616687111663.issue6554@psf.upfronthosting.co.za>
Message-ID: <1248373876.68.0.42793154148.issue6554@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

This is quite a microoptimization.  Why do you think you need to avoid
the exception here?

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6554>
_______________________________________

From report at bugs.python.org  Thu Jul 23 20:35:02 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 23 Jul 2009 18:35:02 +0000
Subject: [issue6554] Do we have something like os.pid_exists()?
In-Reply-To: <1248373715.48.0.616687111663.issue6554@psf.upfronthosting.co.za>
Message-ID: <1248374102.09.0.57824528345.issue6554@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

For what it's worth, here are some timings from my system.  First,
os.kill without raising an exception:

exarkun at boson:~$ python -m timeit -s 'import os; pid = os.getpid()' '
os.kill(pid, 0)
'
1000000 loops, best of 3: 0.413 usec per loop
exarkun at boson:~$ 

Next, os.kill without raising an exception, but with exception handling:

exarkun at boson:~$ python -m timeit -s 'import os; pid = os.getpid()' '
> try:
>     os.kill(pid, 0)
> except OSError, e:
>     pass
> '
1000000 loops, best of 3: 0.42 usec per loop

Finally, os.kill with exception handling and raising an exception:

exarkun at boson:~$ python -m timeit -s 'import os; pid = os.getpid()' '
try:
    os.kill(pid + 1, 0)
except OSError, e:
    pass
'
100000 loops, best of 3: 2.58 usec per loop

The slowest case is almost 7x slower than the fastest case.  However,
this is only triggered when os.kill raises an exception (ie, if the pid
does exist, it's still fast).  Plus, this "slow" case still only takes
two and a half microseconds.  That's pretty fast.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6554>
_______________________________________

From report at bugs.python.org  Thu Jul 23 20:40:54 2009
From: report at bugs.python.org (Nir Soffer)
Date: Thu, 23 Jul 2009 18:40:54 +0000
Subject: [issue6550] asyncore incorrect failure when connection is refused and
	using async_chat channel
In-Reply-To: <1248302571.21.0.910158552759.issue6550@psf.upfronthosting.co.za>
Message-ID: <1248374454.45.0.238514659416.issue6550@psf.upfronthosting.co.za>


Nir Soffer <nirsof at gmail.com> added the comment:

The patch is tested with release26-maint and trunk.

----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6550>
_______________________________________

From report at bugs.python.org  Thu Jul 23 20:47:11 2009
From: report at bugs.python.org (Patricio Mariano Molina)
Date: Thu, 23 Jul 2009 18:47:11 +0000
Subject: [issue6554] Do we have something like os.pid_exists()?
In-Reply-To: <1248373715.48.0.616687111663.issue6554@psf.upfronthosting.co.za>
Message-ID: <1248374831.43.0.429398491995.issue6554@psf.upfronthosting.co.za>


Patricio Mariano Molina <patriciomolina at gmail.com> added the comment:

Hey Jean-Paul, thanks for the quick reply!

You're right, but I wasn't thinking too much about optimization: I think
it would be useful to have that simple function, returning True or False.

I use to search for active PIDs *a lot* with Python

Do you think is a "YAGNI" case?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6554>
_______________________________________

From report at bugs.python.org  Thu Jul 23 20:50:22 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 23 Jul 2009 18:50:22 +0000
Subject: [issue6554] Do we have something like os.pid_exists()?
In-Reply-To: <1248373715.48.0.616687111663.issue6554@psf.upfronthosting.co.za>
Message-ID: <1248375022.61.0.873671789274.issue6554@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

It might be better to pick a better (but probably platform-specific) API
for such a use-case.  os.kill has a problem with false positives (on
Linux it will tell you a process exists even when it doesn't).  Looking
in /proc/ or using a Windows API to enumerate all existing processes
might be better.  These have the advantage of giving you a bunch of PID
information all at once which you can then check against, rather than
repeatedly making syscalls.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6554>
_______________________________________

From report at bugs.python.org  Thu Jul 23 20:56:25 2009
From: report at bugs.python.org (Patricio Mariano Molina)
Date: Thu, 23 Jul 2009 18:56:25 +0000
Subject: [issue6554] Do we have something like os.pid_exists()?
In-Reply-To: <1248373715.48.0.616687111663.issue6554@psf.upfronthosting.co.za>
Message-ID: <1248375385.83.0.360542891655.issue6554@psf.upfronthosting.co.za>


Patricio Mariano Molina <patriciomolina at gmail.com> added the comment:

Sounds good. And what do you think about os.pid_exists() using /proc/ or
a Windows API?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6554>
_______________________________________

From report at bugs.python.org  Thu Jul 23 21:04:13 2009
From: report at bugs.python.org (Nir Soffer)
Date: Thu, 23 Jul 2009 19:04:13 +0000
Subject: [issue5262] PythonLauncher considered harmfull
In-Reply-To: <1234638505.38.0.029039550018.issue5262@psf.upfronthosting.co.za>
Message-ID: <1248375853.11.0.28968267091.issue5262@psf.upfronthosting.co.za>


Nir Soffer <nirsof at gmail.com> added the comment:

I also think it should be removed. Opening a file should run it only if it 
is executable.

----------
nosy: +nirs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5262>
_______________________________________

From report at bugs.python.org  Thu Jul 23 21:11:47 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 23 Jul 2009 19:11:47 +0000
Subject: [issue5262] PythonLauncher considered harmfull
In-Reply-To: <1234638505.38.0.029039550018.issue5262@psf.upfronthosting.co.za>
Message-ID: <1248376307.82.0.607880277941.issue5262@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

At the very least PythonLauncher should not be the default for opening 
python files, and should actively warn against being the default 
(basicly reversing the current default).

When PythonLauncher is the default application for .py files double-
clicking a .py file, or opening it from Mail.app will run the script. 
This is not what I'd expect when opening a source file and is risky when 
this happens accidently.

There are several ways for running python scripts by double-clicking on 
them. Two examples:

* Use py2app to create an .app bundle

* Give the script a ".command" suffix and a '#!/usr/bin/python' prefix.

Both result in "files" where it is clear that opening them will result 
in code execution.

----------
versions: +Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5262>
_______________________________________

From report at bugs.python.org  Thu Jul 23 21:14:02 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 23 Jul 2009 19:14:02 +0000
Subject: [issue6554] Do we have something like os.pid_exists()?
In-Reply-To: <1248373715.48.0.616687111663.issue6554@psf.upfronthosting.co.za>
Message-ID: <1248376442.83.0.261320689672.issue6554@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

The os module is mostly for wrappers around native platform APIs.  So at
the very least, I don't think such an API belongs there.  It would fit
in to a general process-related module, perhaps.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6554>
_______________________________________

From report at bugs.python.org  Thu Jul 23 22:07:15 2009
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Thu, 23 Jul 2009 20:07:15 +0000
Subject: [issue6555] distutils config file should have the same name on both
	platforms and all scopes
In-Reply-To: <1248379635.87.0.00387112145543.issue6555@psf.upfronthosting.co.za>
Message-ID: <1248379635.87.0.00387112145543.issue6555@psf.upfronthosting.co.za>


New submission from Zooko O'Whielacronx <zooko at zooko.com>:

Currently we have this:

http://docs.python.org/install/#location-and-names-of-config-files

The distutils config file can have one of four different names depending
on which platform and which location.  This makes it harder for people
to remember the file's name and location, and more complicated for
programs that want to detect it.  Why not give it the same name on both
platforms and all locations?

----------
assignee: tarek
components: Distutils
messages: 90860
nosy: tarek, zooko
severity: normal
status: open
title: distutils config file should have the same name on both platforms and all scopes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6555>
_______________________________________

From report at bugs.python.org  Thu Jul 23 22:09:21 2009
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Thu, 23 Jul 2009 20:09:21 +0000
Subject: [issue6556] "HOME" is not a standard environment variable on Windows
In-Reply-To: <1248379761.36.0.601035706586.issue6556@psf.upfronthosting.co.za>
Message-ID: <1248379761.36.0.601035706586.issue6556@psf.upfronthosting.co.za>


New submission from Zooko O'Whielacronx <zooko at zooko.com>:

The distutils looks in an environment variable named "HOME" on Windows:

http://docs.python.org/install/#location-and-names-of-config-files

Windows does not by default create such a variable, so only if a user
has manually configured one will it work.  The standard variable for
this purpose on Windows appears to be spelled "USERPROFILE":

http://en.wikipedia.org/wiki/Environment_variable

----------
assignee: tarek
components: Distutils
messages: 90861
nosy: tarek, zooko
severity: normal
status: open
title: "HOME" is not a standard environment variable on Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6556>
_______________________________________

From report at bugs.python.org  Thu Jul 23 22:14:25 2009
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Thu, 23 Jul 2009 20:14:25 +0000
Subject: [issue6555] distutils config file should have the same name on both
	platforms and all scopes
In-Reply-To: <1248379635.87.0.00387112145543.issue6555@psf.upfronthosting.co.za>
Message-ID: <1248380064.98.0.754848733471.issue6555@psf.upfronthosting.co.za>


Zooko O'Whielacronx <zooko at zooko.com> added the comment:

I was spurred to write this ticket today because of a conversation with
J.P. Calderone:

<exarkun> but, I have no clue where distutils.cfg goes on Windows

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6555>
_______________________________________

From report at bugs.python.org  Thu Jul 23 22:25:36 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 23 Jul 2009 20:25:36 +0000
Subject: [issue6549] ttk.Style not translating some Tcl options
In-Reply-To: <1248300651.32.0.979739193906.issue6549@psf.upfronthosting.co.za>
Message-ID: <1248380736.56.0.654413587634.issue6549@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Hi Mark,

I don't think I remember very well where those element options are used.
For instance, where can you use the 'embossed' option ? Would it be only
when using style.configure/style.map with '.' as the style name ?

Knowing that would help to know if the proposed change will affect
something else (and if different/new tests should be added).

----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6549>
_______________________________________

From report at bugs.python.org  Thu Jul 23 23:52:49 2009
From: report at bugs.python.org (Till Maas)
Date: Thu, 23 Jul 2009 21:52:49 +0000
Subject: [issue6557] urllib.urlopen creates bad requests when location header
	of 301 redirects contain spaces
In-Reply-To: <1248385969.73.0.0313821964129.issue6557@psf.upfronthosting.co.za>
Message-ID: <1248385969.73.0.0313821964129.issue6557@psf.upfronthosting.co.za>


New submission from Till Maas <opensource at till.name>:

If urllib.urlopen is pointed to an url that returns a redirection with a
location header that points to a url containing spaces, that are
properly urlencoded, then it creates a bad request with the spaces not
encoded in the url. Here is an example/test case:

In [1]: import urllib

In [2]:
u=urllib.urlopen("http://sourceforge.net/project/showfiles.php?group_id=16847&package_id=13374")

In [3]: u.url
Out[3]: 'http://sourceforge.net/projects/xmlrpc-c/files/Xmlrpc-c Super
Stable/download'

In [4]: u.read()
Out[4]: '<html>\r\n<head><title>400 Bad Request</title></head>\r\n<body
bgcolor="white">\r\n<center><h1>400 Bad
Request</h1></center>\r\n<hr><center>nginx/0.7.60</center>\r\n</body>\r\n</html>\r\n'

In [5]:
u=urllib.urlopen("http://sourceforge.net/projects/xmlrpc-c/files/Xmlrpc-c%20Super%20Stable/download")

In [6]: u.read()[0:100]
Out[6]: '\n\n<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0
Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xh'

In [7]:

----------
components: Library (Lib)
messages: 90864
nosy: till
severity: normal
status: open
title: urllib.urlopen creates bad requests when location header of 301 redirects contain spaces
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6557>
_______________________________________

From report at bugs.python.org  Fri Jul 24 00:36:20 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 23 Jul 2009 22:36:20 +0000
Subject: [issue6553] cPickle "binunicode" segmentation fault
In-Reply-To: <1248362119.25.0.536343582132.issue6553@psf.upfronthosting.co.za>
Message-ID: <1248388580.35.0.403923389062.issue6553@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Fixed in r74189 (trunk) and r74190 (2.6)
Thanks for the report!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6553>
_______________________________________

From report at bugs.python.org  Fri Jul 24 01:08:37 2009
From: report at bugs.python.org (Thomas Wouters)
Date: Thu, 23 Jul 2009 23:08:37 +0000
Subject: [issue1590864] Function-level import in os triggering an threaded
	import deadlock
Message-ID: <1248390517.32.0.579099727252.issue1590864@psf.upfronthosting.co.za>


Thomas Wouters <thomas at python.org> added the comment:

Here's a preliminary fix (also see
http://codereview.appspot.com/96125/show )

----------
assignee:  -> twouters
keywords: +patch
nosy: +twouters
Added file: http://bugs.python.org/file14553/import_lock_fork_deadlock.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1590864>
_______________________________________

From report at bugs.python.org  Fri Jul 24 01:28:55 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 23 Jul 2009 23:28:55 +0000
Subject: [issue6554] Do we have something like	os.pid_exists()?
In-Reply-To: <1248373715.48.0.616687111663.issue6554@psf.upfronthosting.co.za>
Message-ID: <4A68F234.6070602@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I'd love to do the same without catching an exception (they're
> expensive!)

Why do you say that? I don't believe that exceptions are expensive
(e.g. compared to the system call)

----------
nosy: +loewis
title: Do we have something like os.pid_exists()? -> Do we have something like	os.pid_exists()?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6554>
_______________________________________

From report at bugs.python.org  Fri Jul 24 03:17:54 2009
From: report at bugs.python.org (Garrett Cooper)
Date: Fri, 24 Jul 2009 01:17:54 +0000
Subject: [issue6558] #ifdef linux is incorrect;
	should be #ifdef __linux__ (preferred standard)
In-Reply-To: <1248398274.01.0.259740550657.issue6558@psf.upfronthosting.co.za>
Message-ID: <1248398274.01.0.259740550657.issue6558@psf.upfronthosting.co.za>


New submission from Garrett Cooper <yanegomi at gmail.com>:

The following files are looking for the `linux' constant, when it fact
they should be looking for `__linux__' (from 2.6.2 release's sources):

Modules/_ctypes/libffi/src/mips/ffitarget.h:#ifdef linux
Modules/socketmodule.c:#ifdef linux
Modules/socketmodule.c:#ifdef linux

The correct check is being made for FreeBSD (__FreeBSD__), for instance.

This is a defacto standard set by gcc, as discussed here:
<http://lists.debian.org/debian-devel/2001/01/msg00951.html>. You can
dump out all of the available constants for any given gcc compiler via:

[garrcoop at sjc-lds-102 ~/Python-2.6.2]$ echo "" | gcc -E -dM -c - | grep
linux
#define __linux 1
#define __linux__ 1
#define __gnu_linux__ 1
#define linux 1

I point this out because one of our compilers, doesn't have this
definition and it's tossing up errors with the linuxaudiodev and oss
modules periodically when cross-compiling, as shown below :(:

/nobackup/shujagan/tmp/contrib/python/Modules/linuxaudiodev.c:31: error:
conflicting types for 'uint32_t'
/nobackup/shujagan/tmp/linkfarm/mips32/usr/include/stdint.h:52: error:
previous declaration of 'uint32_t' was here

/nobackup/shujagan/tmp/contrib/python/Modules/ossaudiodev.c:37: error:
conflicting types for 'uint32_t'
/nobackup/shujagan/tmp/linkfarm/mips32/usr/include/stdint.h:52: error:
previous declaration of 'uint32_t' was here

We've suggested using --without-audio, but this is a standard which
should be adhered to as __linux__ is the constant of choice when looking
for the Linux compiler...

Thanks!
-Garrett

----------
assignee: theller
components: Build, Extension Modules, ctypes
messages: 90868
nosy: theller, yaneurabeya
severity: normal
status: open
title: #ifdef linux is incorrect; should be #ifdef __linux__ (preferred standard)
type: compile error
versions: Python 2.4, Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6558>
_______________________________________

From report at bugs.python.org  Fri Jul 24 05:12:12 2009
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 24 Jul 2009 03:12:12 +0000
Subject: [issue5511] zipfile - add __exit__ attribute to make ZipFile object
	compatible with with_statement
In-Reply-To: <1237400664.18.0.956324816364.issue5511@psf.upfronthosting.co.za>
Message-ID: <1248405132.32.0.578434589124.issue5511@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Submitted a patch against trunk. Let me know if you need anything else
(doc patch?).

----------
keywords: +patch
nosy: +briancurtin
Added file: http://bugs.python.org/file14554/zipfile_issue_5511.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5511>
_______________________________________

From report at bugs.python.org  Fri Jul 24 08:18:30 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 24 Jul 2009 06:18:30 +0000
Subject: [issue5511] zipfile - add __exit__ attribute to make ZipFile object
	compatible with with_statement
In-Reply-To: <1237400664.18.0.956324816364.issue5511@psf.upfronthosting.co.za>
Message-ID: <1248416310.47.0.863185728068.issue5511@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

It would be nice if you could provide unit tests.
If you can also provide a patch for the doc, it's even better.

----------
keywords: +needs review
nosy: +ezio.melotti
priority:  -> normal
stage: needs patch -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5511>
_______________________________________

From report at bugs.python.org  Fri Jul 24 09:56:37 2009
From: report at bugs.python.org (Zhigang Wang)
Date: Fri, 24 Jul 2009 07:56:37 +0000
Subject: [issue6559] [PATCH]add pass_fds paramter to subprocess.Popen()
In-Reply-To: <1248422197.05.0.784368367425.issue6559@psf.upfronthosting.co.za>
Message-ID: <1248422197.05.0.784368367425.issue6559@psf.upfronthosting.co.za>


New submission from Zhigang Wang <w1z2g3 at gmail.com>:

The current subprocess.Popen() has a boolean close_fds parameter, which
cannot satisfy all the requirements. Eg. want to pass specific fd to
child process, but close others.

This patch adds a extra parameter pass_fds to subprocess.Popen's
__init__(). This parameter only effect when close_fds=True. When
close_fds=True, all fds in pass_fds will not closed before exec.

----------
components: Library (Lib)
files: python-subprocess-add-pass-fds.patch
keywords: patch
messages: 90871
nosy: zhigang
severity: normal
status: open
title: [PATCH]add pass_fds paramter to subprocess.Popen()
versions: Python 3.2
Added file: http://bugs.python.org/file14555/python-subprocess-add-pass-fds.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6559>
_______________________________________

From report at bugs.python.org  Fri Jul 24 10:08:11 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 24 Jul 2009 08:08:11 +0000
Subject: [issue6559] [PATCH]add pass_fds paramter to subprocess.Popen()
In-Reply-To: <1248422197.05.0.784368367425.issue6559@psf.upfronthosting.co.za>
Message-ID: <1248422891.62.0.953970959537.issue6559@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

A couple of unit tests would be great, as well as a paragraph for the
documentation.

----------
nosy: +amaury.forgeotdarc
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6559>
_______________________________________

From report at bugs.python.org  Fri Jul 24 10:20:10 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 24 Jul 2009 08:20:10 +0000
Subject: [issue6236] os.popen causes illegal seek on AIX in Python 3.1rc
In-Reply-To: <1244427618.5.0.797941537993.issue6236@psf.upfronthosting.co.za>
Message-ID: <1248423610.3.0.758148797088.issue6236@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Perhaps, although I don't know where /dev/tty would be involved in
os.popen().

For reference, under Linux I get:
>>> open("/dev/tty","a")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 29] Illegal seek

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6236>
_______________________________________

From report at bugs.python.org  Fri Jul 24 10:28:19 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 24 Jul 2009 08:28:19 +0000
Subject: [issue6559] [PATCH]add pass_fds paramter to subprocess.Popen()
In-Reply-To: <1248422197.05.0.784368367425.issue6559@psf.upfronthosting.co.za>
Message-ID: <1248424099.53.0.548156213679.issue6559@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The reason os.closerange() is used is that it can be slow to call
os.close() on lots of fds (I suppose this depends on the OS). See
http://code.python.org/hg/trunk/rev/43caff85ec85

Therefore, the patch should be smart enough to continue using
os.closerange() on ranges of contiguous FDs to be closed.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6559>
_______________________________________

From report at bugs.python.org  Fri Jul 24 10:29:00 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 24 Jul 2009 08:29:00 +0000
Subject: [issue1436346] yday in datetime module
Message-ID: <1248424140.34.0.552734124417.issue1436346@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +pitrou
versions: +Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1436346>
_______________________________________

From report at bugs.python.org  Fri Jul 24 10:30:19 2009
From: report at bugs.python.org (=?utf-8?q?K=C3=A1lm=C3=A1n_Gergely?=)
Date: Fri, 24 Jul 2009 08:30:19 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1248424219.19.0.278000580973.issue6560@psf.upfronthosting.co.za>
Message-ID: <1248424219.19.0.278000580973.issue6560@psf.upfronthosting.co.za>


New submission from K?lm?n Gergely <kalman.gergely at duodecad.hu>:

This is the rewritten-from-scratch implementation of the
sendmsg()/recvmsg() methods.
Any comments / suggestions / flames are very welcome. Currently it
supports what I need
and I'm only releasing it because I don't have much time to develop it
further in the
forseeable future (1-2 months). It is rewritten from scratch, using the
python c-api
documents. I've tried my best, but I wouldn't bet that it works
error-free. I'd be glad
if someone could give me a review on what I've might done wrong.

The features that are missing:
- using scatter/gather
- using it with non-stream oriented sockets (doesn't support addresses
/msg_name/)

These should be very easy to implement. If no one takes up the task of
implementing the
missing features than I'll do it of course, you just have to wait a
little while. Of
course any errors present in the code right now will be fixed.

Thanks

Kalman Gergely

----------
components: Library (Lib)
files: srmsg.patch
keywords: patch
messages: 90875
nosy: synapse
severity: normal
status: open
title: socket sendmsg(), recvmsg() methods
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file14556/srmsg.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6560>
_______________________________________

From report at bugs.python.org  Fri Jul 24 10:31:43 2009
From: report at bugs.python.org (=?utf-8?q?K=C3=A1lm=C3=A1n_Gergely?=)
Date: Fri, 24 Jul 2009 08:31:43 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1248424219.19.0.278000580973.issue6560@psf.upfronthosting.co.za>
Message-ID: <1248424303.02.0.987359648646.issue6560@psf.upfronthosting.co.za>


K?lm?n Gergely <kalman.gergely at duodecad.hu> added the comment:

the tester application

----------
Added file: http://bugs.python.org/file14557/sendrecvmsgtest.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6560>
_______________________________________

From report at bugs.python.org  Fri Jul 24 11:37:52 2009
From: report at bugs.python.org (Thomas Herve)
Date: Fri, 24 Jul 2009 09:37:52 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1248424219.19.0.278000580973.issue6560@psf.upfronthosting.co.za>
Message-ID: <1248428272.21.0.434807221794.issue6560@psf.upfronthosting.co.za>


Thomas Herve <therve at free.fr> added the comment:

This is a duplicate (although updated patch) from bug #1194378. It would
still need unit tests...

----------
nosy: +therve

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6560>
_______________________________________

From report at bugs.python.org  Fri Jul 24 11:44:35 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 24 Jul 2009 09:44:35 +0000
Subject: [issue6331] Add unicode script info to the unicode database
In-Reply-To: <1245790259.44.0.08771310344.issue6331@psf.upfronthosting.co.za>
Message-ID: <1248428675.78.0.00942652496295.issue6331@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +needs review
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6331>
_______________________________________

From report at bugs.python.org  Fri Jul 24 12:48:01 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 24 Jul 2009 10:48:01 +0000
Subject: [issue6561] Regex '\d' should not match unicode category 'No'.
In-Reply-To: <1248432481.83.0.138486397936.issue6561@psf.upfronthosting.co.za>
Message-ID: <1248432481.83.0.138486397936.issue6561@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

In Python 3, or in Python 2 with the re.UNICODE flag, it appears that 
the regex r'\d' matches all unicode characters with category either 'Nd' 
(Number, Decimal Digit) or 'No' (Number, Other), but not characters in 
category 'Nl' (Number, Letter):

Python 3.2a0 (py3k:74188, Jul 23 2009, 16:01:29) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import re
>>> import unicodedata
>>> x = '\u2781'
>>> unicodedata.category(x)
'No'
>>> unicodedata.name(x)
'DINGBAT CIRCLED SANS-SERIF DIGIT TWO'
>>> re.match(r'\d', '\u2781')
<_sre.SRE_Match object at 0x3d5d08>

I believe (but am not 100% sure) that r'\d' should only match characters 
in category 'Nd'.  To back up this belief:

(1) int and float currently accept characters in category 'Nd' but not 
'No'; it would seem useful for '\d' to match those characters that are 
accepted by int, so that e.g., something matched with '\d+' could be 
directly passed to int.  (This came up in a #python-dev discussion
about whether the Decimal type should accept other unicode digits;  
that's a separate issue, though.)

(2) In Perl 5.10 (and possibly some earlier versions too), '\d' matches 
only characters in category 'Nd'

(3) Unicode Technical Standard #18 ("Unicode Regular Expressions") at 
http://unicode.org/unicode/reports/tr18/ recommends that '\d' should 
correspond to \p{gc=Decimal_Number}

Marc-Andr?, do you have any opinion on this?

It's probably slightly dangerous to change this in 2.6 or 3.1;  I'm 
proposing that '\d' should be modified to accept only characters of 
category 'Nd' in 2.7 and 3.2.

(Thanks Ezio Melotti for finding all the references above and doing Perl 
testing!)

----------
components: Extension Modules
messages: 90878
nosy: ezio.melotti, lemburg, marketdickinson
severity: normal
stage: test needed
status: open
title: Regex '\d' should not match unicode category 'No'.
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6561>
_______________________________________

From report at bugs.python.org  Fri Jul 24 13:26:35 2009
From: report at bugs.python.org (David Roberts)
Date: Fri, 24 Jul 2009 11:26:35 +0000
Subject: [issue6562] OverflowError in RLock.acquire()
In-Reply-To: <1248434795.41.0.567943786679.issue6562@psf.upfronthosting.co.za>
Message-ID: <1248434795.41.0.567943786679.issue6562@psf.upfronthosting.co.za>


New submission from David Roberts <d at vidr.cc>:

I'm getting the following error on Windows in an application I've
written (the error does not occur on Linux):

Exception in thread Thread-4:
Traceback (most recent call last):
 File "C:\Python26\lib\threading.py", line 525, in __bootstrap_inner
   self.run()
 File "C:\Documents and Settings\David\My
Documents\pyzui\pyzui\tileprovider.py", line 97, in run
   self.__tilecache[tile_id] = Tile(tile)
 File "C:\Documents and Settings\David\My
Documents\pyzui\pyzui\tilecache.py", line 165, in __setitem__
   with self.__lock:
 File "C:\Python26\lib\threading.py", line 115, in acquire
   me = current_thread()
 File "C:\Python26\lib\threading.py", line 803, in currentThread
   return _active[_get_ident()]
OverflowError: can't convert negative value to unsigned long

Where __lock is an RLock object.

The odd thing is that it only affects a single class (which is derived
from the TileProvider class in tileprovider.py, which in turn is derived
from threading.Thread). This led me to believe there was an error in my
code, but I asked on the mailing list and was told that it is likely a
bug in the threading module.

The Python version is 2.6.2.

----------
components: Library (Lib), Windows
messages: 90879
nosy: davidar
severity: normal
status: open
title: OverflowError in RLock.acquire()
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6562>
_______________________________________

From report at bugs.python.org  Fri Jul 24 13:58:04 2009
From: report at bugs.python.org (Eric Smith)
Date: Fri, 24 Jul 2009 11:58:04 +0000
Subject: [issue6561] Regex '\d' should not match unicode category 'No'.
In-Reply-To: <1248432481.83.0.138486397936.issue6561@psf.upfronthosting.co.za>
Message-ID: <1248436684.03.0.879089207757.issue6561@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6561>
_______________________________________

From report at bugs.python.org  Fri Jul 24 14:08:41 2009
From: report at bugs.python.org (Till Maas)
Date: Fri, 24 Jul 2009 12:08:41 +0000
Subject: [issue6516] reset owner/group to root for distutils tarballs
In-Reply-To: <1247933699.76.0.278346370296.issue6516@psf.upfronthosting.co.za>
Message-ID: <1248437321.27.0.191728756787.issue6516@psf.upfronthosting.co.za>


Till Maas <opensource at till.name> added the comment:

I want to create uniform tarballs, independent of which username was
used to create the tarball.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6516>
_______________________________________

From report at bugs.python.org  Fri Jul 24 14:09:36 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Fri, 24 Jul 2009 12:09:36 +0000
Subject: [issue6558] #ifdef linux is incorrect;
	should be #ifdef __linux__ (preferred standard)
In-Reply-To: <1248398274.01.0.259740550657.issue6558@psf.upfronthosting.co.za>
Message-ID: <1248437376.04.0.0687557788675.issue6558@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

Did my patch python-trunk-20081209-c89.patch from issue 4558 work for you ?

Is the issue fixed in original libffi ?

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6558>
_______________________________________

From report at bugs.python.org  Fri Jul 24 15:17:31 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 24 Jul 2009 13:17:31 +0000
Subject: [issue6236] os.popen causes illegal seek on AIX in Python 3.1rc
In-Reply-To: <1244427618.5.0.797941537993.issue6236@psf.upfronthosting.co.za>
Message-ID: <1248441451.78.0.681146375554.issue6236@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

/dev/tty is probably similar to stdout, at least when python is started
without redirection.

What is the output of
>>> sys.stdout.seekable()
when run from an interactive interpreter?
Does it depend on the active console? (xterm, ssh...)

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6236>
_______________________________________

From report at bugs.python.org  Fri Jul 24 15:20:43 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 24 Jul 2009 13:20:43 +0000
Subject: [issue6562] OverflowError in RLock.acquire()
In-Reply-To: <1248434795.41.0.567943786679.issue6562@psf.upfronthosting.co.za>
Message-ID: <1248441643.8.0.384466161733.issue6562@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This is strange, thread.get_ident() isn't supposed to raise this kind of
error.
Could you call it individually from the same thread to see what it returns?
Also, could you post the code for your derived class for us to see?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6562>
_______________________________________

From report at bugs.python.org  Fri Jul 24 16:32:02 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 24 Jul 2009 14:32:02 +0000
Subject: [issue1764044] copy 2
Message-ID: <1248445922.61.0.016756462176.issue1764044@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The "f": drive probably was a FAT32 filesystem, which has a resolution
of two seconds...

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1764044>
_______________________________________

From report at bugs.python.org  Fri Jul 24 16:52:50 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 24 Jul 2009 14:52:50 +0000
Subject: [issue6561] Regex '\d' should not match unicode category 'No'.
In-Reply-To: <1248432481.83.0.138486397936.issue6561@psf.upfronthosting.co.za>
Message-ID: <1248447170.25.0.0173888584541.issue6561@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Patch against py3k.

----------
keywords: +patch
Added file: http://bugs.python.org/file14558/issue6561.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6561>
_______________________________________

From report at bugs.python.org  Fri Jul 24 17:00:34 2009
From: report at bugs.python.org (jan matejek)
Date: Fri, 24 Jul 2009 15:00:34 +0000
Subject: [issue5103] ssl.SSLSocket timeout not working correctly when remote
	end is hanging
In-Reply-To: <1233269067.88.0.11384047057.issue5103@psf.upfronthosting.co.za>
Message-ID: <1248447634.14.0.0785320461087.issue5103@psf.upfronthosting.co.za>


jan matejek <jmatejek at suse.cz> added the comment:

i believe that the bug lies in bad implementation/backport of feature
from 3.0 patch for issue1251.

see this revision:
http://svn.python.org/view/python/branches/release30-maint/Lib/ssl.py?r1=59339&r2=59340
where the code was added for py3k branch.

the logic behind that code is that when the timeout is zero
(non-blocking socket), but the caller explicitly specifies that they
want to block (which only happens when an application handles
do_handshake by itself), timeout is set to None and reset to zero after
the call.
and this change was made to "better support non-blocking sockets", the
original patch (
http://svn.python.org/view/python/branches/py3k/Lib/ssl.py?view=diff&r1=58996&r2=58997
) did not have this code at all

on the other hand, what the 2.6 version does is not making any sense. i
don't even see how it got to be that way instead of using py3k's
do_handshake with optional "block" parameter - seeing as the change was
made six months later and changed the API anyway

the correct thing to do here is simply

if do_handshake_on_connect:
    self.do_handshake()

without the timeout setting/resetting stuff

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5103>
_______________________________________

From report at bugs.python.org  Fri Jul 24 17:42:50 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 24 Jul 2009 15:42:50 +0000
Subject: [issue481171] Hang using files named prn.txt, etc
Message-ID: <1248450170.84.0.255571443308.issue481171@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

It seems that Windows has been "patched"...
open("COM").read() does not hang: it reads from the console until you
hit Ctrl-Z.
Testing on Windows 2000, some device names always succeed, others fail
with IOError when you open them or write to them.

The behavior seems correct to me (except of course this very concept of
special device names), and matches the expectations of the OP.

----------
nosy: +amaury.forgeotdarc
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue481171>
_______________________________________

From report at bugs.python.org  Fri Jul 24 18:36:31 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 24 Jul 2009 16:36:31 +0000
Subject: [issue6561] Regex '\d' should not match unicode category 'No'.
In-Reply-To: <1248432481.83.0.138486397936.issue6561@psf.upfronthosting.co.za>
Message-ID: <1248453391.88.0.126644009616.issue6561@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

New patch;  same as before, but includes clarification to the 
documentation.

----------
Added file: http://bugs.python.org/file14559/issue6561.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6561>
_______________________________________

From report at bugs.python.org  Fri Jul 24 18:36:43 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 24 Jul 2009 16:36:43 +0000
Subject: [issue6561] Regex '\d' should not match unicode category 'No'.
In-Reply-To: <1248432481.83.0.138486397936.issue6561@psf.upfronthosting.co.za>
Message-ID: <1248453403.31.0.515896983204.issue6561@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


Removed file: http://bugs.python.org/file14558/issue6561.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6561>
_______________________________________

From report at bugs.python.org  Fri Jul 24 20:11:55 2009
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 24 Jul 2009 18:11:55 +0000
Subject: [issue6563] inserting None into sys.modules does not raise
	ImportError with importlib
In-Reply-To: <1248459115.79.0.0648644877351.issue6563@psf.upfronthosting.co.za>
Message-ID: <1248459115.79.0.0648644877351.issue6563@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

When you insert None into sys.modules, the built-in import raises an 
ImportError, but importlib does not.

See http://mail.python.org/pipermail/python-dev/2009-July/090780.html for 
the discussion that brought this up.

----------
assignee: brett.cannon
components: Library (Lib)
messages: 90889
nosy: brett.cannon
priority: normal
severity: normal
stage: test needed
status: open
title: inserting None into sys.modules does not raise ImportError with importlib
type: behavior
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6563>
_______________________________________

From report at bugs.python.org  Fri Jul 24 20:24:22 2009
From: report at bugs.python.org (Gaelen Marsden)
Date: Fri, 24 Jul 2009 18:24:22 +0000
Subject: [issue6564] Error in Sec. 8.4 of Tutorial
In-Reply-To: <1248459862.63.0.495728002028.issue6564@psf.upfronthosting.co.za>
Message-ID: <1248459862.63.0.495728002028.issue6564@psf.upfronthosting.co.za>


New submission from Gaelen Marsden <gaelen.marsden at gmail.com>:

In Section 8.4 of the Tutorial, "Raising Exceptions", the text following
the first example states "Alternatively, the above could be written as
raise NameError('HiThere')." Perhaps I am being dense, but I can see no
difference between the two.

----------
assignee: georg.brandl
components: Documentation
messages: 90890
nosy: georg.brandl, gmarsden
severity: normal
status: open
title: Error in Sec. 8.4 of Tutorial
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6564>
_______________________________________

From report at bugs.python.org  Fri Jul 24 21:46:53 2009
From: report at bugs.python.org (Andre Roberge)
Date: Fri, 24 Jul 2009 19:46:53 +0000
Subject: [issue6565] improper use of __setitem__ in ElementTree for Python 3.1
In-Reply-To: <1248464813.63.0.470228683416.issue6565@psf.upfronthosting.co.za>
Message-ID: <1248464813.63.0.470228683416.issue6565@psf.upfronthosting.co.za>


New submission from Andre Roberge <andre.roberge at gmail.com>:

I have a function to replace the content of an ElementTree Element by
that of another one which works using Python 2 but not with Python 3.
I get an assertion error.  

It was suggested on the Python list that the problem is that in Python 3
slice assignments are done with __setitem__ rather than __setslice__ but
ElementTree has not been adapted to that -- hence the title given to
this bug.

The function that I use to demonstrate this (with a workaround solution)
is as follows:

def replace_element(elem, replacement):
    '''replace the content of an ElementTree Element by that of
another
       one.
    '''
    elem.clear()
    elem.text = replacement.text
    elem.tail = replacement.tail
    elem.tag = replacement.tag
    elem.attrib = replacement.attrib
    try:
        elem[:] = replacement[:]  # works with Python 2.5 but not 3.1
    except AssertionError:
        del elem[:]
        for child in replacement:
            elem.append(child)

I have included a small test file which demonstrate the behaviour.

----------
components: Library (Lib)
files: test.py
messages: 90891
nosy: aroberge
severity: normal
status: open
title: improper use of __setitem__ in ElementTree for Python 3.1
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file14560/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6565>
_______________________________________

From report at bugs.python.org  Fri Jul 24 21:57:38 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 24 Jul 2009 19:57:38 +0000
Subject: [issue6507] Enhance dis.dis to autocompile codestrings
In-Reply-To: <1247857575.21.0.389925271165.issue6507@psf.upfronthosting.co.za>
Message-ID: <1248465458.0.0.998636989214.issue6507@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Trying both 'eval' and 'exec' looks fine to me.
Marking 'easy' because I expect it should be ;-)

----------
keywords: +easy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6507>
_______________________________________

From report at bugs.python.org  Fri Jul 24 21:59:36 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 24 Jul 2009 19:59:36 +0000
Subject: [issue6518] Enable 'with' statement in ossaudiodev module
In-Reply-To: <1247965666.73.0.755368316919.issue6518@psf.upfronthosting.co.za>
Message-ID: <1248465576.06.0.00826983581048.issue6518@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Seems like a sensible idea.
Note: 3.0 is no longer maintained.
Marking 'easy' because I expect that copying and adapting __exit__ from
regular open should be.

----------
keywords: +easy
nosy: +tjreedy
versions:  -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6518>
_______________________________________

From report at bugs.python.org  Fri Jul 24 22:10:15 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 24 Jul 2009 20:10:15 +0000
Subject: [issue6564] Error in Sec. 8.4 of Tutorial
In-Reply-To: <1248459862.63.0.495728002028.issue6564@psf.upfronthosting.co.za>
Message-ID: <1248466215.67.0.50603293781.issue6564@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Indeed :)

Fixed in r74194.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6564>
_______________________________________

From report at bugs.python.org  Fri Jul 24 22:28:20 2009
From: report at bugs.python.org (Nir Soffer)
Date: Fri, 24 Jul 2009 20:28:20 +0000
Subject: [issue6550] asyncore incorrect failure when connection is refused and
	using async_chat channel
In-Reply-To: <1248302571.21.0.910158552759.issue6550@psf.upfronthosting.co.za>
Message-ID: <1248467300.16.0.559190035323.issue6550@psf.upfronthosting.co.za>


Nir Soffer <nirsof at gmail.com> added the comment:

Tested on Ubuntu Linux 9.04.

The tests will probably fail on Windows, since connection refused is
detected trough handle_expt_event, and not in hadnle_read_event. I hope
someone on Windows will fix this :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6550>
_______________________________________

From report at bugs.python.org  Fri Jul 24 23:07:58 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 24 Jul 2009 21:07:58 +0000
Subject: [issue6566] json.dumps converts None to "null" (not null)
In-Reply-To: <1248469678.72.0.793111928959.issue6566@psf.upfronthosting.co.za>
Message-ID: <1248469678.72.0.793111928959.issue6566@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

In [2]: json.dumps({'a': 1, 'b': {'c': 3, None: 5}})
Out[2]: '{"a": 1, "b": {"c": 3, "null": 5}}'

In [3]: j = json.dumps({'a': 1, 'b': {'c': 3, None: 5}})

In [4]: json.loads(j)
Out[4]: {u'a': 1, u'b': {u'c': 3, u'null': 5}}

I was surprised to note that None was converted to "null" instead of 
null. This happens only in dicts and not, for example, lists:

In [5]: json.dumps([None, 1, "a"])
Out[5]: '[null, 1, "a"]'

----------
components: Library (Lib)
messages: 90896
nosy: srid
severity: normal
status: open
title: json.dumps converts None to "null" (not null)
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6566>
_______________________________________

From report at bugs.python.org  Fri Jul 24 23:09:02 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 24 Jul 2009 21:09:02 +0000
Subject: [issue6566] json.dumps converts None to "null" (not null)
In-Reply-To: <1248469678.72.0.793111928959.issue6566@psf.upfronthosting.co.za>
Message-ID: <1248469742.19.0.668792274005.issue6566@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

The simplest repro:

In [6]: json.dumps({None: 3})
Out[6]: '{"null": 3}'

In [7]: json.loads(json.dumps({None: 3}))
Out[7]: {u'null': 3}

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6566>
_______________________________________

From report at bugs.python.org  Fri Jul 24 23:11:48 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 24 Jul 2009 21:11:48 +0000
Subject: [issue6566] json.dumps converts None to "null" (not null)
In-Reply-To: <1248469678.72.0.793111928959.issue6566@psf.upfronthosting.co.za>
Message-ID: <1248469908.56.0.331978169198.issue6566@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> bob.ippolito
nosy: +bob.ippolito
status: open -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6566>
_______________________________________

From report at bugs.python.org  Fri Jul 24 23:13:15 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 24 Jul 2009 21:13:15 +0000
Subject: [issue6566] json.dumps converts None to "null" (not null)
In-Reply-To: <1248469678.72.0.793111928959.issue6566@psf.upfronthosting.co.za>
Message-ID: <1248469995.72.0.79275400065.issue6566@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Also repros on 3.0/3.1

----------
versions: +Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6566>
_______________________________________

From report at bugs.python.org  Fri Jul 24 23:13:36 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Fri, 24 Jul 2009 21:13:36 +0000
Subject: [issue6566] json.dumps converts None to "null" (not null)
In-Reply-To: <1248469678.72.0.793111928959.issue6566@psf.upfronthosting.co.za>
Message-ID: <1248470016.63.0.0809099439357.issue6566@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Notice what it does to other dict keys:

    >>> simplejson.dumps({1: 1})
    '{"1": 1}'

In other words, I don't think this is a bug.  It's how JSON works.  JSON
dict keys are strings *only*.

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6566>
_______________________________________

From report at bugs.python.org  Fri Jul 24 23:17:36 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 24 Jul 2009 21:17:36 +0000
Subject: [issue6566] json.dumps converts None to "null" (not null)
In-Reply-To: <1248469678.72.0.793111928959.issue6566@psf.upfronthosting.co.za>
Message-ID: <1248470256.79.0.317559247427.issue6566@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

> JSON dict keys are strings *only*.

I might be helpful to point this out (along with other caveats) in the 
standard library documentation for JSON.

An explicit mention of ``loads(dumps(x)) != x for certain structures`` 
would be nice.

I, sir, was genuinely surprised to discover this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6566>
_______________________________________

From report at bugs.python.org  Fri Jul 24 23:53:42 2009
From: report at bugs.python.org (Nir Soffer)
Date: Fri, 24 Jul 2009 21:53:42 +0000
Subject: [issue6550] asyncore incorrect failure when connection is refused and
	using async_chat channel
In-Reply-To: <1248302571.21.0.910158552759.issue6550@psf.upfronthosting.co.za>
Message-ID: <1248472422.88.0.383169211392.issue6550@psf.upfronthosting.co.za>


Nir Soffer <nirsof at gmail.com> added the comment:

The first fix reverted to 2.5 behavior, when self.connected is false when 
handle_connect is called. This behavior is little stupid - why call 
handle_connect if the socket is not really connected?

This fix ensure that handle_connect is called only if the socket is 
connected - just like it is done in handle_write_event. Now it does not 
matter when you set the connected flag, before or after handle_connect.

Tested in trunk on Mac OS X.

----------
Added file: http://bugs.python.org/file14561/asycore-handle-connect-event-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6550>
_______________________________________

From report at bugs.python.org  Sat Jul 25 00:05:36 2009
From: report at bugs.python.org (Lucas Prado Melo)
Date: Fri, 24 Jul 2009 22:05:36 +0000
Subject: [issue6567] Isn't inf  almost equal to inf?
In-Reply-To: <1248473136.17.0.947327850034.issue6567@psf.upfronthosting.co.za>
Message-ID: <1248473136.17.0.947327850034.issue6567@psf.upfronthosting.co.za>


New submission from Lucas Prado Melo <lucaspradomelo at gmail.com>:

When we use TestCase.assertAlmostEqual to compare two float('inf')
objects, the result is that float('inf') is not almost equal to
float('inf').
I believe this is a bug. I tested against r74195 of Python 3.2 and
against Python 2.6.2.

----------
messages: 90902
nosy: lucaspmelo
severity: normal
status: open
title: Isn't inf  almost equal to inf?
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6567>
_______________________________________

From report at bugs.python.org  Sat Jul 25 00:06:29 2009
From: report at bugs.python.org (Lucas Prado Melo)
Date: Fri, 24 Jul 2009 22:06:29 +0000
Subject: [issue6567] Isn't inf  almost equal to inf?
In-Reply-To: <1248473136.17.0.947327850034.issue6567@psf.upfronthosting.co.za>
Message-ID: <1248473189.93.0.198832762382.issue6567@psf.upfronthosting.co.za>


Changes by Lucas Prado Melo <lucaspradomelo at gmail.com>:


----------
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6567>
_______________________________________

From report at bugs.python.org  Sat Jul 25 00:06:58 2009
From: report at bugs.python.org (Lucas Prado Melo)
Date: Fri, 24 Jul 2009 22:06:58 +0000
Subject: [issue6567] Isn't inf  almost equal to inf?
In-Reply-To: <1248473136.17.0.947327850034.issue6567@psf.upfronthosting.co.za>
Message-ID: <1248473218.62.0.00802827945715.issue6567@psf.upfronthosting.co.za>


Changes by Lucas Prado Melo <lucaspradomelo at gmail.com>:


----------
components: +Tests

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6567>
_______________________________________

From report at bugs.python.org  Sat Jul 25 00:07:15 2009
From: report at bugs.python.org (Lucas Prado Melo)
Date: Fri, 24 Jul 2009 22:07:15 +0000
Subject: [issue6567] Isn't inf  almost equal to inf?
In-Reply-To: <1248473136.17.0.947327850034.issue6567@psf.upfronthosting.co.za>
Message-ID: <1248473235.36.0.740119543631.issue6567@psf.upfronthosting.co.za>


Changes by Lucas Prado Melo <lucaspradomelo at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6567>
_______________________________________

From report at bugs.python.org  Sat Jul 25 00:15:08 2009
From: report at bugs.python.org (Nir Soffer)
Date: Fri, 24 Jul 2009 22:15:08 +0000
Subject: [issue6550] asyncore incorrect failure when connection is refused and
	using async_chat channel
In-Reply-To: <1248302571.21.0.910158552759.issue6550@psf.upfronthosting.co.za>
Message-ID: <1248473708.13.0.236153076513.issue6550@psf.upfronthosting.co.za>


Nir Soffer <nirsof at gmail.com> added the comment:

This version fix also handle_expt_event, so connection refused error 
should be handled in the same way also on Windows.

----------
Added file: http://bugs.python.org/file14562/asycore-handle-connect-event-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6550>
_______________________________________

From report at bugs.python.org  Sat Jul 25 01:16:07 2009
From: report at bugs.python.org (Michael Foord)
Date: Fri, 24 Jul 2009 23:16:07 +0000
Subject: [issue6568] unittest test discovery improvements
In-Reply-To: <1248477367.35.0.856395228547.issue6568@psf.upfronthosting.co.za>
Message-ID: <1248477367.35.0.856395228547.issue6568@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

Issue to track improvements in the standalone discover.py that I need to
port to the test discovery in unittest.

* Failure to import a module does not halt discovery
* Will not attempt to import test files whose names are not valid Python
  identifiers, even if they match the pattern

----------
assignee: michael.foord
messages: 90904
nosy: michael.foord
severity: normal
stage: needs patch
status: open
title: unittest test discovery improvements
type: feature request
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6568>
_______________________________________

From report at bugs.python.org  Sat Jul 25 01:58:02 2009
From: report at bugs.python.org (Eric Smith)
Date: Fri, 24 Jul 2009 23:58:02 +0000
Subject: [issue6567] Isn't inf  almost equal to inf?
In-Reply-To: <1248473136.17.0.947327850034.issue6567@psf.upfronthosting.co.za>
Message-ID: <1248479882.44.0.0977050266606.issue6567@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6567>
_______________________________________

From report at bugs.python.org  Sat Jul 25 02:20:47 2009
From: report at bugs.python.org (Garrett Cooper)
Date: Sat, 25 Jul 2009 00:20:47 +0000
Subject: [issue6558] #ifdef linux is incorrect;
	should be #ifdef __linux__ (preferred standard)
In-Reply-To: <1248398274.01.0.259740550657.issue6558@psf.upfronthosting.co.za>
Message-ID: <1248481247.79.0.163741820043.issue6558@psf.upfronthosting.co.za>


Garrett Cooper <yanegomi at gmail.com> added the comment:

__linux is legitimate too, so the patch looks ok, but...

1) It won't apply cleanly against 2.4.5, most likely.
2) Why __linux instead of __linux__ ?

gcooper at orangebox ~ $ echo "" | gcc --std=c89 -E -dM -c - | grep linux
#define __linux 1
#define __linux__ 1
#define __gnu_linux__ 1

__linux__ is the preferred nomenclature in the kernel.org sources, IIRC...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6558>
_______________________________________

From report at bugs.python.org  Sat Jul 25 02:26:56 2009
From: report at bugs.python.org (Michael Foord)
Date: Sat, 25 Jul 2009 00:26:56 +0000
Subject: [issue6567] Isn't inf  almost equal to inf?
In-Reply-To: <1248473136.17.0.947327850034.issue6567@psf.upfronthosting.co.za>
Message-ID: <1248481616.6.0.779620612395.issue6567@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Uhm... they may or may not be almost equal, but probably not.
Comparisons on them are defined to be undefined so you're using the
wrong thing to test them. Use assertTrue and math.isinf instead.

----------
nosy: +michael.foord
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6567>
_______________________________________

From report at bugs.python.org  Sat Jul 25 02:47:56 2009
From: report at bugs.python.org (Kouki Hashimoto)
Date: Sat, 25 Jul 2009 00:47:56 +0000
Subject: [issue6569] unittest document bug (random.shuffle sequence)
In-Reply-To: <1248482876.59.0.638608810535.issue6569@psf.upfronthosting.co.za>
Message-ID: <1248482876.59.0.638608810535.issue6569@psf.upfronthosting.co.za>


New submission from Kouki Hashimoto <hsmtkk at gmail.com>:

Hello.
I found a bug in unittest sample code.
http://docs.python.org/dev/py3k/library/unittest.html#unittest-minimal-example
(naming this code as test_sample.py)

I got this error.
$ python3.2 test_sample.py
..E
======================================================================
ERROR: test_shuffle (__main__.TestSequenceFunctions)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_sample.py", line 11, in test_shuffle
    random.shuffle(self.seq)
  File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/random.py",
line 270, in shuffle
    x[i], x[j] = x[j], x[i]
TypeError: 'range' object does not support item assignment

----------------------------------------------------------------------
Ran 3 tests in 0.004s

I think this code should be fixed with attached patch.
Regards.

----------
assignee: georg.brandl
components: Documentation
files: unittest.rst.patch
keywords: patch
messages: 90907
nosy: georg.brandl, hsmtkk
severity: normal
status: open
title: unittest document bug (random.shuffle sequence)
versions: Python 3.2
Added file: http://bugs.python.org/file14563/unittest.rst.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6569>
_______________________________________

From report at bugs.python.org  Sat Jul 25 03:02:21 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 25 Jul 2009 01:02:21 +0000
Subject: [issue6569] unittest document bug (random.shuffle sequence)
In-Reply-To: <1248482876.59.0.638608810535.issue6569@psf.upfronthosting.co.za>
Message-ID: <1248483741.97.0.512538920604.issue6569@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r74196.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6569>
_______________________________________

From report at bugs.python.org  Sat Jul 25 06:28:59 2009
From: report at bugs.python.org (Senthil)
Date: Sat, 25 Jul 2009 04:28:59 +0000
Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
Message-ID: <1248496139.27.0.872144931781.issue1424152@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

Fixed for 3.2 in py3k branch revision 74198. Asked python-dev for
objections on back porting changes 2.6.

Shall back port changes to py2.6 and py3.1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1424152>
_______________________________________

From report at bugs.python.org  Sat Jul 25 06:30:10 2009
From: report at bugs.python.org (Senthil)
Date: Sat, 25 Jul 2009 04:30:10 +0000
Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
Message-ID: <1248496210.04.0.210968279366.issue1424152@psf.upfronthosting.co.za>


Changes by Senthil <orsenthil at gmail.com>:


----------
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1424152>
_______________________________________

From report at bugs.python.org  Sat Jul 25 09:39:46 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Sat, 25 Jul 2009 07:39:46 +0000
Subject: [issue6562] OverflowError in RLock.acquire()
In-Reply-To: <1248434795.41.0.567943786679.issue6562@psf.upfronthosting.co.za>
Message-ID: <1248507586.6.0.452420099292.issue6562@psf.upfronthosting.co.za>


Changes by Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:


----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6562>
_______________________________________

From report at bugs.python.org  Sat Jul 25 10:35:40 2009
From: report at bugs.python.org (Mark du Preez)
Date: Sat, 25 Jul 2009 08:35:40 +0000
Subject: [issue6570] Documentation Clarity
In-Reply-To: <1248510940.46.0.953855607394.issue6570@psf.upfronthosting.co.za>
Message-ID: <1248510940.46.0.953855607394.issue6570@psf.upfronthosting.co.za>


New submission from Mark du Preez <drunkard at thepub.co.za>:

Hi

In section 4.7.2 of the tutorial documentation, we suddenly find the
following paragraph:

"In general, an argument list must have any positional arguments
followed by any keyword arguments, where the keywords must be chosen
from the formal parameter names. It?s not important whether a formal
parameter has a default value or not. No argument may receive a value
more than once ? formal parameter names corresponding to positional
arguments cannot be used as keywords in the same calls. Here?s an
example that fails due to this restriction:"

To a beginner who is reading a tutorial to learn how to use this
language for the first time, it is completely overwhelming. What is a
"positional argument" vs a "keyword argument" and what is a "formal
parameter name"?

None of these things have been explained up until this point and an
understanding of their meaning is required to make sense of this paragraph.

Please consider revising this section.

Thank you.

Mark

----------
assignee: georg.brandl
components: Documentation
messages: 90910
nosy: StMark, georg.brandl
severity: normal
status: open
title: Documentation Clarity
type: feature request
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6570>
_______________________________________

From report at bugs.python.org  Sat Jul 25 10:38:25 2009
From: report at bugs.python.org (David Roberts)
Date: Sat, 25 Jul 2009 08:38:25 +0000
Subject: [issue6562] OverflowError in RLock.acquire()
In-Reply-To: <1248434795.41.0.567943786679.issue6562@psf.upfronthosting.co.za>
Message-ID: <1248511105.45.0.993420786193.issue6562@psf.upfronthosting.co.za>


David Roberts <d at vidr.cc> added the comment:

thread.get_ident() returns 1192 and 1560 in the cases where there is no
error, and 1316 in the case where the error is thrown. Doesn't seem
particularly unusual, and shows get_ident() isn't throwing the error itself.

I also noticed that there is a warning right before the exception is raised:

C:\Python26\lib\threading.py:803: RuntimeWarning: tp_compare didn't
return -1 or -2 for exception
  return _active[_get_ident()]

I've attached the relevant snippets of code. As you can see
OSMTileProvider (the class that is triggering the exception) doesn't
actually do all that much, and the two other classes derived from
DynamicTileProvider function correctly so I don't understand what it is
about this specific class.

----------
Added file: http://bugs.python.org/file14564/tileproviders.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6562>
_______________________________________

From report at bugs.python.org  Sat Jul 25 11:36:22 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 25 Jul 2009 09:36:22 +0000
Subject: [issue6562] OverflowError in RLock.acquire()
In-Reply-To: <1248434795.41.0.567943786679.issue6562@psf.upfronthosting.co.za>
Message-ID: <1248514582.57.0.542054928746.issue6562@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Could you provide a complete example for us to reproduce the issue?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6562>
_______________________________________

From report at bugs.python.org  Sat Jul 25 11:41:50 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 25 Jul 2009 09:41:50 +0000
Subject: [issue6525] string.lowercase/uppercase/letters not affected by locale
	changes on linux
In-Reply-To: <1248108222.18.0.565207839087.issue6525@psf.upfronthosting.co.za>
Message-ID: <1248514910.81.0.0906924830906.issue6525@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I reproduced the issue on my Linux machine. Regardless of the locale I
use, string.lowercase/uppercase/letters is always equal to
string.ascii_lowercase.
On windows instead, other letters are added.

----------
resolution: wont fix -> 
status: closed -> open
title: Problem with string.lowercase in Windows XP -> string.lowercase/uppercase/letters not affected by locale changes on linux

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6525>
_______________________________________

From report at bugs.python.org  Sat Jul 25 12:35:17 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 25 Jul 2009 10:35:17 +0000
Subject: [issue6525] string.lowercase/uppercase/letters not affected by locale
	changes on linux
In-Reply-To: <1248108222.18.0.565207839087.issue6525@psf.upfronthosting.co.za>
Message-ID: <1248518117.74.0.631758925161.issue6525@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This seems to be normal when using an UTF-8 locale. For (e.g.) 'de_DE'
string.lowercase is changed here, for 'de_DE.utf-8' it isn't.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6525>
_______________________________________

From report at bugs.python.org  Sat Jul 25 13:12:36 2009
From: report at bugs.python.org (David Roberts)
Date: Sat, 25 Jul 2009 11:12:36 +0000
Subject: [issue6562] OverflowError in RLock.acquire()
In-Reply-To: <1248434795.41.0.567943786679.issue6562@psf.upfronthosting.co.za>
Message-ID: <1248520356.86.0.158236829421.issue6562@psf.upfronthosting.co.za>


David Roberts <d at vidr.cc> added the comment:

I haven't been able to isolate the issue. Could someone provide some
insight into what the error could possibly mean so that I have a better
idea of what I'm trying to isolate?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6562>
_______________________________________

From report at bugs.python.org  Sat Jul 25 13:38:58 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 25 Jul 2009 11:38:58 +0000
Subject: [issue6562] OverflowError in RLock.acquire()
In-Reply-To: <1248511105.45.0.993420786193.issue6562@psf.upfronthosting.co.za>
Message-ID: <1248522104.5107.4.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I also noticed that there is a warning right before the exception is raised:
> 
> C:\Python26\lib\threading.py:803: RuntimeWarning: tp_compare didn't
> return -1 or -2 for exception
>   return _active[_get_ident()]

Right, it probably means the exception was raised before this very code
line, but wasn't properly signalled to the Python runtime.
Does the error disappear if you comment out the "with self.__lock" line?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6562>
_______________________________________

From report at bugs.python.org  Sat Jul 25 14:15:25 2009
From: report at bugs.python.org (Colin J. Williams)
Date: Sat, 25 Jul 2009 12:15:25 +0000
Subject: [issue6571] Help index
In-Reply-To: <1248524124.94.0.366651342464.issue6571@psf.upfronthosting.co.za>
Message-ID: <1248524124.94.0.366651342464.issue6571@psf.upfronthosting.co.za>


New submission from Colin J. Williams <cjw at ncf.ca>:

Shift operators.  It would be good if "<<" and ">>" could be included 
in the index.

Incidentally, the usage seems counter-intuitive.

One would expect ">>" to be a shift to the right and 
"<<" to be a shift to the left.

----------
assignee: georg.brandl
components: Documentation
messages: 90917
nosy: cjw, georg.brandl
severity: normal
status: open
title: Help index
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6571>
_______________________________________

From report at bugs.python.org  Sat Jul 25 14:28:15 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Sat, 25 Jul 2009 12:28:15 +0000
Subject: [issue6571] Help index
In-Reply-To: <1248524124.94.0.366651342464.issue6571@psf.upfronthosting.co.za>
Message-ID: <1248524895.29.0.551815463268.issue6571@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Seems to work as expected for me:

>>> 7 >> 1
3
>>> 7 << 1
14

----------
nosy: +skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6571>
_______________________________________

From report at bugs.python.org  Sat Jul 25 14:35:39 2009
From: report at bugs.python.org (David Roberts)
Date: Sat, 25 Jul 2009 12:35:39 +0000
Subject: [issue6562] OverflowError in RLock.acquire()
In-Reply-To: <1248434795.41.0.567943786679.issue6562@psf.upfronthosting.co.za>
Message-ID: <1248525339.65.0.207294353555.issue6562@psf.upfronthosting.co.za>


David Roberts <d at vidr.cc> added the comment:

If I comment out all occurrences of "with self.__lock:" I then get the
same error in another part of the code:

C:\Python26\lib\threading.py:803: RuntimeWarning: tp_compare didn't
return -1 or -2 for exception
  return _active[_get_ident()]
Exception in thread Thread-4:
Traceback (most recent call last):
  File "C:\Python26\lib\threading.py", line 525, in __bootstrap_inner
    self.run()
  File "C:\Documents and Settings\David\My
Documents\pyzui\pyzui\tileprovider.py", line 82, in run
    self.__tasks_available.acquire()
  File "C:\Python26\lib\threading.py", line 115, in acquire
    me = current_thread()
  File "C:\Python26\lib\threading.py", line 803, in currentThread
    return _active[_get_ident()]
OverflowError: can't convert negative value to unsigned long

Where self.__tasks_available is a threading.Condition.

If I comment out that bit, I then get the following error:

Traceback (most recent call last):
  File "C:\Documents and Settings\David\My
Documents\pyzui\pyzui\tileprovider.py", line 91, in run
    tile = self._load(tile_id)
  File "C:\Documents and Settings\David\My
Documents\pyzui\pyzui\dynamictileprovider.py", line 55, in _load
    tile_id, True, filext=self.filext)
  File "C:\Documents and Settings\David\My
Documents\pyzui\pyzui\tilestore.py", line 72, in get_tile_path
    prefix = get_media_path(media_id)
  File "C:\Documents and Settings\David\My
Documents\pyzui\pyzui\tilestore.py", line 46, in get_media_path
    media_dir = os.path.join(tile_dir, media_hash)
  File "C:\Python26\lib\ntpath.py", line 97, in join
    if path[-1] in "/\\":
IndexError: cannot fit 'int' into an index-sized integer

I'm not sure if this error is related to the other errors, but similarly
this error only occurs in this specific thread.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6562>
_______________________________________

From report at bugs.python.org  Sat Jul 25 14:47:17 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 25 Jul 2009 12:47:17 +0000
Subject: [issue6562] OverflowError in RLock.acquire()
In-Reply-To: <1248525339.65.0.207294353555.issue6562@psf.upfronthosting.co.za>
Message-ID: <1248526206.5107.9.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le samedi 25 juillet 2009 ? 12:35 +0000, David Roberts a ?crit :
>   File "C:\Python26\lib\ntpath.py", line 97, in join
>     if path[-1] in "/\\":
> IndexError: cannot fit 'int' into an index-sized integer

This is definitely fishy and shouldn't happen in such a line of code.
Perhaps there is some deficient exception handling in one of the
extension modules you are using.

What if you remove calls to Image.open() (I assume it is the PIL
library?) and simply return filenames instead of Image objects?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6562>
_______________________________________

From report at bugs.python.org  Sat Jul 25 14:56:53 2009
From: report at bugs.python.org (Lucas Prado Melo)
Date: Sat, 25 Jul 2009 12:56:53 +0000
Subject: [issue6567] Make inf be almost equal to inf
In-Reply-To: <1248473136.17.0.947327850034.issue6567@psf.upfronthosting.co.za>
Message-ID: <1248526613.48.0.662450524709.issue6567@psf.upfronthosting.co.za>


Lucas Prado Melo <lucaspradomelo at gmail.com> added the comment:

I would like to ask as a feature request that "inf" be almost equal to
"inf".
I wrote a program with a timeline class that had a method to tell the
time of the last event registered into it such that some events would be
positioned at the infinite when they wouldn't occur. I did generic tests
that would receive any output from this method and compare to the
expected result through unittest.TestCase.assertAlmostEqual(). Notice,
though, that I couldn't just pick assertEqual() to do this job because
the time of the last event would be defined through a series of
calculations.
Despite that, I believe that everything which is equal to anything else
would definitely be almost equal too. Thus, it would be nice to check
for equality before checking for almost-equality to define whether two
objects are almost equal.

----------
status: closed -> open
title: Isn't inf  almost equal to inf? -> Make inf be almost equal to inf
type: behavior -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6567>
_______________________________________

From report at bugs.python.org  Sat Jul 25 15:02:26 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 25 Jul 2009 13:02:26 +0000
Subject: [issue6571] Help index
In-Reply-To: <1248524124.94.0.366651342464.issue6571@psf.upfronthosting.co.za>
Message-ID: <1248526946.78.0.0760214915817.issue6571@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Added index entries in r74200.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6571>
_______________________________________

From report at bugs.python.org  Sat Jul 25 15:20:01 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 25 Jul 2009 13:20:01 +0000
Subject: [issue6567] Make inf be almost equal to inf
In-Reply-To: <1248473136.17.0.947327850034.issue6567@psf.upfronthosting.co.za>
Message-ID: <1248528001.22.0.890549154502.issue6567@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6567>
_______________________________________

From report at bugs.python.org  Sat Jul 25 15:23:20 2009
From: report at bugs.python.org (Michael Foord)
Date: Sat, 25 Jul 2009 13:23:20 +0000
Subject: [issue6567] Make inf be almost equal to inf
In-Reply-To: <1248473136.17.0.947327850034.issue6567@psf.upfronthosting.co.za>
Message-ID: <1248528200.64.0.34387343588.issue6567@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Hmm... I guess equality does imply almost-equals. I'll make and document
the change that objects that compare equal will also compare almost equal.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6567>
_______________________________________

From report at bugs.python.org  Sat Jul 25 17:03:34 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 25 Jul 2009 15:03:34 +0000
Subject: [issue6518] Enable 'with' statement in ossaudiodev module
In-Reply-To: <1247965666.73.0.755368316919.issue6518@psf.upfronthosting.co.za>
Message-ID: <1248534214.14.0.775077632478.issue6518@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
versions:  -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6518>
_______________________________________

From report at bugs.python.org  Sat Jul 25 17:16:29 2009
From: report at bugs.python.org (Manas)
Date: Sat, 25 Jul 2009 15:16:29 +0000
Subject: [issue6572] Manas Thapliyal wants to chat
In-Reply-To: <f7e1212e0907250816h38602468p@mail.gmail.com>
Message-ID: <f7e1212e0907250816h38602468p@mail.gmail.com>


New submission from Manas <gravitywarrior1 at gmail.com>:

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

Manas Thapliyal wants to stay in better touch using some of Google's coolest new
products.

If you already have Gmail or Google Talk, visit:
http://mail.google.com/mail/b-6dec705464-1ad2ad81d2-c136c6a2ca2ffe8f
You'll need to click this link to be able to chat with Manas Thapliyal.

To get Gmail - a free email account from Google with over 2,800 megabytes of
storage - and chat with Manas Thapliyal, visit:
http://mail.google.com/mail/a-6dec705464-1ad2ad81d2-c136c6a2ca2ffe8f

Gmail offers:
- Instant messaging right inside Gmail
- Powerful spam protection
- Built-in search for finding your messages and a helpful way of organizing
  emails into "conversations"
- No pop-up ads or untargeted banners - just text ads and related information
  that are relevant to the content of your messages

All this, and its yours for free. But wait, there's more! By opening a Gmail
account, you also get access to Google Talk, Google's instant messaging
service:

http://www.google.com/talk/

Google Talk offers:
- Web-based chat that you can use anywhere, without a download
- A contact list that's synchronized with your Gmail account
- Free, high quality PC-to-PC voice calls when you download the Google Talk
  client

Gmail and Google Talk are still in beta. We're working hard to add new features
and make improvements, so we might also ask for your comments and suggestions
periodically. We appreciate your help in making our products even better!

Thanks,
The Google Team

To learn more about Gmail and Google Talk, visit:
http://mail.google.com/mail/help/about.html
http://www.google.com/talk/about.html

(If clicking the URLs in this message does not work, copy and paste them into
the address bar of your browser).

----------
messages: 90924
nosy: gravitywarrior1
severity: normal
status: open
title: Manas Thapliyal wants to chat

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6572>
_______________________________________

From report at bugs.python.org  Sat Jul 25 17:18:13 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 25 Jul 2009 15:18:13 +0000
Subject: [issue6572] Manas Thapliyal wants to chat
In-Reply-To: <f7e1212e0907250816h38602468p@mail.gmail.com>
Message-ID: <1248535093.82.0.138806037807.issue6572@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6572>
_______________________________________

From report at bugs.python.org  Sat Jul 25 17:24:21 2009
From: report at bugs.python.org (Shawn Smout)
Date: Sat, 25 Jul 2009 15:24:21 +0000
Subject: [issue6573] set union method ignores arguments appearing after the
	original set
In-Reply-To: <1248535461.31.0.573143089601.issue6573@psf.upfronthosting.co.za>
Message-ID: <1248535461.31.0.573143089601.issue6573@psf.upfronthosting.co.za>


New submission from Shawn Smout <silroquen at yahoo.com>:

When calling the union method of a set with several arguments, if one of
those sets is the original set, all arguments appearing after it are
ignored.  For example:

x = set()
x.union(set([1]), x, set([2]))

evaluates to set([1]), not set([1, 2]) as expected.  As another example,
since all empty frozensets are the same,

frozenset().union(frozenset([1]), frozenset(), frozenset([2]))

also evaluates to just frozenset([1]).

The fix is trivial, so I'm attaching a patch.

----------
files: set_union.patch
keywords: patch
messages: 90925
nosy: ssmout
severity: normal
status: open
title: set union method ignores arguments appearing after the original set
Added file: http://bugs.python.org/file14565/set_union.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6573>
_______________________________________

From report at bugs.python.org  Sat Jul 25 17:26:03 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 25 Jul 2009 15:26:03 +0000
Subject: [issue6573] set union method ignores arguments appearing after the
	original set
In-Reply-To: <1248535461.31.0.573143089601.issue6573@psf.upfronthosting.co.za>
Message-ID: <1248535563.43.0.920466518998.issue6573@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6573>
_______________________________________

From report at bugs.python.org  Sat Jul 25 19:02:56 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 25 Jul 2009 17:02:56 +0000
Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
Message-ID: <1248541376.92.0.97985528854.issue1424152@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

*Rereads latest patch*

I'm happy with this being backported as a bugfix to 3.1 and 2.6 so long
as the set_tunnel method is hidden.  Call it _set_tunnel() in the
backport (and don't document its existence).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1424152>
_______________________________________

From report at bugs.python.org  Sat Jul 25 19:20:53 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 25 Jul 2009 17:20:53 +0000
Subject: [issue6565] improper use of __setitem__ in ElementTree for Python 3.1
In-Reply-To: <1248464813.63.0.470228683416.issue6565@psf.upfronthosting.co.za>
Message-ID: <1248542453.42.0.759726358882.issue6565@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> effbot
nosy: +effbot
priority:  -> high
stage:  -> needs patch
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6565>
_______________________________________

From report at bugs.python.org  Sat Jul 25 19:23:38 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 25 Jul 2009 17:23:38 +0000
Subject: [issue6561] Regex '\d' should not match unicode category 'No'.
In-Reply-To: <1248432481.83.0.138486397936.issue6561@psf.upfronthosting.co.za>
Message-ID: <1248542618.95.0.340126603784.issue6561@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This sounds reasonable to me.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6561>
_______________________________________

From report at bugs.python.org  Sat Jul 25 19:34:16 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 25 Jul 2009 17:34:16 +0000
Subject: [issue6567] Make inf be almost equal to inf
In-Reply-To: <1248473136.17.0.947327850034.issue6567@psf.upfronthosting.co.za>
Message-ID: <1248543256.78.0.42171209112.issue6567@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

good catch.  thanks!

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6567>
_______________________________________

From report at bugs.python.org  Sat Jul 25 19:36:58 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 25 Jul 2009 17:36:58 +0000
Subject: [issue5511] zipfile - add __exit__ attribute to make ZipFile object
	compatible with with_statement
In-Reply-To: <1237400664.18.0.956324816364.issue5511@psf.upfronthosting.co.za>
Message-ID: <1248543418.78.0.516042756858.issue5511@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5511>
_______________________________________

From report at bugs.python.org  Sat Jul 25 20:01:51 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 25 Jul 2009 18:01:51 +0000
Subject: [issue6561] Regex '\d' should not match unicode category 'No'.
In-Reply-To: <1248432481.83.0.138486397936.issue6561@psf.upfronthosting.co.za>
Message-ID: <1248544911.79.0.95124691119.issue6561@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This seems to me quite redundant:
+      Matches any Unicode decimal digit; more specifically, matches
+      any character in Unicode category [Nd] (Number, Decimal Digit).
+      This includes ``[0-9]``, and also many other digit characters.
I suggest something like:
Matches the decimal digits ``[0-9]`` and all the characters that belong
to the Unicode category Nd (Number, Decimal Digit).

Two more minor details: instead of '\d', I'd use '^\d$' and instead of
self.assertEqual(re.match('\d', x), None)
self.assertIsNone(re.match('\d', x)).

----------
keywords: +needs review
priority:  -> normal
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6561>
_______________________________________

From report at bugs.python.org  Sat Jul 25 21:52:13 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 25 Jul 2009 19:52:13 +0000
Subject: [issue6567] Make inf be almost equal to inf
In-Reply-To: <1248473136.17.0.947327850034.issue6567@psf.upfronthosting.co.za>
Message-ID: <1248551533.86.0.454033311361.issue6567@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

[lucaspmelo]
> I would like to ask as a feature request that "inf" be almost equal to
> "inf".

Sounds reasonable to me.  Just so long as float('-inf') isn't almost equal 
to float('inf');  that would be weird.

One could almost make a case for values very close to the upper limit of 
the floating-point range being almost equal to float('inf'), but I think 
that's taking things a bit too far.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6567>
_______________________________________

From report at bugs.python.org  Sat Jul 25 22:29:06 2009
From: report at bugs.python.org (Michael Foord)
Date: Sat, 25 Jul 2009 20:29:06 +0000
Subject: [issue6567] Make inf be almost equal to inf
In-Reply-To: <1248473136.17.0.947327850034.issue6567@psf.upfronthosting.co.za>
Message-ID: <1248553746.48.0.688605941625.issue6567@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

All I'm proposing to do is add a short circuit equality test to
assertAlmostEquals.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6567>
_______________________________________

From report at bugs.python.org  Sun Jul 26 02:27:24 2009
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 26 Jul 2009 00:27:24 +0000
Subject: [issue5511] zipfile - add __exit__ attribute to make ZipFile object
	compatible with with_statement
In-Reply-To: <1237400664.18.0.956324816364.issue5511@psf.upfronthosting.co.za>
Message-ID: <1248568044.73.0.991082414164.issue5511@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Attached is a patch containing the fix, the updated tests, and the doc
change. Let me know if you have any questions, suggestions, etc.

----------
Added file: http://bugs.python.org/file14566/issue5511_complete.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5511>
_______________________________________

From report at bugs.python.org  Sun Jul 26 02:27:35 2009
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 26 Jul 2009 00:27:35 +0000
Subject: [issue5511] zipfile - add __exit__ attribute to make ZipFile object
	compatible with with_statement
In-Reply-To: <1237400664.18.0.956324816364.issue5511@psf.upfronthosting.co.za>
Message-ID: <1248568055.48.0.137457263972.issue5511@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


Removed file: http://bugs.python.org/file14554/zipfile_issue_5511.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5511>
_______________________________________

From report at bugs.python.org  Sun Jul 26 04:43:24 2009
From: report at bugs.python.org (David Roberts)
Date: Sun, 26 Jul 2009 02:43:24 +0000
Subject: [issue6562] OverflowError in RLock.acquire()
In-Reply-To: <1248434795.41.0.567943786679.issue6562@psf.upfronthosting.co.za>
Message-ID: <1248576204.01.0.844166839009.issue6562@psf.upfronthosting.co.za>


David Roberts <d at vidr.cc> added the comment:

Yes, it is the PIL library. Removing calls to Image.open() still results
in the same error - the exception is thrown before it even reaches that
bit of the code anyway.

Another odd thing is that the exception is only thrown on some of the
calls to get_tile_path, every second call to be exact - see the attached
log file.

I'm also attaching the relevant code from tilestore.py.

----------
Added file: http://bugs.python.org/file14567/osm.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6562>
_______________________________________

From report at bugs.python.org  Sun Jul 26 04:44:11 2009
From: report at bugs.python.org (David Roberts)
Date: Sun, 26 Jul 2009 02:44:11 +0000
Subject: [issue6562] OverflowError in RLock.acquire()
In-Reply-To: <1248434795.41.0.567943786679.issue6562@psf.upfronthosting.co.za>
Message-ID: <1248576251.62.0.698637036907.issue6562@psf.upfronthosting.co.za>


Changes by David Roberts <d at vidr.cc>:


Added file: http://bugs.python.org/file14568/tilestore.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6562>
_______________________________________

From report at bugs.python.org  Sun Jul 26 05:13:40 2009
From: report at bugs.python.org (Senthil)
Date: Sun, 26 Jul 2009 03:13:40 +0000
Subject: [issue6557] urllib.urlopen creates bad requests when location header
	of 301 redirects contain spaces
In-Reply-To: <1248385969.73.0.0313821964129.issue6557@psf.upfronthosting.co.za>
Message-ID: <1248578020.72.0.192938938285.issue6557@psf.upfronthosting.co.za>


Changes by Senthil <orsenthil at gmail.com>:


----------
assignee:  -> orsenthil
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6557>
_______________________________________

From report at bugs.python.org  Sun Jul 26 06:52:18 2009
From: report at bugs.python.org (Bob Ippolito)
Date: Sun, 26 Jul 2009 04:52:18 +0000
Subject: [issue6566] json.dumps converts None to "null" (not null)
In-Reply-To: <1248469678.72.0.793111928959.issue6566@psf.upfronthosting.co.za>
Message-ID: <1248583938.25.0.42553944699.issue6566@psf.upfronthosting.co.za>


Bob Ippolito <bob at redivi.com> added the comment:

JP is correct, this is how JSON works. The behavior of coercing keys to 
strings is often desirable, although I agree it could be confusing if you 
aren't familiar with the JSON spec.

----------
components: +Documentation -Library (Lib)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6566>
_______________________________________

From report at bugs.python.org  Sun Jul 26 10:29:53 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 26 Jul 2009 08:29:53 +0000
Subject: [issue481171] Hang using files named prn.txt, etc
Message-ID: <1248596993.64.0.789941545588.issue481171@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue481171>
_______________________________________

From report at bugs.python.org  Sun Jul 26 11:34:13 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 26 Jul 2009 09:34:13 +0000
Subject: [issue6574] List the __future__ features in a table
In-Reply-To: <1248600853.49.0.371600667943.issue6574@psf.upfronthosting.co.za>
Message-ID: <1248600853.49.0.371600667943.issue6574@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

The documentation about the __future__ features [1] only lists the
features available for that particular version, without specifying when
they were added and their effects.
It would be nice to have a table with |feature|version added|effect|.
A better place for this table could also be the page of the __future__
module [2].

[1]: http://docs.python.org/reference/simple_stmts.html#future
[2]: http://docs.python.org/library/__future__.html

----------
assignee: ezio.melotti
components: Documentation
keywords: easy
messages: 90935
nosy: ezio.melotti
priority: low
severity: normal
stage: needs patch
status: open
title: List the __future__ features in a table
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6574>
_______________________________________

From report at bugs.python.org  Sun Jul 26 12:28:53 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 26 Jul 2009 10:28:53 +0000
Subject: [issue6567] Make inf be almost equal to inf
In-Reply-To: <1248473136.17.0.947327850034.issue6567@psf.upfronthosting.co.za>
Message-ID: <1248604133.18.0.22830688109.issue6567@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Sounds good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6567>
_______________________________________

From report at bugs.python.org  Sun Jul 26 12:32:20 2009
From: report at bugs.python.org (Ori Avtalion)
Date: Sun, 26 Jul 2009 10:32:20 +0000
Subject: [issue1820] Enhance Object/structseq.c to match namedtuple and
	tuple	api
In-Reply-To: <1200284428.58.0.762384814897.issue1820@psf.upfronthosting.co.za>
Message-ID: <1248604340.14.0.608771123283.issue1820@psf.upfronthosting.co.za>


Changes by Ori Avtalion <ori at avtalion.name>:


----------
nosy: +salty-horse

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1820>
_______________________________________

From report at bugs.python.org  Sun Jul 26 14:21:53 2009
From: report at bugs.python.org (Jan Kaliszewski)
Date: Sun, 26 Jul 2009 12:21:53 +0000
Subject: [issue6575] Can't download docs
In-Reply-To: <1248610913.94.0.0307799249969.issue6575@psf.upfronthosting.co.za>
Message-ID: <1248610913.94.0.0307799249969.issue6575@psf.upfronthosting.co.za>


New submission from Jan Kaliszewski <zuo at chopin.edu.pl>:

http://docs.python.org/3.1/download.html (available both with 'Download 
these documents' link @docs and 'Download Current Python 3.1 
Documentation' link @http://www.python.org/doc/) doesn't contain links 
to packed docs, but text for dev-releases:

"We don't package the documentation for development releases for 
download. Downloads will be available for the final release."

----------
assignee: georg.brandl
components: Documentation
messages: 90937
nosy: georg.brandl, zuo
severity: normal
status: open
title: Can't download docs
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6575>
_______________________________________

From report at bugs.python.org  Sun Jul 26 14:41:19 2009
From: report at bugs.python.org (Senthil)
Date: Sun, 26 Jul 2009 12:41:19 +0000
Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
Message-ID: <1248612079.86.0.362061126163.issue1424152@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

Agreed to the suggestions made by Greg.
The fix is now backported.
For Py2.6 in the revision 74203.
For Py3k in the revision 74204.

Closing this issue.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1424152>
_______________________________________

From report at bugs.python.org  Sun Jul 26 14:42:52 2009
From: report at bugs.python.org (Robert Lehmann)
Date: Sun, 26 Jul 2009 12:42:52 +0000
Subject: [issue6574] List the __future__ features in a table
In-Reply-To: <1248600853.49.0.371600667943.issue6574@psf.upfronthosting.co.za>
Message-ID: <1248612172.68.0.0157037142893.issue6574@psf.upfronthosting.co.za>


Robert Lehmann <lehmannro at gmail.com> added the comment:

I composed a list of __future__ features and linked the respective PEPs.

Even though the language reference would be a better place to store such
general information (being PEP'd and all) I found the library
reference's __future__.py documentation to be a cleaner host for that table.

Python 3 docs would need to add the barry_as_FLUFL feature to that table.

----------
keywords: +patch
nosy: +lehmannro
Added file: http://bugs.python.org/file14569/future.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6574>
_______________________________________

From report at bugs.python.org  Sun Jul 26 14:44:05 2009
From: report at bugs.python.org (Senthil)
Date: Sun, 26 Jul 2009 12:44:05 +0000
Subject: [issue1448934] urllib2+https+proxy not working
Message-ID: <1248612245.27.0.922445021076.issue1448934@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

Well, the fix for this same as that for Issue1424152.
Closing this issue as it is already handled.

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1448934>
_______________________________________

From report at bugs.python.org  Sun Jul 26 15:13:12 2009
From: report at bugs.python.org (Jan Kaliszewski)
Date: Sun, 26 Jul 2009 13:13:12 +0000
Subject: [issue6576] re docs: wrong link targets
In-Reply-To: <1248613991.98.0.0140220759492.issue6576@psf.upfronthosting.co.za>
Message-ID: <1248613991.98.0.0140220759492.issue6576@psf.upfronthosting.co.za>


New submission from Jan Kaliszewski <zuo at chopin.edu.pl>:

Some of links in re docs should lead to RegexObject.match()|
RegexObject.search() method but lead to re.match()|re.search() module 
function.

These are the places in 2.6 docs (in 2.7-3.2 versions' you'll find the 
bug in analogous places):

http://docs.python.org/library/re.html#re.compile
http://docs.python.org/library/re.html#re.RegexObject.match
http://docs.python.org/library/re.html#re.RegexObject.search
http://docs.python.org/library/re.html#re.MatchObject.pos
http://docs.python.org/library/re.html#re.MatchObject.endpos
http://docs.python.org/library/re.html#re.MatchObject.re
http://docs.python.org/library/re.html#re.MatchObject.string (<- here 
maybe both possibilities should be noted, which would mean changing not 
only link targets but also the content)

----------
assignee: georg.brandl
components: Documentation
messages: 90941
nosy: georg.brandl, zuo
severity: normal
status: open
title: re docs: wrong link targets
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6576>
_______________________________________

From report at bugs.python.org  Sun Jul 26 15:37:16 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 26 Jul 2009 13:37:16 +0000
Subject: [issue6576] re docs: wrong link targets
In-Reply-To: <1248613991.98.0.0140220759492.issue6576@psf.upfronthosting.co.za>
Message-ID: <1248615436.8.0.245135538669.issue6576@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks for the report, I fixed the references (and a few to compile())
in r74205.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6576>
_______________________________________

From report at bugs.python.org  Sun Jul 26 15:38:30 2009
From: report at bugs.python.org (Jan Kaliszewski)
Date: Sun, 26 Jul 2009 13:38:30 +0000
Subject: [issue6577] Links wrongly targeting to builtin functions' instead of
	module functions/methods
In-Reply-To: <1248615510.07.0.327416656356.issue6577@psf.upfronthosting.co.za>
Message-ID: <1248615510.07.0.327416656356.issue6577@psf.upfronthosting.co.za>


New submission from Jan Kaliszewski <zuo at chopin.edu.pl>:

The problem can be found in many places in docs -- tipically, where 
there is a function/method with name identical to builtin name (or 
sometimes to another function/method within the same module -- see: 
#6575): links leads to te latter but should lead to the former.

One example -- open():

http://docs.python.org/library/shelve.html?
highlight=open#shelve.DbfilenameShelf
http://docs.python.org/library/shelve.html?highlight=open#example

http://docs.python.org/library/sunau.html?highlight=open#sunau.openfp
http://docs.python.org/library/sunau.html?highlight=open#au-read-objects
http://docs.python.org/library/sunau.html?highlight=open#au-write-
objects

http://docs.python.org/library/wave.html?highlight=open#wave.openfp
http://docs.python.org/library/wave.html?highlight=open#wave-read-
objects
http://docs.python.org/library/wave.html?highlight=open#wave-write-
objects

http://docs.python.org/library/io.html?highlight=open#module-interface
http://docs.python.org/library/io.html?highlight=open#io.open
http://docs.python.org/library/io.html?highlight=open#io.IOBase.readline

It's hard to find all such place by hand; probably it's a job for a 
script...

----------
assignee: georg.brandl
components: Documentation
messages: 90943
nosy: georg.brandl, zuo
severity: normal
status: open
title: Links wrongly targeting to builtin functions' instead of module functions/methods
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6577>
_______________________________________

From report at bugs.python.org  Sun Jul 26 15:44:06 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 26 Jul 2009 13:44:06 +0000
Subject: [issue6575] Can't download docs
In-Reply-To: <1248610913.94.0.0307799249969.issue6575@psf.upfronthosting.co.za>
Message-ID: <1248615846.01.0.258251053847.issue6575@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r74206; the online version should be updated soon.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6575>
_______________________________________

From report at bugs.python.org  Sun Jul 26 15:57:09 2009
From: report at bugs.python.org (Jan Kaliszewski)
Date: Sun, 26 Jul 2009 13:57:09 +0000
Subject: [issue6578] 2 problems with 'Docs for other versions' section on left
	HTML docs sidebar
In-Reply-To: <1248616629.63.0.429238805122.issue6578@psf.upfronthosting.co.za>
Message-ID: <1248616629.63.0.429238805122.issue6578@psf.upfronthosting.co.za>


New submission from Jan Kaliszewski <zuo at chopin.edu.pl>:

* In 2.6 the content of that section isn't up to date (3.1 is 
descripted as 'in development')

* In 3.0 there is no that section.

----------
messages: 90945
nosy: zuo
severity: normal
status: open
title: 2 problems with 'Docs for other versions' section on left HTML docs sidebar
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6578>
_______________________________________

From report at bugs.python.org  Sun Jul 26 15:57:21 2009
From: report at bugs.python.org (Jan Kaliszewski)
Date: Sun, 26 Jul 2009 13:57:21 +0000
Subject: [issue6578] 2 problems with 'Docs for other versions' section on left
	HTML docs sidebar
In-Reply-To: <1248616629.63.0.429238805122.issue6578@psf.upfronthosting.co.za>
Message-ID: <1248616641.25.0.918782132131.issue6578@psf.upfronthosting.co.za>


Changes by Jan Kaliszewski <zuo at chopin.edu.pl>:


----------
assignee:  -> georg.brandl
components: +Documentation
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6578>
_______________________________________

From report at bugs.python.org  Sun Jul 26 16:11:09 2009
From: report at bugs.python.org (Jan Kaliszewski)
Date: Sun, 26 Jul 2009 14:11:09 +0000
Subject: [issue6579] No update about automatic numbering of fields in format
	strings (e.g. 'A {} with {} buttocks')
In-Reply-To: <1248617469.33.0.437131453768.issue6579@psf.upfronthosting.co.za>
Message-ID: <1248617469.33.0.437131453768.issue6579@psf.upfronthosting.co.za>


New submission from Jan Kaliszewski <zuo at chopin.edu.pl>:

As we can read in http://docs.python.org/3.1/whatsnew/3.1.html#other-
language-changes:

----
The fields in format() strings can now be automatically numbered:
>>> 'Sir {} of {}'.format('Gallahad', 'Camelot')
'Sir Gallahad of Camelot'

Formerly, the string would have required numbered fields such as: 'Sir 
{0} of {1}'.

(Contributed by Eric Smith; issue 5237.)
----

But it is not mentioned in 3.2's, 3.1's and 2.7's docs about format 
string syntax, e.g. in 3.1 docs we have:

http://docs.python.org/3.1/library/string.html#format-string-syntax

[Please note that also grammar for a replacement field should be 
updated there ('field_name' should be in '[' ']', but I'm not sure if 
it'd be enough)].

----------
assignee: georg.brandl
components: Documentation
messages: 90946
nosy: georg.brandl, zuo
severity: normal
status: open
title: No update about automatic numbering of fields in format strings (e.g. 'A {} with {} buttocks')
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6579>
_______________________________________

From report at bugs.python.org  Sun Jul 26 16:20:05 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 26 Jul 2009 14:20:05 +0000
Subject: [issue6577] Links wrongly targeting to builtin functions' instead of
	module functions/methods
In-Reply-To: <1248615510.07.0.327416656356.issue6577@psf.upfronthosting.co.za>
Message-ID: <1248618005.9.0.348910214597.issue6577@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I made an exhaustive search for all builtins; should now be fixed in
r74207. Thanks for making me do it properly :)

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6577>
_______________________________________

From report at bugs.python.org  Sun Jul 26 16:22:06 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 26 Jul 2009 14:22:06 +0000
Subject: [issue6579] No update about automatic numbering of fields in format
	strings (e.g. 'A {} with {} buttocks')
In-Reply-To: <1248617469.33.0.437131453768.issue6579@psf.upfronthosting.co.za>
Message-ID: <1248618126.56.0.799513241904.issue6579@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The 2.6 one looks fine to me; 3.2 is correctly marked as in development
there.

I don't care about 3.0; it's not supported anymore.

----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6579>
_______________________________________

From report at bugs.python.org  Sun Jul 26 16:24:38 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 26 Jul 2009 14:24:38 +0000
Subject: [issue6579] No update about automatic numbering of fields in format
	strings (e.g. 'A {} with {} buttocks')
In-Reply-To: <1248617469.33.0.437131453768.issue6579@psf.upfronthosting.co.za>
Message-ID: <1248618278.82.0.837998439259.issue6579@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Argh, of course it's even more important to point to the current version
for 3.0... fixed in r74208.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6579>
_______________________________________

From report at bugs.python.org  Sun Jul 26 16:24:46 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 26 Jul 2009 14:24:46 +0000
Subject: [issue6579] No update about automatic numbering of fields in format
	strings (e.g. 'A {} with {} buttocks')
In-Reply-To: <1248617469.33.0.437131453768.issue6579@psf.upfronthosting.co.za>
Message-ID: <1248618286.82.0.192317789819.issue6579@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6579>
_______________________________________

From report at bugs.python.org  Sun Jul 26 16:25:03 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 26 Jul 2009 14:25:03 +0000
Subject: [issue6579] No update about automatic numbering of fields in format
	strings (e.g. 'A {} with {} buttocks')
In-Reply-To: <1248617469.33.0.437131453768.issue6579@psf.upfronthosting.co.za>
Message-ID: <1248618303.17.0.476129998718.issue6579@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6579>
_______________________________________

From report at bugs.python.org  Sun Jul 26 16:25:22 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 26 Jul 2009 14:25:22 +0000
Subject: [issue6578] 2 problems with 'Docs for other versions' section on left
	HTML docs sidebar
In-Reply-To: <1248616629.63.0.429238805122.issue6578@psf.upfronthosting.co.za>
Message-ID: <1248618322.08.0.224967196351.issue6578@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The 2.6 one looks fine to me; 3.2 is correctly marked as in development
there.

Added the section to 3.0 branch in r74208.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6578>
_______________________________________

From report at bugs.python.org  Sun Jul 26 16:25:48 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 26 Jul 2009 14:25:48 +0000
Subject: [issue6579] No update about automatic numbering of fields in format
	strings (e.g. 'A {} with {} buttocks')
In-Reply-To: <1248617469.33.0.437131453768.issue6579@psf.upfronthosting.co.za>
Message-ID: <1248618348.8.0.259471504795.issue6579@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

(Sorry for my confusion, reopening.)

----------
assignee: georg.brandl -> eric.smith
nosy: +eric.smith
resolution: works for me -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6579>
_______________________________________

From report at bugs.python.org  Sun Jul 26 19:21:33 2009
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Sun, 26 Jul 2009 17:21:33 +0000
Subject: [issue2698] Extension module build fails for MinGW: missing
	vcvarsall.bat
In-Reply-To: <1209230424.66.0.154562223128.issue2698@psf.upfronthosting.co.za>
Message-ID: <1248628893.65.0.586871298898.issue2698@psf.upfronthosting.co.za>


Changes by Hagen F?rstenau <hfuerstenau at gmx.net>:


----------
nosy: +hagen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2698>
_______________________________________

From report at bugs.python.org  Sun Jul 26 19:25:03 2009
From: report at bugs.python.org (Michael R Bax)
Date: Sun, 26 Jul 2009 17:25:03 +0000
Subject: [issue6580] No deprecation warning for list comprehension leak
	conflict
In-Reply-To: <1248629103.59.0.528554407036.issue6580@psf.upfronthosting.co.za>
Message-ID: <1248629103.59.0.528554407036.issue6580@psf.upfronthosting.co.za>


New submission from Michael R Bax <mrbax at users.sourceforge.net>:

PEP 289 states that "Python 2.4 and beyond should issue a deprecation 
warning if a list comprehension's loop variable has the same name as a 
variable used in the immediately surrounding scope".  But no warning is 
shown when running
    for x in [ 0 ]: print [ x for x in [ 1 ] ]
in Python 2.5.2 (at least).

----------
components: Interpreter Core
messages: 90952
nosy: mrbax
severity: normal
status: open
title: No deprecation warning for list comprehension leak conflict
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6580>
_______________________________________

From report at bugs.python.org  Sun Jul 26 20:03:05 2009
From: report at bugs.python.org (Ori Avtalion)
Date: Sun, 26 Jul 2009 18:03:05 +0000
Subject: [issue1820] Enhance Object/structseq.c to match namedtuple and
	tuple	api
In-Reply-To: <1200284428.58.0.762384814897.issue1820@psf.upfronthosting.co.za>
Message-ID: <1248631385.82.0.17199602396.issue1820@psf.upfronthosting.co.za>


Ori Avtalion <ori at avtalion.name> added the comment:

For those who missed it, the patch that was committed in r59967 was
quickly reverted in r59970 with the comment:

"Temporarily revert 59967 until GC can be added."

Raymond, can you please explain what was missing from the patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1820>
_______________________________________

From report at bugs.python.org  Sun Jul 26 21:11:53 2009
From: report at bugs.python.org (Matthew Barnett)
Date: Sun, 26 Jul 2009 19:11:53 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1248635513.59.0.91169053599.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

issue2636-20090726.zip is a new implementation of the re engine. It
replaces re.py, sre.py, sre_constants.py, sre_parse.py and
sre_compile.py with a new re.py and replaces sre_constants.h, sre.h and
_sre.c with _re.h and _re.c.

The internal engine no longer interprets a form of bytecode but instead
follows a linked set of nodes, and it can work breadth-wise as well as
depth-first, which makes it perform much better when faced with one of
those 'pathological' regexes.

It supports scoped flags, variable-length lookbehind, Unicode
properties, named characters, atomic groups, possessive quantifiers, and
will handle zero-width splits correctly when the ZEROWIDTH flag is set.

There are a few more things to add, like allowing indexing for capture
groups, and further speed improvements might be possible (at worst it's
roughly the same speed as the existing re module).

I'll be adding some documentation about how it works and the slight
differences in behaviour later.

----------
Added file: http://bugs.python.org/file14570/issue2636-20090726.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Sun Jul 26 22:21:36 2009
From: report at bugs.python.org (Michael Foord)
Date: Sun, 26 Jul 2009 20:21:36 +0000
Subject: [issue6581] inspect.py sys._getframe patch for Python 2.6
In-Reply-To: <1248639696.3.0.831428549243.issue6581@psf.upfronthosting.co.za>
Message-ID: <1248639696.3.0.831428549243.issue6581@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

Patch for inspect.py so that it will import correctly even if
sys._getframe is unavailable. 

Without this patch inspect can't be imported under IronPython 2.6
(breaking basic features like help) when started without Python stack
frame support.

The same fix is required on trunk.

----------
assignee: michael.foord
components: Library (Lib)
files: inspect.patch
keywords: needs review, patch, patch
messages: 90955
nosy: michael.foord
severity: normal
status: open
title: inspect.py sys._getframe patch for Python 2.6
type: behavior
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file14571/inspect.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6581>
_______________________________________

From report at bugs.python.org  Sun Jul 26 22:27:21 2009
From: report at bugs.python.org (Michael Foord)
Date: Sun, 26 Jul 2009 20:27:21 +0000
Subject: [issue6581] inspect.py sys._getframe patch for Python 2.6
In-Reply-To: <1248639696.3.0.831428549243.issue6581@psf.upfronthosting.co.za>
Message-ID: <1248640041.52.0.309364679285.issue6581@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

hmm... the lambda should probably take an argument like sys._getframe.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6581>
_______________________________________

From report at bugs.python.org  Sun Jul 26 22:29:50 2009
From: report at bugs.python.org (Neil Tallim)
Date: Sun, 26 Jul 2009 20:29:50 +0000
Subject: [issue1721862] email.FeedParser.BufferedSubFile improperly handles
	"\r\n"
Message-ID: <1248640190.36.0.414622643309.issue1721862@psf.upfronthosting.co.za>


Neil Tallim <red.hamsterx at gmail.com> added the comment:

Attached a patch containing a unit test based on Sye van der Veen's
example and a solution for this problem.

Written against Python 2.6 (trunk), r74214, which was current at the
time of submission.

This is my first patch, so please let me know if I did something wrong
or overstepped bounds by not noticing that this was assigned until after
writing this fix.

----------
keywords: +patch
nosy: +Red HamsterX
Added file: http://bugs.python.org/file14572/1721862.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1721862>
_______________________________________

From report at bugs.python.org  Sun Jul 26 23:02:04 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sun, 26 Jul 2009 21:02:04 +0000
Subject: [issue6499] Can't import xmlrpclib,
	DocXMLRPCServer and SimpleXMLRPCServer when zlib is not available
In-Reply-To: <1247797208.72.0.744238846554.issue6499@psf.upfronthosting.co.za>
Message-ID: <1248642124.17.0.866851664912.issue6499@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Ah, so this is an interpreter shutdown issue, it seems.
Something is causing this thread to not exit until the application exits 
and that can cause all sorts of weird race conditions.  I wonder why that 
is happening.  There must be an issue with test_valid_get_response

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6499>
_______________________________________

From report at bugs.python.org  Sun Jul 26 23:12:59 2009
From: report at bugs.python.org (Michael Foord)
Date: Sun, 26 Jul 2009 21:12:59 +0000
Subject: [issue6581] inspect.py sys._getframe patch for Python 2.6
In-Reply-To: <1248639696.3.0.831428549243.issue6581@psf.upfronthosting.co.za>
Message-ID: <1248642779.98.0.537061658881.issue6581@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Committed in revision 74215 & revision 74216.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6581>
_______________________________________

From report at bugs.python.org  Sun Jul 26 23:15:05 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sun, 26 Jul 2009 21:15:05 +0000
Subject: [issue6499] Can't import xmlrpclib,
	DocXMLRPCServer and SimpleXMLRPCServer when zlib is not available
In-Reply-To: <1247797208.72.0.744238846554.issue6499@psf.upfronthosting.co.za>
Message-ID: <1248642905.47.0.0372246260065.issue6499@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

No, sorry.  You have just introduced the race condition by putting a print 
after the evt.set().  Setting the event causes the main thread to exit 
python and so anything after that line will likely not work.

In fact, this is probably the reason why we didn't get any sensible error 
output, because error of the evt.set in the finally.
Please try the modified version attatched.

----------
Added file: http://bugs.python.org/file14573/test_docxmlrpc.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6499>
_______________________________________

From report at bugs.python.org  Sun Jul 26 23:29:25 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 26 Jul 2009 21:29:25 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1248643765.26.0.154033969763.issue2636@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Sounds like this is an awesome piece of work!

Since the patch is obviously a very large piece and will be hard to
review, may I suggest releasing the new engine as a standalone package
and spreading the word, so that people can stress-test it?  By the time
2.7 is ready to release, if it has had considerable exposure to the
public, that will help acceptance greatly.

The Unicode script identification might not be hard to add to
unicodedata; maybe Martin can do that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Mon Jul 27 00:26:19 2009
From: report at bugs.python.org (Jack Diederich)
Date: Sun, 26 Jul 2009 22:26:19 +0000
Subject: [issue6106] read_until
In-Reply-To: <1243267985.99.0.238483902734.issue6106@psf.upfronthosting.co.za>
Message-ID: <1248647179.27.0.896354082089.issue6106@psf.upfronthosting.co.za>


Jack Diederich <jackdied at gmail.com> added the comment:

fixed in r74217

My thanks to everyone who contributed to this bug.  "irek" if you let me
know your name I'll add it to Misc/ACKS as well.

PS, The additional testcase is not ideal;  it tests the bad behavior by
hooking into the debug output instead of testing the bug directly.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6106>
_______________________________________

From report at bugs.python.org  Mon Jul 27 00:30:33 2009
From: report at bugs.python.org (Jack Diederich)
Date: Sun, 26 Jul 2009 22:30:33 +0000
Subject: [issue6582] test_telnetlib doesn't test Telnet.write
In-Reply-To: <1248647432.95.0.0572688649106.issue6582@psf.upfronthosting.co.za>
Message-ID: <1248647432.95.0.0572688649106.issue6582@psf.upfronthosting.co.za>


New submission from Jack Diederich <jackdied at gmail.com>:

test/test_telnetlib.py has zero tests for the telnetlib.Telnet.write method.

----------
assignee: jackdied
messages: 90963
nosy: jackdied
severity: normal
status: open
title: test_telnetlib doesn't test Telnet.write
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6582>
_______________________________________

From report at bugs.python.org  Mon Jul 27 00:50:42 2009
From: report at bugs.python.org (Jack Diederich)
Date: Sun, 26 Jul 2009 22:50:42 +0000
Subject: [issue5188] telnetlib process_rawq buffer handling is confused
In-Reply-To: <1234131372.15.0.372715702734.issue5188@psf.upfronthosting.co.za>
Message-ID: <1248648642.55.0.983875873672.issue5188@psf.upfronthosting.co.za>


Jack Diederich <jackdied at gmail.com> added the comment:

between r71434 and r74217 this should be fixed for 3.2.

Marking as closed.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5188>
_______________________________________

From report at bugs.python.org  Mon Jul 27 00:55:34 2009
From: report at bugs.python.org (Jack Diederich)
Date: Sun, 26 Jul 2009 22:55:34 +0000
Subject: [issue1360221] telnetlib expect() and read_until() do not time out
	properly
Message-ID: <1248648934.86.0.584039088116.issue1360221@psf.upfronthosting.co.za>


Jack Diederich <jackdied at gmail.com> added the comment:

this was fixed in r47215 (circa 2006).  Marking closed.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1360221>
_______________________________________

From report at bugs.python.org  Mon Jul 27 01:07:40 2009
From: report at bugs.python.org (Jack Diederich)
Date: Sun, 26 Jul 2009 23:07:40 +0000
Subject: [issue1772794] Telnetlib dosn't accept u'only ascii'
Message-ID: <1248649660.38.0.966509747759.issue1772794@psf.upfronthosting.co.za>


Jack Diederich <jackdied at gmail.com> added the comment:

Marking closed/won't fix.  ASCII strings are the byte-ish type in 2.x so
we should expect the caller to convert down from unicode when sending
bytes over the wire.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1772794>
_______________________________________

From report at bugs.python.org  Mon Jul 27 01:26:07 2009
From: report at bugs.python.org (Jack Diederich)
Date: Sun, 26 Jul 2009 23:26:07 +0000
Subject: [issue6582] test_telnetlib doesn't test Telnet.write
In-Reply-To: <1248647432.95.0.0572688649106.issue6582@psf.upfronthosting.co.za>
Message-ID: <1248650767.86.0.468112141145.issue6582@psf.upfronthosting.co.za>


Jack Diederich <jackdied at gmail.com> added the comment:

Marking as easy.  What needs to be done is to add a small fake socket
class that redefines socket.sendall(self, bytes) to capture the args to
sock.sendall so it can be assertEqual'd to the expected bytes.

class SocketSendall(socket.socket):
  _raw_sent = b''
  def sendall(self, data):
    self._raw_sent += data

class TelnetSockSendall(telnetlib.Telnet):
  def open(self, *args, **opts):
    ''' a near-exact copy of Telnet.open '''
    # copy 5 lines from Telnet.open here
    self.sock = SocketSendall(*args, **opts)

then add a unit test that checks the ONLY thing Telnet.write() does,
which is change IAC to IAC+IAC.

----------
components: +Tests
keywords: +easy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6582>
_______________________________________

From report at bugs.python.org  Mon Jul 27 02:12:36 2009
From: report at bugs.python.org (Jack Diederich)
Date: Mon, 27 Jul 2009 00:12:36 +0000
Subject: [issue3071] The ValueError raised by failing to unpack sequence
	should have more information.
In-Reply-To: <1213063566.77.0.933941671492.issue3071@psf.upfronthosting.co.za>
Message-ID: <1248653556.51.0.626153994482.issue3071@psf.upfronthosting.co.za>


Jack Diederich <jackdied at gmail.com> added the comment:

The code that raises the error is in ceval.c which is a critical path. 
The raise is done as soon the iterator has one more item than is needed
(see Daniel Diniz's comments on infinite iterators).  While the check
could return more useful information for known non-infinite iterators
(tuples, lists, etc) it would have to do a big if/else for all the core
types (but excluding their subclasses!).  If someone wants to submit
that patch and a benchmark that shows no slowdown I'll reopen the bug.

Until then I'm closing as WONTFIX.

----------
nosy: +jackdied
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3071>
_______________________________________

From report at bugs.python.org  Mon Jul 27 02:26:17 2009
From: report at bugs.python.org (Jack Diederich)
Date: Mon, 27 Jul 2009 00:26:17 +0000
Subject: [issue2874] Remove use of the stat module in the stdlib
In-Reply-To: <1210913145.44.0.456986373707.issue2874@psf.upfronthosting.co.za>
Message-ID: <1248654377.54.0.699138744854.issue2874@psf.upfronthosting.co.za>


Jack Diederich <jackdied at gmail.com> added the comment:

The stat module wasn't deprecated in 3.1, so is this now a non-issue? 
If not, is it related to issue#1820?

----------
nosy: +jackdied

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2874>
_______________________________________

From report at bugs.python.org  Mon Jul 27 02:32:57 2009
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 27 Jul 2009 00:32:57 +0000
Subject: [issue2874] Remove use of the stat module in the stdlib
In-Reply-To: <1210913145.44.0.456986373707.issue2874@psf.upfronthosting.co.za>
Message-ID: <1248654777.56.0.299799712175.issue2874@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

At this point it is a nice idea that no one wants to deal with to make 
happen. Dropping the priority but leaving open for now until I get around 
to making a final decision as to whether to just give up on this to 
finally allow closure on PEP 3108 once profile/cProfile are merged.

----------
priority: critical -> low
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2874>
_______________________________________

From report at bugs.python.org  Mon Jul 27 03:01:14 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 27 Jul 2009 01:01:14 +0000
Subject: [issue6550] asyncore incorrect failure when connection is refused and
	using async_chat channel
In-Reply-To: <1248302571.21.0.910158552759.issue6550@psf.upfronthosting.co.za>
Message-ID: <1248656474.47.0.171539009937.issue6550@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +josiahcarlson
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6550>
_______________________________________

From report at bugs.python.org  Mon Jul 27 04:23:11 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 27 Jul 2009 02:23:11 +0000
Subject: [issue6561] Regex '\d' should not match unicode category 'No'.
In-Reply-To: <1248432481.83.0.138486397936.issue6561@psf.upfronthosting.co.za>
Message-ID: <1248661391.31.0.58046010873.issue6561@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It may be redundant, but it is also more technically accurate.  I'm -0
on your proposed rephrasing, and trust Mark to make the right decision :)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6561>
_______________________________________

From report at bugs.python.org  Mon Jul 27 04:35:45 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 27 Jul 2009 02:35:45 +0000
Subject: [issue3071] The ValueError raised by failing to unpack sequence
	should have more information.
In-Reply-To: <1213063566.77.0.933941671492.issue3071@psf.upfronthosting.co.za>
Message-ID: <1248662145.6.0.375261272806.issue3071@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Here's a patch implementing part of the requested feature.

pystones cannot tell the difference between trunk at HEAD with or without
this patch applied.  Both report a maximum of 78125 pystones/second/

----------
keywords: +patch
nosy: +exarkun
Added file: http://bugs.python.org/file14574/how-many-values.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3071>
_______________________________________

From report at bugs.python.org  Mon Jul 27 04:39:19 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 27 Jul 2009 02:39:19 +0000
Subject: [issue1194378] sendmsg() and recvmsg() for C socket module
Message-ID: <1248662359.79.0.226570335658.issue1194378@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Closing this as duplicate of #6560.

----------
nosy: +ezio.melotti
resolution:  -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1194378>
_______________________________________

From report at bugs.python.org  Mon Jul 27 05:46:24 2009
From: report at bugs.python.org (Jack Diederich)
Date: Mon, 27 Jul 2009 03:46:24 +0000
Subject: [issue3071] The ValueError raised by failing to unpack sequence
	should have more information.
In-Reply-To: <1213063566.77.0.933941671492.issue3071@psf.upfronthosting.co.za>
Message-ID: <1248666384.49.0.305150249782.issue3071@psf.upfronthosting.co.za>


Jack Diederich <jackdied at gmail.com> added the comment:

I was looking at 3.x, JP's patch is relative to 2.x and takes a little
more unpacking (a couple function calls more) but looks to me to be the
same.  In 2.x unpack_iterable() sets/returns an error once one item more
than is required is received.  It doesn't give any more information
about known-length builtins than anything else.  The same error is
raised for million-item lists as three item lists if the expected number
to unpack is two.

The original feature request was that the error message be better if,
say the left hand side wanted three arguments and the right hand side
provided four.  The ceval.c code is different between 2.x and 3.x but
they both only check for 'exactly the right number, or one or more too
many.'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3071>
_______________________________________

From report at bugs.python.org  Mon Jul 27 07:21:22 2009
From: report at bugs.python.org (Joe Amenta)
Date: Mon, 27 Jul 2009 05:21:22 +0000
Subject: [issue6583] 2to3 fails to fix test.test_support
In-Reply-To: <1248672082.21.0.412952291584.issue6583@psf.upfronthosting.co.za>
Message-ID: <1248672082.21.0.412952291584.issue6583@psf.upfronthosting.co.za>


New submission from Joe Amenta <amentajo at msu.edu>:

PEP 3108 states that test.test_support was renamed to test.support as a
part of the Standard Library Reorganization process.  However...

2to3 does not refactor (or even warn about) test.test_support.  Simply
adding
"test.test_support": "test.support",
into the MAPPING of fix_imports.py would not work, because
fix_imports.py does not accept anything with a dot in it, i.e. "foo.bar".

----------
components: 2to3 (2.x to 3.0 conversion tool)
files: 2to3_out.txt
messages: 90975
nosy: joe.amenta
severity: normal
status: open
title: 2to3 fails to fix test.test_support
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14575/2to3_out.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6583>
_______________________________________

From report at bugs.python.org  Mon Jul 27 08:10:50 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 27 Jul 2009 06:10:50 +0000
Subject: [issue6584] gzip module has no custom exception
In-Reply-To: <1248675050.27.0.747048824781.issue6584@psf.upfronthosting.co.za>
Message-ID: <1248675050.27.0.747048824781.issue6584@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

Much like zipfile.BadZipfile, we need a base custom exception for the 
gzip module. At least, catch gzip-related exceptions and throw a 
tarfile.TarError when used *via* tarfile.*.

See the following example (the exception escaped the "try... except 
tarfile.TarError: .. " block!):

***
  [...]
  File "/home/sridharr/as/pypm/src/pypm/common/compression.py", line 
199, in _ensure_read_write_access
    for tarinfo in tarfileobj.getmembers():
  File "/opt/ActivePython-2.6/lib/python2.6/tarfile.py", line 1791, in 
getmembers
    self._load()        # all members, we first have to
  File "/opt/ActivePython-2.6/lib/python2.6/tarfile.py", line 2352, in 
_load
    tarinfo = self.next()
  File "/opt/ActivePython-2.6/lib/python2.6/tarfile.py", line 2307, in 
next
    self.fileobj.seek(self.offset)
  File "/opt/ActivePython-2.6/lib/python2.6/gzip.py", line 382, in seek
    self.read(1024)
  File "/opt/ActivePython-2.6/lib/python2.6/gzip.py", line 219, in read
    self._read(readsize)
  File "/opt/ActivePython-2.6/lib/python2.6/gzip.py", line 284, in _read
    self._read_eof()
  File "/opt/ActivePython-2.6/lib/python2.6/gzip.py", line 304, in 
_read_eof
    hex(self.crc)))
IOError: CRC check failed 0x115929f0 != 0x9f074a38L

----------
components: Library (Lib)
messages: 90976
nosy: srid
severity: normal
status: open
title: gzip module has no custom exception
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6584>
_______________________________________

From report at bugs.python.org  Mon Jul 27 08:13:17 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 27 Jul 2009 06:13:17 +0000
Subject: [issue6584] gzip module has no custom exception
In-Reply-To: <1248675050.27.0.747048824781.issue6584@psf.upfronthosting.co.za>
Message-ID: <1248675197.91.0.611961675498.issue6584@psf.upfronthosting.co.za>


Changes by Sridhar Ratnakumar <sridharr at activestate.com>:


----------
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6584>
_______________________________________

From report at bugs.python.org  Mon Jul 27 08:17:18 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 27 Jul 2009 06:17:18 +0000
Subject: [issue6584] gzip module has no custom exception
In-Reply-To: <1248675050.27.0.747048824781.issue6584@psf.upfronthosting.co.za>
Message-ID: <1248675438.36.0.273914569968.issue6584@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6584>
_______________________________________

From report at bugs.python.org  Mon Jul 27 09:22:37 2009
From: report at bugs.python.org (Irek Wlizlo)
Date: Mon, 27 Jul 2009 07:22:37 +0000
Subject: [issue6106] read_until
In-Reply-To: <1243267985.99.0.238483902734.issue6106@psf.upfronthosting.co.za>
Message-ID: <1248679357.75.0.572874090033.issue6106@psf.upfronthosting.co.za>


Irek Wlizlo <irczan at gmail.com> added the comment:

Hi,
I updated my profile with name - Irek Wlizlo

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6106>
_______________________________________

From report at bugs.python.org  Mon Jul 27 09:51:31 2009
From: report at bugs.python.org (Dror Levin)
Date: Mon, 27 Jul 2009 07:51:31 +0000
Subject: [issue5833] readline update
In-Reply-To: <1240605993.87.0.323265568101.issue5833@psf.upfronthosting.co.za>
Message-ID: <1248681091.88.0.0272915063768.issue5833@psf.upfronthosting.co.za>


Dror Levin <spatz at psybear.com> added the comment:

This bug was reported in Arch (http://bugs.archlinux.org/task/15548) and
Gentoo (https://bugs.gentoo.org/show_bug.cgi?id=279234)

----------
nosy: +spatz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5833>
_______________________________________

From report at bugs.python.org  Mon Jul 27 11:05:51 2009
From: report at bugs.python.org (Jack Diederich)
Date: Mon, 27 Jul 2009 09:05:51 +0000
Subject: [issue6106] read_until
In-Reply-To: <1243267985.99.0.238483902734.issue6106@psf.upfronthosting.co.za>
Message-ID: <1248685551.68.0.917966523649.issue6106@psf.upfronthosting.co.za>


Jack Diederich <jackdied at gmail.com> added the comment:

Thanks for the update Irek (and the help!). You are now listed in Misc/ACKS.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6106>
_______________________________________

From report at bugs.python.org  Mon Jul 27 11:39:19 2009
From: report at bugs.python.org (Antonio Cavallo)
Date: Mon, 27 Jul 2009 09:39:19 +0000
Subject: [issue6585] configure.in forces specific autoconf version
In-Reply-To: <1248687559.88.0.690836235505.issue6585@psf.upfronthosting.co.za>
Message-ID: <1248687559.88.0.690836235505.issue6585@psf.upfronthosting.co.za>


New submission from Antonio Cavallo <a.cavallo at cavallinux.eu>:

Hi,
I've seen the code change in /python/trunk/configure.in (rev.  74072): 
it enforces a specific autoconfig version (2.61) in order to build 
python.

Unfortunately OpenSuSE 11.1 (mainstream at time of writing) has an 
updated version of autoconf 2.63 (and I think is true for Mandriva as 
well). 

Wouldn't be better to force the 2.61 being the minimal version for 
autoconf allowing more up-to-date versions to be used?

You can have a look into http://pyvm.sourceforge.net/ where continuous 
build of the python interpreter are stored for further references.

----------
components: Build
messages: 90980
nosy: alexandre.vassalotti, cavallo71
severity: normal
status: open
title: configure.in forces specific autoconf version
type: compile error
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6585>
_______________________________________

From report at bugs.python.org  Mon Jul 27 15:50:31 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 27 Jul 2009 13:50:31 +0000
Subject: [issue5992] spurious space after opening parenthesis when
	auto-completing
In-Reply-To: <1241999810.49.0.16520968517.issue5992@psf.upfronthosting.co.za>
Message-ID: <1248702631.0.0.520647967079.issue5992@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> readline update

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5992>
_______________________________________

From report at bugs.python.org  Mon Jul 27 15:57:58 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 27 Jul 2009 13:57:58 +0000
Subject: [issue5833] readline update
In-Reply-To: <1240605993.87.0.323265568101.issue5833@psf.upfronthosting.co.za>
Message-ID: <1248703078.5.0.48371836083.issue5833@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch should be broken into several, one for each bug fix or
enhancement.

Remarks and questions:
- is the readline v6.x fix (which I'm interested in) compatible with
previous readline versions?
- what does "removes '~$-/' from the completer chars list to make the
next item work" mean exactly? is it a bugfix or a new feature?
- I'm not sure filename completion is uncontroversial, it's the kind of
advanced features which we usually let third-party tools (e.g. IPython)
handle if they want to; it may also cause spurious IOs and error messages

----------
nosy: +pitrou
priority:  -> normal
type:  -> behavior
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5833>
_______________________________________

From report at bugs.python.org  Mon Jul 27 16:00:54 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 27 Jul 2009 14:00:54 +0000
Subject: [issue6585] configure.in forces specific autoconf version
In-Reply-To: <1248687559.88.0.690836235505.issue6585@psf.upfronthosting.co.za>
Message-ID: <1248703254.45.0.601684316927.issue6585@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Does the check trigger when building Python, or only when rebuilding the
configure script itself? I think we ship a prebuilt configure script
precisely so that people don't have to care about autoconf versions and
the like.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6585>
_______________________________________

From report at bugs.python.org  Mon Jul 27 17:25:02 2009
From: report at bugs.python.org (Chris Liechti)
Date: Mon, 27 Jul 2009 15:25:02 +0000
Subject: [issue6586] Documentation of os.write and os.read are inaccurate.
In-Reply-To: <1248708302.5.0.774291437722.issue6586@psf.upfronthosting.co.za>
Message-ID: <1248708302.5.0.774291437722.issue6586@psf.upfronthosting.co.za>


New submission from Chris Liechti <cliechti at users.sourceforge.net>:

Documentation of os.write and os.read are inaccurate, it states that the
methods work with 'str' (or strings), which is wrong.

- os.write expects an instance of bytes or buffer
- os.read returns an instance of bytes

The implementation is OK, it fits well with the new io library but the
docs don't describe the implementation.

----------
assignee: georg.brandl
components: Documentation
messages: 90983
nosy: cliechti, georg.brandl
severity: normal
status: open
title: Documentation of os.write and os.read are inaccurate.
versions: Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6586>
_______________________________________

From report at bugs.python.org  Mon Jul 27 17:27:38 2009
From: report at bugs.python.org (Antonio Cavallo)
Date: Mon, 27 Jul 2009 15:27:38 +0000
Subject: [issue6585] configure.in forces specific autoconf version
In-Reply-To: <1248687559.88.0.690836235505.issue6585@psf.upfronthosting.co.za>
Message-ID: <1248708458.99.0.139247487784.issue6585@psf.upfronthosting.co.za>


Antonio Cavallo <a.cavallo at cavallinux.eu> added the comment:

Yes the rebuild does an autoreconf step.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6585>
_______________________________________

From report at bugs.python.org  Mon Jul 27 18:13:04 2009
From: report at bugs.python.org (Matthew Barnett)
Date: Mon, 27 Jul 2009 16:13:04 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1248711184.73.0.874459652993.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

issue2636-20090727.zip contains regex.py, _regex.h, _regex.c and also
_regex.pyd (for Python 2.6 on Windows). For Windows machines just put
regex.py and _regex.pyd into Python's Lib\site-packages folder. I've
changed the name so that it won't hide the re module.

----------
Added file: http://bugs.python.org/file14576/issue2636-20090727.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Mon Jul 27 19:36:49 2009
From: report at bugs.python.org (Neil Tallim)
Date: Mon, 27 Jul 2009 17:36:49 +0000
Subject: [issue1721862] email.FeedParser.BufferedSubFile improperly handles
	"\r\n"
Message-ID: <1248716209.3.0.686790575563.issue1721862@psf.upfronthosting.co.za>


Changes by Neil Tallim <red.hamsterx at gmail.com>:


Removed file: http://bugs.python.org/file14572/1721862.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1721862>
_______________________________________

From report at bugs.python.org  Mon Jul 27 19:36:56 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 27 Jul 2009 17:36:56 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1248716215.99.0.926630222452.issue2636@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Agreed, a standalone release combined with a public announcement about
its availability is a must if we want to get any sort of wide spread
testing.

It'd be great if we had a fully characterized set of tests for the
behavior of the existing engine... but we don't.  So widespread testing
is important.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Mon Jul 27 19:41:59 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 27 Jul 2009 17:41:59 +0000
Subject: [issue6573] set union method ignores arguments appearing after the
	original set
In-Reply-To: <1248535461.31.0.573143089601.issue6573@psf.upfronthosting.co.za>
Message-ID: <1248716519.46.0.954584718145.issue6573@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Good catch.  Thanks.

----------
priority:  -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6573>
_______________________________________

From report at bugs.python.org  Mon Jul 27 19:50:40 2009
From: report at bugs.python.org (Neil Tallim)
Date: Mon, 27 Jul 2009 17:50:40 +0000
Subject: [issue1721862] email.FeedParser.BufferedSubFile improperly handles
	"\r\n"
Message-ID: <1248717040.14.0.33652110783.issue1721862@psf.upfronthosting.co.za>


Neil Tallim <red.hamsterx at gmail.com> added the comment:

Confirmed in trunk and all current branches (r74225: 2.6, 2.7, 3.1, 3.2).

Patches for all four active versions will be added momentarily.

Note: my submission yesterday was mistagged, claiming to be for trunk
while it was really for 2.6, which is what this bug was actively marked
with at the time.

----------
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1721862>
_______________________________________

From report at bugs.python.org  Mon Jul 27 19:53:11 2009
From: report at bugs.python.org (A.M. Kuchling)
Date: Mon, 27 Jul 2009 17:53:11 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1248717191.63.0.573814064207.issue2636@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

We have lengthy sets of tests in Lib/test/regex_tests.py and
Lib/test/test_re.py.

While widespread testing of a standalone module would certainly be good,
I doubt that will exercise many corner cases and the more esoteric
features.  Most actual code probably uses relatively few regex pattern
constructs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Mon Jul 27 19:56:41 2009
From: report at bugs.python.org (Neil Tallim)
Date: Mon, 27 Jul 2009 17:56:41 +0000
Subject: [issue1721862] email.FeedParser.BufferedSubFile improperly handles
	"\r\n"
Message-ID: <1248717401.52.0.84975235663.issue1721862@psf.upfronthosting.co.za>


Neil Tallim <red.hamsterx at gmail.com> added the comment:

Attached a patch containing a unit test based on Sye van der Veen's
example and a solution for issue 1721862.

Written against Python 2.6, r74225.

----------
Added file: http://bugs.python.org/file14577/1721862[2.6].diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1721862>
_______________________________________

From report at bugs.python.org  Mon Jul 27 19:57:28 2009
From: report at bugs.python.org (Neil Tallim)
Date: Mon, 27 Jul 2009 17:57:28 +0000
Subject: [issue1721862] email.FeedParser.BufferedSubFile improperly handles
	"\r\n"
Message-ID: <1248717448.12.0.118886242975.issue1721862@psf.upfronthosting.co.za>


Neil Tallim <red.hamsterx at gmail.com> added the comment:

Attached a patch containing a unit test based on Sye van der Veen's
example and a solution for issue 1721862.

Written against Python 2.7, r74225.

----------
Added file: http://bugs.python.org/file14578/1721862[2.7].diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1721862>
_______________________________________

From report at bugs.python.org  Mon Jul 27 19:58:17 2009
From: report at bugs.python.org (Neil Tallim)
Date: Mon, 27 Jul 2009 17:58:17 +0000
Subject: [issue1721862] email.FeedParser.BufferedSubFile improperly handles
	"\r\n"
Message-ID: <1248717497.75.0.522489152674.issue1721862@psf.upfronthosting.co.za>


Neil Tallim <red.hamsterx at gmail.com> added the comment:

Attached a patch containing a unit test based on Sye van der Veen's
example and a solution for issue 1721862.

Written against Python 3.1, r74225.

----------
Added file: http://bugs.python.org/file14579/1721862[3.1].diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1721862>
_______________________________________

From report at bugs.python.org  Mon Jul 27 19:59:05 2009
From: report at bugs.python.org (Neil Tallim)
Date: Mon, 27 Jul 2009 17:59:05 +0000
Subject: [issue1721862] email.FeedParser.BufferedSubFile improperly handles
	"\r\n"
Message-ID: <1248717545.92.0.0673173309525.issue1721862@psf.upfronthosting.co.za>


Neil Tallim <red.hamsterx at gmail.com> added the comment:

Attached a patch containing a unit test based on Sye van der Veen's
example and a solution for issue 1721862.

Written against Python 3.2, r74225.

----------
Added file: http://bugs.python.org/file14580/1721862[3.2].diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1721862>
_______________________________________

From report at bugs.python.org  Mon Jul 27 21:09:20 2009
From: report at bugs.python.org (Josiah Carlson)
Date: Mon, 27 Jul 2009 19:09:20 +0000
Subject: [issue6550] asyncore incorrect failure when connection is refused and
	using async_chat channel
In-Reply-To: <1248302571.21.0.910158552759.issue6550@psf.upfronthosting.co.za>
Message-ID: <1248721760.29.0.67540539361.issue6550@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

The attached patch cleans up the remnants of the "handle_expt is for 
exceptions", which isn't the case, as well as makes the "connection 
refused" fix actually work on Windows.  Nirs, could you verify this on 
*nix?

----------
assignee:  -> josiahcarlson
keywords: +needs review
Added file: http://bugs.python.org/file14581/asyncore_fix_refused.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6550>
_______________________________________

From report at bugs.python.org  Mon Jul 27 21:56:35 2009
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Mon, 27 Jul 2009 19:56:35 +0000
Subject: [issue2698] Extension module build fails for MinGW: missing
	vcvarsall.bat
In-Reply-To: <1209230424.66.0.154562223128.issue2698@psf.upfronthosting.co.za>
Message-ID: <1248724595.6.0.97050100077.issue2698@psf.upfronthosting.co.za>


Hagen F?rstenau <hfuerstenau at gmx.net> added the comment:

Seems to have been fixed around r73896.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2698>
_______________________________________

From report at bugs.python.org  Mon Jul 27 22:10:36 2009
From: report at bugs.python.org (J. Evans)
Date: Mon, 27 Jul 2009 20:10:36 +0000
Subject: [issue5833] readline update
In-Reply-To: <1240605993.87.0.323265568101.issue5833@psf.upfronthosting.co.za>
Message-ID: <1248725436.86.0.88695626848.issue5833@psf.upfronthosting.co.za>


J. Evans <jrevans1 at earthlink.net> added the comment:

Some clarification about the rest of the patch:

-- We tested the readline fix with version 5.2 and it seemed to work, we
did not do a thorough test with it, or with any other version.

-- When I supplied the patch I supplied the patch that we use when
building python, which also included some enhancements/bug fixes
(depending on how you look at it).  By removing the '~$-/' characters
from the completer list it allows the user to perform file name
completion (with the provided file name completion code).  The file name
completion code has been very rigorously tested.  We have been using it
at our company for the past 10 years with >100 users and have had no
problems with it.

-- We put this here since it never really seemed to be an advanced
feature since readline completion will complete file names on the
command-line as well.  This seemed like a relatively low-level fix that
makes the python tab-expansion facility fully usable instead of just
partly usable.

If you would like me to resubmit the patch as smaller components I can
do that as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5833>
_______________________________________

From report at bugs.python.org  Mon Jul 27 22:33:45 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 27 Jul 2009 20:33:45 +0000
Subject: [issue6573] set union method ignores arguments appearing after the
	original set
In-Reply-To: <1248535461.31.0.573143089601.issue6573@psf.upfronthosting.co.za>
Message-ID: <1248726825.64.0.20769199382.issue6573@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Fixed.  See r74226, r74227, r74228 and r74229.

----------
resolution:  -> fixed
status: open -> closed
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6573>
_______________________________________

From report at bugs.python.org  Tue Jul 28 00:20:10 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 27 Jul 2009 22:20:10 +0000
Subject: [issue6585] configure.in forces specific autoconf version
In-Reply-To: <1248687559.88.0.690836235505.issue6585@psf.upfronthosting.co.za>
Message-ID: <1248733210.64.0.263984504453.issue6585@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

My understanding is that the reason that this particular version of
autoconf is required is that newer versions introduce mixed line endings
into the generated file, which causes problems with storing it in svn.

The introduction of the version check was prompted by the fact that
several developers used the wrong autoconf version when regenerating the
configure script because they weren't aware of this issue.  In addition
to this, however, having different developers regenerate the file using
different autoconf versions would result in the checked-in configure
script ping-ponging because of differing autoconf output.  Thus it seems
it is better in the general case to require that the configure script be
built with a specified version of autoconf.

----------
nosy: +r.david.murray
priority:  -> normal
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6585>
_______________________________________

From report at bugs.python.org  Tue Jul 28 02:32:12 2009
From: report at bugs.python.org (Bill Janssen)
Date: Tue, 28 Jul 2009 00:32:12 +0000
Subject: [issue6587] interrupts during long writes cause connection corruption
	with SSL module
In-Reply-To: <1248741132.11.0.651534522713.issue6587@psf.upfronthosting.co.za>
Message-ID: <1248741132.11.0.651534522713.issue6587@psf.upfronthosting.co.za>


New submission from Bill Janssen <bill.janssen at gmail.com>:

The behavior when a write or send is interrupted is suboptimal.  If the
write buffer moves before a retry is attempted in response to
SSL_ERROR_WANT_OUTPUT, OpenSSL rejects the retry attempt.  See

http://www.mail-archive.com/openssl-users at openssl.org/msg07806.html.

Looks like a simple fix.

----------
assignee: janssen
messages: 90999
nosy: janssen
priority: high
severity: normal
stage: needs patch
status: open
title: interrupts during long writes cause connection corruption with SSL module
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6587>
_______________________________________

From report at bugs.python.org  Tue Jul 28 03:48:18 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 28 Jul 2009 01:48:18 +0000
Subject: [issue5673] Add timeout option to subprocess.Popen
In-Reply-To: <1238701276.41.0.515283298202.issue5673@psf.upfronthosting.co.za>
Message-ID: <1248745698.74.0.0676302575395.issue5673@psf.upfronthosting.co.za>


Changes by Sridhar Ratnakumar <sridharr at activestate.com>:


----------
nosy: +srid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5673>
_______________________________________

From report at bugs.python.org  Tue Jul 28 04:07:14 2009
From: report at bugs.python.org (Jon Debonis)
Date: Tue, 28 Jul 2009 02:07:14 +0000
Subject: [issue6588] insert cookies into cookie jar - cookielib.py
In-Reply-To: <1248746834.41.0.511434731236.issue6588@psf.upfronthosting.co.za>
Message-ID: <1248746834.41.0.511434731236.issue6588@psf.upfronthosting.co.za>


New submission from Jon Debonis <jon at tooln.com>:

Added ability to insert cookies into cookie jar.

Fixed problem where some domain names are prepended with '.' and others 
were not.

Fixed problem with _LWPCookieJar.py to handle case where version = None

----
import urllib2, urllib, time
import cookielib
            
req_url = 'http://google.com'

## OPEN COOKIE JAR - Optional
cj = cookielib.CookieJar()

cookie_handler = urllib2.HTTPCookieProcessor(cj)
opener = urllib2.build_opener(cookie_handler)
urllib2.install_opener(opener)

req = urllib2.Request(url=req_url)
    
cj.add_cookie(req, 'cname2', 'cval2',
                {'expires':  int(time.time()) + 3600,})

cj.add_cookie(req, 'cname3', 'cval3') 

print "-" * 45
print "Cookies before first request is sent:"
for index, cookie in enumerate(cj):
    print index, '  :  ', cookie

res = urllib2.urlopen(req)
# Google will redirect, and clear the additional cookies
print "-" * 45
print "Cookies after first request is sent:"
print "(google cleared extra cookies)"
for index, cookie in enumerate(cj):
    print index, '  :  ', cookie
---

----------
components: Library (Lib)
files: cookie_update.diff
keywords: patch
messages: 91000
nosy: jondebonis
severity: normal
status: open
title: insert cookies into cookie jar - cookielib.py
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file14582/cookie_update.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6588>
_______________________________________

From report at bugs.python.org  Tue Jul 28 04:17:53 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 28 Jul 2009 02:17:53 +0000
Subject: [issue5673] Add timeout option to subprocess.Popen
In-Reply-To: <1238701276.41.0.515283298202.issue5673@psf.upfronthosting.co.za>
Message-ID: <1248747473.15.0.456326739766.issue5673@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

See http://code.google.com/p/python-process/ for some ideas.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5673>
_______________________________________

From report at bugs.python.org  Tue Jul 28 05:59:58 2009
From: report at bugs.python.org (Casey McGinty)
Date: Tue, 28 Jul 2009 03:59:58 +0000
Subject: [issue6589] smtpd.SMTPServer can cause asyncore.loop to enter
	infinite event loop
In-Reply-To: <1248753598.39.0.190804723361.issue6589@psf.upfronthosting.co.za>
Message-ID: <1248753598.39.0.190804723361.issue6589@psf.upfronthosting.co.za>


New submission from Casey McGinty <casey.mcginty at gmail.com>:

When subclass of smtpd.SMTPServer, it is possible the get asyncore.loop
to enter an infinite loop where the following output is shown:

.....
warning: unhandled write event
warning: unhandled read event
warning: unhandled write event
warning: unhandled read event
warning: unhandled write event
warning: unhandled read event
warning: unhandled write event
warning: unhandled read event
warning: unhandled write event
warning: unhandled read event
warning: unhandled write event
warning: unhandled read event
....

To reproduce:
1) Init SMTPServer class instance inside of Thread class and call
asyncore.loop()
2) Init second SMTPServer class instance from a second Thread class,
binding to the same address and port. The SMTPServer instance will raise
an exception that socket cannot bind to the port in use. The socket
exception must be caught at some level, and the program execution
allowed to continue.
3) First SMTPServer thread will enter infinite event loop.


Analysis:
When the exception is raised in the second SMTPServer instance, the new
instance has already registered itself with the asyncore library (ex:
'asyncore.dispatcher.__init__(self)'). There is no code in the
SMTPServere.__init__ method that catches the exception raised, caused by
the failed bind attempt. After the exception is caught, the first thread
continues to run, but asyncore is in an invalid state because it still
has the registration of the second SMTPServer instance that never completed.

Workaround and Proposed Fix:
A viable workaround seems to be catching the raised exception in
__init__ method of the SMTPServer subclass, and call self.close() before
re-raising the exception:

class MySmtpServer( smtpd.SMTPServer, object ):
   def __init__( self, **kwargs ):
      try:
         super( _SmtpSink, self).__init__(**kwargs)
      except Exception as e:
         self.close()   # cleanup asyncore after failure
         raise

For a long term fix, I would recommend performing the
asyncore.dispatcher.close() method call in the SMTPServer.__init__() method.

----------
components: Library (Lib)
messages: 91002
nosy: cmcginty
severity: normal
status: open
title: smtpd.SMTPServer can cause asyncore.loop to enter infinite event loop
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6589>
_______________________________________

From report at bugs.python.org  Tue Jul 28 10:23:45 2009
From: report at bugs.python.org (Chris Rebert)
Date: Tue, 28 Jul 2009 08:23:45 +0000
Subject: [issue4947] sys.stdout fails to use default encoding as advertised
In-Reply-To: <1231931928.79.0.528374921948.issue4947@psf.upfronthosting.co.za>
Message-ID: <1248769425.68.0.0718113850479.issue4947@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


----------
nosy: +cvrebert

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4947>
_______________________________________

From report at bugs.python.org  Tue Jul 28 11:43:01 2009
From: report at bugs.python.org (Hakan)
Date: Tue, 28 Jul 2009 09:43:01 +0000
Subject: [issue6590] Py3K can't set the browser's character encoding! (CGI)
In-Reply-To: <1248774181.34.0.157512876081.issue6590@psf.upfronthosting.co.za>
Message-ID: <1248774181.34.0.157512876081.issue6590@psf.upfronthosting.co.za>


New submission from Hakan <physic.tr at gmail.com>:

Hi,
I'm new to web programming with Python.
In Python2k, the special "# -*- coding: cp1254 -*-" code sets the
character encoding. It works in the internet browsers too and sets the
browser's character encoding. That was really good. But in Py3k, that
special comment doesn't work. Usually, the encoding is UTF-8 in my
browser. That time, non-ascii Turkish characters seems strange symbols.
The locale.setlocale method doesn't work too. The users must manualy set
the encoding from UTF-8 to Turkish(Windows-1254) or Turkish(ISO-8859-9).
Is there anyway to set browser's encoding with Python 3.1? 
I use IIS7 and Windows 7 x64.
BTW, the ASP don't identify Python. But I can use .py files. So, I did
these thing in CGI/.py

----------
components: Unicode
messages: 91003
nosy: [PhysiC]
severity: normal
status: open
title: Py3K can't set the browser's character encoding! (CGI)
type: feature request
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6590>
_______________________________________

From report at bugs.python.org  Tue Jul 28 13:04:47 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Tue, 28 Jul 2009 11:04:47 +0000
Subject: [issue6591] add reference to fcntl.ioctl in the socket module
In-Reply-To: <1248779087.11.0.343607433403.issue6591@psf.upfronthosting.co.za>
Message-ID: <1248779087.11.0.343607433403.issue6591@psf.upfronthosting.co.za>


New submission from Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:

socket.ioctl says it is Windows specific, and people may think there 
is no way to use ioctl with sockets in non-Windows platforms (see 
http://groups.google.com/group/comp.lang.python/browse_thread/
thread/246f4522ad215d74 )
This doc patch adds a reference to the fcntl.fcntl and fcntl.ioctl 
functions so people is aware of them.

----------
assignee: georg.brandl
components: Documentation
files: socket.diff
keywords: patch
messages: 91004
nosy: gagenellina, georg.brandl
severity: normal
status: open
title: add reference to fcntl.ioctl in the socket module
type: feature request
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file14583/socket.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6591>
_______________________________________

From report at bugs.python.org  Tue Jul 28 13:17:23 2009
From: report at bugs.python.org (sorin)
Date: Tue, 28 Jul 2009 11:17:23 +0000
Subject: [issue5808] Subprocess.getstatusoutput Fails Executing 'dir' Command
	on Windows
In-Reply-To: <1240328974.09.0.446818382044.issue5808@psf.upfronthosting.co.za>
Message-ID: <1248779843.79.0.835631019776.issue5808@psf.upfronthosting.co.za>


sorin <sorin.sbarnea at gmail.com> added the comment:

Also the same issue does apply for command.getstatusoutput in Python 2.6.

Maybe this bug should be reopened and solved by adding a platform check
in the module. Also the documentation does not specify what would be the
right multiplatform alternative.

Anyway, the current result it's clearly not the expected behavior and
does not give any hint regarding the source of the problem or possible
solutions.

----------
nosy: +sorin
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5808>
_______________________________________

From report at bugs.python.org  Tue Jul 28 14:12:57 2009
From: report at bugs.python.org (tanvalley)
Date: Tue, 28 Jul 2009 12:12:57 +0000
Subject: [issue6592] otparse: processing variable number of short option
	arguments
Message-ID: <1248783177.09.0.433019746368.issue6592@psf.upfronthosting.co.za>


Changes by tanvalley <tanvalley at hotmail.com>:


----------
components: Library (Lib)
files: optparse-feature
nosy: tanvalley
severity: normal
status: open
title: otparse: processing variable number of short option arguments
type: feature request
versions: Python 2.5
Added file: http://bugs.python.org/file14584/optparse-feature

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6592>
_______________________________________

From report at bugs.python.org  Tue Jul 28 15:00:29 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 28 Jul 2009 13:00:29 +0000
Subject: [issue6590] Py3K can't set the browser's character encoding! (CGI)
In-Reply-To: <1248774181.34.0.157512876081.issue6590@psf.upfronthosting.co.za>
Message-ID: <1248786029.7.0.290114698849.issue6590@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This looks more like a general question than a bug report. You should
probably ask on comp.lang.python or #python at irc.freenode.net.

The "# -*- coding: cp1254 -*-" only specifies the encoding used to save
the source file and it's not related to the encoding used when the data
are printed or sent over the network. This should be the same for both
Py2 and Py3.
The browser determines the encoding reading it from the HTTP headers,
from the content-type in the HTML <meta> tag or from the XML
declaration. If none of these are available it tries to determine it
from the content of the file. You should probably specify the encoding
in the headers and encode the data you send accordingly.

Closing as invalid.

----------
nosy: +ezio.melotti
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6590>
_______________________________________

From report at bugs.python.org  Tue Jul 28 15:04:45 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 28 Jul 2009 13:04:45 +0000
Subject: [issue4947] sys.stdout fails to use default encoding as advertised
In-Reply-To: <1231931928.79.0.528374921948.issue4947@psf.upfronthosting.co.za>
Message-ID: <1248786285.94.0.837230255263.issue4947@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4947>
_______________________________________

From report at bugs.python.org  Tue Jul 28 15:13:13 2009
From: report at bugs.python.org (nestor)
Date: Tue, 28 Jul 2009 13:13:13 +0000
Subject: [issue6236] os.popen causes illegal seek on AIX in Python 3.1rc
In-Reply-To: <1244427618.5.0.797941537993.issue6236@psf.upfronthosting.co.za>
Message-ID: <1248786793.53.0.841613043517.issue6236@psf.upfronthosting.co.za>


nestor <nestornissen at gmail.com> added the comment:

Python 3.1 (r31:73572, Jul  9 2009, 16:28:28) [C] on aix5
Type "help", "copyright", "credits" or "license" for more information.
>>>
>>> import sys
>>> sys.stdout.seekable()
True
>>>

I can access the machine only through ssh.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6236>
_______________________________________

From report at bugs.python.org  Tue Jul 28 18:39:27 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 28 Jul 2009 16:39:27 +0000
Subject: [issue6548] cmath documentation misleading: suggests existence of
	real() and imag() functions
In-Reply-To: <1248299698.0.0.920100025533.issue6548@psf.upfronthosting.co.za>
Message-ID: <1248799167.01.0.664929641387.issue6548@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks, Georg!

Committed, r74230 (trunk), r74231 (release26-maint), r74232 (py3k), r74233 
(release31-maint).  The latter three revisions include the merge of r74184 
from trunk.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6548>
_______________________________________

From report at bugs.python.org  Tue Jul 28 18:52:43 2009
From: report at bugs.python.org (Hakan)
Date: Tue, 28 Jul 2009 16:52:43 +0000
Subject: [issue6590] Py3K can't set the browser's character encoding! (CGI)
In-Reply-To: <1248774181.34.0.157512876081.issue6590@psf.upfronthosting.co.za>
Message-ID: <1248799963.03.0.211394723957.issue6590@psf.upfronthosting.co.za>


Hakan <physic.tr at gmail.com> added the comment:

Thanks for your reply. I said, I'm new to web programming.
Now I add Content-type: text/html; charset=ISO-8859-9...
:)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6590>
_______________________________________

From report at bugs.python.org  Tue Jul 28 19:13:44 2009
From: report at bugs.python.org (Egon Frerich)
Date: Tue, 28 Jul 2009 17:13:44 +0000
Subject: [issue6593] Documentation: gettext install link
In-Reply-To: <1248801224.0.0.797200646429.issue6593@psf.upfronthosting.co.za>
Message-ID: <1248801224.0.0.797200646429.issue6593@psf.upfronthosting.co.za>


New submission from Egon Frerich <e.frerich at nord-com.net>:

The description of gettext.install in 23.1.2 (Class-based API) contains
two links to install() which should go to this function in "The
NullTranslations class" 23.1.2.1 but they don't.

----------
assignee: georg.brandl
components: Documentation
messages: 91010
nosy: efrerich, georg.brandl
severity: normal
status: open
title: Documentation: gettext install link

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6593>
_______________________________________

From report at bugs.python.org  Tue Jul 28 19:20:50 2009
From: report at bugs.python.org (Senthil)
Date: Tue, 28 Jul 2009 17:20:50 +0000
Subject: [issue5808] Subprocess.getstatusoutput Fails Executing 'dir' Command
	on Windows
In-Reply-To: <1240328974.09.0.446818382044.issue5808@psf.upfronthosting.co.za>
Message-ID: <1248801650.48.0.0940381087852.issue5808@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

sorin:

You meant the commands module, correct?
It is well documented in the commands reference:
http://docs.python.org/library/commands.html

* It is applicable to unix only.
* the getstatusoutput is moved to subprocess in 3x.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5808>
_______________________________________

From report at bugs.python.org  Tue Jul 28 19:23:41 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 28 Jul 2009 17:23:41 +0000
Subject: [issue6561] Regex '\d' should not match unicode category 'No'.
In-Reply-To: <1248432481.83.0.138486397936.issue6561@psf.upfronthosting.co.za>
Message-ID: <1248801821.54.0.588963547635.issue6561@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

[ezio.melotti]
> I suggest something like:
> Matches the decimal digits ``[0-9]`` and all the characters that belong
> to the Unicode category Nd (Number, Decimal Digit).

Hmm.  I don't like this because it suggests (to me) that the characters 
[0-9] don't belong to category [Nd].  I agree the previous version was 
clunky, though.  I've shortened it some;  if anyone else wants to work on 
the wording please feel free.  It might be nice to annotate each of these 
character classes (\w, \s) with the Unicode character categories that they 
correspond to.

> Two more minor details: instead of '\d', I'd use '^\d$' and instead of
> self.assertEqual(re.match('\d', x), None)
> self.assertIsNone(re.match('\d', x)).

Thanks.  Changes applied.

Committed to py3k, r74237.   Leaving open for backport to trunk.

----------
stage: patch review -> committed/rejected
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6561>
_______________________________________

From report at bugs.python.org  Tue Jul 28 20:17:43 2009
From: report at bugs.python.org (sorin)
Date: Tue, 28 Jul 2009 18:17:43 +0000
Subject: [issue5808] Subprocess.getstatusoutput Fails Executing 'dir' Command
	on Windows
In-Reply-To: <1240328974.09.0.446818382044.issue5808@psf.upfronthosting.co.za>
Message-ID: <1248805063.49.0.752371318124.issue5808@psf.upfronthosting.co.za>


sorin <sorin.sbarnea at gmail.com> added the comment:

If I made a patch that will raise an error if you include commands
module under Windows will you include it - this will safe others time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5808>
_______________________________________

From report at bugs.python.org  Tue Jul 28 21:21:06 2009
From: report at bugs.python.org (Nir Soffer)
Date: Tue, 28 Jul 2009 19:21:06 +0000
Subject: [issue6550] asyncore incorrect failure when connection is refused and
	using async_chat channel
In-Reply-To: <1248302571.21.0.910158552759.issue6550@psf.upfronthosting.co.za>
Message-ID: <1248808866.68.0.850046350138.issue6550@psf.upfronthosting.co.za>


Nir Soffer <nirsof at gmail.com> added the comment:

I have a big problem with asyncore_fix_refused.patch  - it assumes that a 
dispatcher has a socket attribute, which can be used with t getsockopt(). 
This is true in the default dispatcher class implemented in asyncore, but 
wont work with file_dispatcher, or 3rd party dispatcher class.

The framework should let you drop in your dispatcher class, that will 
implement a minimal interface - handle_x_event, writable, readable etc.

What are the issues on Windows with asyncore-handle-connect-event-3.patch 
on Windows?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6550>
_______________________________________

From report at bugs.python.org  Tue Jul 28 22:19:22 2009
From: report at bugs.python.org (Shawn)
Date: Tue, 28 Jul 2009 20:19:22 +0000
Subject: [issue6594] json C serializer performance tied to structure depth on
	some systems
In-Reply-To: <1248812361.89.0.626576705519.issue6594@psf.upfronthosting.co.za>
Message-ID: <1248812361.89.0.626576705519.issue6594@psf.upfronthosting.co.za>


New submission from Shawn <swalker at opensolaris.org>:

The json serializer's performance (when using the C speedups) appears to
be tied to the depth of the structure being serialized on some systems.
 In particular, dict structure that are more than a few levels deep,
especially when they content mixed values (lists, strings, and other
dicts) causes severe serialization penalties (in the neighborhood of an
extra 20-30 seconds) on some systems.

On SPARC systems, this is very likely because of the recursive call
structure that the C speedups serializer uses which doesn't work well
with SPARC due to register windows.

On x86 systems, recursive call structures are cheap, so this doesn't
appear to be an issue there.

SPARC systems with higher amounts of memory bandwidth don't suffer as
badly from this (such as Niagra T1000, T2000, etc. systems), but older
UltraSparc systems are especially prone to performance issues.

----------
components: Library (Lib)
messages: 91015
nosy: swalker
severity: normal
status: open
title: json C serializer performance tied to structure depth on some systems
type: performance
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6594>
_______________________________________

From report at bugs.python.org  Tue Jul 28 22:23:34 2009
From: report at bugs.python.org (Josiah Carlson)
Date: Tue, 28 Jul 2009 20:23:34 +0000
Subject: [issue6550] asyncore incorrect failure when connection is refused and
	using async_chat channel
In-Reply-To: <1248302571.21.0.910158552759.issue6550@psf.upfronthosting.co.za>
Message-ID: <1248812614.17.0.183921522706.issue6550@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

Firstly, it expects that handle_expt_event() is for handling exceptional 
conditions.  This is not the case.  handle_expt_event() is meant for 
handling "OOB" or "priority" data coming across a socket.  FTP and some 
other protocols use this.  I forgot to fix it earlier, which is why it's 
making it into this patch.

Secondly, I pulled the part that was inside handle_expt_event() that was 
being used to find the exception and pulls it out into _exception(), 
removing the previous behavior (wrt to the broken API), and replacing it 
with something that is cleaner and more correct (assuming sockets).

To respond to it being an issue that the object has a socket with a 
getsockopt(), I can fix it to handle the AttributeError case.

Would you be willing to try this out given my explanation as to why I 
changed your patch?

----------
Added file: http://bugs.python.org/file14585/asyncore_fix_refused-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6550>
_______________________________________

From report at bugs.python.org  Tue Jul 28 23:15:24 2009
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 28 Jul 2009 21:15:24 +0000
Subject: [issue6594] json C serializer performance tied to structure depth on
	some systems
In-Reply-To: <1248812361.89.0.626576705519.issue6594@psf.upfronthosting.co.za>
Message-ID: <1248815724.9.0.343702148178.issue6594@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6594>
_______________________________________

From report at bugs.python.org  Tue Jul 28 23:20:56 2009
From: report at bugs.python.org (Eivind Tagseth)
Date: Tue, 28 Jul 2009 21:20:56 +0000
Subject: [issue5993] python produces zombie in webbrowser.open
In-Reply-To: <1242014278.58.0.774883846907.issue5993@psf.upfronthosting.co.za>
Message-ID: <1248816056.11.0.749290120311.issue5993@psf.upfronthosting.co.za>


Eivind Tagseth <eivindt at multinet.no> added the comment:

The problem seems to be that there are no way to wait() for browser
processes that have died, and there is no mention of needing to wait()
in the documentation.

In my case, webbrowser finds my gnome-setting for the http-url handler
and sets up [ "firefox", "%s" ] as a BackgroundBrowser named 'gnome'.

BackgroundBrowser.open() creates a Popen object and calls p.poll().  The
Popened firefox process finds my existing firefox process, and asks it
to open the url, then terminates.  It doesn't act quickly enough to
terminate before p.poll() is called though, and I end up with a zombie
firefox process, that keeps me from ending firefox unless I also kill my
python process.

If this is how this is intended to work, there should at least be a
section in the documentation warning users to call os.waitX() themselves
to avoid zombie processes.

----------
nosy: +eivindt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5993>
_______________________________________

From report at bugs.python.org  Tue Jul 28 23:24:50 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 28 Jul 2009 21:24:50 +0000
Subject: [issue6561] Regex '\d' should not match unicode category 'No'.
In-Reply-To: <1248432481.83.0.138486397936.issue6561@psf.upfronthosting.co.za>
Message-ID: <1248816290.14.0.929213302754.issue6561@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Backported to trunk in r74240.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6561>
_______________________________________

From report at bugs.python.org  Wed Jul 29 00:20:45 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 28 Jul 2009 22:20:45 +0000
Subject: [issue6511] zipfile: Invalid argument when opening zero-sized files
In-Reply-To: <1247886325.93.0.371232374153.issue6511@psf.upfronthosting.co.za>
Message-ID: <1248819645.42.0.721658412.issue6511@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Fixed in r74245. Thanks for the report!

----------
nosy: +amaury.forgeotdarc
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6511>
_______________________________________

From report at bugs.python.org  Wed Jul 29 00:29:06 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 28 Jul 2009 22:29:06 +0000
Subject: [issue1811] True division of integers could be more accurate
In-Reply-To: <1200115229.68.0.232140016038.issue1811@psf.upfronthosting.co.za>
Message-ID: <1248820146.74.0.139205839868.issue1811@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

An example of a case that's almost 3.5 ulps out (Python 2.6):

Python 2.6.2 (r262:71600, Jul  8 2009, 09:56:31) 
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from __future__ import division
>>> m = 295147931372582273023
>>> n = 295147932265116303360
>>> m/n
0.99999999697597697

The correctly rounded result would be the float given by 
0.9999999969759773.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1811>
_______________________________________

From report at bugs.python.org  Wed Jul 29 00:36:16 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 28 Jul 2009 22:36:16 +0000
Subject: [issue6511] zipfile: Invalid argument when opening zero-sized files
In-Reply-To: <1247886325.93.0.371232374153.issue6511@psf.upfronthosting.co.za>
Message-ID: <1248820576.47.0.254448516915.issue6511@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Amaury, shouldn't this also be merged to the py3k branch? (I am not 
aware of any Python commit policies so just asking)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6511>
_______________________________________

From report at bugs.python.org  Wed Jul 29 00:36:57 2009
From: report at bugs.python.org (Neil Tallim)
Date: Tue, 28 Jul 2009 22:36:57 +0000
Subject: [issue1466065] base64 module ignores non-alphabet characters
Message-ID: <1248820617.45.0.995090122702.issue1466065@psf.upfronthosting.co.za>


Neil Tallim <red.hamsterx at gmail.com> added the comment:

Attached a patch that modifies Modules/binascii.c to raise a TypeError
on any unrecognized base64 input, rather than failing silently. Also
includes unit tests.

Patch built against Python 2.7, r74246.

TypeError was preserved over ValueError, despite the lack of related
logic, for legacy purposes.

----------
keywords: +patch
nosy: +Red HamsterX, ajaksu2
Added file: http://bugs.python.org/file14586/1466065[2.7].diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1466065>
_______________________________________

From report at bugs.python.org  Wed Jul 29 00:38:09 2009
From: report at bugs.python.org (Neil Tallim)
Date: Tue, 28 Jul 2009 22:38:09 +0000
Subject: [issue1466065] base64 module ignores non-alphabet characters
Message-ID: <1248820689.15.0.417596763055.issue1466065@psf.upfronthosting.co.za>


Neil Tallim <red.hamsterx at gmail.com> added the comment:

Attached a patch that modifies Modules/binascii.c to raise a TypeError
on any unrecognized base64 input, rather than failing silently. Also
includes unit tests.

Patch built against Python 3.2, r74246.

TypeError was preserved over ValueError, despite the lack of related
logic, for legacy purposes.

----------
Added file: http://bugs.python.org/file14587/1466065[3.2].diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1466065>
_______________________________________

From report at bugs.python.org  Wed Jul 29 00:39:12 2009
From: report at bugs.python.org (Neil Tallim)
Date: Tue, 28 Jul 2009 22:39:12 +0000
Subject: [issue1466065] base64 module ignores non-alphabet characters
Message-ID: <1248820752.87.0.0489265472874.issue1466065@psf.upfronthosting.co.za>


Neil Tallim <red.hamsterx at gmail.com> added the comment:

Attached a patch that modifies Lib/base64.py to raise a TypeError on any
unrecognized base64 input, rather than failing silently. Also includes
unit tests.

Patch built against Python 2.7, r74246.

----------
Added file: http://bugs.python.org/file14588/1466065[2.7-pure-python].diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1466065>
_______________________________________

From report at bugs.python.org  Wed Jul 29 00:40:57 2009
From: report at bugs.python.org (Neil Tallim)
Date: Tue, 28 Jul 2009 22:40:57 +0000
Subject: [issue1466065] base64 module ignores non-alphabet characters
Message-ID: <1248820857.93.0.575455523996.issue1466065@psf.upfronthosting.co.za>


Neil Tallim <red.hamsterx at gmail.com> added the comment:

Attached a patch that modifies Lib/base64.py to raise a TypeError on any
unrecognized base64 input, rather than continuing silently. Also
includes unit tests.

Patch built against Python 3.2, r74246.

Correction to previous text: base64 continues silently, discarding
unrecognized characters, rather than failing.

----------
Added file: http://bugs.python.org/file14589/1466065[3.2-pure-python].diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1466065>
_______________________________________

From report at bugs.python.org  Wed Jul 29 02:23:59 2009
From: report at bugs.python.org (Neil Tallim)
Date: Wed, 29 Jul 2009 00:23:59 +0000
Subject: [issue1512791] module wave does no rounding
Message-ID: <1248827039.77.0.268798321897.issue1512791@psf.upfronthosting.co.za>


Neil Tallim <red.hamsterx at gmail.com> added the comment:

Attached a patch with a unit test and solution for this problem.

Patch built against Python 2.7, r74246.

Note: It may make more sense to just have wave.setframerate() assert
that it is being fed an integer, and that's a simple fix that won't
require a test. However, that's not what was approved for testing, so
that's not what I wrote.

----------
keywords: +patch
nosy: +Red HamsterX
type: feature request -> behavior
versions: +Python 3.2
Added file: http://bugs.python.org/file14590/1512791[2.7].diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1512791>
_______________________________________

From report at bugs.python.org  Wed Jul 29 02:27:02 2009
From: report at bugs.python.org (Neil Tallim)
Date: Wed, 29 Jul 2009 00:27:02 +0000
Subject: [issue1512791] module wave does no rounding
Message-ID: <1248827222.82.0.53842190753.issue1512791@psf.upfronthosting.co.za>


Neil Tallim <red.hamsterx at gmail.com> added the comment:

Attached a patch with a unit test and solution for this problem.

Patch built against Python 3.2, r74246.

Note: with Python 3.2, an error was thrown if the input value wasn't an
integer because a deprecated struct-related cast was removed. It's
debatable whether we want to actually apply this patch, since the error
couldn't manifest in this version of Python. However, if we patch 2.7,
we might as well patch this to maintain consistency. (Patching 3.2 will
not break anything or make previously broken logic work differently, so
it is safe)

----------
Added file: http://bugs.python.org/file14591/1512791[3.2].diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1512791>
_______________________________________

From report at bugs.python.org  Wed Jul 29 02:56:32 2009
From: report at bugs.python.org (Matthew Barnett)
Date: Wed, 29 Jul 2009 00:56:32 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1248828992.81.0.93848961956.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

issue2636-20090729.zip contains regex.py, _regex.h, _regex.c which will
work with Python 2.5 as well as Python 2.6, and also 2 builds of
_regex.pyd (for Python 2.5 and Python 2.6 on Windows).

This version supports accessing the capture groups by subscripting the
match object, for example:

>>> m = regex.match("(?<foo>.)(?<bar>.)", "abc")
>>> len(m)
3
>>> m[0]
'ab'
>>> m[1 : 3]
['a', 'b']
>>> m["foo"]
'a'

----------
Added file: http://bugs.python.org/file14592/issue2636-20090729.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Wed Jul 29 08:32:58 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 29 Jul 2009 06:32:58 +0000
Subject: [issue6511] zipfile: Invalid argument when opening zero-sized files
In-Reply-To: <1247886325.93.0.371232374153.issue6511@psf.upfronthosting.co.za>
Message-ID: <1248849178.08.0.901536315726.issue6511@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Oh, this was done with r74246, I just forgot to mention it.
Anyway all changes in trunk are regularly merged into py3k.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6511>
_______________________________________

From report at bugs.python.org  Wed Jul 29 10:39:55 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 29 Jul 2009 08:39:55 +0000
Subject: [issue6595] Make Decimal constructor accept all unicode decimal
	digits in input.
In-Reply-To: <1248856795.44.0.0182588213317.issue6595@psf.upfronthosting.co.za>
Message-ID: <1248856795.44.0.0182588213317.issue6595@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

Ezio Melotti asked (on #python-dev) why the Decimal constructor doesn't 
accept decimal digits other than 0-9.  As far as I can tell there's no 
good reason for it not to.  Moreover, the standard on which the decimal 
module is based says[1]:

"""It is recommended that implementations also provide additional number 
formatting routines (including some which are locale-dependent), and if 
available should accept non-European decimal digits in strings."""

All other builtin or standard library numeric types already accept such 
digits:

Python 3.2a0 (py3k:74247, Jul 29 2009, 09:28:12) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from fractions import Fraction
>>> from decimal import Decimal
>>> x = '\uff11\uff10\uff15\uff18\uff15'
>>> x
'?????'
>>> int(x)
10585
>>> float(x)
10585.0
>>> complex(x)
(10585+0j)
>>> Fraction(x)
Fraction(10585, 1)
>>> Decimal(x)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/dickinsm/python/svn/py3k/Lib/decimal.py", line 548, in 
__new__
    "Invalid literal for Decimal: %r" % value)
  File "/Users/dickinsm/python/svn/py3k/Lib/decimal.py", line 3816, in 
_raise_error
    raise error(explanation)
decimal.InvalidOperation: Invalid literal for Decimal: '?????'

I propose adding support for this in Python 3.2 and (possibly) 2.7.  The 
change would be for input only:  no record of the original form of the 
digits would be kept by the Decimal object itself, so that e.g.,
str(Decimal('?????')) would still be '10585'.

[1] See http://speleotrove.com/decimal/daconvs.html

----------
assignee: marketdickinson
components: Library (Lib)
messages: 91030
nosy: ezio.melotti, marketdickinson
severity: normal
status: open
title: Make Decimal constructor accept all unicode decimal digits in input.
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6595>
_______________________________________

From report at bugs.python.org  Wed Jul 29 11:06:44 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 29 Jul 2009 09:06:44 +0000
Subject: [issue6595] Make Decimal constructor accept all unicode decimal
	digits in input.
In-Reply-To: <1248856795.44.0.0182588213317.issue6595@psf.upfronthosting.co.za>
Message-ID: <1248858404.72.0.984121472163.issue6595@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a patch

----------
keywords: +patch
Added file: http://bugs.python.org/file14593/issue6595.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6595>
_______________________________________

From report at bugs.python.org  Wed Jul 29 12:07:46 2009
From: report at bugs.python.org (Eric Smith)
Date: Wed, 29 Jul 2009 10:07:46 +0000
Subject: [issue6595] Make Decimal constructor accept all unicode decimal
	digits in input.
In-Reply-To: <1248856795.44.0.0182588213317.issue6595@psf.upfronthosting.co.za>
Message-ID: <1248862066.03.0.233269784968.issue6595@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

+1

The standard recommends it, and the other numeric types support it, so
Decimal should as well.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6595>
_______________________________________

From report at bugs.python.org  Wed Jul 29 12:35:42 2009
From: report at bugs.python.org (Eric Smith)
Date: Wed, 29 Jul 2009 10:35:42 +0000
Subject: [issue6595] Make Decimal constructor accept all unicode decimal
	digits in input.
In-Reply-To: <1248856795.44.0.0182588213317.issue6595@psf.upfronthosting.co.za>
Message-ID: <1248863742.59.0.882027983305.issue6595@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Since you're calling int() on the result, can't this code:
self._int = str(int((intpart+fracpart).lstrip('0') or '0'))
just be:
self._int = str(int(intpart+fracpart))
?

And here, you already know diag is not None, so do you need the "or '0'"
part?
self._int = str(int(diag or '0')).lstrip('0')

And, in both calls to .lstrip('0'), what happens if you have a
non-European leading '0', like '\uff10'?

Otherwise, the patch looks good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6595>
_______________________________________

From report at bugs.python.org  Wed Jul 29 12:35:58 2009
From: report at bugs.python.org (Anton)
Date: Wed, 29 Jul 2009 10:35:58 +0000
Subject: [issue6596] urllib2 bug on CentOS
In-Reply-To: <1248863758.9.0.379989191773.issue6596@psf.upfronthosting.co.za>
Message-ID: <1248863758.9.0.379989191773.issue6596@psf.upfronthosting.co.za>


New submission from Anton <rk3dov at gmail.com>:

This code gives HTTP Error 500 on CentOS:
---------------------------------------------
import urllib2
url = 'http://wm.exchanger.ru/asp/XMLWMList.asp?exchtype=1'
t = urllib2.urlopen(url).read()
---------------------------------------------

tcpdump:
---------------------------------------------
...
GET /asp/XMLWMList.asp?exchtype=1?3d2ebf80 HTTP/1.1
Accept-Encoding: identity
Host: wm.exchanger.ru
Connection: close
User-Agent: Python-urllib/2.6
...
---------------------------------------------
"?3d2ebf80" appended to request

% uname -a
Linux xxx.xxx 2.6.18-028stab062.3-ent #1 SMP Thu Mar 26 15:12:05 MSK 
2009 i686 i686 i386 GNU/Linux

The same problem with python 2.4.3. On other systems this code works 
nice.

----------
components: Extension Modules
messages: 91034
nosy: rk3dov
severity: normal
status: open
title: urllib2 bug on CentOS
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6596>
_______________________________________

From report at bugs.python.org  Wed Jul 29 12:37:15 2009
From: report at bugs.python.org (Anton)
Date: Wed, 29 Jul 2009 10:37:15 +0000
Subject: [issue6596] urllib2 bug on CentOS
In-Reply-To: <1248863758.9.0.379989191773.issue6596@psf.upfronthosting.co.za>
Message-ID: <1248863835.68.0.335405645759.issue6596@psf.upfronthosting.co.za>


Changes by Anton <rk3dov at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6596>
_______________________________________

From report at bugs.python.org  Wed Jul 29 13:09:49 2009
From: report at bugs.python.org (Matthew Barnett)
Date: Wed, 29 Jul 2009 11:09:49 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1248865789.85.0.530899653254.issue2636@psf.upfronthosting.co.za>


Changes by Matthew Barnett <python at mrabarnett.plus.com>:


Removed file: http://bugs.python.org/file14592/issue2636-20090729.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Wed Jul 29 13:10:26 2009
From: report at bugs.python.org (Matthew Barnett)
Date: Wed, 29 Jul 2009 11:10:26 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1248865826.75.0.803841875028.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

Unfortunately I found a bug in regex.py, caused when I made it
compatible with Python 2.5. :-(

issue2636-20090729.zip is now corrected.

----------
Added file: http://bugs.python.org/file14594/issue2636-20090729.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Wed Jul 29 13:53:39 2009
From: report at bugs.python.org (Nick)
Date: Wed, 29 Jul 2009 11:53:39 +0000
Subject: [issue1544339] _ctypes fails to build on Solaris x86 32-bit (Sun
	compiler)
Message-ID: <1248868419.85.0.0104685575635.issue1544339@psf.upfronthosting.co.za>


Nick <nick_bower at fastmail.fm> added the comment:

I've stumbled head-first into this bug trying to build ctypes 1.0.2, as 
required by the python Shapely GIS library for an important Zope project 
I've been working on.

It's a real surprise to see this bug even exists (since 2006!).  I don't 
understand the cause, but it's totally preventing me from deploying code 
using Shapely (and therefore ctypes) to a new Solaris x86 server that 
otherwise runs on Windows and Linux right now.

How come no progress - is it too hard to solve?

I'm using Sun Studio 12.1.  Out of a bunch of core libraries we're using 
(numpy, geos etc), this little package that has been "accepted" into the 
main Python distro seems to be the only one we've had problems with. :-(

Is there really no way around this?

----------
components: +ctypes
nosy: +nick
versions: +Python 2.4
Added file: http://bugs.python.org/file14595/ffitarget-error.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1544339>
_______________________________________

From report at bugs.python.org  Wed Jul 29 13:59:12 2009
From: report at bugs.python.org (Nir Soffer)
Date: Wed, 29 Jul 2009 11:59:12 +0000
Subject: [issue6550] asyncore incorrect failure when connection is refused and
	using async_chat channel
In-Reply-To: <1248302571.21.0.910158552759.issue6550@psf.upfronthosting.co.za>
Message-ID: <1248868752.71.0.699377161.issue6550@psf.upfronthosting.co.za>


Nir Soffer <nirsof at gmail.com> added the comment:

I'll check the patch this week.

The asyncore framework has low level events - handle_read_event, handle_write_event and 
handle_expt_event - these events are not used for reading, writing and OOB - they are just 
responsible to call the high level events.

The high level events - handle_connect, handle_accept, handle_read, handle_write, 
handle_close and handle_expt should be used only for specific events.

I don't see any problem in checking for errors in handle_expt_event, it works just like 
handle_read_event, that calls handle_connect.

This design allow you do replace the dispatcher with your own dispatcher class, 
implementing only the low level events.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6550>
_______________________________________

From report at bugs.python.org  Wed Jul 29 15:01:32 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 29 Jul 2009 13:01:32 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1248872492.74.0.927847124407.issue2636@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Apparently Perl has a quite comprehensive set of tests at
http://perl5.git.perl.org/perl.git/blob/HEAD:/t/op/re_tests .
If we want the engine to be Perl-compatible, it might be a good idea to
reuse (part of) their tests (if their license allows it).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Wed Jul 29 15:44:02 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 29 Jul 2009 13:44:02 +0000
Subject: [issue1466065] base64 module ignores non-alphabet characters
Message-ID: <1248875042.81.0.418029781756.issue1466065@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The new unit tests pass without modifying the library.
Could you include a case that fails with the current version?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1466065>
_______________________________________

From report at bugs.python.org  Wed Jul 29 18:06:42 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 29 Jul 2009 16:06:42 +0000
Subject: [issue6593] Documentation: gettext install link
In-Reply-To: <1248801224.0.0.797200646429.issue6593@psf.upfronthosting.co.za>
Message-ID: <1248883602.74.0.895408504864.issue6593@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r74252.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6593>
_______________________________________

From report at bugs.python.org  Wed Jul 29 18:09:24 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 29 Jul 2009 16:09:24 +0000
Subject: [issue6591] add reference to fcntl.ioctl in the socket module
In-Reply-To: <1248779087.11.0.343607433403.issue6591@psf.upfronthosting.co.za>
Message-ID: <1248883764.98.0.519199906646.issue6591@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, committed in r74253.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6591>
_______________________________________

From report at bugs.python.org  Wed Jul 29 18:14:29 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 29 Jul 2009 16:14:29 +0000
Subject: [issue6586] Documentation of os.write and os.read are inaccurate.
In-Reply-To: <1248708302.5.0.774291437722.issue6586@psf.upfronthosting.co.za>
Message-ID: <1248884069.46.0.518270846272.issue6586@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r74254.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6586>
_______________________________________

From report at bugs.python.org  Wed Jul 29 18:31:02 2009
From: report at bugs.python.org (Neil Tallim)
Date: Wed, 29 Jul 2009 16:31:02 +0000
Subject: [issue1466065] base64 module ignores non-alphabet characters
Message-ID: <1248885062.35.0.736284445272.issue1466065@psf.upfronthosting.co.za>


Neil Tallim <red.hamsterx at gmail.com> added the comment:

I can't add a test for that without changing unrelated behaviour in the
library that is already known to work fine or checking the string value
of the raised exception, which seems like a bad idea, even though it
would work.

If a character is ignored and this leads to a padding-length issue,
TypeError is raised in both 2.7 and 3.2: 2.7 because everything is a
TypeError, and 3.2 because binascii.Error is converted to TypeError for
legacy purposes.

If a character is ignored and the string's length is still acceptable,
then no error is reported because this was a silent problem.

Post-library-modification, both of these cases will uniformly produce
the proper error, although it is, through type-checking alone,
indistinguishable from the errors that would have existed before -- the
value is in the fact that it will tell the user the nature of the
failure, and it will be noisy when it may have been silent before.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1466065>
_______________________________________

From report at bugs.python.org  Wed Jul 29 18:33:24 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 29 Jul 2009 16:33:24 +0000
Subject: [issue6336] nb_divide missing in docs
In-Reply-To: <1245849137.7.0.528327337133.issue6336@psf.upfronthosting.co.za>
Message-ID: <1248885204.19.0.805558922028.issue6336@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r74256.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6336>
_______________________________________

From report at bugs.python.org  Wed Jul 29 18:40:22 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 29 Jul 2009 16:40:22 +0000
Subject: [issue1466065] base64 module ignores non-alphabet characters
Message-ID: <1248885622.32.0.573001583875.issue1466065@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

If "it may be noisy where it was silent before", then add one of those
cases and make sure the noise doesn't happen before your fix, and does
happen after.

If you have to check the value of the exception string for other tests,
then do so.  There are plenty of examples of this in the existing tests,
(see the pydoc tests, for example).  If you can limit what you test for
so that the test will be resitent to changes in the exact text, so much
the better.  You can use  assertRaisesRegexp for this in 2.7.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1466065>
_______________________________________

From report at bugs.python.org  Wed Jul 29 18:44:25 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 29 Jul 2009 16:44:25 +0000
Subject: [issue1466065] base64 module ignores non-alphabet characters
Message-ID: <1248885865.61.0.453862570113.issue1466065@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

What is the correct behavior for something like this?
   base64.b64decode('!')
2.6 silently returns ''.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1466065>
_______________________________________

From report at bugs.python.org  Wed Jul 29 18:58:05 2009
From: report at bugs.python.org (Neil Tallim)
Date: Wed, 29 Jul 2009 16:58:05 +0000
Subject: [issue1466065] base64 module ignores non-alphabet characters
Message-ID: <1248886685.78.0.179057585697.issue1466065@psf.upfronthosting.co.za>


Neil Tallim <red.hamsterx at gmail.com> added the comment:

According to the documentation cited by Seo Sanghyeon in the first post,
"A TypeError is raised if s were incorrectly padded or if there are
non-alphabet characters present in the string."

The valid range of characters is [A-Za-z0-9], and one or two '='s may
appear at the end of the input to signify dimension-padding. Therefore,
'!' should fail with a TypeError alerting the user to the presence of
unrecognized data, rather than being discarded.

(Additionally, it looks like newline characters in the input aren't
unheard of, and those are probably the reason behind the silent ignores)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1466065>
_______________________________________

From report at bugs.python.org  Wed Jul 29 18:58:33 2009
From: report at bugs.python.org (Neil Tallim)
Date: Wed, 29 Jul 2009 16:58:33 +0000
Subject: [issue1466065] base64 module ignores non-alphabet characters
Message-ID: <1248886713.47.0.783790119975.issue1466065@psf.upfronthosting.co.za>


Neil Tallim <red.hamsterx at gmail.com> added the comment:

R. David Murray, should I update the patches for both the pure-Python
solution and the C solution, or is one domain preferable here? The
Python-based solution keeps all of the invalid-character TypeErrors
collected in the same module, but the C-based solution allows this
problem to be caught more efficiently.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1466065>
_______________________________________

From report at bugs.python.org  Wed Jul 29 19:00:09 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 29 Jul 2009 17:00:09 +0000
Subject: [issue1466065] base64 module ignores non-alphabet characters
Message-ID: <1248886809.76.0.0220250257334.issue1466065@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> Therefore, '!' should fail with a TypeError
Here is your test case!
"Errors should never pass silently."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1466065>
_______________________________________

From report at bugs.python.org  Wed Jul 29 19:05:12 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 29 Jul 2009 17:05:12 +0000
Subject: [issue1466065] base64 module ignores non-alphabet characters
Message-ID: <1248887112.2.0.739188393452.issue1466065@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Amaury is probably better qualified to answer that question, but I would
think the C code version is preferable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1466065>
_______________________________________

From report at bugs.python.org  Wed Jul 29 19:14:21 2009
From: report at bugs.python.org (Neil Tallim)
Date: Wed, 29 Jul 2009 17:14:21 +0000
Subject: [issue1466065] base64 module ignores non-alphabet characters
Message-ID: <1248887661.54.0.0647341719718.issue1466065@psf.upfronthosting.co.za>


Changes by Neil Tallim <red.hamsterx at gmail.com>:


Removed file: http://bugs.python.org/file14586/1466065[2.7].diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1466065>
_______________________________________

From report at bugs.python.org  Wed Jul 29 19:14:26 2009
From: report at bugs.python.org (Neil Tallim)
Date: Wed, 29 Jul 2009 17:14:26 +0000
Subject: [issue1466065] base64 module ignores non-alphabet characters
Message-ID: <1248887666.49.0.395534234723.issue1466065@psf.upfronthosting.co.za>


Changes by Neil Tallim <red.hamsterx at gmail.com>:


Removed file: http://bugs.python.org/file14587/1466065[3.2].diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1466065>
_______________________________________

From report at bugs.python.org  Wed Jul 29 19:14:30 2009
From: report at bugs.python.org (Neil Tallim)
Date: Wed, 29 Jul 2009 17:14:30 +0000
Subject: [issue1466065] base64 module ignores non-alphabet characters
Message-ID: <1248887670.82.0.296508011447.issue1466065@psf.upfronthosting.co.za>


Changes by Neil Tallim <red.hamsterx at gmail.com>:


Removed file: http://bugs.python.org/file14588/1466065[2.7-pure-python].diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1466065>
_______________________________________

From report at bugs.python.org  Wed Jul 29 19:14:34 2009
From: report at bugs.python.org (Neil Tallim)
Date: Wed, 29 Jul 2009 17:14:34 +0000
Subject: [issue1466065] base64 module ignores non-alphabet characters
Message-ID: <1248887674.61.0.604318688775.issue1466065@psf.upfronthosting.co.za>


Changes by Neil Tallim <red.hamsterx at gmail.com>:


Removed file: http://bugs.python.org/file14589/1466065[3.2-pure-python].diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1466065>
_______________________________________

From report at bugs.python.org  Wed Jul 29 19:22:12 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 29 Jul 2009 17:22:12 +0000
Subject: [issue6595] Make Decimal constructor accept all unicode decimal
	digits in input.
In-Reply-To: <1248856795.44.0.0182588213317.issue6595@psf.upfronthosting.co.za>
Message-ID: <1248888132.34.0.474342859771.issue6595@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

+1

Also, I would like to see this backported.  We've long promised that any
variance with the spec will be treated as a bugfix.  The change won't
break any existing code.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6595>
_______________________________________

From report at bugs.python.org  Wed Jul 29 19:23:21 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 29 Jul 2009 17:23:21 +0000
Subject: [issue1466065] base64 module ignores non-alphabet characters
Message-ID: <1248888201.74.0.244541228568.issue1466065@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I've dig into the history of the file and found this change:
http://svn.python.org/view?view=rev&revision=13939
"- Illegal padding is now ignored.  (Recommendation by GvR.)"

The motivation at the time was based on "the general Internet philosophy":
http://mail.python.org/pipermail/python-bugs-list/1999-October/000234.html

I don't know if this is still valid 10 years later, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1466065>
_______________________________________

From report at bugs.python.org  Wed Jul 29 19:35:29 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 29 Jul 2009 17:35:29 +0000
Subject: [issue1466065] base64 module ignores non-alphabet characters
Message-ID: <1248888929.29.0.757220522023.issue1466065@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Perhaps Guido remembers why the decision was made.

----------
nosy: +gvanrossum, pitrou
versions: +Python 2.7, Python 3.2 -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1466065>
_______________________________________

From report at bugs.python.org  Wed Jul 29 19:40:19 2009
From: report at bugs.python.org (Neil Tallim)
Date: Wed, 29 Jul 2009 17:40:19 +0000
Subject: [issue1466065] base64 module ignores non-alphabet characters
Message-ID: <1248889219.88.0.811199755552.issue1466065@psf.upfronthosting.co.za>


Neil Tallim <red.hamsterx at gmail.com> added the comment:

I'll hold off on uploading new patches until someone makes a decision, then.

It seems like, perhaps, simply amending the documentation would be
sufficient, since this behaviour shouldn't break any valid messages that
might reach this module. At worst, it'll just treat gibberish as valid,
and that's what it's been doing for a decade. (Although the other decode
routines are all strict by comparison)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1466065>
_______________________________________

From report at bugs.python.org  Wed Jul 29 19:55:47 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 29 Jul 2009 17:55:47 +0000
Subject: [issue1466065] base64 module ignores non-alphabet characters
Message-ID: <1248890147.35.0.692190734224.issue1466065@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

It strikes me as simply a documentation bug. Maybe whoever wrote the
docs just assumed it would work that way. I expect that changing it to
insist on valid input would break some use cases. If you want a
validating API, perhaps a new API could be added that validates as well
as converts.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1466065>
_______________________________________

From report at bugs.python.org  Wed Jul 29 20:04:58 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 29 Jul 2009 18:04:58 +0000
Subject: [issue1466065] base64 module ignores non-alphabet characters
Message-ID: <1248890698.05.0.900708657335.issue1466065@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It turns out that the RFC is unambiguous on this point.  Quoting the
base64 section of RFC 2045:

   The encoded output stream must be represented in lines of no more
   than 76 characters each.  All line breaks or other characters not
   found in Table 1 must be ignored by decoding software.  In base64
   data, characters other than those in Table 1, line breaks, and other
   white space probably indicate a transmission error, about which a
   warning message or even a message rejection might be appropriate
   under some circumstances.

Since "some circumstances" is not something the base64 decoder can
decide, that has to be left to a higher level ap.  So if unexpected
characters are to generate an error, it would need to be enabled via a
flag that defaults to not raising the error, IMO.  Unless someone has a
use case for rejecting an improperly encoded message, we should probably
just fix the docs (perhaps noting that this behavior is in accordance
with the RFC).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1466065>
_______________________________________

From report at bugs.python.org  Wed Jul 29 20:14:05 2009
From: report at bugs.python.org (Neil Tallim)
Date: Wed, 29 Jul 2009 18:14:05 +0000
Subject: [issue1466065] base64 module ignores non-alphabet characters
Message-ID: <1248891245.82.0.15774886024.issue1466065@psf.upfronthosting.co.za>


Neil Tallim <red.hamsterx at gmail.com> added the comment:

RFC 3548, referenced by the base64 module's docs, has a rather different
statement on how invalid characters should be treated.

>From 2.3 Interpretation of non-alphabet characters in encoded data:
   Implementations MUST reject the encoding if it contains characters
   outside the base alphabet when interpreting base encoded data, unless
   the specification referring to this document explicitly states
   otherwise.  Such specifications may, as MIME does, instead state that
   characters outside the base encoding alphabet should simply be
   ignored when interpreting data ("be liberal in what you accept").

So it looks like we can safely just say that invalid characters are
ignored in the docs, as long as it's explicit, but that's probably not
what people will expect.


I'll add doc patches in a moment, and someone who's actually a developer
(i.e., not me) can decide whether they're good enough.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1466065>
_______________________________________

From report at bugs.python.org  Wed Jul 29 20:19:12 2009
From: report at bugs.python.org (Josiah Carlson)
Date: Wed, 29 Jul 2009 18:19:12 +0000
Subject: [issue6550] asyncore incorrect failure when connection is refused and
	using async_chat channel
In-Reply-To: <1248302571.21.0.910158552759.issue6550@psf.upfronthosting.co.za>
Message-ID: <1248891552.24.0.307313128775.issue6550@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

Originally, handle_expt_event() was described as "handles OOB data or 
exceptions", but over-using handle_expt_event() as an error/close 
handler is a bad idea.  The function asyncore.readwrite() (called by 
asyncore.poll2()) does the right thing WRT handle_expt_event(), which it 
makes sense to apply to the standard select-based asyncore.poll().  
That's what this does (in addition to fixing the close case that you 
pointed out).

In terms of "only implementing low-level stuff", this is still the case.  
You still only need to implement handle_*(), not handle_*_event() .  But 
now, handle_expt_event() isn't written to do more than it should have 
been doing in the first place.

I've updated the patch to include semantics for actually handling OOB 
data, which I've verified by using a slightly modified pyftpdlib (remove 
the socket option calls to set socket.SO_OOBINLINE) and it's tests on 
both Windows and Ubuntu 8.04 (I also ran the full Python test suite on 
my Ubuntu install, and any failures were obviously not asyncore/asynchat 
related).

----------
Added file: http://bugs.python.org/file14596/asyncore_fix_refused-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6550>
_______________________________________

From report at bugs.python.org  Wed Jul 29 20:19:31 2009
From: report at bugs.python.org (Josiah Carlson)
Date: Wed, 29 Jul 2009 18:19:31 +0000
Subject: [issue6550] asyncore incorrect failure when connection is refused and
	using async_chat channel
In-Reply-To: <1248302571.21.0.910158552759.issue6550@psf.upfronthosting.co.za>
Message-ID: <1248891571.49.0.343508034687.issue6550@psf.upfronthosting.co.za>


Changes by Josiah Carlson <josiahcarlson at users.sourceforge.net>:


Removed file: http://bugs.python.org/file14581/asyncore_fix_refused.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6550>
_______________________________________

From report at bugs.python.org  Wed Jul 29 20:19:35 2009
From: report at bugs.python.org (Josiah Carlson)
Date: Wed, 29 Jul 2009 18:19:35 +0000
Subject: [issue6550] asyncore incorrect failure when connection is refused and
	using async_chat channel
In-Reply-To: <1248302571.21.0.910158552759.issue6550@psf.upfronthosting.co.za>
Message-ID: <1248891575.51.0.576382832581.issue6550@psf.upfronthosting.co.za>


Changes by Josiah Carlson <josiahcarlson at users.sourceforge.net>:


Removed file: http://bugs.python.org/file14585/asyncore_fix_refused-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6550>
_______________________________________

From report at bugs.python.org  Wed Jul 29 20:23:27 2009
From: report at bugs.python.org (Neil Tallim)
Date: Wed, 29 Jul 2009 18:23:27 +0000
Subject: [issue1466065] base64 module ignores non-alphabet characters
Message-ID: <1248891807.45.0.353830252544.issue1466065@psf.upfronthosting.co.za>


Neil Tallim <red.hamsterx at gmail.com> added the comment:

Attached a documentation patch indicating that the
ignore-invalid-characters behaviour is intentional, citing relevant RFCs
for support.

Patch built against Python 2.7, r74261.

----------
Added file: http://bugs.python.org/file14597/1466065[2.7].diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1466065>
_______________________________________

From report at bugs.python.org  Wed Jul 29 20:23:57 2009
From: report at bugs.python.org (Neil Tallim)
Date: Wed, 29 Jul 2009 18:23:57 +0000
Subject: [issue1466065] base64 module ignores non-alphabet characters
Message-ID: <1248891837.01.0.53026997149.issue1466065@psf.upfronthosting.co.za>


Neil Tallim <red.hamsterx at gmail.com> added the comment:

Attached a documentation patch indicating that the
ignore-invalid-characters behaviour is intentional, citing relevant RFCs
for support.

Patch built against Python 3.2, r74261.

----------
Added file: http://bugs.python.org/file14598/1466065[3.2].diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1466065>
_______________________________________

From report at bugs.python.org  Wed Jul 29 20:28:05 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 29 Jul 2009 18:28:05 +0000
Subject: [issue1466065] base64 module ignores non-alphabet characters
Message-ID: <1248892085.13.0.413878906372.issue1466065@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1466065>
_______________________________________

From report at bugs.python.org  Wed Jul 29 20:39:28 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 29 Jul 2009 18:39:28 +0000
Subject: [issue1466065] base64 module ignores non-alphabet characters
Message-ID: <1248892768.03.0.144940350228.issue1466065@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Hmm.  But if the module is used outside of MIME (which it can be, and in
fact is in the stdlib itself), then an error must be raised in order to
comply with that RFC.  So it sounds like we really ought to have that
flag.  And I was even wrong about the appropriate default.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1466065>
_______________________________________

From report at bugs.python.org  Wed Jul 29 20:53:26 2009
From: report at bugs.python.org (Neil Tallim)
Date: Wed, 29 Jul 2009 18:53:26 +0000
Subject: [issue1466065] base64 module ignores non-alphabet characters
Message-ID: <1248893606.13.0.62492240823.issue1466065@psf.upfronthosting.co.za>


Neil Tallim <red.hamsterx at gmail.com> added the comment:

It isn't written that only MIME may ignore such content. The key terms
there are 'may' and 'explicitly states otherwise'.

If the documentation is clear, then all future application developers
will know to check for validity using a regular expression like
'^[A-Za-z0-9+/\r\n]+={0,2}$'. Any existing applications in which
validity matters should already have a similar workaround.

While I do agree that standards are always good and that workarounds are
bad, Guido does have a very valid point: "changing it to
insist on valid input would break some use cases", and I think we
already missed the 2.x -> 3.x window where that would have been acceptable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1466065>
_______________________________________

From report at bugs.python.org  Wed Jul 29 21:01:50 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 29 Jul 2009 19:01:50 +0000
Subject: [issue6596] urllib2 bug on CentOS
In-Reply-To: <1248863758.9.0.379989191773.issue6596@psf.upfronthosting.co.za>
Message-ID: <1248894110.45.0.705784291368.issue6596@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

What C compiler have you been using?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6596>
_______________________________________

From report at bugs.python.org  Wed Jul 29 21:05:05 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 29 Jul 2009 19:05:05 +0000
Subject: [issue1466065] base64 module ignores non-alphabet characters
In-Reply-To: <1248893606.13.0.62492240823.issue1466065@psf.upfronthosting.co.za>
Message-ID: <1248894476.2463.0.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> If the documentation is clear, then all future application developers
> will know to check for validity using a regular expression like
> '^[A-Za-z0-9+/\r\n]+={0,2}$'. Any existing applications in which
> validity matters should already have a similar workaround.

But having to validate input manually kinds of defeats the point of
having a decoder in the stdlib, therefore I agree with MRAB that a
validation flag would be useful.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1466065>
_______________________________________

From report at bugs.python.org  Wed Jul 29 21:07:57 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 29 Jul 2009 19:07:57 +0000
Subject: [issue1466065] base64 module ignores non-alphabet characters
Message-ID: <1248894477.77.0.690122826988.issue1466065@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

And if the flag defaults to the current behavior that should satisfy the
backward compatiblity issues.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1466065>
_______________________________________

From report at bugs.python.org  Wed Jul 29 21:23:45 2009
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Wed, 29 Jul 2009 19:23:45 +0000
Subject: [issue6275] let unittest.assertRaises() return the exception object
	caught
In-Reply-To: <1244842994.31.0.225778913715.issue6275@psf.upfronthosting.co.za>
Message-ID: <1248895425.44.0.414401060976.issue6275@psf.upfronthosting.co.za>


Changes by Raghuram Devarakonda <draghuram at gmail.com>:


----------
nosy: +draghuram

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6275>
_______________________________________

From report at bugs.python.org  Wed Jul 29 21:33:01 2009
From: report at bugs.python.org (Neil Tallim)
Date: Wed, 29 Jul 2009 19:33:01 +0000
Subject: [issue1466065] base64 module ignores non-alphabet characters
Message-ID: <1248895981.95.0.0767076987148.issue1466065@psf.upfronthosting.co.za>


Changes by Neil Tallim <red.hamsterx at gmail.com>:


Removed file: http://bugs.python.org/file14597/1466065[2.7].diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1466065>
_______________________________________

From report at bugs.python.org  Wed Jul 29 21:33:05 2009
From: report at bugs.python.org (Neil Tallim)
Date: Wed, 29 Jul 2009 19:33:05 +0000
Subject: [issue1466065] base64 module ignores non-alphabet characters
Message-ID: <1248895985.81.0.325091701666.issue1466065@psf.upfronthosting.co.za>


Changes by Neil Tallim <red.hamsterx at gmail.com>:


Removed file: http://bugs.python.org/file14598/1466065[3.2].diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1466065>
_______________________________________

From report at bugs.python.org  Wed Jul 29 21:35:52 2009
From: report at bugs.python.org (Dror Levin)
Date: Wed, 29 Jul 2009 19:35:52 +0000
Subject: [issue5833] readline update
In-Reply-To: <1240605993.87.0.323265568101.issue5833@psf.upfronthosting.co.za>
Message-ID: <1248896152.05.0.373268960588.issue5833@psf.upfronthosting.co.za>


Dror Levin <spatz at psybear.com> added the comment:

Arch Linux devs have split the patch and applied only the extra-space
fix, which is what I'm attaching now. I've compiled Python 2.6.2 on
Gentoo with this patch and can report it works well (I tested with ipython).

----------
Added file: http://bugs.python.org/file14599/python-2.6-readline.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5833>
_______________________________________

From report at bugs.python.org  Wed Jul 29 21:36:56 2009
From: report at bugs.python.org (Neil Tallim)
Date: Wed, 29 Jul 2009 19:36:56 +0000
Subject: [issue1466065] base64 module ignores non-alphabet characters
Message-ID: <1248896216.02.0.220513977255.issue1466065@psf.upfronthosting.co.za>


Neil Tallim <red.hamsterx at gmail.com> added the comment:

Attached a documentation/unit-test/solution patch that adds a
validate=False parameter to the b64decode function of Lib/base64.py,
which may be set to True to have invalid base64 content be rejected with
a TypeError.

Patch built against Python 3.2, r74261.

----------
Added file: http://bugs.python.org/file14600/1466065[3.2-complete].diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1466065>
_______________________________________

From report at bugs.python.org  Wed Jul 29 21:38:25 2009
From: report at bugs.python.org (Neil Tallim)
Date: Wed, 29 Jul 2009 19:38:25 +0000
Subject: [issue1466065] base64 module ignores non-alphabet characters
Message-ID: <1248896305.14.0.980810770972.issue1466065@psf.upfronthosting.co.za>


Neil Tallim <red.hamsterx at gmail.com> added the comment:

Attached a documentation/unit-test/solution patch that adds a
validate=False parameter to the b64decode function of Lib/base64.py,
which may be set to True to have invalid base64 content be rejected with
a TypeError.

Patch built against Python 2.7, r74261.


Note: Sorry this went on for so long. However, I think I understand the
patch-submission process a lot better now.

----------
Added file: http://bugs.python.org/file14601/1466065[2.7-complete].diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1466065>
_______________________________________

From report at bugs.python.org  Wed Jul 29 22:21:23 2009
From: report at bugs.python.org (Anton)
Date: Wed, 29 Jul 2009 20:21:23 +0000
Subject: [issue6596] urllib2 bug on CentOS
In-Reply-To: <1248863758.9.0.379989191773.issue6596@psf.upfronthosting.co.za>
Message-ID: <1248898883.97.0.631407073882.issue6596@psf.upfronthosting.co.za>


Anton <rk3dov at gmail.com> added the comment:

% gcc -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --
infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-
checking=release --with-system-zlib --enable-__cxa_atexit --disable-
libunwind-exceptions --enable-libgcj-multifile --enable-
languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --
disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-
gcj-1.4.2.0/jre --with-cpu=generic --host=i386-redhat-linux
Thread model: posix
gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6596>
_______________________________________

From report at bugs.python.org  Wed Jul 29 23:49:00 2009
From: report at bugs.python.org (John Levon)
Date: Wed, 29 Jul 2009 21:49:00 +0000
Subject: [issue1975] signals not always delivered to main thread,
	since other threads have the signal unmasked
In-Reply-To: <1201711085.9.0.419365608938.issue1975@psf.upfronthosting.co.za>
Message-ID: <1248904140.98.0.783790230279.issue1975@psf.upfronthosting.co.za>


John Levon <movement at users.sourceforge.net> added the comment:

Any progress on this regression? A patch is available... thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1975>
_______________________________________

From report at bugs.python.org  Thu Jul 30 00:22:53 2009
From: report at bugs.python.org (Justin MacCallum)
Date: Wed, 29 Jul 2009 22:22:53 +0000
Subject: [issue5738] multiprocessing example wrong
In-Reply-To: <1239483237.04.0.0741779763922.issue5738@psf.upfronthosting.co.za>
Message-ID: <1248906173.24.0.803810823054.issue5738@psf.upfronthosting.co.za>


Justin MacCallum <justin.maccallum at me.com> added the comment:

I think this should either be fixed or removed from the documentation. It 
is very confusing as is. I have next to no idea what I'm doing, but I've 
attached a patch that allows this code to function, at least sort of. You 
can now create cluster and pool objects and run jobs using map or 
apply_async, for example. However, there are still problems with the 
shutdown of the pool.

I would very much like to see this functionality working correctly and 
robustly. A distributed Pool class would be very useful in, e.g. 
scientific programming.

----------
keywords: +patch
nosy: +jlmaccal
Added file: http://bugs.python.org/file14602/mp_patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5738>
_______________________________________

From report at bugs.python.org  Thu Jul 30 00:25:28 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 29 Jul 2009 22:25:28 +0000
Subject: [issue1466065] base64 module ignores non-alphabet characters
Message-ID: <1248906328.7.0.211467288542.issue1466065@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1466065>
_______________________________________

From report at bugs.python.org  Thu Jul 30 01:21:39 2009
From: report at bugs.python.org (Matthew Russell)
Date: Wed, 29 Jul 2009 23:21:39 +0000
Subject: [issue6597] Depricate iterable.next in Python > 2.6.x when called
	with -3 option
In-Reply-To: <1248909699.69.0.0901747009049.issue6597@psf.upfronthosting.co.za>
Message-ID: <1248909699.69.0.0901747009049.issue6597@psf.upfronthosting.co.za>


New submission from Matthew Russell <matt.horizon5 at gmail.com>:

Not sure if this should be (tentative) feature request or behavior...

It might help new comers and those preparing to port to Python 3.

----------
assignee: georg.brandl
components: 2to3 (2.x to 3.0 conversion tool), Documentation, Interpreter Core
messages: 91072
nosy: georg.brandl, mattrussell
severity: normal
status: open
title: Depricate iterable.next in Python > 2.6.x when called with -3 option
type: behavior
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6597>
_______________________________________

From report at bugs.python.org  Thu Jul 30 01:22:11 2009
From: report at bugs.python.org (Matthew Russell)
Date: Wed, 29 Jul 2009 23:22:11 +0000
Subject: [issue6597] Deprecate iterable.next in Python > 2.6.x when called
	with -3 option ?
In-Reply-To: <1248909699.69.0.0901747009049.issue6597@psf.upfronthosting.co.za>
Message-ID: <1248909731.28.0.955605060175.issue6597@psf.upfronthosting.co.za>


Changes by Matthew Russell <matt.horizon5 at gmail.com>:


----------
title: Depricate iterable.next in Python > 2.6.x when called with -3 option -> Deprecate iterable.next in Python > 2.6.x when called with -3 option ?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6597>
_______________________________________

From report at bugs.python.org  Thu Jul 30 02:32:16 2009
From: report at bugs.python.org (Michael Hudson)
Date: Thu, 30 Jul 2009 00:32:16 +0000
Subject: [issue6598] calling email.utils.make_msgid frequently has a
	non-trivial probability of generating colliding ids
In-Reply-To: <1248913936.65.0.487457323949.issue6598@psf.upfronthosting.co.za>
Message-ID: <1248913936.65.0.487457323949.issue6598@psf.upfronthosting.co.za>


New submission from Michael Hudson <mwh at users.sourceforge.net>:

If you call email.utils.make_msgid a number of times within the same
second, the uniqueness of the results depends on random.randint(100000)
returning different values each time.

A little mathematics proves that you don't have to call make_msgid
*that* often to get the same message id twice: if you call it 'n' times,
the probability of a collision is approximately "1 -
math.exp(-n*(n-1)/200000.0)", and for n == 100, that's about 5%.  For n
== 1000, it's over 99%.

These numbers are born out by experiment:

>>> def collisions(n):
...     msgids = [make_msgid() for i in range(n)]
...     return len(msgids) - len(set(msgids))
... 
>>> sum((collisions(100)>0) for i in range(1000))
49
>>> sum((collisions(1000)>0) for i in range(1000))
991

I think probably having a counter in addition to the randomness would be
a good fix for the problem, though I guess then you have to worry about
thread safety.

----------
components: Library (Lib)
messages: 91073
nosy: mwh
severity: normal
status: open
title: calling email.utils.make_msgid frequently has a non-trivial probability of generating colliding ids
type: behavior
versions: 3rd party, Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6598>
_______________________________________

From report at bugs.python.org  Thu Jul 30 02:34:48 2009
From: report at bugs.python.org (Michael Hudson)
Date: Thu, 30 Jul 2009 00:34:48 +0000
Subject: [issue6598] calling email.utils.make_msgid frequently has a
	non-trivial probability of generating colliding ids
In-Reply-To: <1248913936.65.0.487457323949.issue6598@psf.upfronthosting.co.za>
Message-ID: <1248914088.48.0.653128836552.issue6598@psf.upfronthosting.co.za>


Michael Hudson <mwh at users.sourceforge.net> added the comment:

A higher resolution timer would also help, of course.

(Thanks to James Knight for the prod).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6598>
_______________________________________

From report at bugs.python.org  Thu Jul 30 03:14:15 2009
From: report at bugs.python.org (James Abbatiello)
Date: Thu, 30 Jul 2009 01:14:15 +0000
Subject: [issue6599] 2to3 test_print_function_option fails on Windows
In-Reply-To: <1248916455.36.0.400701947417.issue6599@psf.upfronthosting.co.za>
Message-ID: <1248916455.36.0.400701947417.issue6599@psf.upfronthosting.co.za>


New submission from James Abbatiello <abbeyj at gmail.com>:

test_print_function_option is failing on Windows.  Patch attached. 
Output of failure:

C:>python test.py
test_all_project_files (lib2to3.tests.test_all_fixers.Test_all) ...
<snip>\2to3\lib2to3\refactor.py:194: DeprecationWarning: the
'print_function' option is deprecated
  DeprecationWarning)
<snip>
======================================================================
FAIL: test_print_function_option
(lib2to3.tests.test_refactor.TestRefactoringTool)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "<snip>\2to3\lib2to3\tests\test_refactor.py", line 51, in
test_print_function_option
    self.assertEqual(len(w), 1)
AssertionError: 0 != 1

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


On my system test_all_fixers.py comes before test_refactor.py in the
output of os.listdir().  The warning gets fired by test_all_fixers and
then won't be retriggered in test_refactor.  Since the option doesn't do
anything anymore I've just removed its use.

----------
components: 2to3 (2.x to 3.0 conversion tool)
files: print_function_option.patch
keywords: patch
messages: 91075
nosy: abbeyj, benjamin.peterson
severity: normal
status: open
title: 2to3 test_print_function_option fails on Windows
Added file: http://bugs.python.org/file14603/print_function_option.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6599>
_______________________________________

From report at bugs.python.org  Thu Jul 30 03:23:22 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 30 Jul 2009 01:23:22 +0000
Subject: [issue6600] MemoryError in AiX 64-bit build
In-Reply-To: <1248917002.34.0.391671010793.issue6600@psf.upfronthosting.co.za>
Message-ID: <1248917002.34.0.391671010793.issue6600@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

(currently investigating the root cause of this issue...)

bash-2.04$ build/py2_6_2-aix5-powerpc-apy26-rrun/python/python -c "open
('/tmp/test', 'w')"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
MemoryError

bash-2.04$ build/py2_6_2-aix5-powerpc-apy26-rrun/python/python -c 
"import platform; print platform.uname()"
('AIX', 'asaixv5152', '1', '5', '000C763E4C00', 'powerpc')

bash-2.04$ file build/py2_6_2-aix5-powerpc-apy26-rrun/python/python 
build/py2_6_2-aix5-powerpc-apy26-rrun/python/python:    64-bit XCOFF 
executable or object module not stripped

----------
components: Build, IO
messages: 91076
nosy: srid
severity: normal
status: open
title: MemoryError in AiX 64-bit build
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6600>
_______________________________________

From report at bugs.python.org  Thu Jul 30 03:29:30 2009
From: report at bugs.python.org (James Abbatiello)
Date: Thu, 30 Jul 2009 01:29:30 +0000
Subject: [issue5093] 2to3 with a pipe on non-ASCII script
In-Reply-To: <1233188998.2.0.237730602839.issue5093@psf.upfronthosting.co.za>
Message-ID: <1248917370.8.0.496857960368.issue5093@psf.upfronthosting.co.za>


James Abbatiello <abbeyj at gmail.com> added the comment:

The --no-diffs option was recently added which looks like a good workaround.

Here's an attempt at a solution.  If sys.stdout has an encoding set then
use that, just as is being done now.  If there is no encoding (implying
"ascii") then use the encoding of the input file.

----------
nosy: +abbeyj
Added file: http://bugs.python.org/file14604/output_encoding.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5093>
_______________________________________

From report at bugs.python.org  Thu Jul 30 03:38:07 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 30 Jul 2009 01:38:07 +0000
Subject: [issue6600] MemoryError in AiX 64-bit build
In-Reply-To: <1248917002.34.0.391671010793.issue6600@psf.upfronthosting.co.za>
Message-ID: <1248917887.3.0.562548428803.issue6600@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

I suspect this is related to http://mail.python.org/pipermail/python-
bugs-list/2003-November/021158.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6600>
_______________________________________

From report at bugs.python.org  Thu Jul 30 05:00:21 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 30 Jul 2009 03:00:21 +0000
Subject: [issue6600] MemoryError in AiX 64-bit build
In-Reply-To: <1248917002.34.0.391671010793.issue6600@psf.upfronthosting.co.za>
Message-ID: <1248922821.65.0.331966923516.issue6600@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

I localized the error to line 248 in http://svn.python.org/view/python/
branches/release26-maint/Objects/fileobject.c?annotate=68135#248 
(brandl's change made 3 years ago)

  static PyObject *
  open_the_file(PyFileObject *f, char *name, char *mode)
  {
  [...]
    /* probably need to replace 'U' by 'rb' */
    newmode = PyMem_MALLOC(strlen(mode) + 3);
    if (!newmode) {
      PyErr_NoMemory();
      return NULL;
    }

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6600>
_______________________________________

From report at bugs.python.org  Thu Jul 30 05:11:26 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 30 Jul 2009 03:11:26 +0000
Subject: [issue6600] MemoryError in AiX 64-bit build
In-Reply-To: <1248917002.34.0.391671010793.issue6600@psf.upfronthosting.co.za>
Message-ID: <1248923486.75.0.829804654043.issue6600@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Interesting. If add the line:

  newmode = PyMem_MALLOC(4);

next to the existing line:

  newmode = PyMem_MALLOC(strlen(mode) + 3);

there is no MemoryError!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6600>
_______________________________________

From report at bugs.python.org  Thu Jul 30 05:21:05 2009
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 30 Jul 2009 03:21:05 +0000
Subject: [issue6526] importlib.import_module affects permissions of .pyc files
	subsequently created by import
In-Reply-To: <1248115523.66.0.058614511154.issue6526@psf.upfronthosting.co.za>
Message-ID: <1248924065.83.0.738619821729.issue6526@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


Removed file: http://bugs.python.org/file14527/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6526>
_______________________________________

From report at bugs.python.org  Thu Jul 30 05:26:35 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 30 Jul 2009 03:26:35 +0000
Subject: [issue6600] MemoryError in AiX 64-bit build
In-Reply-To: <1248917002.34.0.391671010793.issue6600@psf.upfronthosting.co.za>
Message-ID: <1248924395.51.0.56826831706.issue6600@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

This is strange .. the attached patch (reverses operands to +) fixes 
the issue.

----------
Added file: http://bugs.python.org/file14605/patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6600>
_______________________________________

From report at bugs.python.org  Thu Jul 30 05:59:47 2009
From: report at bugs.python.org (Andrew McNabb)
Date: Thu, 30 Jul 2009 03:59:47 +0000
Subject: [issue4606] Passing 'None' if argtype is set to POINTER(...) doesn't
	always result in NULL
In-Reply-To: <1228816020.28.0.155864486659.issue4606@psf.upfronthosting.co.za>
Message-ID: <1248926387.37.0.275185643216.issue4606@psf.upfronthosting.co.za>


Andrew McNabb <amcnabb at mcnabbs.org> added the comment:

I ran into this problem, too.  It took me a long time to track down the
segfaults.  It's really bad to pass in None and have the system pick
some random address instead of 0.

I looked at the attached patch, and it seems to me the only alternative
approach would be to use PyLong_FromLong instead of PyInt_FromLong. 
However, since ConvParam already handles None appropriately, I think the
fix in patch_ctypes_none_arg.diff really is the best way to do it.

This patch is a one-line fix (plus tests and documentation), and it
fixes a bug which crashes the interpreter.  The patch seems very
straightforward, and there is no way that code could depend on the
current behavior.  I'm not sure if my patch review counts for much, but
there you have it. :)

It would be great if this patch could be applied quickly and added to
the maintenance branch for 2.6.  Thanks.

----------
nosy: +amcnabb
type: behavior -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4606>
_______________________________________

From report at bugs.python.org  Thu Jul 30 06:20:36 2009
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 30 Jul 2009 04:20:36 +0000
Subject: [issue6526] importlib.import_module affects permissions of .pyc files
	subsequently created by import
In-Reply-To: <1248115523.66.0.058614511154.issue6526@psf.upfronthosting.co.za>
Message-ID: <1248927636.16.0.841838514688.issue6526@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

So removing the built-in, frozen, and extension importers did not stop the 
bug from happening. Calling importlib._bootstrap._PyFileFinder directly 
does not trigger the bug, even when trying with a finder for '.' first. 
And having sys.path be only '.' for fileinput still triggers the bug.

On another day, the next step is to start stripping out stuff in importlib 
to see what the minimal thing is that triggers the bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6526>
_______________________________________

From report at bugs.python.org  Thu Jul 30 09:27:54 2009
From: report at bugs.python.org (Zbigniew Chyla)
Date: Thu, 30 Jul 2009 07:27:54 +0000
Subject: [issue3932] HTMLParser cannot handle '&' and non-ascii characters in
	attribute names
In-Reply-To: <1222086790.7.0.800001604957.issue3932@psf.upfronthosting.co.za>
Message-ID: <1248938874.33.0.332790308829.issue3932@psf.upfronthosting.co.za>


Zbigniew Chyla <Zbigniew.Chyla at koelner.pl> added the comment:

Since `HTMLParser.unescape` in 2.5 returns `str` for `str` input, 2.6
should remain compatible. Therefore I propose the attached patch
(`HTMLParser-unescape-fix.diff`). With this patch applied the result
will have the same type as the input.

----------
keywords: +patch
nosy: +zchyla
Added file: http://bugs.python.org/file14606/HTMLParser-unescape-fix.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3932>
_______________________________________

From report at bugs.python.org  Thu Jul 30 09:28:32 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 30 Jul 2009 07:28:32 +0000
Subject: [issue6343] TimedRotatingFileHandler permission denied rename failure
	on Windows
In-Reply-To: <1245949185.33.0.897995880567.issue6343@psf.upfronthosting.co.za>
Message-ID: <1248938912.23.0.115541419386.issue6343@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

No activity for a while, closing.

----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6343>
_______________________________________

From report at bugs.python.org  Thu Jul 30 09:29:03 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 30 Jul 2009 07:29:03 +0000
Subject: [issue6314] logging.basicConfig(level='DEBUG',
	... and setLevel("DEBUG") result in no logging
In-Reply-To: <1245473929.89.0.283081310598.issue6314@psf.upfronthosting.co.za>
Message-ID: <1248938943.32.0.802974731477.issue6314@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

No feedback, closing.

----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6314>
_______________________________________

From report at bugs.python.org  Thu Jul 30 09:30:45 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 30 Jul 2009 07:30:45 +0000
Subject: [issue6136] Make logging configuration files easier to use
In-Reply-To: <1243494599.99.0.653406283097.issue6136@psf.upfronthosting.co.za>
Message-ID: <1248939045.1.0.470077223766.issue6136@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

No feedback, closing.

----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6136>
_______________________________________

From report at bugs.python.org  Thu Jul 30 09:30:58 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 30 Jul 2009 07:30:58 +0000
Subject: [issue6136] Make logging configuration files easier to use
In-Reply-To: <1243494599.99.0.653406283097.issue6136@psf.upfronthosting.co.za>
Message-ID: <1248939058.88.0.779353129433.issue6136@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
assignee:  -> vsajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6136>
_______________________________________

From report at bugs.python.org  Thu Jul 30 09:31:15 2009
From: report at bugs.python.org (Artur Frysiak)
Date: Thu, 30 Jul 2009 07:31:15 +0000
Subject: [issue3932] HTMLParser cannot handle '&' and non-ascii characters in
	attribute names
In-Reply-To: <1222086790.7.0.800001604957.issue3932@psf.upfronthosting.co.za>
Message-ID: <1248939075.76.0.0457246374448.issue3932@psf.upfronthosting.co.za>


Changes by Artur Frysiak <wiget at pld-linux.org>:


----------
nosy: +wiget

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3932>
_______________________________________

From report at bugs.python.org  Thu Jul 30 10:21:31 2009
From: report at bugs.python.org (Gavin Panella)
Date: Thu, 30 Jul 2009 08:21:31 +0000
Subject: [issue6598] calling email.utils.make_msgid frequently has a
	non-trivial probability of generating colliding ids
In-Reply-To: <1248913936.65.0.487457323949.issue6598@psf.upfronthosting.co.za>
Message-ID: <1248942091.67.0.642848343558.issue6598@psf.upfronthosting.co.za>


Changes by Gavin Panella <gavin at gromper.net>:


----------
nosy: +allenap

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6598>
_______________________________________

From report at bugs.python.org  Thu Jul 30 11:33:15 2009
From: report at bugs.python.org (Alexander Myodov)
Date: Thu, 30 Jul 2009 09:33:15 +0000
Subject: [issue6601] Fractions do not support other Fractions as numerators or
	denominators
In-Reply-To: <1248946395.45.0.703572208084.issue6601@psf.upfronthosting.co.za>
Message-ID: <1248946395.45.0.703572208084.issue6601@psf.upfronthosting.co.za>


New submission from Alexander Myodov <amyodov at gmail.com>:

Occurs in 2.6, doesn't occur in 3.1.
Example:

Python 2.6.2+ (release26-maint, Jun 23 2009, 07:08:39)
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from fractions import Fraction
>>> Fraction(Fraction(3,5), Fraction(1,2))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/fractions.py", line 99, in __new__
    numerator = operator.index(numerator)
TypeError: 'Fraction' object cannot be interpreted as an index


Compare:

Python 3.1 (r31:73572, Jul 23 2009, 23:41:26)
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from fractions import Fraction
>>> Fraction(Fraction(3,5), Fraction(1,2))
Fraction(6, 5)

----------
messages: 91088
nosy: honeyman
severity: normal
status: open
title: Fractions do not support other Fractions as numerators or denominators
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6601>
_______________________________________

From report at bugs.python.org  Thu Jul 30 11:43:21 2009
From: report at bugs.python.org (Anton)
Date: Thu, 30 Jul 2009 09:43:21 +0000
Subject: [issue6596] urllib2 bug on CentOS
In-Reply-To: <1248863758.9.0.379989191773.issue6596@psf.upfronthosting.co.za>
Message-ID: <1248947001.4.0.527489896928.issue6596@psf.upfronthosting.co.za>


Anton <rk3dov at gmail.com> added the comment:

The same problem with gcc 4.3.2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6596>
_______________________________________

From report at bugs.python.org  Thu Jul 30 11:53:06 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 30 Jul 2009 09:53:06 +0000
Subject: [issue6601] Fractions do not support other Fractions as numerators or
	denominators
In-Reply-To: <1248946395.45.0.703572208084.issue6601@psf.upfronthosting.co.za>
Message-ID: <1248947586.41.0.397201465622.issue6601@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Support for this was already added in 2.7 in r71832 (see issue 5812).  
Since this was a new feature and not a bugfix I don't think it would be 
appropriate to backport this change to 2.6.

----------
nosy: +marketdickinson
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6601>
_______________________________________

From report at bugs.python.org  Thu Jul 30 12:05:46 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 30 Jul 2009 10:05:46 +0000
Subject: [issue6601] Fractions do not support other Fractions as numerators or
	denominators
In-Reply-To: <1248946395.45.0.703572208084.issue6601@psf.upfronthosting.co.za>
Message-ID: <1248948346.63.0.965552413078.issue6601@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Hmm.  I've just noticed that r71832 didn't properly update the docs.  
Fixed in r74265 (trunk), r74267 (py3k) and r74268 (release31-maint).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6601>
_______________________________________

From report at bugs.python.org  Thu Jul 30 12:10:36 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 30 Jul 2009 10:10:36 +0000
Subject: [issue6595] Make Decimal constructor accept all unicode decimal
	digits in input.
In-Reply-To: <1248856795.44.0.0182588213317.issue6595@psf.upfronthosting.co.za>
Message-ID: <1248948636.41.0.35710764805.issue6595@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the feedback;  I've added 2.6, 2.7, 3.1 to the
versions and will backport.

[Eric]
> Since you're calling int() on the result, can't this code:
> self._int = str(int((intpart+fracpart).lstrip('0') or '0'))
> just be:
> self._int = str(int(intpart+fracpart))
> ?

Yes!  Thank you.  I'm not sure what (if anything) I was thinking here.

The str(int(...)) hack is quite an ugly way to normalize a string;  it 
also has the drawback of taking time quadratic in the length of the 
input.  In its defence: (a) I can't think of anything better; (b) this 
change seems to have no noticeable effect on the time to run the test-
suite, and (c) since all the arithmetic operations use string <-> int 
conversions anyway the quadratic time behaviour doesn't really make 
things any worse than they already are.

> And here, you already know diag is not None, so do you need the "or 
'0'"
> part?
> self._int = str(int(diag or '0')).lstrip('0')

I think *something* like this is needed, since diag can legitimately be 
the empty string.  It might be clearer as a proper if block, though:  
'if diag: ...  else: ...'.

----------
versions: +Python 2.6, Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6595>
_______________________________________

From report at bugs.python.org  Thu Jul 30 13:13:26 2009
From: report at bugs.python.org (tomkm)
Date: Thu, 30 Jul 2009 11:13:26 +0000
Subject: [issue6602] BaseHTTPServer log_message should log to sys.stdout
In-Reply-To: <1248952406.18.0.680079792557.issue6602@psf.upfronthosting.co.za>
Message-ID: <1248952406.18.0.680079792557.issue6602@psf.upfronthosting.co.za>


New submission from tomkm <tom at dialogue.net>:

I believe that the log_message method of BaseHTTPServer should log to
sys.stdout not sys.stderr, whereas log_error should log to sys.stderr
instead of just delegating to log_message.

I found this inconsistency when using SimpleXMLRPCServer which logs both
successful (200) and non-successful (non-200) requests to stderr when
logRequests is set to True.

----------
components: None
messages: 91093
nosy: tomkm
severity: normal
status: open
title: BaseHTTPServer log_message should log to sys.stdout
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6602>
_______________________________________

From report at bugs.python.org  Thu Jul 30 15:19:56 2009
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 30 Jul 2009 13:19:56 +0000
Subject: [issue4473] POP3 missing support for starttls
In-Reply-To: <1228063143.07.0.0563421485939.issue4473@psf.upfronthosting.co.za>
Message-ID: <1248959996.08.0.507072271538.issue4473@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4473>
_______________________________________

From report at bugs.python.org  Thu Jul 30 15:24:25 2009
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 30 Jul 2009 13:24:25 +0000
Subject: [issue4473] POP3 missing support for starttls
In-Reply-To: <1228063143.07.0.0563421485939.issue4473@psf.upfronthosting.co.za>
Message-ID: <1248960265.74.0.105084833203.issue4473@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

How is going? Any hope for 2.7/3.2?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4473>
_______________________________________

From report at bugs.python.org  Thu Jul 30 15:47:14 2009
From: report at bugs.python.org (Eric Smith)
Date: Thu, 30 Jul 2009 13:47:14 +0000
Subject: [issue6330] trunk does not build with --enable-unicode=ucs4
In-Reply-To: <1245783429.44.0.152732934194.issue6330@psf.upfronthosting.co.za>
Message-ID: <1248961634.37.0.138170471231.issue6330@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Fixed in r74269 (trunk). Code copied to py3k, just so the code stays in
sync, in r74271.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6330>
_______________________________________

From report at bugs.python.org  Thu Jul 30 16:01:09 2009
From: report at bugs.python.org (Michael Gorven)
Date: Thu, 30 Jul 2009 14:01:09 +0000
Subject: [issue4434] Embedding into a shared library fails
In-Reply-To: <1227690819.98.0.0359225476492.issue4434@psf.upfronthosting.co.za>
Message-ID: <1248962469.15.0.23911459176.issue4434@psf.upfronthosting.co.za>


Michael Gorven <michael at gorven.za.net> added the comment:

Note that on Ubuntu Hardy at least, the libpython2.5.so symlink only
exists in the python2.5-dev package. This means that in order for the
library to work without the dev package installed, it should dlopen
libpython2.5.so.1 instead.

----------
nosy: +mgorven

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4434>
_______________________________________

From report at bugs.python.org  Thu Jul 30 16:30:36 2009
From: report at bugs.python.org (Artur Frysiak)
Date: Thu, 30 Jul 2009 14:30:36 +0000
Subject: [issue6603] Compilation error if configuref --with-computed-gotos
In-Reply-To: <1248964236.44.0.906577171773.issue6603@psf.upfronthosting.co.za>
Message-ID: <1248964236.44.0.906577171773.issue6603@psf.upfronthosting.co.za>


New submission from Artur Frysiak <wiget at pld-linux.org>:

Building Python 3.1 (or Python from mercural py3k branch) fail if
configured --with-computed-gotos.

Traceback (most recent call last):
  File "./setup.py", line 13, in <module>
    from distutils.core import Extension, setup
  File "/home/users/wiget/mirror/python/cpython/Lib/distutils/core.py",
line 18, in <module>
    from distutils.dist import Distribution
  File "/home/users/wiget/mirror/python/cpython/Lib/distutils/dist.py",
line 12, in <module>
    import warnings
  File "/home/users/wiget/mirror/python/cpython/Lib/warnings.py", line
6, in <module>
    import linecache
  File "/home/users/wiget/mirror/python/cpython/Lib/linecache.py", line
10, in <module>
    import tokenize
  File "/home/users/wiget/mirror/python/cpython/Lib/tokenize.py", line
94, in <module>
    Ignore = Whitespace + any(r'\\\r?\n' + Whitespace) + maybe(Comment)
  File "/home/users/wiget/mirror/python/cpython/Lib/tokenize.py", line
87, in any
    def any(*choices): return group(*choices) + '*'
TypeError: group() argument after ** must be a mapping, not tuple
make: *** [sharedmods] Error 1

Compiled on PLD Linux using GCC 4.4.1

----------
components: Build
messages: 91097
nosy: wiget
severity: normal
status: open
title: Compilation error if configuref --with-computed-gotos
type: compile error
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6603>
_______________________________________

From report at bugs.python.org  Thu Jul 30 16:33:26 2009
From: report at bugs.python.org (Artur Frysiak)
Date: Thu, 30 Jul 2009 14:33:26 +0000
Subject: [issue6603] Compilation error if configuref --with-computed-gotos
In-Reply-To: <1248964236.44.0.906577171773.issue6603@psf.upfronthosting.co.za>
Message-ID: <1248964406.42.0.271781559818.issue6603@psf.upfronthosting.co.za>


Artur Frysiak <wiget at pld-linux.org> added the comment:

Exact options used to configure:

./configure \
 --enable-ipv6 \
 --with-wide-unicode \
 --enable-shared \
 --with-computed-gotos \
 --with-dbmliborder=gdbm:bdb \
 --with-signal-module \
 --with-tsc \
 --with-threads \
 --with-doc-strings \
 --with-fpectl \
 --with-system-ffi

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6603>
_______________________________________

From report at bugs.python.org  Thu Jul 30 16:35:46 2009
From: report at bugs.python.org (Artur Frysiak)
Date: Thu, 30 Jul 2009 14:35:46 +0000
Subject: [issue828336] Allow set swig include dirs in setup.py
Message-ID: <1248964546.33.0.791720840609.issue828336@psf.upfronthosting.co.za>


Artur Frysiak <wiget at pld-linux.org> added the comment:

Yes. issue1046644 solves this.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue828336>
_______________________________________

From report at bugs.python.org  Thu Jul 30 18:54:36 2009
From: report at bugs.python.org (jan matejek)
Date: Thu, 30 Jul 2009 16:54:36 +0000
Subject: [issue6604] test_distutils subtest test_get_exe_bytes fails depending
	on execution order
In-Reply-To: <1248972876.14.0.894982225722.issue6604@psf.upfronthosting.co.za>
Message-ID: <1248972876.14.0.894982225722.issue6604@psf.upfronthosting.co.za>


New submission from jan matejek <jmatejek at suse.cz>:

test_bdist_wininst.py fails in non-windows environment, depending on the
order of execution of tests in the test_distutils suite

When this test is not run on windows, msvccompiler.py fails to load
win32 registry modules and emits a warning-level message to the log.
Depending on which tests run before this test, the log threshold might
be set lower than WARN. in such case, The warning is actually printed,
test runner detects it and fails the test (which otherwise passes).

the attached patch sets log threshold to ERROR, silencing the warning
and producing a happier test ;e)

----------
assignee: tarek
components: Distutils
files: python-2.6.2-test_distutils.patch
keywords: patch
messages: 91100
nosy: matejcik, tarek
severity: normal
status: open
title: test_distutils subtest test_get_exe_bytes fails depending on execution order
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14607/python-2.6.2-test_distutils.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6604>
_______________________________________

From report at bugs.python.org  Thu Jul 30 19:16:24 2009
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 30 Jul 2009 17:16:24 +0000
Subject: [issue6597] Deprecate iterable.next in Python > 2.6.x when called
	with -3 option ?
In-Reply-To: <1248909699.69.0.0901747009049.issue6597@psf.upfronthosting.co.za>
Message-ID: <1248974184.61.0.242545518093.issue6597@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

2to3 already performs the change for calls to iter.next() as well the 
method definition, so a deprecation warning is redundant.

Thanks for the thought, though.

----------
assignee: georg.brandl -> 
components:  -Documentation, Interpreter Core
nosy: +brett.cannon
resolution:  -> rejected
stage:  -> test needed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6597>
_______________________________________

From report at bugs.python.org  Thu Jul 30 19:59:49 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Thu, 30 Jul 2009 17:59:49 +0000
Subject: [issue6042] Document and slightly simplify lnotab tracing
In-Reply-To: <1242505022.27.0.997047692556.issue6042@psf.upfronthosting.co.za>
Message-ID: <1248976789.4.0.538229730089.issue6042@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

The patch was merged to 3.x in r74132.

----------
assignee: jyasskin -> 
nosy: +alexandre.vassalotti
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6042>
_______________________________________

From report at bugs.python.org  Thu Jul 30 21:14:56 2009
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 30 Jul 2009 19:14:56 +0000
Subject: [issue4606] Passing 'None' if argtype is set to POINTER(...) doesn't
	always result in NULL
In-Reply-To: <1248926387.37.0.275185643216.issue4606@psf.upfronthosting.co.za>
Message-ID: <4A71F12E.70202@ctypes.org>


Thomas Heller <theller at ctypes.org> added the comment:

Thanks for bringing my attention to this problem again, and for the review.

Andrew McNabb schrieb:
> 
> I looked at the attached patch, and it seems to me the only alternative
> approach would be to use PyLong_FromLong instead of PyInt_FromLong. 

Using PyLong_FromLong doesn't make a difference at all, if you look into
the ConvParam code.

> However, since ConvParam already handles None appropriately, I think the
> fix in patch_ctypes_none_arg.diff really is the best way to do it.

The problem is that the patch changes the behaviour of the
'POINTER(...).from_param' methods, so I'm unsure if it can be applied
to 2.6 (or even 2.5).  Opinions?

> This patch is a one-line fix (plus tests and documentation), and it
> fixes a bug which crashes the interpreter.  The patch seems very

The patch is missing a 'Py_INCREF(value)' before the 'return value;',
but this is a minor point.

> straightforward, and there is no way that code could depend on the
> current behavior.

It could (on 32-bit systems), although I'm not sure if there is code
that does.

> I'm not sure if my patch review counts for much, but
> there you have it. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4606>
_______________________________________

From report at bugs.python.org  Thu Jul 30 21:17:38 2009
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 30 Jul 2009 19:17:38 +0000
Subject: [issue4606] Passing 'None' if argtype is set to POINTER(...) doesn't
	always result in NULL
In-Reply-To: <1228816020.28.0.155864486659.issue4606@psf.upfronthosting.co.za>
Message-ID: <1248981458.09.0.907024871685.issue4606@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

Here's a corrected patch against svn trunk.

----------
Added file: http://bugs.python.org/file14608/patch-ctypes-none-arg-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4606>
_______________________________________

From report at bugs.python.org  Thu Jul 30 21:23:12 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 30 Jul 2009 19:23:12 +0000
Subject: [issue6600] MemoryError in AiX 64-bit build - PyMem_MALLOC failed
In-Reply-To: <1248917002.34.0.391671010793.issue6600@psf.upfronthosting.co.za>
Message-ID: <1248981792.26.0.52553289048.issue6600@psf.upfronthosting.co.za>


Changes by Sridhar Ratnakumar <sridharr at activestate.com>:


----------
components: +Interpreter Core -Build, IO
title: MemoryError in AiX 64-bit build -> MemoryError in AiX 64-bit build - PyMem_MALLOC failed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6600>
_______________________________________

From report at bugs.python.org  Thu Jul 30 21:29:29 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 30 Jul 2009 19:29:29 +0000
Subject: [issue6600] MemoryError in AiX 64-bit build - PyMem_MALLOC failed
In-Reply-To: <1248917002.34.0.391671010793.issue6600@psf.upfronthosting.co.za>
Message-ID: <1248982169.42.0.985424870363.issue6600@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

This is after preprocessor run (cc_r -E):-

Original:
newmode = (((__strlen(mode) + 3) < 0 || (__strlen(mode) + 3) > 
((Py_ssize_t)(((size_t)-1)>>1))) ? 0 : malloc((__strlen(mode) + 3) ? 
(__strlen(mode) + 3) : 1));

Patched:
newmode = (((3 + __strlen(mode)) < 0 || (3 + __strlen(mode)) > 
((Py_ssize_t)(((size_t)-1)>>1))) ? 0 : malloc((3 + __strlen(mode)) ? (3 
+ __strlen(mode)) : 1));

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6600>
_______________________________________

From report at bugs.python.org  Thu Jul 30 21:39:23 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 30 Jul 2009 19:39:23 +0000
Subject: [issue6600] MemoryError in AiX 64-bit build - PyMem_MALLOC failed
In-Reply-To: <1248917002.34.0.391671010793.issue6600@psf.upfronthosting.co.za>
Message-ID: <1248982763.48.0.134979293796.issue6600@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Damn, now even the original code (without the patch) works. This is an 
unreliable issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6600>
_______________________________________

From report at bugs.python.org  Thu Jul 30 22:18:02 2009
From: report at bugs.python.org (Casey McGinty)
Date: Thu, 30 Jul 2009 20:18:02 +0000
Subject: [issue6605] smtplib.SMTP.sendmail() rejected after quit(),
	connect() sequence, no HELO
In-Reply-To: <1248985082.82.0.727591290783.issue6605@psf.upfronthosting.co.za>
Message-ID: <1248985082.82.0.727591290783.issue6605@psf.upfronthosting.co.za>


New submission from Casey McGinty <casey.mcginty at gmail.com>:

The smtplib.SMTP.quit() method does not reset the 'helo_resp' and
'ehlo_resp' instance attributes. During the next
smtplib.SMTP.sendmail(), the HELO/EHLO commands are not sent, and may
cause the remote SMTP service to reject the message, due to improper
protocol handshaking.

To fix, self.helo_resp and self.ehlo_resp should be set to 'None' in the
smtplib.SMTP.quit() method.

----------
components: Library (Lib)
messages: 91107
nosy: cmcginty
severity: normal
status: open
title: smtplib.SMTP.sendmail() rejected after quit(),connect() sequence, no HELO
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6605>
_______________________________________

From report at bugs.python.org  Thu Jul 30 22:21:11 2009
From: report at bugs.python.org (Casey McGinty)
Date: Thu, 30 Jul 2009 20:21:11 +0000
Subject: [issue6605] smtplib.SMTP.sendmail() rejected after quit(),
	connect() sequence, no HELO
In-Reply-To: <1248985082.82.0.727591290783.issue6605@psf.upfronthosting.co.za>
Message-ID: <1248985271.49.0.12933995581.issue6605@psf.upfronthosting.co.za>


Casey McGinty <casey.mcginty at gmail.com> added the comment:

Sorry, duplicate of #4142

----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6605>
_______________________________________

From report at bugs.python.org  Thu Jul 30 22:24:53 2009
From: report at bugs.python.org (Joseph Tate)
Date: Thu, 30 Jul 2009 20:24:53 +0000
Subject: [issue6606] csv.Sniffer.sniff on data with doublequotes doesn't set
	up the dialect properly
In-Reply-To: <1248985492.71.0.602333062674.issue6606@psf.upfronthosting.co.za>
Message-ID: <1248985492.71.0.602333062674.issue6606@psf.upfronthosting.co.za>


New submission from Joseph Tate <jtate+python at dragonstrider.com>:

Given the attached code, the Sniffer.sniff routine does not set the
doublequote property.  This results in errors during reader operations.
 If the doublequote property is set in the dialect, the data is read
properly.

The data was created using oocalc, forcing it to use ascii quotes rather
than u'\u201c\u201d'.

----------
components: Library (Lib)
files: foo.py
messages: 91109
nosy: jtate
severity: normal
status: open
title: csv.Sniffer.sniff on data with doublequotes doesn't set up the dialect properly
type: behavior
versions: Python 2.4, Python 2.6
Added file: http://bugs.python.org/file14609/foo.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6606>
_______________________________________

From report at bugs.python.org  Thu Jul 30 22:25:40 2009
From: report at bugs.python.org (Joseph Tate)
Date: Thu, 30 Jul 2009 20:25:40 +0000
Subject: [issue6606] csv.Sniffer.sniff on data with doublequotes doesn't set
	up the dialect properly
In-Reply-To: <1248985492.71.0.602333062674.issue6606@psf.upfronthosting.co.za>
Message-ID: <1248985540.34.0.428335560422.issue6606@psf.upfronthosting.co.za>


Joseph Tate <jtate+python at dragonstrider.com> added the comment:

Note that no exceptions are raised, the reader just returns improperly
parsed records.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6606>
_______________________________________

From report at bugs.python.org  Thu Jul 30 22:40:28 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 30 Jul 2009 20:40:28 +0000
Subject: [issue6596] urllib2 bug on CentOS
In-Reply-To: <1248863758.9.0.379989191773.issue6596@psf.upfronthosting.co.za>
Message-ID: <1248986428.59.0.654076429508.issue6596@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Can you rule out hardware problems?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6596>
_______________________________________

From report at bugs.python.org  Thu Jul 30 22:43:04 2009
From: report at bugs.python.org (Andrew McNabb)
Date: Thu, 30 Jul 2009 20:43:04 +0000
Subject: [issue4606] Passing 'None' if argtype is set to POINTER(...) doesn't
	always result in NULL
In-Reply-To: <4A71F12E.70202@ctypes.org>
Message-ID: <20090730204256.GB9602@mcnabbs.org>


Andrew McNabb <amcnabb at mcnabbs.org> added the comment:

On Thu, Jul 30, 2009 at 07:14:56PM +0000, Thomas Heller wrote:
> 
> Thanks for bringing my attention to this problem again, and for the review.

I'm just glad to help.

> The problem is that the patch changes the behaviour of the
> 'POINTER(...).from_param' methods, so I'm unsure if it can be applied
> to 2.6 (or even 2.5).  Opinions?

Hmm.  So you're saying that someone could be calling from_param() and
expecting to see 0 instead of None.  Am I understanding correctly?  I
suppose that could happen on either 32-bit or 64-bit systems (because
from_param returns 0 for both).  I can't personally think of a situation
where someone would rely on that, but maybe it's something to ask about
on python-dev.

I just looked at ConvParam in a little more detail, and it seems that
the problem is caused because setting pa->value.i to 0 only works for
the lower-order bits.  Apparently the higher order bits in pa->value are
non-zero when ConvParam is called.  Would it be possible to zero-out
pa->value at the top of ConvParam (i.e., putting "bzero(&(pa->value),
sizeof(pa->value)" or something at the top of ConvParam)?  Am I missing
something about what's in pa before ConvParam is called?

> The patch is missing a 'Py_INCREF(value)' before the 'return value;',
> but this is a minor point.

Thanks for pointing that out.  I'm still getting familiar with reference
counting in the Python API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4606>
_______________________________________

From report at bugs.python.org  Thu Jul 30 23:33:04 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 30 Jul 2009 21:33:04 +0000
Subject: [issue6600] MemoryError in AiX 64-bit build - PyMem_MALLOC failed
In-Reply-To: <1248917002.34.0.391671010793.issue6600@psf.upfronthosting.co.za>
Message-ID: <1248989584.57.0.407141930979.issue6600@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Forget the last comment, the patch is still valid and without it python 
gives MemoryError.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6600>
_______________________________________

From report at bugs.python.org  Fri Jul 31 01:56:35 2009
From: report at bugs.python.org (Amir Habibi)
Date: Thu, 30 Jul 2009 23:56:35 +0000
Subject: [issue6607] asctime causing python to crash
In-Reply-To: <1248998194.31.0.18315754711.issue6607@psf.upfronthosting.co.za>
Message-ID: <1248998194.31.0.18315754711.issue6607@psf.upfronthosting.co.za>


New submission from Amir Habibi <amir at aryosys.com>:

I use:
Python 2.6.2 
(r262:71605, Apr 14 2009, 22:40:02) 
[MSC v.1500 32 bit (Intel)] on win32

import time
asctime((2009, 1, 1, 24, 0, 0, 0, 0, 0))

the 24 is a wrong parameter but it should'n't crash the engine. This may
be the side effect of a more serious problem though. An assertion may
fix it.

----------
components: None
messages: 91114
nosy: AmirHabibi
severity: normal
status: open
title: asctime causing python to crash
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6607>
_______________________________________

From report at bugs.python.org  Fri Jul 31 01:56:48 2009
From: report at bugs.python.org (Amir Habibi)
Date: Thu, 30 Jul 2009 23:56:48 +0000
Subject: [issue6608] asctime causing python to crash
In-Reply-To: <1248998208.56.0.3155599029.issue6608@psf.upfronthosting.co.za>
Message-ID: <1248998208.56.0.3155599029.issue6608@psf.upfronthosting.co.za>


New submission from Amir Habibi <amir at aryosys.com>:

I use:
Python 2.6.2 
(r262:71605, Apr 14 2009, 22:40:02) 
[MSC v.1500 32 bit (Intel)] on win32

import time
time.asctime((2009, 1, 1, 24, 0, 0, 0, 0, 0))

the 24 is a wrong parameter but it should'n't crash the engine. This may
be the side effect of a more serious problem though. An assertion may
fix it.

----------
components: None
messages: 91115
nosy: AmirHabibi
severity: normal
status: open
title: asctime causing python to crash
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6608>
_______________________________________

From report at bugs.python.org  Fri Jul 31 02:12:50 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 31 Jul 2009 00:12:50 +0000
Subject: [issue6609] zipfile: WindowsError [267] The directory name is invalid
In-Reply-To: <1248999170.31.0.424602339152.issue6609@psf.upfronthosting.co.za>
Message-ID: <1248999170.31.0.424602339152.issue6609@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

The following exception occured when I tried to extract http://
sourceforge.net/projects/slut/files/slut/slut-0.9.0/slut-0.9.0.zip/
download using the zipfile module on Windows XP.

C:\\HOME\\as\\pypm-infinitude\\scratch\\b\\slut-0.9.0.zip.work is 1) 
current working directory 2) directory where the zip file was stored, 
3) directory where the extraction is to happen.

  [...]
    f.extractall()
  File "C:\Python26\lib\zipfile.py", line 935, in extractall
    self.extract(zipinfo, path, pwd)
  File "C:\Python26\lib\zipfile.py", line 923, in extract
    return self._extract_member(member, path, pwd)
  File "C:\Python26\lib\zipfile.py", line 957, in _extract_member
    os.makedirs(upperdirs)
  File "C:\Python26\lib\os.py", line 157, in makedirs
    mkdir(name, mode)
WindowsError: [Error 267] The directory name is invalid: 'C:\\HOME\\as\
\pypm-infinitude\\scratch\\b\\slut-0.9.0.zip.work\\slut-0.9\\aux'

----------
components: Library (Lib), Windows
messages: 91116
nosy: srid
severity: normal
status: open
title: zipfile: WindowsError [267] The directory name is invalid
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6609>
_______________________________________

From report at bugs.python.org  Fri Jul 31 02:16:45 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 31 Jul 2009 00:16:45 +0000
Subject: [issue6609] zipfile: WindowsError [267] The directory name is invalid
In-Reply-To: <1248999170.31.0.424602339152.issue6609@psf.upfronthosting.co.za>
Message-ID: <1248999405.74.0.0812985707934.issue6609@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Shortly following this exception, I tried to create the directory myself

  C:\...> mkdir slut-0.9\aux
  The directory name is invalid.

Curiously, I searched the internet for why a directory named 'aux' 
cannot be created anywhere on the Windows filesystem. The reason - this 
is a 'special' name: http://www.blindedbytech.com/2006/11/16/forbidden-
file-and-folder-names-on-windows/

However, does this mean one can never create a directory named by these 
special names? Apparently .. that is what I think is the case. I cannot 
even create a folder named 'aux' using Windows explorer!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6609>
_______________________________________

From report at bugs.python.org  Fri Jul 31 02:27:04 2009
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 31 Jul 2009 00:27:04 +0000
Subject: [issue6610] Subprocess descriptor debacle
In-Reply-To: <1249000024.51.0.280381658662.issue6610@psf.upfronthosting.co.za>
Message-ID: <1249000024.51.0.280381658662.issue6610@psf.upfronthosting.co.za>


New submission from Christian Heimes <lists at cheimes.de>:

The subprocess module may suffer from a minor design flaw that is
described at http://unixwiz.net/techtips/remap-pipe-fds.html under the
heading "Descriptor Debacle". The problem can occur under rare
conditions when a subprocess is created from a Python daemon process.

Proposed solution:

Create a function os.duprange(*args) that takes one or more tuple pairs
of file descriptors. The function takes care of the necessary order and
dubbing of fds.

----------
components: Library (Lib)
keywords: easy, needs review
messages: 91118
nosy: christian.heimes
priority: normal
severity: normal
stage: needs patch
status: open
title: Subprocess descriptor debacle
type: resource usage
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6610>
_______________________________________

From report at bugs.python.org  Fri Jul 31 02:29:50 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 31 Jul 2009 00:29:50 +0000
Subject: [issue6609] zipfile: WindowsError [267] The directory name is invalid
In-Reply-To: <1248999170.31.0.424602339152.issue6609@psf.upfronthosting.co.za>
Message-ID: <1249000190.56.0.220503543121.issue6609@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Let's keep this open as these sort of errors should ideally by wrapped 
under ZipError, no?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6609>
_______________________________________

From report at bugs.python.org  Fri Jul 31 03:48:20 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Fri, 31 Jul 2009 01:48:20 +0000
Subject: [issue6607] asctime causing python to crash
In-Reply-To: <1248998194.31.0.18315754711.issue6607@psf.upfronthosting.co.za>
Message-ID: <1249004900.84.0.586347515537.issue6607@psf.upfronthosting.co.za>


Changes by Alexandre Vassalotti <alexandre at peadrop.com>:


----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6607>
_______________________________________

From report at bugs.python.org  Fri Jul 31 04:08:16 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Fri, 31 Jul 2009 02:08:16 +0000
Subject: [issue6608] asctime causing python to crash
In-Reply-To: <1248998208.56.0.3155599029.issue6608@psf.upfronthosting.co.za>
Message-ID: <1249006096.34.0.957811404878.issue6608@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Confirmed. On Windows, the out-of-range value triggers a debugging
assertion in the CRT library.

----------
components: +Extension Modules, Windows -None
nosy: +alexandre.vassalotti
priority:  -> normal
stage:  -> needs patch
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6608>
_______________________________________

From report at bugs.python.org  Fri Jul 31 04:31:56 2009
From: report at bugs.python.org (Eric Smith)
Date: Fri, 31 Jul 2009 02:31:56 +0000
Subject: [issue6579] No update about automatic numbering of fields in format
	strings (e.g. 'A {} with {} buttocks')
In-Reply-To: <1248617469.33.0.437131453768.issue6579@psf.upfronthosting.co.za>
Message-ID: <1249007516.56.0.540451538069.issue6579@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

In http://docs.python.org/3.1/library/string.html#format-string-syntax,
the auto-numbering is mentioned, in the sentence that starts "If the
numerical arg_names in a format string are 0, 1, 2, ... in sequence,
they can all be omitted".

It's true that the field_name should be optional. I'll look at fixing that.

----------
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6579>
_______________________________________

From report at bugs.python.org  Fri Jul 31 05:35:32 2009
From: report at bugs.python.org (Thomas W. Barr)
Date: Fri, 31 Jul 2009 03:35:32 +0000
Subject: [issue6606] csv.Sniffer.sniff on data with doublequotes doesn't set
	up the dialect properly
In-Reply-To: <1248985492.71.0.602333062674.issue6606@psf.upfronthosting.co.za>
Message-ID: <1249011332.33.0.953241762629.issue6606@psf.upfronthosting.co.za>


Thomas W. Barr <twb at rice.edu> added the comment:

The Sniffer.sniff routine doesn't set the doublequote property at all
right now. I'm working on a patch to see if I can add this functionality.

----------
nosy: +twb
type: behavior -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6606>
_______________________________________

From report at bugs.python.org  Fri Jul 31 06:16:17 2009
From: report at bugs.python.org (Thomas W. Barr)
Date: Fri, 31 Jul 2009 04:16:17 +0000
Subject: [issue6606] csv.Sniffer.sniff on data with doublequotes doesn't set
	up the dialect properly
In-Reply-To: <1248985492.71.0.602333062674.issue6606@psf.upfronthosting.co.za>
Message-ID: <1249013777.56.0.249946016253.issue6606@psf.upfronthosting.co.za>


Thomas W. Barr <twb at rice.edu> added the comment:

Test for this issue.

----------
keywords: +patch
Added file: http://bugs.python.org/file14610/test_csv.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6606>
_______________________________________

From report at bugs.python.org  Fri Jul 31 06:17:25 2009
From: report at bugs.python.org (Thomas W. Barr)
Date: Fri, 31 Jul 2009 04:17:25 +0000
Subject: [issue6606] csv.Sniffer.sniff on data with doublequotes doesn't set
	up the dialect properly
In-Reply-To: <1248985492.71.0.602333062674.issue6606@psf.upfronthosting.co.za>
Message-ID: <1249013845.17.0.296145870851.issue6606@psf.upfronthosting.co.za>


Thomas W. Barr <twb at rice.edu> added the comment:

Patch for the issue. Looks for extraneous quote inside the quotes by the
delimiters.

----------
Added file: http://bugs.python.org/file14611/csv.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6606>
_______________________________________

From report at bugs.python.org  Fri Jul 31 06:19:42 2009
From: report at bugs.python.org (Thomas W. Barr)
Date: Fri, 31 Jul 2009 04:19:42 +0000
Subject: [issue6606] csv.Sniffer.sniff on data with doublequotes doesn't set
	up the dialect properly
In-Reply-To: <1248985492.71.0.602333062674.issue6606@psf.upfronthosting.co.za>
Message-ID: <1249013982.82.0.555383880218.issue6606@psf.upfronthosting.co.za>


Thomas W. Barr <twb at rice.edu> added the comment:

The documentation doesn't actually say what parameters are sniffed, so
technically, that doesn't need to be changed. Should this be added?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6606>
_______________________________________

From report at bugs.python.org  Fri Jul 31 06:20:49 2009
From: report at bugs.python.org (Thomas W. Barr)
Date: Fri, 31 Jul 2009 04:20:49 +0000
Subject: [issue6606] csv.Sniffer.sniff on data with doublequotes doesn't set
	up the dialect properly
In-Reply-To: <1248985492.71.0.602333062674.issue6606@psf.upfronthosting.co.za>
Message-ID: <1249014049.63.0.39742384188.issue6606@psf.upfronthosting.co.za>


Changes by Thomas W. Barr <twb at rice.edu>:


Removed file: http://bugs.python.org/file14611/csv.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6606>
_______________________________________

From report at bugs.python.org  Fri Jul 31 06:22:32 2009
From: report at bugs.python.org (Thomas W. Barr)
Date: Fri, 31 Jul 2009 04:22:32 +0000
Subject: [issue6606] csv.Sniffer.sniff on data with doublequotes doesn't set
	up the dialect properly
In-Reply-To: <1248985492.71.0.602333062674.issue6606@psf.upfronthosting.co.za>
Message-ID: <1249014152.17.0.406448075218.issue6606@psf.upfronthosting.co.za>


Thomas W. Barr <twb at rice.edu> added the comment:

Reformatted line in patch.

----------
Added file: http://bugs.python.org/file14612/csv.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6606>
_______________________________________

From report at bugs.python.org  Fri Jul 31 08:18:59 2009
From: report at bugs.python.org (Senthil)
Date: Fri, 31 Jul 2009 06:18:59 +0000
Subject: [issue6596] urllib2 bug on CentOS
In-Reply-To: <1248986428.59.0.654076429508.issue6596@psf.upfronthosting.co.za>
Message-ID: <20090731061845.GA10233@ubuntu.ubuntu-domain>


Senthil <orsenthil at gmail.com> added the comment:

I would also suggest run the following command:

$python /usr/local/lib/python2.6/test/regrtest.py -v test_urllib2
test_urllib test_socket > output-of-tests.txt

And attach output-of-tests.txt. It might help in getting to
the root cause of the issue.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6596>
_______________________________________

From report at bugs.python.org  Fri Jul 31 09:41:02 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 31 Jul 2009 07:41:02 +0000
Subject: [issue6550] asyncore incorrect failure when connection is refused and
	using async_chat channel
In-Reply-To: <1248302571.21.0.910158552759.issue6550@psf.upfronthosting.co.za>
Message-ID: <1249026062.06.0.698095477234.issue6550@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <billiejoex at users.sourceforge.net>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6550>
_______________________________________

From report at bugs.python.org  Fri Jul 31 09:45:54 2009
From: report at bugs.python.org (Liu DongMiao)
Date: Fri, 31 Jul 2009 07:45:54 +0000
Subject: [issue6611] HTMLParser cannot deal with mixture of arbitrary data and
	character reference
In-Reply-To: <1249026354.39.0.530341625498.issue6611@psf.upfronthosting.co.za>
Message-ID: <1249026354.39.0.530341625498.issue6611@psf.upfronthosting.co.za>


New submission from Liu DongMiao <liudongmiao at gmail.com>:

HTMLParser (Python 2.6.2) Cannot deal with mixture of arbitrary data and
character reference. 

In line 365-373, replaceEntities(s) returns unichr(charref) in unicode,
which cannot be a mixture with arbitrary data in str.

A fix way: replace unichr(c) with unichr(c).encode('utf-8').

----------
components: Library (Lib)
files: chinese.py
messages: 91128
nosy: liudongmiao at gmail.com
severity: normal
status: open
title: HTMLParser cannot deal with mixture of arbitrary data and character reference
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file14613/chinese.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6611>
_______________________________________

From report at bugs.python.org  Fri Jul 31 11:53:27 2009
From: report at bugs.python.org (W. Trevor King)
Date: Fri, 31 Jul 2009 09:53:27 +0000
Subject: [issue6612] 'import site' fails when called from an unlinked directory
In-Reply-To: <1249034007.06.0.695800326888.issue6612@psf.upfronthosting.co.za>
Message-ID: <1249034007.06.0.695800326888.issue6612@psf.upfronthosting.co.za>


New submission from W. Trevor King <wking at drexel.edu>:

I don't imagine this comes up very often, but:

$ mkdir /tmp/a; cd /tmp/a; rmdir /tmp/a; python -c 'import site';
rmdir: removing directory, /tmp/a
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/wking/lib/python/site.py", line 73, in <module>
    __boot()
  File "/home/wking/lib/python/site.py", line 33, in __boot
    imp.load_module('site',stream,path,descr)
  File "/usr/lib/python2.5/site.py", line 408, in <module>
    main()
  File "/usr/lib/python2.5/site.py", line 392, in main
    paths_in_sys = removeduppaths()
  File "/usr/lib/python2.5/site.py", line 96, in removeduppaths
    dir, dircase = makepath(dir)
  File "/usr/lib/python2.5/site.py", line 72, in makepath
    dir = os.path.abspath(os.path.join(*paths))
  File "/usr/lib/python2.5/posixpath.py", line 403, in abspath
    path = join(os.getcwd(), path)
OSError: [Errno 2] No such file or directory

----------
messages: 91129
nosy: labrat
severity: normal
status: open
title: 'import site' fails when called from an unlinked directory
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6612>
_______________________________________

From report at bugs.python.org  Fri Jul 31 14:33:39 2009
From: report at bugs.python.org (Matthew Barnett)
Date: Fri, 31 Jul 2009 12:33:39 +0000
Subject: [issue5093] 2to3 with a pipe on non-ASCII script
In-Reply-To: <1233188998.2.0.237730602839.issue5093@psf.upfronthosting.co.za>
Message-ID: <1249043611.51.0.80497055501.issue5093@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

I'd like to suggest that it the output could/should be encoded in UTF-8.

----------
nosy: +mrabarnett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5093>
_______________________________________

From report at bugs.python.org  Fri Jul 31 17:13:44 2009
From: report at bugs.python.org (Tiago Coutinho)
Date: Fri, 31 Jul 2009 15:13:44 +0000
Subject: [issue6613] ctypes.PyThreadState_SetAsyncExc does not work on linux
	64bit machines
In-Reply-To: <1249053223.75.0.703019238493.issue6613@psf.upfronthosting.co.za>
Message-ID: <1249053223.75.0.703019238493.issue6613@psf.upfronthosting.co.za>


New submission from Tiago Coutinho <coutinhotiago at gmail.com>:

Hello,

It seems that the ctypes.PyThreadState_SetAsyncExc is not working in
Linux 64bits machines

I have tried the code in attachment in python 2.5 and 2.6 in both 32bits
and 64bits machines with the following return:

      | linux 32bits | linux 64bits |
------|--------------|--------------|
py2.5 |     1 (OK)   |     0 (ERR)  |
py2.6 |     1 (OK)   |     0 (ERR)  |

I have also tried to make a python extension in C++ exporting a function
to python that simply calls the C++ PyThreadState_SetAsyncExc and this
works fine.

----------
assignee: theller
components: ctypes
files: t16.py
messages: 91131
nosy: coutinhotiago, theller
severity: normal
status: open
title: ctypes.PyThreadState_SetAsyncExc does not work on linux 64bit machines
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file14614/t16.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6613>
_______________________________________

From report at bugs.python.org  Fri Jul 31 17:56:55 2009
From: report at bugs.python.org (Thomas Heller)
Date: Fri, 31 Jul 2009 15:56:55 +0000
Subject: [issue6613] ctypes.PyThreadState_SetAsyncExc does not work on linux
	64bit machines
In-Reply-To: <1249053223.75.0.703019238493.issue6613@psf.upfronthosting.co.za>
Message-ID: <1249055815.06.0.22345947208.issue6613@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

I have no time to figure out what the attached script is supposed to do.
 Please provide a standalone test-script and describe exactly how it
should be used to reproduce the bug.

However, I guess the problem is that the signature of
PyThreadState_SetAsyncEx is this:
  int PyThreadState_SetAsyncExc( long id, PyObject *exc)

To call this function correctly on a 64-bit system you have to set
argtypes because 'long' isn't the same as 'int' any longer.  Without
argtypes, ctypes passes a Python integer as 'int' argument.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6613>
_______________________________________

From report at bugs.python.org  Fri Jul 31 18:30:16 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 31 Jul 2009 16:30:16 +0000
Subject: [issue6595] Make Decimal constructor accept all unicode decimal
	digits in input.
In-Reply-To: <1248856795.44.0.0182588213317.issue6595@psf.upfronthosting.co.za>
Message-ID: <1249057816.62.0.511893687255.issue6595@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I like the str(int(...))  approach because it guarantees handling that
is consistent with other types.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6595>
_______________________________________

From report at bugs.python.org  Fri Jul 31 18:56:02 2009
From: report at bugs.python.org (Joshua Bronson)
Date: Fri, 31 Jul 2009 16:56:02 +0000
Subject: [issue6614] heapq.nsmallest and nlargest should be smarter/more
	usable/more consistent
In-Reply-To: <1249059362.21.0.599959669928.issue6614@psf.upfronthosting.co.za>
Message-ID: <1249059362.21.0.599959669928.issue6614@psf.upfronthosting.co.za>


New submission from Joshua Bronson <jabronson at gmail.com>:

>From http://docs.python.org/library/heapq.html:
> The latter two functions (nlargest and nsmallest) perform best for
> smaller values of n. For larger values, it is more efficient to use
> the sorted() function. Also, when n==1, it is more efficient to use
> the builtin min() and max() functions.

A quick usability win for the heapq module: Be more specific than "smaller" and 
"larger", e.g. "when n is O(...(len(iterable)))".

>From http://groups.google.com/group/comp.lang.python/msg/9556f56ae25ecf3b:
> I find it interesting that the heapq functions tell you in the
> documentation that they aren't suitable for use where n==1 or where
> n is near the total size of the sequence whereas random.sample()
> chooses what it thinks is the best algorithm based on the input. At
> the very least I would have thought the heapq functions could check
> for n==1 and call min/max when it is.

+1. It looks like the pure Python implementation of nsmallest is actually already 
choosing either an insort algorithm or a minheap algorithm based on whether n * 10 <= 
len(iterable), but the C implementation of nsmallest unconditionally uses a minheap 
algorithm. Neither the pure Python nor the C implementation of nlargest chooses its 
algorithm conditionally. For the sake of consistency and usability, all 
implementations of nsmallest and nlargest should choose the most efficient algorithm 
from among min/max, insort, and minheap, and the docs should be updated to describe 
this behavior.

Also, in looking through the heapq.py that came with my Python 2.6.2 distribution, I 
noticed that line 196 seems to have no reason to be there:
    _heappushpop = heappushpop                                      
This is the only occurrence of "_heappushpop" in the file.

I made a patch for heapq.py, but since I'm not a CPython hacker, I thought it might 
be better to leave the changes up to someone who could do both the pure Python and 
the C implementations in tandem. I'd be happy to contribute documentation when the 
time comes if that would help.

----------
messages: 91134
nosy: jab
severity: normal
status: open
title: heapq.nsmallest and nlargest should be smarter/more usable/more consistent
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6614>
_______________________________________

From report at bugs.python.org  Fri Jul 31 19:18:08 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 31 Jul 2009 17:18:08 +0000
Subject: [issue6614] heapq.nsmallest and nlargest should be smarter/more
	usable/more consistent
In-Reply-To: <1249059362.21.0.599959669928.issue6614@psf.upfronthosting.co.za>
Message-ID: <1249060688.88.0.699508139967.issue6614@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

FWIW, 2.7 and 3.1 already have automatic selection of sort()/min()/max()
alternatives.  They use pure python to dispatch to the underlying C
functions:

http://svn.python.org/view/python/branches/release31-maint/Lib/heapq.py?revision=73579&view=markup

----------
assignee:  -> rhettinger
nosy: +rhettinger
resolution:  -> out of date
status: open -> closed
type: behavior -> performance
versions: +Python 3.2 -Python 2.5, Python 2.6, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6614>
_______________________________________

From report at bugs.python.org  Fri Jul 31 20:02:49 2009
From: report at bugs.python.org (James Abbatiello)
Date: Fri, 31 Jul 2009 18:02:49 +0000
Subject: [issue5093] 2to3 with a pipe on non-ASCII script
In-Reply-To: <1233188998.2.0.237730602839.issue5093@psf.upfronthosting.co.za>
Message-ID: <1249063369.43.0.0234458666003.issue5093@psf.upfronthosting.co.za>


James Abbatiello <abbeyj at gmail.com> added the comment:

In what case(s) do you propose the output to be encoded in UTF-8?  If
output is to a terminal and that terminal is set to Latin-1 or cp437 or
whatever then outputting UTF-8 in that case will only show garbage
characters to the user.

If output is to a file then using the encoding of the input file makes
the most sense to me.  Assume you have a simple program encoded in
Latin-1 that prints out a string with some non-ASCII characters.  The
patch is printed in UTF-8 encoding and redirected to a file.  The patch
program has no idea what encodings are used and it will just compare the
bytes in the original to the bytes in the patch file.  These won't match
since the encodings are different and he patch will fail.

If the output is to a pipe then I'm not sure what the right thing is. 
It may be intended for display on the screen with something like `less`
or it may not.  I don't think there's a good solution for this.

So following the above logic the patch attached here does the following:
1) If output is to a terminal (sys.stdout.encoding is set) then use that
encoding for output
2) Otherwise if an encoding was determined for the input file, use that
encoding for output
3) If all else fails, use 'ascii' encoding.  If the input contained
non-ASCII characters and no encoding has been determined for the input
then this will cause an exception to be raised.  I think this can only
happen when reading the input file from stdin.  Perhaps that case needs
to be looked at for how to detect the encoding of stdin.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5093>
_______________________________________

From report at bugs.python.org  Fri Jul 31 20:18:46 2009
From: report at bugs.python.org (Joshua Bronson)
Date: Fri, 31 Jul 2009 18:18:46 +0000
Subject: [issue6614] heapq.nsmallest and nlargest should be smarter/more
	usable/more consistent
In-Reply-To: <1249059362.21.0.599959669928.issue6614@psf.upfronthosting.co.za>
Message-ID: <1249064326.74.0.280021684491.issue6614@psf.upfronthosting.co.za>


Joshua Bronson <jabronson at gmail.com> added the comment:

Oh, that's great!

(I also noticed that the previously inutile line "_heappushpop = heappushpop" 
is now doing something in the heapq.py you linked to, nice.)

It looks like the docs haven't been updated yet though. For instance, 
http://docs.python.org/3.1/library/heapq.html still says "The latter two 
functions perform best for smaller values of n. For larger values, it is more 
efficient to use the sorted() function. Also, when n==1, it is more efficient 
to use the builtin min() and max() functions."

Also, I notice the pure Python implementation of nsmallest still does that 
check to see if n * 10 <= len(iterable), and if so uses an insort-based 
algorithm. It looks like this is still undocumented, inconsistent with the C 
implementation, and asymmetrical to the implementations of nlargest. If this 
branch is remaining there on purpose, I'd love see its existence mentioned and 
its theoretical basis explained in the docs, along with any similar branches 
implemented elsewhere in the code, if they should be.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6614>
_______________________________________

From report at bugs.python.org  Fri Jul 31 20:28:14 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 31 Jul 2009 18:28:14 +0000
Subject: [issue6614] heapq.nsmallest and nlargest should be smarter/more
	usable/more consistent
In-Reply-To: <1249059362.21.0.599959669928.issue6614@psf.upfronthosting.co.za>
Message-ID: <1249064894.87.0.0948736221162.issue6614@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I prefer the docs the way they are.  They help the reader understand the
relationship between min, max, nsmallest, nlargest, and sorted.

I'm not sure where you got the n * 10 <= len(iterable) switch-over
point.  That is arbitrary.  The correct switchover point depends on the
cost of the comparison function, whether the length of the input is
known, whether the input data is partially ordered, memory constraints,
whether a key function is used, and on other factors.   

FWIW, I also wrote the logic for random.sample().  The switchover logic
was straight-forward because performance depended on factors that were
fully known (length of input, sample size, memory utilization, and
average number of probes for each strategy).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6614>
_______________________________________

From report at bugs.python.org  Fri Jul 31 20:33:07 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 31 Jul 2009 18:33:07 +0000
Subject: [issue6614] heapq.nsmallest and nlargest should be smarter/more
	usable/more consistent
In-Reply-To: <1249059362.21.0.599959669928.issue6614@psf.upfronthosting.co.za>
Message-ID: <1249065187.0.0.963793623143.issue6614@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

One other thought:  When memory is tight, the programmer needs to be
able to select the heap algorithm in favor of sorted() even for
relatively large values of n.  I do not want an automatic switchover
point that takes away a programmer's choice between speed and space
efficiency.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6614>
_______________________________________

From report at bugs.python.org  Fri Jul 31 20:37:16 2009
From: report at bugs.python.org (Matthew Barnett)
Date: Fri, 31 Jul 2009 18:37:16 +0000
Subject: [issue5093] 2to3 with a pipe on non-ASCII script
In-Reply-To: <1233188998.2.0.237730602839.issue5093@psf.upfronthosting.co.za>
Message-ID: <1249065436.25.0.698106014964.issue5093@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

I was thinking that if you're converting a Python 2.x script to Python
3.x using 2to3 then also encoding the new script in UTF-8 might be a
good idea.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5093>
_______________________________________

From report at bugs.python.org  Fri Jul 31 20:41:54 2009
From: report at bugs.python.org (=?utf-8?q?Fran=C3=A7ois_HOUNDONOUGBO?=)
Date: Fri, 31 Jul 2009 18:41:54 +0000
Subject: [issue3493] No Backslash (\) in IDLE 1.2.2
In-Reply-To: <1217703828.28.0.450562077127.issue3493@psf.upfronthosting.co.za>
Message-ID: <1249065714.13.0.660706209983.issue3493@psf.upfronthosting.co.za>


Fran?ois HOUNDONOUGBO <funnyfrancois at gmail.com> added the comment:

Same probleme here with Idle 2.6.2, with a french keyboard.
I finally thought that it was due to a default binding recorded as 
<Option><Slash> or <Option><Shift>:, something like that, which is 
identical to the binding of Backslash character on my keyboard.
So I modified the binding "expand word" (can't remember why this one), 
recorded it under a new key set and applied it. After that, the 
backslash combination worked perfectly!!

But ... the bug now is that if I come back to the default OSX key set, 
it still works ...

(Another detail is that with the Logitech keyboard configuration (usb PC 
keyboard), it works at first try...)

Maybe this workaround will save your afternoon ...

----------
nosy: +funnyfrancois

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3493>
_______________________________________

From report at bugs.python.org  Fri Jul 31 21:22:33 2009
From: report at bugs.python.org (Joshua Bronson)
Date: Fri, 31 Jul 2009 19:22:33 +0000
Subject: [issue6614] heapq.nsmallest and nlargest should be smarter/more
	usable/more consistent
In-Reply-To: <1249059362.21.0.599959669928.issue6614@psf.upfronthosting.co.za>
Message-ID: <1249068153.91.0.565336800522.issue6614@psf.upfronthosting.co.za>


Joshua Bronson <jabronson at gmail.com> added the comment:

> I prefer the docs the way they are.  They help the reader understand
> the relationship between min, max, nsmallest, nlargest, and sorted.

Except that it's no longer true that "when n==1, it is more efficient to use the 
builtin min() and max() functions." Shouldn't this be updated to say "when n==1, 
it is equivalent to using the builtin min() and max() functions"?

> I'm not sure where you got the n * 10 <= len(iterable) switch-over
> point.

It's right in the file you linked to. Search for "n * 10" in 
http://svn.python.org/view/python/branches/release31-maint/Lib/heapq.py?
revision=73579&view=markup.

> That is arbitrary.  The correct switchover point depends on the
> cost of the comparison function, whether the length of the input is
> known, whether the input data is partially ordered, memory constraints,
> whether a key function is used, and on other factors.   

So should that be removed, then?

> FWIW, I also wrote the logic for random.sample().  The switchover logic
> was straight-forward because performance depended on factors that were
> fully known (length of input, sample size, memory utilization, and
> average number of probes for each strategy).
> One other thought:  When memory is tight, the programmer needs to be
> able to select the heap algorithm in favor of sorted() even for
> relatively large values of n.  I do not want an automatic switchover
> point that takes away a programmer's choice between speed and space
> efficiency.

Agreed, and thanks for the additional info.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6614>
_______________________________________

From report at bugs.python.org  Fri Jul 31 21:26:52 2009
From: report at bugs.python.org (Thomas W. Barr)
Date: Fri, 31 Jul 2009 19:26:52 +0000
Subject: [issue6606] csv.Sniffer.sniff on data with doublequotes doesn't set
	up the dialect properly
In-Reply-To: <1248985492.71.0.602333062674.issue6606@psf.upfronthosting.co.za>
Message-ID: <1249068412.17.0.953397043541.issue6606@psf.upfronthosting.co.za>


Thomas W. Barr <twb at rice.edu> added the comment:

Patch uploaded to rietveld: http://codereview.appspot.com/96202/show

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6606>
_______________________________________

From report at bugs.python.org  Fri Jul 31 21:34:32 2009
From: report at bugs.python.org (Thomas Heller)
Date: Fri, 31 Jul 2009 19:34:32 +0000
Subject: [issue4606] Passing 'None' if argtype is set to POINTER(...) doesn't
	always result in NULL
In-Reply-To: <1228816020.28.0.155864486659.issue4606@psf.upfronthosting.co.za>
Message-ID: <1249068872.87.0.697493317365.issue4606@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

Andrew McNabb schrieb:
> I just looked at ConvParam in a little more detail, and it seems that
> the problem is caused because setting pa->value.i to 0 only works for
> the lower-order bits.  Apparently the higher order bits in pa->value are
> non-zero when ConvParam is called.  Would it be possible to zero-out
> pa->value at the top of ConvParam (i.e., putting "bzero(&(pa->value),
> sizeof(pa->value)" or something at the top of ConvParam)?  Am I missing
> something about what's in pa before ConvParam is called?

Zeroing out higher order bits wouldn't help because the parameter would
still be passed as int instead as pointer; see the ffi_type field.

However, after thinking the whole issue over for some time I'm now
convinced that this patch is the right approach; even if .from_param()
returns 'None' instead of '0' the former should be accepted as well
because it better represents a NULL pointer anyway.

So I will apply the patch to trunk and 2.6, and forward port to the
python3 branches.  After further testing.

----------
resolution:  -> accepted
versions: +Python 2.7, Python 3.0, Python 3.1, Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4606>
_______________________________________

From report at bugs.python.org  Fri Jul 31 21:35:25 2009
From: report at bugs.python.org (Thomas Heller)
Date: Fri, 31 Jul 2009 19:35:25 +0000
Subject: [issue4606] Passing 'None' if argtype is set to POINTER(...) doesn't
	always result in NULL
In-Reply-To: <1228816020.28.0.155864486659.issue4606@psf.upfronthosting.co.za>
Message-ID: <1249068925.68.0.758672979319.issue4606@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

Python 3.0 is dead ;-).

----------
versions:  -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4606>
_______________________________________

From report at bugs.python.org  Fri Jul 31 21:36:04 2009
From: report at bugs.python.org (Joshua Bronson)
Date: Fri, 31 Jul 2009 19:36:04 +0000
Subject: [issue6614] heapq.nsmallest and nlargest should be smarter/more
	usable/more consistent
In-Reply-To: <1249059362.21.0.599959669928.issue6614@psf.upfronthosting.co.za>
Message-ID: <1249068964.38.0.0277457344309.issue6614@psf.upfronthosting.co.za>


Joshua Bronson <jabronson at gmail.com> added the comment:

One more thing:

> I prefer the docs the way they are.  They help the reader understand
> the relationship between min, max, nsmallest, nlargest, and sorted.

The docs still use the unspecific language "for smaller values of n" and 
"for larger values". I think careful readers would appreciate an addition 
along the lines of what you wrote earlier -- the optimal switchover point 
depends on the cost of the comparison function, the ordering of the input 
data, etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6614>
_______________________________________

From report at bugs.python.org  Fri Jul 31 21:39:38 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 31 Jul 2009 19:39:38 +0000
Subject: [issue6614] heapq.nsmallest and nlargest should be smarter/more
	usable/more consistent
In-Reply-To: <1249059362.21.0.599959669928.issue6614@psf.upfronthosting.co.za>
Message-ID: <1249069178.4.0.475994578957.issue6614@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

> Except that it's no longer true that "when n==1, it is
> more efficient to use the builtin min() and max() functions."

There's still the dispatch overhead.
If someone needs a n==1 case, they
*should* use min/max for both speed
and clarity.

Also, it is important the the docs
communicate the relationship between
min/max, nlargest/nsmallest, and sorted.


> It's right in the file you linked to. Search for "n * 10" in ...

That is in the pure python version of nsmallest() and that
code is not used (it is overriden by the C version).  The
actual C implementation works differently -- it uses an
underlying maxheap so it can use a cleaner algorithm that
doesn't need switchover tricks.

If you feel like "kicking the ball around", please continue the
discussion on comp.lang.python -- I think we're done here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6614>
_______________________________________

From report at bugs.python.org  Fri Jul 31 22:03:57 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 31 Jul 2009 20:03:57 +0000
Subject: [issue6570] Tutorial clarity: section 4.7.2, parameters and arguments
In-Reply-To: <1248510940.46.0.953855607394.issue6570@psf.upfronthosting.co.za>
Message-ID: <1249070637.26.0.776358632156.issue6570@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
title: Documentation Clarity -> Tutorial clarity: section 4.7.2, parameters and arguments

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6570>
_______________________________________

From report at bugs.python.org  Fri Jul 31 22:07:26 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 31 Jul 2009 20:07:26 +0000
Subject: [issue6574] List the __future__ features in a table
In-Reply-To: <1248600853.49.0.371600667943.issue6574@psf.upfronthosting.co.za>
Message-ID: <1249070846.13.0.806560167193.issue6574@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

For Python3, the table should start empty as of 3.0/3.1

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6574>
_______________________________________

From report at bugs.python.org  Fri Jul 31 22:11:26 2009
From: report at bugs.python.org (Thomas Heller)
Date: Fri, 31 Jul 2009 20:11:26 +0000
Subject: [issue6239] c_char_p return value returns string, not bytes
In-Reply-To: <1244477249.92.0.44777371921.issue6239@psf.upfronthosting.co.za>
Message-ID: <1249071086.06.0.9733260349.issue6239@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

Here's a patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file14615/c_char_p.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6239>
_______________________________________

From report at bugs.python.org  Fri Jul 31 22:26:18 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 31 Jul 2009 20:26:18 +0000
Subject: [issue6580] No deprecation warning for list comprehension leak
	conflict
In-Reply-To: <1248629103.59.0.528554407036.issue6580@psf.upfronthosting.co.za>
Message-ID: <1249071978.38.0.990445761121.issue6580@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

2.5 is closed to fixes other than security fixes.
So this needs to be checked with the latest 2.6.

The implementation of new features does not always exactly follow the
PEP. So if there is also no warning in 2.6, the question remains whether
accident or intention. Perhaps it was decided that the warning was too
difficult or that it would make too much noise because some people were
doing this intentionally and would not want the warning, whereas few
people accidentally do the sort of thing your example does.

If this is true, as I sort of suspect, the PEP should be revised not to
mislead.

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6580>
_______________________________________

From report at bugs.python.org  Fri Jul 31 22:32:13 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 31 Jul 2009 20:32:13 +0000
Subject: [issue6584] gzip module has no custom exception
In-Reply-To: <1248675050.27.0.747048824781.issue6584@psf.upfronthosting.co.za>
Message-ID: <1249072333.93.0.177961646408.issue6584@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Unless something in the docs claims that there is/should be such a
thing, this is a feature request, not a bug ('behavior') report, and
only applicable to future x.y versions.

----------
nosy: +tjreedy
type: behavior -> feature request
versions: +Python 2.7 -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6584>
_______________________________________

From report at bugs.python.org  Fri Jul 31 22:42:07 2009
From: report at bugs.python.org (Joshua Bronson)
Date: Fri, 31 Jul 2009 20:42:07 +0000
Subject: [issue6614] heapq.nsmallest and nlargest should be smarter/more
	usable/more consistent
In-Reply-To: <1249059362.21.0.599959669928.issue6614@psf.upfronthosting.co.za>
Message-ID: <1249072927.05.0.984772946808.issue6614@psf.upfronthosting.co.za>


Joshua Bronson <jabronson at gmail.com> added the comment:

> That is in the pure python version of nsmallest() and that
> code is not used (it is overriden by the C version).

So just because it isn't used by CPython it should remain in there even 
though as you said yourself it's completely without basis? What about non 
CPython? I'm not trying to "kick the ball around" here, we're both on the 
same team just trying to make Python better.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6614>
_______________________________________

From report at bugs.python.org  Fri Jul 31 23:03:28 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 31 Jul 2009 21:03:28 +0000
Subject: [issue1115] Minor Change For Better cross compile
In-Reply-To: <1189061255.17.0.84912008961.issue1115@psf.upfronthosting.co.za>
Message-ID: <1249074208.22.0.496634323994.issue1115@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
assignee: loewis -> gregory.p.smith
nosy: +gregory.p.smith
priority: low -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1115>
_______________________________________

From report at bugs.python.org  Fri Jul 31 23:05:04 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 31 Jul 2009 21:05:04 +0000
Subject: [issue3718] environment variable MACHDEP and python build system
In-Reply-To: <1219961932.19.0.767904041106.issue3718@psf.upfronthosting.co.za>
Message-ID: <1249074304.51.0.874629702399.issue3718@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3718>
_______________________________________

From report at bugs.python.org  Fri Jul 31 23:10:28 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 31 Jul 2009 21:10:28 +0000
Subject: [issue1006238] cross compile patch
Message-ID: <1249074628.4.0.651910358082.issue1006238@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1006238>
_______________________________________

From report at bugs.python.org  Fri Jul 31 23:13:38 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 31 Jul 2009 21:13:38 +0000
Subject: [issue1597850] Cross compiling patches for MINGW
Message-ID: <1249074818.42.0.86837652187.issue1597850@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1597850>
_______________________________________

From report at bugs.python.org  Fri Jul 31 23:14:32 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 31 Jul 2009 21:14:32 +0000
Subject: [issue5404] Cross-compiling Python
In-Reply-To: <1235984629.04.0.168155698084.issue5404@psf.upfronthosting.co.za>
Message-ID: <1249074872.68.0.154514224384.issue5404@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5404>
_______________________________________

From report at bugs.python.org  Fri Jul 31 23:23:29 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 31 Jul 2009 21:23:29 +0000
Subject: [issue6614] heapq.nsmallest and nlargest should be smarter/more
	usable/more consistent
In-Reply-To: <1249059362.21.0.599959669928.issue6614@psf.upfronthosting.co.za>
Message-ID: <1249075409.81.0.186230958299.issue6614@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

There is a basis for the pure python version to switch to bisect.

There is not a basis for having the final wrapped C function switch to
using sorted().  That is a programmer decision.

The pure python version is there to show how it could be done using a
minheap and it is a bit of hack to get it to work at all.  The C version
uses a maxheap and does not need logic for switching to bisect.  It is
clean and fast.

I'm sorry, but I've lost interest in continuing this discussion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6614>
_______________________________________

From report at bugs.python.org  Fri Jul 31 23:38:55 2009
From: report at bugs.python.org (Martin)
Date: Fri, 31 Jul 2009 21:38:55 +0000
Subject: [issue5505] sys.stdin.read() doesn't return after first EOF on Windows
In-Reply-To: <1237368034.29.0.0565107663013.issue5505@psf.upfronthosting.co.za>
Message-ID: <1249076335.99.0.162087180462.issue5505@psf.upfronthosting.co.za>


Martin <famart80 at gmail.com> added the comment:

Looks like python needs eof() or something for file objects, just like
any other languages.

Since read() is using the system call, that's the right behavior: read()
blocks until EOF, and returns whatever was buffered. EOF character is
consumed, but since it's a stdin, it is never closed. The next read()
will again wait for normal input.

The 2nd EOF mark without anything in-between will return an empty string.

----------
nosy: +famart

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5505>
_______________________________________