From report at bugs.python.org  Fri Oct  1 03:07:58 2010
From: report at bugs.python.org (Martin)
Date: Fri, 01 Oct 2010 01:07:58 +0000
Subject: [New-bugs-announce] [issue10003] signal.SIGBREAK regression on
	windows
In-Reply-To: <1285895278.8.0.672270997961.issue10003@psf.upfronthosting.co.za>
Message-ID: <1285895278.8.0.672270997961.issue10003@psf.upfronthosting.co.za>


New submission from Martin <gzlist at googlemail.com>:

The change in response to bug 9324 breaks bzr on windows as we use signal.SIGBREAK to listen for a ctrl+break keyboard press.

Although SIGBREAK is not documented as valid on:
<http://msdn.microsoft.com/library/xdkz3x12>
It does in fact work and corresponds to CTRL_BREAK_EVENT in native windows terms.

----------
components: Extension Modules, Windows
messages: 117769
nosy: brian.curtin, gz
priority: normal
severity: normal
status: open
title: signal.SIGBREAK regression on windows
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Oct  1 13:05:48 2010
From: report at bugs.python.org (Thomas Guettler)
Date: Fri, 01 Oct 2010 11:05:48 +0000
Subject: [New-bugs-announce] [issue10004] email/quoprimime.py Exception
	(with patch)
In-Reply-To: <1285931148.27.0.357018449582.issue10004@psf.upfronthosting.co.za>
Message-ID: <1285931148.27.0.357018449582.issue10004@psf.upfronthosting.co.za>


New submission from Thomas Guettler <guettli at thomas-guettler.de>:

I get the following traceback. I created a patch against email/quoprimime.py from SVN branch python2.7

  File "/usr/lib64/python2.6/email/header.py", line 93, in decode_header
    dec = email.quoprimime.header_decode(encoded)
  File "/usr/lib64/python2.6/email/quoprimime.py", line 336, in header_decode
    return re.sub(r'=\w{2}', _unquote_match, s)
  File "/usr/lib64/python2.6/re.py", line 150, in sub
    return _compile(pattern, 0).sub(repl, string, count)
  File "/usr/lib64/python2.6/email/quoprimime.py", line 324, in _unquote_match
    return unquote(s)
  File "/usr/lib64/python2.6/email/quoprimime.py", line 106, in unquote
    return chr(int(s[1:3], 16))
ValueError: invalid literal for int() with base 16: 'ih'

----------
components: Library (Lib)
files: quoprimime.py.diff
keywords: patch
messages: 117784
nosy: guettli
priority: normal
severity: normal
status: open
title: email/quoprimime.py Exception (with patch)
versions: Python 2.7
Added file: http://bugs.python.org/file19080/quoprimime.py.diff

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

From report at bugs.python.org  Fri Oct  1 14:58:41 2010
From: report at bugs.python.org (Popa Claudiu)
Date: Fri, 01 Oct 2010 12:58:41 +0000
Subject: [New-bugs-announce] [issue10005] Postgresql calls undefined method
	in __str__
In-Reply-To: <1285937921.5.0.29820555696.issue10005@psf.upfronthosting.co.za>
Message-ID: <1285937921.5.0.29820555696.issue10005@psf.upfronthosting.co.za>


New submission from Popa Claudiu <pcmanticore at gmail.com>:

In postgresql library, client3.py, the "__str__" method defined in Connection close calls the undefined method self.exception_string as in the following line of code:

excstr = ''.join(self.exception_string(type(self.exception), self.exception))

----------
components: Library (Lib)
messages: 117793
nosy: Popa.Claudiu
priority: normal
severity: normal
status: open
title: Postgresql calls undefined method in __str__
type: behavior
versions: 3rd party

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

From report at bugs.python.org  Fri Oct  1 15:47:33 2010
From: report at bugs.python.org (Yaroslav Halchenko)
Date: Fri, 01 Oct 2010 13:47:33 +0000
Subject: [New-bugs-announce] [issue10006] non-Pythonic fate of
	__abstractmethods__
In-Reply-To: <1285940853.14.0.546762707016.issue10006@psf.upfronthosting.co.za>
Message-ID: <1285940853.14.0.546762707016.issue10006@psf.upfronthosting.co.za>


New submission from Yaroslav Halchenko <yarikoptic at gmail.com>:

We ran into this while generating documentation for our project (PyMVPA) with recent sphinx and python2.6 (fine with 2.5, failed for 2.6, 2.7, 3.1), which relies on traversing all attributes given by "dir(obj)", BUT apparently __abstractmethods__ becomes very special -- it is given by "dir(obj)" since it is present in obj.__class__, but getattr(obj, "__abstractmethods__") fails for classes derived from type.  E.g. following sample demonstrates it:

print("in type's dir" , '__abstractmethods__' in dir(type))
print(type.__abstractmethods__)

class type3(type):
    pass

print("in type3's dir" , '__abstractmethods__' in dir(type3))
print(type3.__abstractmethods__)


results in output:

$> python2.6 trash/type_subclass.py
("in type's dir", True)
<attribute '__abstractmethods__' of 'type' objects>
("in type3's dir", True)
Traceback (most recent call last):
  File "trash/type_subclass.py", line 9, in <module>
    print(type3.__abstractmethods__)
AttributeError: __abstractmethods__


$> python3.1 trash/type_subclass.py 
in type's dir True
<attribute '__abstractmethods__' of 'type' objects>
in type3's dir True
Traceback (most recent call last):
  File "trash/type_subclass.py", line 9, in <module>
    print(type3.__abstractmethods__)
AttributeError: __abstractmethods__


And that seems to be the only attribute behaving like that (others are fine and accessible).  Some people even seems to provide workarounds already, e.g.:
http://bitbucket.org/DasIch/bpython-colorful/src/19bb4cb0a65d/bpython/repl.py
when __abstractmethods__ is accessed only for the subclasses of ABCmeta ...

so, is it a bug or a feature (so we have to take care about it in all traversals of attributes given by dir())? ;)

----------
messages: 117798
nosy: Yaroslav.Halchenko
priority: normal
severity: normal
status: open
title: non-Pythonic fate of __abstractmethods__
versions: Python 2.6

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

From report at bugs.python.org  Fri Oct  1 16:47:10 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 01 Oct 2010 14:47:10 +0000
Subject: [New-bugs-announce] [issue10007] Visual C++ cannot build _ssl and
	_hashlib if newer	OpenSSL is placed in $(dist) directory (PCBuild)
In-Reply-To: <1285944430.56.0.132893198817.issue10007@psf.upfronthosting.co.za>
Message-ID: <1285944430.56.0.132893198817.issue10007@psf.upfronthosting.co.za>


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

Visual C++ cannot build _ssl and _hashlib if newer OpenSSL
is placed in $(dist) directory. This happens on PCbuild.

Python3.2 uses openssl-1.0.0a
Python3.1 and 2.7 uses openssl-0.9.8l

If the directory layout is like this, Python3.1
cannot build _ssl and _hashlib.

python-dev
   +- openssl-0.9.8l
   +- openssl-1.0.0a
   +- py3k
   +- release31-maint
   +- release27-maint

Because build_ssl.py in release31-maint thinks newer
is better, and select openssl-1.0.0a, but pyproject.vsprops
hard-corded $(openssldir) as openssl-0.9.8l. So Modules/ssl.c
cannot import ssl.h and so on.

----------
components: Build
messages: 117805
nosy: ocean-city
priority: normal
severity: normal
status: open
title: Visual C++ cannot build _ssl and _hashlib if newer OpenSSL is placed in $(dist) directory (PCBuild)
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Oct  1 20:45:09 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 01 Oct 2010 18:45:09 +0000
Subject: [New-bugs-announce] [issue10008] Two links point to same place
In-Reply-To: <1285958709.04.0.778307485723.issue10008@psf.upfronthosting.co.za>
Message-ID: <1285958709.04.0.778307485723.issue10008@psf.upfronthosting.co.za>


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

Please see http://docs.python.org/genindex-T.html

  Thread (class in threading), [1]

This two links point to same place. I think latter should point
http://docs.python.org/library/threading.html#thread-objects
or
class threading.Thread(group=None, target=None, name=None, args=(), kwargs={})
bellow.

# Latter doesn't have perma link.

----------
assignee: docs at python
components: Documentation
messages: 117824
nosy: docs at python, ocean-city
priority: normal
severity: normal
status: open
title: Two links point to same place
versions: Python 2.7

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

From report at bugs.python.org  Fri Oct  1 22:11:49 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 01 Oct 2010 20:11:49 +0000
Subject: [New-bugs-announce] [issue10009] Automated MSI installation does
	not work
In-Reply-To: <1285963909.15.0.466947839123.issue10009@psf.upfronthosting.co.za>
Message-ID: <1285963909.15.0.466947839123.issue10009@psf.upfronthosting.co.za>


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

>From an old post on python-dev:
2010/08/04 Paul Kippes:
> For the most part, the information at
> http://www.python.org/download/releases/2.4/msi/ assisted me with
> automating a 2.7 installation on Windows XP. ?The following initial
> attempt, however, failed to provide a working python installation.
> (Messages are either "The system cannot execute the specified
> program." or "This application has failed to start because the
> application configuration is incorrect. ?Reinstalling the application
> may fix this problem.")
>
> msiexec /qb /i python-2.7.msi ALLUSERS=1 ADDLOCAL=Extensions
>
> After looking through Tools/msi/msi.py, I was able to automate a
> minimal and working Python installation with this adjustment:
>
> ADDLOCAL=Extensions,SharedCRT
>
> Since the only reference I could find to the above web page was when
> the MSI installer was first announced
> (http://www.python.org/download/releases/2.4.2), the installer options
> may have changed since then.
>
> Would you check if my change is what you intended and perhaps migrate
> the web page of the 2.4 release note to 2.7?
>
> Thanks!

----------
components: Installation
messages: 117831
nosy: amaury.forgeotdarc, loewis
priority: normal
severity: normal
status: open
title: Automated MSI installation does not work

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

From report at bugs.python.org  Fri Oct  1 22:55:04 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 01 Oct 2010 20:55:04 +0000
Subject: [New-bugs-announce] [issue10010] ".. index::" position
In-Reply-To: <1285966504.08.0.573086754525.issue10010@psf.upfronthosting.co.za>
Message-ID: <1285966504.08.0.573086754525.issue10010@psf.upfronthosting.co.za>


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

Hello. While I was reading HTML help, I felt some links
were not pointing to *before* what I wanted to read. When
I selected "sort (list method)" in keyword pane, it jumped
to *Note* section, but I was not sure where I was. Table
above was actually what I wanted to read.

With attached patch, I am happy.

----------
assignee: docs at python
components: Documentation
files: py27_doc_index.patch
keywords: patch
messages: 117833
nosy: docs at python, ocean-city
priority: normal
severity: normal
status: open
title: ".. index::" position
versions: Python 2.7
Added file: http://bugs.python.org/file19090/py27_doc_index.patch

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

From report at bugs.python.org  Sat Oct  2 00:51:10 2010
From: report at bugs.python.org (Ram Rachum)
Date: Fri, 01 Oct 2010 22:51:10 +0000
Subject: [New-bugs-announce] [issue10011] `except` doesn't use `isinstance`
In-Reply-To: <1285973470.62.0.723186105709.issue10011@psf.upfronthosting.co.za>
Message-ID: <1285973470.62.0.723186105709.issue10011@psf.upfronthosting.co.za>


New submission from Ram Rachum <cool-rr at cool-rr.com>:

Is there a reason why `execpt` compares base classes instead of using `isinstance`? This prevents using `__instancecheck__` to override the instance check.

----------
components: Interpreter Core
messages: 117844
nosy: cool-RR
priority: normal
severity: normal
status: open
title: `except` doesn't use `isinstance`
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Oct  2 01:44:08 2010
From: report at bugs.python.org (Cliff Wells)
Date: Fri, 01 Oct 2010 23:44:08 +0000
Subject: [New-bugs-announce] [issue10012] httplib shadows builtin,
	assumes strings
In-Reply-To: <1285976648.58.0.0752019030242.issue10012@psf.upfronthosting.co.za>
Message-ID: <1285976648.58.0.0752019030242.issue10012@psf.upfronthosting.co.za>


New submission from Cliff Wells <cliff at develix.com>:

httplib.py ~Line 924

    def putheader(self, header, *values):
        str = '%s: %s' % (header, '\r\n\t'.join(values))
        self._output(str)


should be changed to something like:


    def putheader(self, header, *values):
        ...
        s = '%s: %s' % (header, '\r\n\t'.join([str(v) for v in values]))
        self._output(s)

The current version shadows str builtin with a local variable.  join method assumes strings so they should probably be explicitly cast (at least one 3rd party library appears to pass Content-length as an integer, causing this to fail.  Of course, this can't be done unless the str builtin is no longer shadowed.

----------
components: Library (Lib)
messages: 117852
nosy: cwells
priority: normal
severity: normal
status: open
title: httplib shadows builtin, assumes strings
versions: Python 2.7

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

From report at bugs.python.org  Sat Oct  2 13:13:43 2010
From: report at bugs.python.org (Paul Menzel)
Date: Sat, 02 Oct 2010 11:13:43 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue10013=5D_fix_=60=2E/libpyth?=
 =?utf-8?q?on2=2E6=2Eso=3A_undefined_reference_to_=60=5FPyParser=5FGrammar?=
 =?utf-8?q?=C2=B4=60_in_parallel_builds?=
In-Reply-To: <1286018023.44.0.511102577172.issue10013@psf.upfronthosting.co.za>
Message-ID: <1286018023.44.0.511102577172.issue10013@psf.upfronthosting.co.za>


New submission from Paul Menzel <paulepanter at users.sourceforge.net>:

Compiling Python in parallel sometimes fails as reported in [1] and [2].

    ./libpython2.6.so: undefined reference to `_PyParser_Grammar?

Fedora applies a patch by dmalcolm <dmalcolm at fedoraproject.org> which fixes this issue [3].

    diff -up Python-2.7/Makefile.pre.in.fix-parallel-make Python-2.7/Makefile.pre.in
    --- Python-2.7/Makefile.pre.in.fix-parallel-make	2010-07-22 15:01:39.567996932 -0400
    +++ Python-2.7/Makefile.pre.in	2010-07-22 15:47:02.437998509 -0400
    @@ -207,6 +207,7 @@ SIGNAL_OBJS=	@SIGNAL_OBJS@
     
     ##########################################################################
     # Grammar
    +GRAMMAR_STAMP=	$(srcdir)/grammar-stamp
     GRAMMAR_H=	$(srcdir)/Include/graminit.h
     GRAMMAR_C=	$(srcdir)/Python/graminit.c
     GRAMMAR_INPUT=	$(srcdir)/Grammar/Grammar
    @@ -530,10 +531,24 @@ Modules/getpath.o: $(srcdir)/Modules/get
     Modules/python.o: $(srcdir)/Modules/python.c
     	$(MAINCC) -c $(PY_CFLAGS) -o $@ $(srcdir)/Modules/python.c
     
    +# GNU "make" interprets rules with two dependents as two copies of the rule.
    +# 
    +# In a parallel build this can lead to pgen being run twice, once for each of
    +# GRAMMAR_H and GRAMMAR_C, leading to race conditions in which the compiler
    +# reads a partially-overwritten copy of one of these files, leading to syntax
    +# errors (or linker errors if the fragment happens to be syntactically valid C)
    +#
    +# See http://www.gnu.org/software/hello/manual/automake/Multiple-Outputs.html
    +# for more information
    +#
    +# Introduce ".grammar-stamp" as a contrived single output from PGEN to avoid
    +# this:
    +$(GRAMMAR_H) $(GRAMMAR_C): $(GRAMMAR_STAMP)
     
    -$(GRAMMAR_H) $(GRAMMAR_C): $(PGEN) $(GRAMMAR_INPUT)
    +$(GRAMMAR_STAMP): $(PGEN) $(GRAMMAR_INPUT)
     		-@$(INSTALL) -d Include
     		-$(PGEN) $(GRAMMAR_INPUT) $(GRAMMAR_H) $(GRAMMAR_C)
    +		touch $(GRAMMAR_STAMP)
     
     $(PGEN):	$(PGENOBJS)
     		$(CC) $(OPT) $(LDFLAGS) $(PGENOBJS) $(LIBS) -o $(PGEN)

Could you please apply it. Could this also be applied to 2.6.x?


[1] http://doc.services.openoffice.org/wiki/RedTinderboxStatusInEIS
[2] http://www.openoffice.org/issues/show_bug.cgi?id=114866
[3] http://pkgs.fedoraproject.org/gitweb/?p=python.git;a=commit;h=b95f6cc2ca6a009f97436c6aa16cfd70547353d9

----------
components: Build
messages: 117865
nosy: PaulePanter
priority: normal
severity: normal
status: open
title: fix `./libpython2.6.so: undefined reference to `_PyParser_Grammar?` in parallel builds
type: compile error
versions: Python 2.6

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

From report at bugs.python.org  Sat Oct  2 14:14:23 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 02 Oct 2010 12:14:23 +0000
Subject: [New-bugs-announce] [issue10014] sys.path[0] is incorrect if
	PYTHONFSENCODING is used
In-Reply-To: <1286021663.34.0.689026258035.issue10014@psf.upfronthosting.co.za>
Message-ID: <1286021663.34.0.689026258035.issue10014@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

In the following example, sys.path[0] should be '/home/SHARE/SVN/py3k\udcc3\udca9' (my locale and filesystem encodings are utf-8):

$ cd /home/SHARE/SVN/py3k?
$ echo "import sys; print(sys.path[0])" > x.py
$ ./python x.py
/home/SHARE/SVN/py3k?
$ PYTHONFSENCODING=ascii ./python x.py
/home/SHARE/SVN/py3k?

The problem is that PySys_SetArgvEx() inserts argv[0] at sys.path[0], but argv[0] is decoded using the locale encoding (by _Py_char2wchar() in main()), whereas paths of sys.path are supposed to be encodable (and decoded) by sys.getfilesystemencoding().

argv array should be decoded using the filesystem encoding (see issue #9992) or argv[0] should be redecoded (encode to the locale encoding, and decode from the filesystem encoding, see issue #9630).

----------
components: Unicode
messages: 117870
nosy: haypo
priority: normal
severity: normal
status: open
title: sys.path[0] is incorrect if PYTHONFSENCODING is used
versions: Python 3.2

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

From report at bugs.python.org  Sat Oct  2 16:00:29 2010
From: report at bugs.python.org (Michael Olson)
Date: Sat, 02 Oct 2010 14:00:29 +0000
Subject: [New-bugs-announce] [issue10015] Creating a
	multiproccess.pool.ThreadPool from a child	thread blows up.
In-Reply-To: <1286028029.62.0.429525925265.issue10015@psf.upfronthosting.co.za>
Message-ID: <1286028029.62.0.429525925265.issue10015@psf.upfronthosting.co.za>


New submission from Michael Olson <olson at irinim.net>:

Using Python 2.7 x32 on Windows XP

Attempting to create a multiprocessing.pool.ThreadPool
in a child thread created using threading.Thread, an
AttributeError is thrown. A ThreadPool created in the 
main thread can be passed to the child thread and used.


Exact text of exception
-------------------
  File "D:\Dev\Python27\lib\multiprocessing\dummy\__init__.py", line 47, in star
t
    self._parent._children[self] = None
AttributeError: 'Thread' object has no attribute '_children'


Demonstration Code
-------------------
import unittest
from threading import Thread
from multiprocessing.pool import ThreadPool


def f(x):
    return x*x


def create_and_run(cb, pool = None):
    if not pool:
        pool = ThreadPool(2)
    r = pool.map_async(f, range(10))
    cb(r.get())


class TestThreadPool(unittest.TestCase):
    def setUp(self):
        self.expected = [f(x) for x in range(10)]

    def callback(self, data):
        self.data = data

    def test_creating_pool_in_mainthread(self):
        """Test multiprocessing.pool.ThreadPool from main thread"""
        self.data = None
        create_and_run(self.callback)
        self.assertEqual(self.data, self.expected)

    def test_creating_pool_in_subthread(self):
        """Test multiprocessing.pool.ThreadPool from a child thread."""
        self.data = None
        t = Thread(target=create_and_run, args=[self.callback])
        t.start()
        t.join()
        self.assertEqual(self.data, self.expected)

    def test_creating_pool_in_subthread_workaround(self):
        """Test running a ThreadPool created in main thread, used in child."""
        self.data = None
        pool = ThreadPool(2)
        t = Thread(target=create_and_run, args=[self.callback, pool])
        t.start()
        t.join()
        self.assertEqual(self.data, self.expected)


if __name__ =='__main__':
    suite = unittest.TestLoader().loadTestsFromTestCase(TestThreadPool)
    unittest.TextTestRunner(verbosity=2).run(suite)

----------
components: Library (Lib)
files: potential_issue_demo.py
messages: 117875
nosy: Michael.Olson
priority: normal
severity: normal
status: open
title: Creating a multiproccess.pool.ThreadPool from a child thread blows up.
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file19105/potential_issue_demo.py

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

From report at bugs.python.org  Sat Oct  2 16:16:55 2010
From: report at bugs.python.org (Tom Potts)
Date: Sat, 02 Oct 2010 14:16:55 +0000
Subject: [New-bugs-announce] [issue10016] shutil.copyfile -- allow sparse
	copying
In-Reply-To: <1286029015.57.0.815158740908.issue10016@psf.upfronthosting.co.za>
Message-ID: <1286029015.57.0.815158740908.issue10016@psf.upfronthosting.co.za>


New submission from Tom Potts <karaken12 at gmail.com>:

Copying a sparse file under Linux using shutil.copyfile will not result in a sparse file at the end of the process.  I'm submitting a patch that will remedy this.

Note that I am only concerned with Linux at the moment -- as far as I know this patch will not mess things up on other platforms, but this will need to be tested.  It depends on the behaviour of os.truncate() when the pointer is past the end of the file, which according to the docs is platform dependant.

Tom

P.S. This is my first time submitting an issue -- if there's anything I need to do and haven't, please let me know.

----------
components: Library (Lib)
files: shutil-2.6.patch
keywords: patch
messages: 117878
nosy: karaken12
priority: normal
severity: normal
status: open
title: shutil.copyfile -- allow sparse copying
type: feature request
versions: Python 2.6, Python 2.7, Python 3.2
Added file: http://bugs.python.org/file19107/shutil-2.6.patch

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

From report at bugs.python.org  Sat Oct  2 22:35:20 2010
From: report at bugs.python.org (Arnaud Delobelle)
Date: Sat, 02 Oct 2010 20:35:20 +0000
Subject: [New-bugs-announce] [issue10017] pprint.pprint raises TypeError on
	dictionaries with	user-defined types as keys
In-Reply-To: <1286051720.0.0.33399911329.issue10017@psf.upfronthosting.co.za>
Message-ID: <1286051720.0.0.33399911329.issue10017@psf.upfronthosting.co.za>


New submission from Arnaud Delobelle <arnodel at googlemail.com>:

The pprint function in the python 3.1 pprint module fails when
printing a dictionary containing more than one item and with one item
being a user-defined type.  It seems pprint tries to sort the keys but
fails, (maybe because calling __lt__ on a user-defined type doesn't
bind its first argument to 'self'?  Looking into pprint.py would
probably yield the answer).

This seems related to issue 3976 but it was fixed in r76389 and
r76390.  My example below fails in r79147.  I'm not in a position to check more recent revisions right now.

In Python 2.6, the following works fine:

Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from pprint import pprint
>>> class A(object): pass
... 
>>> pprint({A:1, 1:2})
{1: 2, <class __main__.A at 0xb77dc47c>: 1}


But in Python 3.1, it fails with the error below:

Python 3.1.2 (r312:79147, Apr 15 2010, 12:35:07) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from pprint import pprint
>>> class A: pass
... 
>>> pprint({A:1, 1:2})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.1/pprint.py", line 55, in pprint
    printer.pprint(object)
  File "/usr/lib/python3.1/pprint.py", line 132, in pprint
    self._format(object, self._stream, 0, 0, {}, 0)
  File "/usr/lib/python3.1/pprint.py", line 155, in _format
    rep = self._repr(object, context, level - 1)
  File "/usr/lib/python3.1/pprint.py", line 242, in _repr
    self._depth, level)
  File "/usr/lib/python3.1/pprint.py", line 254, in format
    return _safe_repr(object, context, maxlevels, level)
  File "/usr/lib/python3.1/pprint.py", line 296, in _safe_repr
    items = sorted(object.items(), key=_safe_tuple)
  File "/usr/lib/python3.1/pprint.py", line 89, in __lt__
    rv = self.obj.__lt__(other.obj)
TypeError: expected 1 arguments, got 0

----------
components: Library (Lib)
messages: 117895
nosy: arno
priority: normal
severity: normal
status: open
title: pprint.pprint raises TypeError on dictionaries with user-defined types as keys
versions: Python 3.1

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

From report at bugs.python.org  Sun Oct  3 06:19:22 2010
From: report at bugs.python.org (Grant Andrew)
Date: Sun, 03 Oct 2010 04:19:22 +0000
Subject: [New-bugs-announce] [issue10018] IDLE not loading in xp pro due to
	tcl issue
In-Reply-To: <1286079562.42.0.239403513139.issue10018@psf.upfronthosting.co.za>
Message-ID: <1286079562.42.0.239403513139.issue10018@psf.upfronthosting.co.za>


New submission from Grant Andrew <gveggie at gmail.com>:

I'm attempting to use Python for the first time and am running into issues before I'm out the door.  I started with 3.2 and have worked backward installing older versions in hopes that IDLE would load on my xp pro laptop.  

After reading several threads here, I ran C:\>C:\python27\python C:\python27\Lib\idlelib\idle.py at a command prompt and received the following output:

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

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


This probably means that Tcl wasn't installed properly.

After searching threads here and a general google search on TCL I couldn't turn up a link that helped with this issue.  The closest tcl version available is 8.4.19 which isn't exact, so I'm hesitant to install this and blow something else up.

Help is appreciated!

Grant

----------
components: IDLE
messages: 117907
nosy: Grant.Andrew
priority: normal
severity: normal
status: open
title: IDLE not loading in xp pro due to tcl issue
type: crash
versions: Python 2.5, Python 2.6, Python 2.7

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

From report at bugs.python.org  Sun Oct  3 18:22:37 2010
From: report at bugs.python.org (David Janes)
Date: Sun, 03 Oct 2010 16:22:37 +0000
Subject: [New-bugs-announce] [issue10019] json.dumps with indent = 0 not
	adding newlines
In-Reply-To: <1286122957.24.0.240376565719.issue10019@psf.upfronthosting.co.za>
Message-ID: <1286122957.24.0.240376565719.issue10019@psf.upfronthosting.co.za>


New submission from David Janes <davidjanes at davidjanes.com>:

In Python 2.6.4, json.dumps(...,indent=0) produced newlines as documented here: http://docs.python.org/library/json.html#json.dump
In Python 2.7, it no longer adds newlines.

$ python
Python 2.6.4 (r264:75706, Jan 13 2010, 19:41:08) 
[GCC 4.1.2 20080704 (Red Hat 4.1.2-46)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import json
>>> json.dumps({3:1,4:2},indent=0)
'{\n"3": 1, \n"4": 2\n}'
>>> print json.dumps({3:1,4:2},indent=0)
{
"3": 1, 
"4": 2
}



$ python
Python 2.7 (r27:82500, Oct  3 2010, 06:00:45) 
[GCC 4.1.2 20080704 (Red Hat 4.1.2-46)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import json
>>> json.dumps({3:1,4:2})
'{"3": 1, "4": 2}'
>>> print json.dumps({3:1,4:2},indent=0)
{"3": 1, "4": 2}

----------
components: Library (Lib)
messages: 117917
nosy: dpjanes
priority: normal
severity: normal
status: open
title: json.dumps with indent = 0 not adding newlines
versions: Python 2.7

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

From report at bugs.python.org  Sun Oct  3 18:52:33 2010
From: report at bugs.python.org (Doug Hellmann)
Date: Sun, 03 Oct 2010 16:52:33 +0000
Subject: [New-bugs-announce] [issue10020] docs for sqlite3 describe
	functions not available	without recompiling
In-Reply-To: <1286124753.24.0.309036392806.issue10020@psf.upfronthosting.co.za>
Message-ID: <1286124753.24.0.309036392806.issue10020@psf.upfronthosting.co.za>


New submission from Doug Hellmann <doug.hellmann at gmail.com>:

The documentation for the sqlite3 module describes enable_load_extension() and load_extension() methods of the Connection object, but those functions are only available if the user has compiled from source *after* modifying the setup.py to turn off SQLITE_OMIT_LOAD_EXTENSION.

I'd like to see the functions enabled by default (by changing setup.py) but at the very least the documentation should be updated.

----------
components: Extension Modules
messages: 117919
nosy: doughellmann
priority: normal
severity: normal
status: open
title: docs for sqlite3 describe functions not available without recompiling
versions: Python 2.7

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

From report at bugs.python.org  Mon Oct  4 18:24:06 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 04 Oct 2010 16:24:06 +0000
Subject: [New-bugs-announce] [issue10021] Format parser is too permissive
In-Reply-To: <1286209446.65.0.698670214161.issue10021@psf.upfronthosting.co.za>
Message-ID: <1286209446.65.0.698670214161.issue10021@psf.upfronthosting.co.za>


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

According to the Format String Syntax section [1], attribute_name must be an identifier.  However, the parser does not catch a violation of this rule and happily passes non-indentifier strings to getattribute:

>>> class X:
...    def __getattribute__(self, a): return 'foo'
... 
>>> '{.$#@}'.format(X())
'foo'
 
If this is a desirable feature, I think it should be clearly documented because in some cases, for example when formatted objects are proxies to  database entries, passing arbitrary strings to __getattribute__ may be wasteful at best and a security hole at worst.


[1] http://docs.python.org/dev/py3k/library/string.html#format-string-syntax

----------
components: Interpreter Core
messages: 117961
nosy: belopolsky
priority: normal
severity: normal
status: open
title: Format parser is too permissive
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Mon Oct  4 18:32:15 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Oct 2010 16:32:15 +0000
Subject: [New-bugs-announce] [issue10022] Emit more information in decoded
	SSL certificates
In-Reply-To: <1286209935.64.0.606028166295.issue10022@psf.upfronthosting.co.za>
Message-ID: <1286209935.64.0.606028166295.issue10022@psf.upfronthosting.co.za>


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

There's some code in _ssl.c which exports more information in decoded SSL certificates (such as notBefore or issuer), but it is only enabled when the hidden function _ssl._test_decode_cert is used. It would be nice to export all this information by default; I can't think of any inconvenience caused by it.

----------
components: Library (Lib)
messages: 117962
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Emit more information in decoded SSL certificates
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Mon Oct  4 23:33:02 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Oct 2010 21:33:02 +0000
Subject: [New-bugs-announce] [issue10023] test_lib2to3 leaks under 3.1
In-Reply-To: <1286227982.74.0.164487876735.issue10023@psf.upfronthosting.co.za>
Message-ID: <1286227982.74.0.164487876735.issue10023@psf.upfronthosting.co.za>


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

test_lib2to3
beginning 5 repetitions
12345
No handlers could be found for logger "RefactoringTool"
.....
test_lib2to3 leaked [32, 32] references, sum=64

----------
components: Library (Lib), Tests
messages: 117983
nosy: benjamin.peterson, pitrou
priority: normal
severity: normal
status: open
title: test_lib2to3 leaks under 3.1
type: resource usage
versions: Python 3.1

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

From report at bugs.python.org  Mon Oct  4 23:45:51 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Oct 2010 21:45:51 +0000
Subject: [New-bugs-announce] [issue10024] Outdated advice in C-API tutorial?
In-Reply-To: <1286228751.32.0.127029935422.issue10024@psf.upfronthosting.co.za>
Message-ID: <1286228751.32.0.127029935422.issue10024@psf.upfronthosting.co.za>


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

In http://docs.python.org/dev/extending/newtypes.html, you can read:

?To enable object creation, we have to provide a tp_new implementation. In this case, we can just use the default implementation provided by the API function PyType_GenericNew(). We?d like to just assign this to the tp_new slot, but we can?t, for portability sake, On some platforms or compilers, we can?t statically initialize a structure member with a function defined in another C module, so, instead, we?ll assign the tp_new slot in the module initialization function just before calling PyType_Ready()?

But the thing is, we ourselves (CPython) do exactly what is discouraged here, both in built-in types and dynamically loaded extensions.
So is this piece of advice still necessary?

----------
assignee: docs at python
components: Documentation
messages: 117984
nosy: docs at python, loewis, pitrou
priority: normal
severity: normal
status: open
title: Outdated advice in C-API tutorial?
type: resource usage
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Oct  5 01:33:06 2010
From: report at bugs.python.org (Tom Goddard)
Date: Mon, 04 Oct 2010 23:33:06 +0000
Subject: [New-bugs-announce] [issue10025] random.seed not initialized as
	advertised
In-Reply-To: <1286235186.65.0.07824350342.issue10025@psf.upfronthosting.co.za>
Message-ID: <1286235186.65.0.07824350342.issue10025@psf.upfronthosting.co.za>


New submission from Tom Goddard <goddard at cgl.ucsf.edu>:

In Python 2.7, random.seed() with a string argument is documented as being equivalent to random.seed() with argument equal to the hash of the string argument.  This is not the actual behavior.  Reading the _random C code reveals it in fact casts the signed hash value to unsigned long.  This also appears to be the situation with Python 2.5.2.  Rather than fix this in 2.7.1 it seems preferable to just correct the documentation in 2.7.1 to preserve backward compatibility.  Bug #7889 has already addressed this problem in Python 3.2 by eliminating the use of hash() for non-integer random.seed() arguments.  I encountered this problem while trying to produce identical sequences of random numbers on 64-bit architectures as on 32-bit architectures.

Here is a demonstration of the bug in Python 2.7, 32-bit.

random.seed('1pov')
random.uniform(0,1)
0.713827305919223

random.seed(hash('1pov'))
random.uniform(0,1)
0.40934677883730686

hash('1pov')
-747753952

random.seed(hash('1pov') + 2**32)  # unsigned long cast
random.uniform(0,1)
0.713827305919223

----------
components: Library (Lib)
messages: 117988
nosy: goddard
priority: normal
severity: normal
status: open
title: random.seed not initialized as advertised
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Oct  5 12:17:34 2010
From: report at bugs.python.org (=?utf-8?q?Vojt=C4=9Bch_Rylko?=)
Date: Tue, 05 Oct 2010 10:17:34 +0000
Subject: [New-bugs-announce] [issue10026] xml.dom.pulldom strange behavior
In-Reply-To: <1286273854.3.0.24375174829.issue10026@psf.upfronthosting.co.za>
Message-ID: <1286273854.3.0.24375174829.issue10026@psf.upfronthosting.co.za>


New submission from Vojt?ch Rylko <vojta.rylko at seznam.cz>:

Hi,

I have file with 10 000 records of same element item (always same):

$ head test.xml
<channel>
<item><section>Twitter</section></item>
<item><section>Twitter</section></item>
<item><section>Twitter</section></item>
<item><section>Twitter</section></item>
<item><section>Twitter</section></item>
<item><section>Twitter</section></item>
<item><section>Twitter</section></item>
<item><section>Twitter</section></item>
<item><section>Twitter</section></item>

And run simply program for printing content of element section:

$ python pulldom.py test.xml | head
Twitter
Twitter
Twitter
Twitter
Twitter
Twitter
Twitter
Twitter
Twitter
Twitter

Seems work fine:
$ python pulldom.py test.xml | wc -l
10000

But (in two cases of 10 000) gives me just "Twi" not Twitter:
$ python pulldom.py test.xml  | grep -v Twitter
Twi
Twi 


Why? This example program demonstrate big problems in my real application - xml.dom.pulldom is cutting content of some elements.

Thanks for any advice
Vojta Rylko

---------------------------
Python 2.5.4 (r254:67916, Feb 10 2009, 14:58:09)
[GCC 4.2.4] on linux2
---------------------------
pulldom.py:
---------------------------
file=open(sys.argv[1])
events = pulldom.parse(file)

for event, node in events:
        if event == pulldom.START_ELEMENT:
                if node.tagName == 'item':
                        events.expandNode(node)
                        print node.getElementsByTagName('section').item(0).firstChild.data

----------
components: XML
messages: 117999
nosy: vojta.rylko
priority: normal
severity: normal
status: open
title: xml.dom.pulldom strange behavior
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Tue Oct  5 16:35:27 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 05 Oct 2010 14:35:27 +0000
Subject: [New-bugs-announce] [issue10027] os.lstat/os.stat don't set
	st_nlink on Windows
In-Reply-To: <1286289327.29.0.159315245099.issue10027@psf.upfronthosting.co.za>
Message-ID: <1286289327.29.0.159315245099.issue10027@psf.upfronthosting.co.za>


New submission from Brian Curtin <curtin at acm.org>:

In msg117834 on #8879 it was noticed that os.lstat and os.stat don't set st_nlink on Windows, which is causing the patch on that issue to fail test_tarfile.

Attached is a stripped down version of the patch Hirokazu Yamamoto proposed on #8879, containing just the os.*stat changes. As stated in that message, the patch is a quick hack to get test_os and test_tarfile working, so it could use review.

----------
components: Extension Modules, Windows
files: st_nlink.diff
keywords: needs review, patch
messages: 118012
nosy: brian.curtin, ocean-city
priority: normal
severity: normal
stage: patch review
status: open
title: os.lstat/os.stat don't set st_nlink on Windows
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file19134/st_nlink.diff

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

From report at bugs.python.org  Tue Oct  5 20:25:39 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 05 Oct 2010 18:25:39 +0000
Subject: [New-bugs-announce] [issue10028] test_concurrent_futures fails on
	Windows Server 2003
In-Reply-To: <1286303139.16.0.442132720104.issue10028@psf.upfronthosting.co.za>
Message-ID: <1286303139.16.0.442132720104.issue10028@psf.upfronthosting.co.za>


New submission from Brian Curtin <curtin at acm.org>:

I haven't seen this on any of my machines except for Windows Server 2003 x64. For whatever reason, SetEvent is failing.


======================================================================
FAIL: test_zero_timeout (test.test_concurrent_futures.ProcessPoolAsCompletedTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\python-dev\py3k\lib\test\test_concurrent_futures.py", line 515, in test_zero_timeout
    call1.close()
  File "C:\python-dev\py3k\lib\test\test_concurrent_futures.py", line 109, in close
    self.set_can()
  File "C:\python-dev\py3k\lib\test\test_concurrent_futures.py", line 100, in set_can
    self._signal_event(self._can_finish)
  File "C:\python-dev\py3k\lib\test\test_concurrent_futures.py", line 83, in _signal_event
    assert r != 0
AssertionError

======================================================================
FAIL: test_zero_timeout (test.test_concurrent_futures.ThreadPoolAsCompletedTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\python-dev\py3k\lib\test\test_concurrent_futures.py", line 515, in test_zero_timeout
    call1.close()
  File "C:\python-dev\py3k\lib\test\test_concurrent_futures.py", line 109, in close
    self.set_can()
  File "C:\python-dev\py3k\lib\test\test_concurrent_futures.py", line 100, in set_can
    self._signal_event(self._can_finish)
  File "C:\python-dev\py3k\lib\test\test_concurrent_futures.py", line 83, in _signal_event
    assert r != 0
AssertionError

----------
components: Library (Lib), Tests, Windows
messages: 118024
nosy: bquinlan, brian.curtin
priority: normal
severity: normal
stage: needs patch
status: open
title: test_concurrent_futures fails on Windows Server 2003
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Tue Oct  5 20:26:46 2010
From: report at bugs.python.org (Max)
Date: Tue, 05 Oct 2010 18:26:46 +0000
Subject: [New-bugs-announce] [issue10029] bug in sample code in documentation
In-Reply-To: <1286303206.24.0.0440700795071.issue10029@psf.upfronthosting.co.za>
Message-ID: <1286303206.24.0.0440700795071.issue10029@psf.upfronthosting.co.za>


New submission from Max <maxmoroz at gmail.com>:

The sample code explaining zip function is incorrect at http://docs.python.org/py3k/library/functions.html?highlight=zip#zip:

def zip(*iterables):
    # zip('ABCD', 'xy') --> Ax By
    iterables = map(iter, iterables)
    while iterables:
        yield tuple(map(next, iterables))

See http://stackoverflow.com/questions/3865640/understanding-zip-function for discussion.

----------
assignee: docs at python
components: Documentation
messages: 118025
nosy: docs at python, max
priority: normal
severity: normal
status: open
title: bug in sample code in documentation
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Tue Oct  5 22:08:51 2010
From: report at bugs.python.org (Shashank)
Date: Tue, 05 Oct 2010 20:08:51 +0000
Subject: [New-bugs-announce] [issue10030] Patch for zip decryption speedup
In-Reply-To: <1286309331.81.0.797536492786.issue10030@psf.upfronthosting.co.za>
Message-ID: <1286309331.81.0.797536492786.issue10030@psf.upfronthosting.co.za>


New submission from Shashank <shashank.sunny.singh at gmail.com>:

As promised in this thread http://mail.python.org/pipermail/python-dev/2009-August/091450.html (a year ago!), attached is a patch that replaces simple zip decryption logic written in pure python with that in C.

As reported in the link above, this can result in speedups up to couple of orders of magnitude.

There doesn't seem to be any need to add any new tests as this patch doesn't change any public API

----------
components: Library (Lib)
files: zipdecrypt.patch
keywords: patch
messages: 118030
nosy: shashank
priority: normal
severity: normal
status: open
title: Patch for zip decryption speedup
type: performance
versions: Python 2.7
Added file: http://bugs.python.org/file19135/zipdecrypt.patch

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

From report at bugs.python.org  Tue Oct  5 22:18:11 2010
From: report at bugs.python.org (Darren Dale)
Date: Tue, 05 Oct 2010 20:18:11 +0000
Subject: [New-bugs-announce] [issue10031] Withdraw anti-recommendation of
	relative imports from	documentation
In-Reply-To: <1286309891.2.0.339569302596.issue10031@psf.upfronthosting.co.za>
Message-ID: <1286309891.2.0.339569302596.issue10031@psf.upfronthosting.co.za>


New submission from Darren Dale <dsdale24 at gmail.com>:

Old-style relative imports have been strongly discouraged in some sections of the python documentation. This was discussed on the python-dev mailing list. Executive summary: "The issue is implementing a PEP with nice support for relative imports, and then documenting that it should never be used." To which Guido responded:

---
"Isn't this mostly historical? Until the new relative-import syntax was
implemented there were various problems with relative imports. The
short-term solution was to recommend not using them. The long-term
solution was to implement an unambiguous syntax. Now it is time to
withdraw the anti-recommendation. Of course, without going overboard
-- I still find them an acquired taste; but they have their place."
---

It was suggested I open a ticket and suggest specific changes. They are listed below:

The faq at
http://docs.python.org/py3k/faq/programming.html#what-are-the-best-practices-for-using-import-in-a-module
could go from:

"Never use relative package imports. If you?re writing code that?s in the package.sub.m1 module and want to import package.sub.m2, do not just write from . import m2, even though it?s legal. Write from package.sub import m2 instead. See PEP 328 for details."

to:

"Although the python community generally prefers absolute imports, relative imports may be useful in certain circumstances. See PEP 328 for details."



The programming faq for python-2.7 at
http://docs.python.org/faq/programming.html#what-are-the-best-practices-for-using-import-in-a-module
could go from:

"Never use relative package imports. If you?re writing code that?s in the package.sub.m1 module and want to import package.sub.m2, do not just write import m2, even though it?s legal. Write from package.sub import m2 instead. Relative imports can lead to a module being initialized twice, leading to confusing bugs. See PEP 328 for details."

to:

"Although the python community generally prefers absolute imports, relative imports may be useful in certain circumstances. Support for relative imports has recently been improved, and the use of the old-style relative imports is strongly discouraged. See PEP 328 for details."

There is also this warning against relative imports in PEP 8, that could go from:

   - Relative imports for intra-package imports are highly discouraged.
     Always use the absolute package path for all imports.
     Even now that PEP 328 [7] is fully implemented in Python 2.5,
     its style of explicit relative imports is actively discouraged;
     absolute imports are more portable and usually more readable.

to:

   - While the python community generally prefers absolute imports,
     relative imports may be useful in certain circumstances. Now that
     PEP 328 [7] is fully implemented in Python 2.5 and later, the
     older style of implicit relative imports is strongly discouraged.

----------
assignee: docs at python
components: Documentation
messages: 118031
nosy: docs at python, dsdale24
priority: normal
severity: normal
status: open
title: Withdraw anti-recommendation of relative imports from documentation
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Oct  5 22:48:04 2010
From: report at bugs.python.org (Tjeerd Pinkert)
Date: Tue, 05 Oct 2010 20:48:04 +0000
Subject: [New-bugs-announce] [issue10032] os.setuid and os.setgid have
	unexpected influence on	serial module
In-Reply-To: <1286311684.44.0.770931367073.issue10032@psf.upfronthosting.co.za>
Message-ID: <1286311684.44.0.770931367073.issue10032@psf.upfronthosting.co.za>


New submission from Tjeerd Pinkert <t.j.pinkert at alumnus.utwente.nl>:

If I use os.setgid and os.setuid to switch to an other user in some daemon code, I cannot open the serial port anymore. If I run the same code directly from the user I can open the serial port. Since the serial module is using the open() call to open the serial device I wonder if the mistake is in the serial module or in the os module.

see also:
https://sourceforge.net/tracker/?func=detail&aid=3081643&group_id=46487&atid=446302

Sample code showing the behaviour using the daemon module from:
http://hathawaymix.org/Software/Sketches/daemon.py
(and no it's not this module, also my own crappy code did the same thing and gives the same erroneous behaviour)

------------------------
#!/usr/bin/python

"""Test daemon"""

import daemon
import logging
import time
import serial
import os

class HelloDaemon(daemon.Daemon):
    default_conf = 'test.conf'
    section = 'test'

    def setup_user(self):
        print os.getuid(), os.getgid()
        ser=serial.Serial(0)
        print ser.portstr
        ser.close()

    def run(self):
        while True:
            logging.info('The daemon says hello')
            time.sleep(1)

if __name__ == '__main__':
    HelloDaemon().main()
-----------------------------------------

now make the config file:
--------------------------------
[test]
uid = 
gid = 
pidfile = ./hellodaemon.pid
logfile = ./hellodaemon.log
loglevel = info
----------------------

when I run it as my own user it works fine, e.g.:
tjp at machine$ ./test.py
1000 1000
/dev/ttyS0

it nicely opens the port.

if I fill in tjp for uid and gid in the configfile and run it as:
tjp at machine$ sudo ./test.py
1000 1000
Traceback (most recent call last):
  File "./test.py", line 26, in <module>
    HelloDaemon().main()
  File "/home/tjp/tmp/pydaemon/daemon.py", line 121, in main
    self.start()
  File "/home/tjp/tmp/pydaemon/daemon.py", line 196, in start
    self.setup_user()
  File "./test.py", line 17, in setup_user
    ser=serial.Serial(0)
  File "/usr/lib/python2.6/dist-packages/serial/serialutil.py", line 166, in __init__
    self.open()
  File "/usr/lib/python2.6/dist-packages/serial/serialposix.py", line 175, in open
    raise SerialException("could not open port %s: %s" % (self._port, msg))
serial.serialutil.SerialException: could not open port 0: [Errno 13] Permission denied: '/dev/ttyS0'



I hope someone with more experience can either help me out, or confirm if this should be regarded a bug, and then in which module, os or serial

Yours, Tjeerd

----------
components: Extension Modules
messages: 118033
nosy: Tjeerd.Pinkert
priority: normal
severity: normal
status: open
title: os.setuid and os.setgid have unexpected influence on serial module
versions: Python 2.6

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

From report at bugs.python.org  Tue Oct  5 23:38:05 2010
From: report at bugs.python.org (danosaure)
Date: Tue, 05 Oct 2010 21:38:05 +0000
Subject: [New-bugs-announce] [issue10033] can't run unittest because of
	issubclass
In-Reply-To: <1286314685.42.0.495645038827.issue10033@psf.upfronthosting.co.za>
Message-ID: <1286314685.42.0.495645038827.issue10033@psf.upfronthosting.co.za>


New submission from danosaure <danosaure at gmail.com>:

I cannot run the simpliest test because issubclass() is always returning False in unittest.py

If i follow the documentation, the following should work.

    python -m unittest simple_test

It finds 0 tests because in unittest.py, in the following line:

            if (isinstance(obj, (type, types.ClassType)) and
                issubclass(obj, TestCase)):
                tests.append(self.loadTestsFromTestCase(obj))

and "issubclass()" always return False. The cause is "unittest" module is loaded twice. If I modify "unittest.py" to add "print", it pass in my test module and check my "class A(unittest.TestCase)".

Obviously, if I do the check interactively, it will return True.

Is there a problem with the "python -m unittest module" syntax? It seems to have two namespaces.

----------
components: Tests
files: simple_test.py
messages: 118035
nosy: Danosaure
priority: normal
severity: normal
status: open
title: can't run unittest because of issubclass
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file19136/simple_test.py

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

From report at bugs.python.org  Wed Oct  6 00:47:52 2010
From: report at bugs.python.org (Jason Baker)
Date: Tue, 05 Oct 2010 22:47:52 +0000
Subject: [New-bugs-announce] [issue10034] Readline doc issue
In-Reply-To: <1286318872.8.0.983307601226.issue10034@psf.upfronthosting.co.za>
Message-ID: <1286318872.8.0.983307601226.issue10034@psf.upfronthosting.co.za>


New submission from Jason Baker <amnorvend at gmail.com>:

There's an error in the documentation for readline here:  http://docs.python.org/library/readline.html#example

The first example doesn't import readline.

----------
assignee: docs at python
components: Documentation
messages: 118040
nosy: Jason.Baker, docs at python
priority: normal
severity: normal
status: open
title: Readline doc issue
versions: Python 2.7

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

From report at bugs.python.org  Wed Oct  6 06:28:02 2010
From: report at bugs.python.org (halfjuice)
Date: Wed, 06 Oct 2010 04:28:02 +0000
Subject: [New-bugs-announce] [issue10035] sgmllib fail to parse html
	containing <!- .... ->
In-Reply-To: <1286339282.85.0.467383816638.issue10035@psf.upfronthosting.co.za>
Message-ID: <1286339282.85.0.467383816638.issue10035@psf.upfronthosting.co.za>


New submission from halfjuice <halfjuice at gmail.com>:

When parsing html containing the following tag:
... <!- ie6 doesn't allow empty div. -> ...
SGMLParser will stop parse following content without any warning. When such tag is removed everything works fine.

When looking into sgmllib.py, statement below found:

    if rawdata.startswith("<!", i):
        # This is some sort of declaration; in "HTML as
        # deployed," this should only be the document type
        # declaration ("<!DOCTYPE html...>").

I think that's why something goes wrong here.

----------
components: Library (Lib)
messages: 118048
nosy: halfjuice
priority: normal
severity: normal
status: open
title: sgmllib fail to parse html containing <!- .... ->
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Wed Oct  6 07:51:25 2010
From: report at bugs.python.org (Jeffrey Finkelstein)
Date: Wed, 06 Oct 2010 05:51:25 +0000
Subject: [New-bugs-announce] [issue10036] compiler warnings for various
	modules on Ubuntu x86
In-Reply-To: <1286344285.28.0.174737248843.issue10036@psf.upfronthosting.co.za>
Message-ID: <1286344285.28.0.174737248843.issue10036@psf.upfronthosting.co.za>


New submission from Jeffrey Finkelstein <jeffrey.finkelstein at gmail.com>:

On Ubuntu 10.04.1, with
"uname -a" outputting "Linux hostname 2.6.32-25-generic #44-Ubuntu SMP Fri Sep 17 20:26:08 UTC 2010 i686 GNU/Linux"
"gcc --version" outputting "gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3"

On hg revision 7965 of the py3k branch, I get the following compile-time warnings:

/mnt/data/src/py3k/Modules/_posixsubprocess.c: In function ?child_exec?:
/mnt/data/src/py3k/Modules/_posixsubprocess.c:152: warning: ignoring return value of ?write?, declared with attribute warn_unused_result
/mnt/data/src/py3k/Modules/_posixsubprocess.c:158: warning: ignoring return value of ?write?, declared with attribute warn_unused_result
/mnt/data/src/py3k/Modules/_posixsubprocess.c:159: warning: ignoring return value of ?write?, declared with attribute warn_unused_result
/mnt/data/src/py3k/Modules/_posixsubprocess.c:163: warning: ignoring return value of ?write?, declared with attribute warn_unused_result
/mnt/data/src/py3k/Modules/_posixsubprocess.c:164: warning: ignoring return value of ?write?, declared with attribute warn_unused_result

/mnt/data/src/py3k/Modules/socketmodule.c: In function ?socket_gethostbyname_ex?:
/mnt/data/src/py3k/Modules/socketmodule.c:3282: warning: dereferencing pointer ?sa? does break strict-aliasing rules
/mnt/data/src/py3k/Modules/socketmodule.c:3280: note: initialized from here
/mnt/data/src/py3k/Modules/socketmodule.c: In function ?socket_gethostbyaddr?:
/mnt/data/src/py3k/Modules/socketmodule.c:3339: warning: dereferencing pointer ?sa? does break strict-aliasing rules
/mnt/data/src/py3k/Modules/socketmodule.c:3309: note: initialized from here

/mnt/data/src/py3k/Modules/_multiprocessing/multiprocessing.c: In function ?multiprocessing_sendfd?:
/mnt/data/src/py3k/Modules/_multiprocessing/multiprocessing.c:125: warning: dereferencing type-punned pointer will break strict-aliasing rules
/mnt/data/src/py3k/Modules/_multiprocessing/multiprocessing.c: In function ?multiprocessing_recvfd?:
/mnt/data/src/py3k/Modules/_multiprocessing/multiprocessing.c:168: warning: dereferencing type-punned pointer will break strict-aliasing rules

/mnt/data/src/py3k/Modules/_ctypes/libffi/src/closures.c: In function ?dlmmap_locked?:
/mnt/data/src/py3k/Modules/_ctypes/libffi/src/closures.c:416: warning: ignoring return value of ?ftruncate?, declared with attribute warn_unused_result
/mnt/data/src/py3k/Modules/_ctypes/libffi/src/closures.c:428: warning: ignoring return value of ?ftruncate?, declared with attribute warn_unused_result
/mnt/data/src/py3k/Modules/_ctypes/libffi/src/dlmalloc.c: In function ?mmap_resize?:
/mnt/data/src/py3k/Modules/_ctypes/libffi/src/dlmalloc.c:3193: warning: implicit declaration of function ?mremap?
/mnt/data/src/py3k/Modules/_ctypes/libffi/src/dlmalloc.c: In function ?sys_trim?:
/mnt/data/src/py3k/Modules/_ctypes/libffi/src/dlmalloc.c:3612: warning: comparison between pointer and integer

----------
components: Build
messages: 118051
nosy: jfinkels
priority: normal
severity: normal
status: open
title: compiler warnings for various modules on Ubuntu x86
type: compile error
versions: Python 3.2

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

From report at bugs.python.org  Wed Oct  6 13:25:58 2010
From: report at bugs.python.org (Ask Solem)
Date: Wed, 06 Oct 2010 11:25:58 +0000
Subject: [New-bugs-announce] [issue10037] multiprocessing.pool processes
	started by worker handler	stops working
In-Reply-To: <1286364358.68.0.746245038707.issue10037@psf.upfronthosting.co.za>
Message-ID: <1286364358.68.0.746245038707.issue10037@psf.upfronthosting.co.za>


New submission from Ask Solem <askh at opera.com>:

While working on an "autoscaling" (yes, people call it that...) feature for Celery, I noticed that the processes created by the _handle_workers thread doesn't always work.  I have reproduced this in general, by just using the maxtasksperchild feature and letting the workers terminate themselves so this seems to have always been an issue (just not easy to reproduce unless workers are created with some frequency)

I'm not quite sure of the reason yet, but I finally managed to track it down to the workers being stuck while receiving from the queue.

The patch attached seems to resolve the issue by polling the queue before trying to receive.

I know this is short, I may have some more data later.

----------
components: Library (Lib)
files: multiprocessing-worker-poll.patch
keywords: needs review, patch
messages: 118062
nosy: asksol
priority: critical
severity: normal
stage: patch review
status: open
title: multiprocessing.pool processes started by worker handler stops working
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file19139/multiprocessing-worker-poll.patch

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

From report at bugs.python.org  Wed Oct  6 17:36:58 2010
From: report at bugs.python.org (Nik Tautenhahn)
Date: Wed, 06 Oct 2010 15:36:58 +0000
Subject: [New-bugs-announce] [issue10038] Returntype of json.loads() on
	strings
In-Reply-To: <1286379418.7.0.631387512608.issue10038@psf.upfronthosting.co.za>
Message-ID: <1286379418.7.0.631387512608.issue10038@psf.upfronthosting.co.za>


New submission from Nik Tautenhahn <nik at livinglogic.de>:

Hi,

before 2.7, an
import json
json.loads('"abc"')

yielded u"abc".

in 2.7 I get
"abc" (a byte string).

I would have expected an entry in "news" or "What's new in 2.7" why this change happened. In addition, all examples at http://docs.python.org/library/json are wrong for Python 2.7  if json.loads is involved.

Any insight on this?

best regards,
Nik

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 118069
nosy: docs at python, llnik
priority: normal
severity: normal
status: open
title: Returntype of json.loads() on strings
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Oct  7 03:25:33 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Oct 2010 01:25:33 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue10039=5D_python_=C3=A9=2Epy?=
 =?utf-8?q?_fails_with_UnicodeEncodeError_if_PYTHONFSENCODING_is_used?=
In-Reply-To: <1286414733.34.0.0267403088134.issue10039@psf.upfronthosting.co.za>
Message-ID: <1286414733.34.0.0267403088134.issue10039@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

If a program name contains a non-ascii character in its name and/or full path and PYTHONFSENCODING is set to an encoding different than the locale encoding, Python fails to open the program.

Example in the utf-8 locale:

$ PYTHONFSENCODING=ascii ./python ?.py
UnicodeEncodeError: 'ascii' codec can't encode character '\xe9' in position 0: ordinal not in range(128)

This issue is similar to #9992 and #10014.

Solutions: remove PYTHONFSENCODING environment variable or redecode the filename from the locale encoding to the filesystem encoding.

Attached patch implements the latter.

--

We may also redecode Py_GetProgramName().

----------
components: Interpreter Core, Unicode
files: redecode_filename.patch
keywords: patch
messages: 118089
nosy: haypo
priority: normal
severity: normal
status: open
title: python ?.py fails with UnicodeEncodeError if PYTHONFSENCODING is used
versions: Python 3.2
Added file: http://bugs.python.org/file19143/redecode_filename.patch

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

From report at bugs.python.org  Thu Oct  7 03:57:13 2010
From: report at bugs.python.org (Robert Rohde)
Date: Thu, 07 Oct 2010 01:57:13 +0000
Subject: [New-bugs-announce] [issue10040] GZipFile failure on large files
In-Reply-To: <1286416633.51.0.196300487006.issue10040@psf.upfronthosting.co.za>
Message-ID: <1286416633.51.0.196300487006.issue10040@psf.upfronthosting.co.za>


New submission from Robert Rohde <rohde at robertrohde.com>:

I attempted to use GZipFile to process a 1.93 GB file that expands to 18.8 GB.

This consistently produces the same corrupted output file that has approximately, but not exactly, the right output file size.

I bypassed GZipFile by calling the 7-Zip executable to open the compressed file.  This works correctly and consistently.

I haven't tried to figure out how GZipFile works, but I assume that this failure is probably related to the very large size of the files I am working with.  I've used GZipFile before on much smaller files with no apparent problems.  I have no idea what precisely goes wrong, or how to fix it, but I felt it was important to note that GZipFile isn't working for at least some very large files.

----------
components: Library (Lib)
messages: 118091
nosy: Robert.Rohde
priority: normal
severity: normal
status: open
title: GZipFile failure on large files
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Oct  7 10:12:59 2010
From: report at bugs.python.org (kai zhu)
Date: Thu, 07 Oct 2010 08:12:59 +0000
Subject: [New-bugs-announce] [issue10041] socket.makefile(mode =
	'r').readline() silently removes	carriage return
In-Reply-To: <1286439179.94.0.684121251448.issue10041@psf.upfronthosting.co.za>
Message-ID: <1286439179.94.0.684121251448.issue10041@psf.upfronthosting.co.za>


New submission from kai zhu <kaizhu256 at gmail.com>:

i'm working on an independent py2to3 utility which directly imports py2x modules, by reverse compiling ast trees (code.google.com/p/asciiporn/source/browse/stable.py)

while forward porting the python2x redis client, this issue came up.
i kno its bad to use strings in sockets, but it seems webapps use it exploiting the fact utf8 is becoming a defacto web 'binary' standard



$ python3.1 echo.py
connected <socket.socket object, fd=4, family=2, type=1, proto=0> ('127.0.0.1', 41115)

$ python3.1 client.py 
b'hello\r\n' recv()
b'hello\r\n' makefile(mode = "rb")
'hello\n' makefile(mode = "r")


## echo.py - echo server program
import socket
serv = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
try:
  serv.bind(('localhost', 12345))
  serv.listen(1)
  while True:
    conn, addr = serv.accept()
    print( 'connected', conn, addr )
    while True:
      data = conn.recv(4096)
      if not data:
        conn.close()
        break
      conn.send(data)
finally:
  serv.close()



## client.py - client program
data = b'hello\r\n'
import socket
clie = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
try:
  clie.connect(('localhost', 12345))

  clie.send(data)
  data = clie.recv(4096)
  print(repr(data), 'recv()')

  clie.send(data)
  file = clie.makefile('rb')
  data = file.readline()
  print(repr(data), 'makefile(mode = "rb")')

  clie.send(data)
  file = clie.makefile('r')
  data = file.readline()
  print(repr(data), 'makefile(mode = "r")') ## '\r' is silently dropped
finally:
  clie.close()

----------
components: 2to3 (2.x to 3.0 conversion tool), IO, Library (Lib), Unicode
messages: 118095
nosy: kaizhu
priority: normal
severity: normal
status: open
title: socket.makefile(mode = 'r').readline() silently removes carriage return
type: behavior
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Oct  7 10:26:52 2010
From: report at bugs.python.org (Francesco Ricciardi)
Date: Thu, 07 Oct 2010 08:26:52 +0000
Subject: [New-bugs-announce] [issue10042] total_ordering stack overflow
In-Reply-To: <1286440012.74.0.624864175042.issue10042@psf.upfronthosting.co.za>
Message-ID: <1286440012.74.0.624864175042.issue10042@psf.upfronthosting.co.za>


New submission from Francesco Ricciardi <francesco.ricciardi at hp.com>:

Tested with version 3.2a2. Not tested on version 2.7.

The current implementation of functools.total_ordering generates a stack overflow because it implements the new comparison functions with inline operator, which the Python interpreter might reverse if "other" does not implement them. Reversing the comparison makes the interpreter call again the lambda function for comparison generating a stack overflow.

Run the attached test file for an example of this behavior.

----------
components: Library (Lib)
files: test_total_ordering.py
messages: 118096
nosy: francescor
priority: normal
severity: normal
status: open
title: total_ordering stack overflow
type: crash
versions: Python 3.2
Added file: http://bugs.python.org/file19144/test_total_ordering.py

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

From report at bugs.python.org  Thu Oct  7 12:13:50 2010
From: report at bugs.python.org (Steven Samuel Cole)
Date: Thu, 07 Oct 2010 10:13:50 +0000
Subject: [New-bugs-announce] [issue10043] UnboundLocalError with local
	variable set by setattr, caused by code run later
In-Reply-To: <1286446430.16.0.85312530766.issue10043@psf.upfronthosting.co.za>
Message-ID: <1286446430.16.0.85312530766.issue10043@psf.upfronthosting.co.za>


New submission from Steven Samuel Cole <steven.samuel.cole at gmail.com>:

inside a function, I create a local variable by using setattr with the current module as object, as in
  setattr(modules[__name__], 'name', 'value')

if I _later_ in the code set name to None, the attribute becomes unavailable even for code that is executed _before_ setting name to None.

please also see sample file.

----------
components: Interpreter Core
files: show_weird_behavior.py
messages: 118099
nosy: ssc
priority: normal
severity: normal
status: open
title: UnboundLocalError with local variable set by setattr, caused by code run later
type: behavior
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file19146/show_weird_behavior.py

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

From report at bugs.python.org  Thu Oct  7 13:56:30 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 07 Oct 2010 11:56:30 +0000
Subject: [New-bugs-announce] [issue10044] small int optimization
In-Reply-To: <1286452590.11.0.255060275257.issue10044@psf.upfronthosting.co.za>
Message-ID: <1286452590.11.0.255060275257.issue10044@psf.upfronthosting.co.za>


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

This is an experimental patch to optimize some operations on small ints.
pystone is 5-10% faster, pybench 2-3% faster, and here are some relevant benchmarks from unladen swallow:

### nbody ###
Min: 0.345136 -> 0.317502: 1.09x faster
Avg: 0.346827 -> 0.319561: 1.09x faster
Significant (t=79.50)
Stddev: 0.00140 -> 0.00198: 1.4084x larger

### nqueens ###
Min: 0.339744 -> 0.313506: 1.08x faster
Avg: 0.342630 -> 0.315380: 1.09x faster
Significant (t=73.41)
Stddev: 0.00218 -> 0.00146: 1.4931x smaller


If the principle gets accepted, we could experiment with further optimizations such as dedicated opcodes for addition-with-int-constant, subscripting-with-int-constant, etc.

----------
files: smallints.patch
keywords: patch
messages: 118103
nosy: Aahz, aahz, mark.dickinson, pitrou, rhettinger, stutzbach
priority: normal
severity: normal
status: open
title: small int optimization
type: performance
versions: Python 3.2
Added file: http://bugs.python.org/file19148/smallints.patch

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

From report at bugs.python.org  Thu Oct  7 19:37:49 2010
From: report at bugs.python.org (Patrick Strawderman)
Date: Thu, 07 Oct 2010 17:37:49 +0000
Subject: [New-bugs-announce] [issue10045] poor cStringIO.StringO seek
	performance
In-Reply-To: <1286473069.73.0.766959244837.issue10045@psf.upfronthosting.co.za>
Message-ID: <1286473069.73.0.766959244837.issue10045@psf.upfronthosting.co.za>


New submission from Patrick Strawderman <patrick at zope.com>:

cStringIO.StringO's seek method has O(n) characteristics in certain,
albeit pathological, cases, while the pure Python implementation and
cStringIO.StringI's seek methods both execute in constant time in all cases.

When the file offset is set n bytes beyond the end of actual data,
the gap is filled in with n bytes in cStringIO.StringO's seek method.

however, POSIX states that reads of data in the gap will return null bytes
only if a subsequent write has taken place, so filling in the gap is not
required at the time of the seek.

This patch for 2.7 corrects the behavior by unifying StringO and StringI's
seek methods, and moving the writing of null bytes to StringO's write
method.  There may be a more elegant way to write this, I don't know.
I believe this issue affects Python 3 as well, though I have yet to
test it.

NOTE: Perhaps this seems like an extreme edge case not worthy of a fix, but
this actually caused problems for us when parsing images with malformed
EXIF data; a web request for uploading such a photo was taking on the order
of 15 minutes.  When we stopped using cStringIO.StringO, it took seconds.

----------
files: cStringIO.diff
keywords: patch
messages: 118123
nosy: boogenhagn
priority: normal
severity: normal
status: open
title: poor cStringIO.StringO seek performance
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file19150/cStringIO.diff

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

From report at bugs.python.org  Thu Oct  7 23:34:55 2010
From: report at bugs.python.org (Jason Baker)
Date: Thu, 07 Oct 2010 21:34:55 +0000
Subject: [New-bugs-announce] [issue10046] Correction to atexit documentation
In-Reply-To: <1286487295.44.0.431847380909.issue10046@psf.upfronthosting.co.za>
Message-ID: <1286487295.44.0.431847380909.issue10046@psf.upfronthosting.co.za>


New submission from Jason Baker <amnorvend at gmail.com>:

There's an issue with the documentation on the atexit module[1].  It states:

"Note: the functions registered via this module are not called when the program is killed by a signal, when a Python fatal internal error is detected, or when os._exit() is called."

This isn't necessarily true.  For instance, if I start the following script:

from atexit import register
from time import sleep

@register
def end():
    print 'atexit'

while True:
    sleep(1)

...and then do a "kill -SIGINT <pid>", the atexit function gets called.  It would be helpful to have a more detailed description of the rules on how this works.

[1] http://docs.python.org/library/atexit.html#module-atexit

----------
assignee: docs at python
components: Documentation
messages: 118141
nosy: Jason.Baker, docs at python
priority: normal
severity: normal
status: open
title: Correction to atexit documentation
versions: Python 2.7

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

From report at bugs.python.org  Fri Oct  8 00:51:28 2010
From: report at bugs.python.org (Thomas Klausner)
Date: Thu, 07 Oct 2010 22:51:28 +0000
Subject: [New-bugs-announce] [issue10047] python-2.6.6 coredump running
	newspipe
In-Reply-To: <1286491888.31.0.583289344322.issue10047@psf.upfronthosting.co.za>
Message-ID: <1286491888.31.0.583289344322.issue10047@psf.upfronthosting.co.za>


New submission from Thomas Klausner <tk at giga.or.at>:

I'm running newspipe-1.1.9, an RSS reader
(http://newspipe.sourceforge.net/), on NetBSD-5.99.11/amd64 using
Python-2.6.6.

Sometimes, it core dumps with particular feeds in the configuration (I
guess depending on the feed, because when I comment out the offending
feed in the opml file, it runs through to completion).

The backtrace looks like this:
Core was generated by `python'.
Program terminated with signal 10, Bus error.
#0  0x00007f7ffdc35a21 in PyOS_snprintf (str=0x7f7ff5dfe3d8 "@", size=120, format=0x1 <Address 0x1 out of bounds>) at Python/mysnprintf.c:43
43      {
(gdb) bt
#0  0x00007f7ffdc35a21 in PyOS_snprintf (str=0x7f7ff5dfe3d8 "@", size=120, format=0x1 <Address 0x1 out of bounds>) at Python/mysnprintf.c:43
#1  0x00007f7ffdc471a6 in PyOS_ascii_formatd (buffer=0x7f7ff5dfe3d8 "@", buf_size=120, format=0x7f7ff5dfe388 "%.2f", d=0.15256118774414062) at Python/pystrtod.c:455
#2  0x00007f7ffdbaa7fa in formatfloat (buf=0x7f7ff5dfe3d8 "@", buflen=120, flags=16, prec=2, type=102, v=0x7f7ffcc6d510) at Objects/stringobject.c:4378
#3  0x00007f7ffdbabd32 in PyString_Format (format=0x7f7ffc8144e0, args=0x7f7ffcc6d510) at Objects/stringobject.c:4943
#4  0x00007f7ffdbaa3b0 in string_mod (v=0x7f7ffc8144e0, w=0x7f7ffcc6d510) at Objects/stringobject.c:4116
#5  0x00007f7ffdb459db in binary_op1 (v=0x7f7ffc8144e0, w=0x7f7ffcc6d510, op_slot=32) at Objects/abstract.c:917
#6  0x00007f7ffdb45c81 in binary_op (v=0x7f7ffc8144e0, w=0x7f7ffcc6d510, op_slot=32, op_name=0x7f7ffdc6c089 "%") at Objects/abstract.c:969
#7  0x00007f7ffdb467ad in PyNumber_Remainder (v=0x7f7ffc8144e0, w=0x7f7ffcc6d510) at Objects/abstract.c:1221
#8  0x00007f7ffdc08a03 in PyEval_EvalFrameEx (f=0x7f7fefa1dab0, throwflag=0) at Python/ceval.c:1180
#9  0x00007f7ffdc1175f in fast_function (func=0x7f7ff8a9bed8, pp_stack=0x7f7ff5dfeae8, n=1, na=1, nk=0) at Python/ceval.c:3836
#10 0x00007f7ffdc11565 in call_function (pp_stack=0x7f7ff5dfeae8, oparg=1) at Python/ceval.c:3771
#11 0x00007f7ffdc0d81f in PyEval_EvalFrameEx (f=0x7f7fee920420, throwflag=0) at Python/ceval.c:2412
#12 0x00007f7ffdc0f715 in PyEval_EvalCodeEx (co=0x7f7ffcc247b0, globals=0x7f7ffd1c5880, locals=0x0, args=0x7f7ff5b0aac8, argcount=8, kws=0x7f7ff5b0ab08, kwcount=0, defs=0x7f7ff8d3c4e8,
    defcount=5, closure=0x0) at Python/ceval.c:3000
#13 0x00007f7ffdc1184a in fast_function (func=0x7f7ff8a9cc80, pp_stack=0x7f7ff5dfeff8, n=8, na=8, nk=0) at Python/ceval.c:3846
#14 0x00007f7ffdc11565 in call_function (pp_stack=0x7f7ff5dfeff8, oparg=7) at Python/ceval.c:3771
#15 0x00007f7ffdc0d81f in PyEval_EvalFrameEx (f=0x7f7ff5b0a820, throwflag=0) at Python/ceval.c:2412
#16 0x00007f7ffdc1175f in fast_function (func=0x7f7ff8a9e140, pp_stack=0x7f7ff5dff358, n=1, na=1, nk=0) at Python/ceval.c:3836
#17 0x00007f7ffdc11565 in call_function (pp_stack=0x7f7ff5dff358, oparg=0) at Python/ceval.c:3771
#18 0x00007f7ffdc0d81f in PyEval_EvalFrameEx (f=0x7f7ff5b0a420, throwflag=0) at Python/ceval.c:2412
#19 0x00007f7ffdc1175f in fast_function (func=0x7f7ffca1db90, pp_stack=0x7f7ff5dff6b8, n=1, na=1, nk=0) at Python/ceval.c:3836
#20 0x00007f7ffdc11565 in call_function (pp_stack=0x7f7ff5dff6b8, oparg=0) at Python/ceval.c:3771
#21 0x00007f7ffdc0d81f in PyEval_EvalFrameEx (f=0x7f7ff5b03190, throwflag=0) at Python/ceval.c:2412
#22 0x00007f7ffdc0f715 in PyEval_EvalCodeEx (co=0x7f7ffca0d4e0, globals=0x7f7ffca473a0, locals=0x0, args=0x7f7ff04d3e68, argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0)
    at Python/ceval.c:3000
#23 0x00007f7ffdb7a612 in function_call (func=0x7f7ffca1daa0, arg=0x7f7ff04d3e50, kw=0x0) at Objects/funcobject.c:524
#24 0x00007f7ffdb495e8 in PyObject_Call (func=0x7f7ffca1daa0, arg=0x7f7ff04d3e50, kw=0x0) at Objects/abstract.c:2492
#25 0x00007f7ffdb5eca0 in instancemethod_call (func=0x7f7ffca1daa0, arg=0x7f7ff04d3e50, kw=0x0) at Objects/classobject.c:2579
#26 0x00007f7ffdb495e8 in PyObject_Call (func=0x7f7ff8ac2a00, arg=0x7f7ffd112050, kw=0x0) at Objects/abstract.c:2492
#27 0x00007f7ffdc10cd3 in PyEval_CallObjectWithKeywords (func=0x7f7ff8ac2a00, arg=0x7f7ffd112050, kw=0x0) at Python/ceval.c:3619
#28 0x00007f7ffdc4e69f in t_bootstrap (boot_raw=0x7f7ffd1b4590) at ./Modules/threadmodule.c:428
#29 0x00007f7ffd90ba32 in pthread_setcancelstate () from /usr/lib/libpthread.so.1
#30 0x00007f7ffd26e9b0 in ___lwp_park50 () from /usr/lib/libc.so.12
#31 0x0000000000000000 in ?? ()
(gdb) fr 1
#1  0x00007f7ffdc471a6 in PyOS_ascii_formatd (buffer=0x7f7ff5dfe3d8 "@", buf_size=120, format=0x7f7ff5dfe388 "%.2f", d=0.15256118774414062) at Python/pystrtod.c:455
455         PyOS_snprintf(buffer, buf_size, format, d);
(gdb) l
450             format = tmp_format;
451         }
452
453
454         /* Have PyOS_snprintf do the hard work */
455         PyOS_snprintf(buffer, buf_size, format, d);
456
457         /* Do various fixups on the return string */
458
459         /* Get the current locale, and find the decimal point string.
(gdb) p format
$1 = 0x7f7ff5dfe388 "%.2f"
(gdb) fr 0
#0  0x00007f7ffdc35a21 in PyOS_snprintf (str=0x7f7ff5dfe3d8 "@", size=120, format=0x1 <Address 0x1 out of bounds>) at Python/mysnprintf.c:43
43      {
(gdb) l
38         CAUTION:  Unlike C99, str != NULL and size > 0 are required.
39      */
40
41      int
42      PyOS_snprintf(char *str, size_t size, const  char  *format, ...)
43      {
44          int rc;
45          va_list va;
46
47          va_start(va, format);
(gdb)

It seems that the format argument is corrupted while calling PyOS_snprintf.

Any ideas what could cause this or how to fix this?

----------
components: Interpreter Core
messages: 118150
nosy: wiz
priority: normal
severity: normal
status: open
title: python-2.6.6 coredump running newspipe
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Fri Oct  8 13:06:30 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 08 Oct 2010 11:06:30 +0000
Subject: [New-bugs-announce] [issue10048] urllib.request documentation
	confusing
In-Reply-To: <1286535990.46.0.129844190964.issue10048@psf.upfronthosting.co.za>
Message-ID: <1286535990.46.0.129844190964.issue10048@psf.upfronthosting.co.za>


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

The urllib.request documentation intermingles old 2.x urllib (FancyURLopener, etc.) with urllib2-inherited (*Handler, build_opener, etc.) primitives without making any distinction. This makes it rather confusing for the reader to figure out which ones to use.

Ideally, the use of the old primitives should also be discouraged.

----------
assignee: docs at python
components: Documentation
messages: 118179
nosy: docs at python, orsenthil, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: urllib.request documentation confusing
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Oct  8 13:13:46 2010
From: report at bugs.python.org (=?utf-8?b?SHJ2b2plIE5pa8WhacSH?=)
Date: Fri, 08 Oct 2010 11:13:46 +0000
Subject: [New-bugs-announce] [issue10049] Add the null context manager to
	contextlib
In-Reply-To: <1286536426.03.0.247784217987.issue10049@psf.upfronthosting.co.za>
Message-ID: <1286536426.03.0.247784217987.issue10049@psf.upfronthosting.co.za>


New submission from Hrvoje Nik?i? <hniksic at gmail.com>:

I find that I frequently need the "null" (no-op) context manager.  For example, in code such as:

with transaction or contextlib.null():
    ...

Since there is no easy expression to create a null context manager, we must resort to workarounds, such as:

if transaction:
    with transaction:
        ... code ...
else:
    ... duplicated code ...

(with the usual options of moving the duplicated code to a function?but still.)

Or by creating ad-hoc null context managers with the help of contextlib.contextmanager:

if transaction is None:
    transaction = contextlib.contextmanager(lambda: iter([None])()
with transaction:
    ...

Adding a "null" context manager would be both practical and elegant.  I have attached a patch for contextlib.py

----------
files: fl
messages: 118181
nosy: hniksic
priority: normal
severity: normal
status: open
title: Add the null context manager to contextlib
Added file: http://bugs.python.org/file19158/fl

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

From report at bugs.python.org  Fri Oct  8 13:14:31 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 08 Oct 2010 11:14:31 +0000
Subject: [New-bugs-announce] [issue10050] urllib.request still has old 2.x
	urllib primitives
In-Reply-To: <1286536471.26.0.454336144311.issue10050@psf.upfronthosting.co.za>
Message-ID: <1286536471.26.0.454336144311.issue10050@psf.upfronthosting.co.za>


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

3.x urllib.request still has a lot of stuff inherited from 2.x urllib: URLopener, FancyURLopener, the urlretrieve implementation (perhaps others?).

Ideally, urlretrieve should be reimplemented using urlopen or build_opener, and the other stuff deprecated.

----------
assignee: orsenthil
components: Library (Lib)
messages: 118182
nosy: jhylton, orsenthil, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: urllib.request still has old 2.x urllib primitives
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Oct  8 13:49:39 2010
From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBHw7Nybnk=?=)
Date: Fri, 08 Oct 2010 11:49:39 +0000
Subject: [New-bugs-announce] [issue10051] distutils fail to install
	unicode-encoded files with	POSIX locale
In-Reply-To: <1286538579.43.0.363477643478.issue10051@psf.upfronthosting.co.za>
Message-ID: <1286538579.43.0.363477643478.issue10051@psf.upfronthosting.co.za>


New submission from Micha? G?rny <mgorny at gentoo.org>:

I was reported an issue where the user was unable to install my package [1] using python3.1. I was able to guess the issue comes from locale being set to POSIX and reproduce it.

It seems that the reasons are utf8-encoded characters in the installed script file. All the project files carry encoding declaration as per PEP-0263. They install fine with python2 but fail both with 3.1 and 3.2.

I think the build system should be locale-agnostic, and work correctly even if LC_ALL=C. If it's necessary to use text mode for scripts, I think a similar encoding guessing method should be used as in python itself.

I'm attaching a complete build log (for multiple versions of Python). Below I'm repasting the backtrace:

Traceback (most recent call last):
  File "setup.py", line 35, in <module>
    'Topic :: System :: Installation/Setup'
  File "/usr/lib64/python3.1/distutils/core.py", line 149, in setup
    dist.run_commands()
  File "/usr/lib64/python3.1/distutils/dist.py", line 919, in run_commands
    self.run_command(cmd)
  File "/usr/lib64/python3.1/distutils/dist.py", line 938, in run_command
    cmd_obj.run()
  File "/usr/lib64/python3.1/distutils/command/build.py", line 128, in run
    self.run_command(cmd_name)
  File "/usr/lib64/python3.1/distutils/cmd.py", line 315, in run_command
    self.distribution.run_command(command)
  File "/usr/lib64/python3.1/distutils/dist.py", line 938, in run_command
    cmd_obj.run()
  File "/usr/lib64/python3.1/distutils/command/build_scripts.py", line 51, in run
    self.copy_scripts()
  File "/usr/lib64/python3.1/distutils/command/build_scripts.py", line 83, in copy_scripts
    first_line = f.readline()
  File "/usr/lib64/python3.1/encodings/ascii.py", line 26, in decode
    return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc5 in position 127: ordinal not in range(128)

[1] http://github.com/mgorny/smart-live-rebuild

----------
assignee: tarek
components: Distutils
files: build.log
messages: 118188
nosy: eric.araujo, mgorny, tarek
priority: normal
severity: normal
status: open
title: distutils fail to install unicode-encoded files with POSIX locale
type: behavior
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file19159/build.log

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

From report at bugs.python.org  Sat Oct  9 09:26:45 2010
From: report at bugs.python.org (Akira Kitada)
Date: Sat, 09 Oct 2010 07:26:45 +0000
Subject: [New-bugs-announce] [issue10052] Python/dtoa.c:158: #error "Failed
	to find an exact-width	32-bit integer type" (FreeBSD 4.11 +
	gcc 2.95.4)
In-Reply-To: <1286609205.46.0.0704666326351.issue10052@psf.upfronthosting.co.za>
Message-ID: <1286609205.46.0.0704666326351.issue10052@psf.upfronthosting.co.za>


New submission from Akira Kitada <akitada at gmail.com>:

Building Python 2.7 fails on FreeBSD 4.11 with gcc 2.95.4 as below:

"""
gcc -pthread -c -fno-strict-aliasing -g -O2 -DNDEBUG -g  -O3 -Wall -Wstrict-prototypes  -I. -IInclude -I./Include   -DPy_BUILD_CORE -o Python/dtoa.o Python/dtoa.c
Python/dtoa.c:158: #error "Failed to find an exact-width 32-bit integer type"
gmake: *** [Python/dtoa.o] Error 1
"""

This error occurs when HAVE_UINT32_T or HAVE_INT32_T are not defined.
Those constants are defined in Include/pyport.h as:

"""
#if (defined UINT32_MAX || defined uint32_t)
#ifndef PY_UINT32_T
#define HAVE_UINT32_T 1
#define PY_UINT32_T uint32_t
#endif
#endif
"""

"""
#if (defined INT32_MAX || defined int32_t)
#ifndef PY_INT32_T
#define HAVE_INT32_T 1
#define PY_INT32_T int32_t
#endif
#endif
"""

This doesn't work for FreeBSD 4, where exact-width integer types are defined #typedef and does not provide *_MAX for them.

I don't think this is the right fix but adding following macro to pyport.h fixed the problem.

"""
#define UINT32_MAX 0xffffffff
#define INT32_MAX 0x7fffffff
"""

----------
components: Build
messages: 118246
nosy: akitada
priority: normal
severity: normal
status: open
title: Python/dtoa.c:158: #error "Failed to find an exact-width 32-bit integer type" (FreeBSD 4.11 + gcc 2.95.4)
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Sat Oct  9 10:08:19 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 09 Oct 2010 08:08:19 +0000
Subject: [New-bugs-announce] [issue10053] Probably fd should not be closed
	when FileIO#__init__	failed
In-Reply-To: <1286611699.72.0.643946384367.issue10053@psf.upfronthosting.co.za>
Message-ID: <1286611699.72.0.643946384367.issue10053@psf.upfronthosting.co.za>


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

I suppose when _io.FileIO(fd) failed, passed fd
should not be closed. Otherwise, we cannot write the
code like this.

     fd = os.open(path, os.O_RDONLY)
     try:
         buf = io.open(fd, "wb")
     except:
         os.close(fd)
         raise

I found some corner case (rarely happens) in FileIO#__init__
Is this patch correct? Thank you.

----------
components: IO
files: py3k_ensure_fd_not_closed_after_fileio_init_failed.patch
keywords: patch
messages: 118249
nosy: ocean-city
priority: normal
severity: normal
stage: patch review
status: open
title: Probably fd should not be closed when FileIO#__init__ failed
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file19171/py3k_ensure_fd_not_closed_after_fileio_init_failed.patch

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

From report at bugs.python.org  Sat Oct  9 10:10:53 2010
From: report at bugs.python.org (Akira Kitada)
Date: Sat, 09 Oct 2010 08:10:53 +0000
Subject: [New-bugs-announce] [issue10054] select extension does not build on
	platforms where	uintptr_t is provided in inttypes.h
In-Reply-To: <1286611853.89.0.308304033443.issue10054@psf.upfronthosting.co.za>
Message-ID: <1286611853.89.0.308304033443.issue10054@psf.upfronthosting.co.za>


New submission from Akira Kitada <akitada at gmail.com>:

Some platforms have uintptr_t in inttypes.h but Python bulid system
assumes it's defined in stdint.h and it causes build failure:

"""
building 'select' extension
gcc -pthread -fPIC -fno-strict-aliasing -g -O2 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -I/usr/local/include -I/usr/home/akitada/
src/release27-maint/Include -I/usr/home/akitada/src/release27-maint -c /usr/home/akitada/src/release27-maint/Modules/selectmodule.c -o build/temp.freebsd-4.
11-RELEASE-i386-2.7/usr/home/akitada/src/release27-maint/Modules/selectmodule.o
/usr/home/akitada/src/release27-maint/Modules/selectmodule.c:1189: #error uintptr_t does not match void *!
"""

----------
components: Build
messages: 118251
nosy: akitada
priority: normal
severity: normal
status: open
title: select extension does not build on platforms where uintptr_t is provided in inttypes.h
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Sat Oct  9 10:32:04 2010
From: report at bugs.python.org (Akira Kitada)
Date: Sat, 09 Oct 2010 08:32:04 +0000
Subject: [New-bugs-announce] [issue10055] C99 code in _json.c
In-Reply-To: <1286613124.83.0.838959560604.issue10055@psf.upfronthosting.co.za>
Message-ID: <1286613124.83.0.838959560604.issue10055@psf.upfronthosting.co.za>


New submission from Akira Kitada <akitada at gmail.com>:

I found some C99 code in _json.c.
Attached patch makes it C89.

The C99 part is only used for ucs4 Python. That's probably the reason
it's overlooked.

----------
components: Build
files: _json.c.diff
keywords: patch
messages: 118255
nosy: akitada
priority: normal
severity: normal
status: open
title: C99 code in _json.c
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file19174/_json.c.diff

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

From report at bugs.python.org  Sat Oct  9 12:18:30 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Oct 2010 10:18:30 +0000
Subject: [New-bugs-announce] [issue10056] Can't build tkinter with libtk 8.6
In-Reply-To: <1286619510.51.0.775607940456.issue10056@psf.upfronthosting.co.za>
Message-ID: <1286619510.51.0.775607940456.issue10056@psf.upfronthosting.co.za>


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

This is only with 3.1. Following patch allows building:

Index: setup.py
===================================================================
--- setup.py	(r?vision 85336)
+++ setup.py	(copie de travail)
@@ -1450,7 +1450,7 @@
         # The versions with dots are used on Unix, and the versions without
         # dots on Windows, for detection by cygwin.
         tcllib = tklib = tcl_includes = tk_includes = None
-        for version in ['8.5', '85', '8.4', '84', '8.3', '83', '8.2',
+        for version in ['8.6', '86', '8.5', '85', '8.4', '84', '8.3', '83', '8.2',
                         '82', '8.1', '81', '8.0', '80']:
             tklib = self.compiler.find_library_file(lib_dirs, 'tk' + version)
             tcllib = self.compiler.find_library_file(lib_dirs, 'tcl' + version)


However, there is then a test failure:

======================================================================
FAIL: test_tag_configure (tkinter.test.test_ttk.test_widgets.TreeviewTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/31/Lib/tkinter/test/test_ttk/test_widgets.py", line 1116, in test_tag_configure
    'blue')
AssertionError: <color object at 0x202a8f0> != 'blue'

----------
assignee: gpolo
components: Build
messages: 118260
nosy: gpolo, pitrou
priority: normal
severity: normal
status: open
title: Can't build tkinter with libtk 8.6
type: compile error
versions: Python 3.1

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

From report at bugs.python.org  Sat Oct  9 20:02:00 2010
From: report at bugs.python.org (Jan Kratochvil)
Date: Sat, 09 Oct 2010 18:02:00 +0000
Subject: [New-bugs-announce] [issue10057] Unclear if exception should be set
In-Reply-To: <1286647320.48.0.566967627744.issue10057@psf.upfronthosting.co.za>
Message-ID: <1286647320.48.0.566967627744.issue10057@psf.upfronthosting.co.za>


New submission from Jan Kratochvil <jan.kratochvil at redhat.com>:

http://docs.python.org/py3k/c-api/object.html
PyObject_GetItem
Return element [...] or NULL on failure.

Found element => return its pointer.
Found no element => return NULL (with no exception set).

But it is unclear whether the function can also:
Error happened => return NULL with an exception set.

It affects multiple versions of the doc, did not check which all.

----------
assignee: docs at python
components: Documentation
messages: 118281
nosy: docs at python, jankratochvil
priority: normal
severity: normal
status: open
title: Unclear if exception should be set
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Sun Oct 10 01:37:57 2010
From: report at bugs.python.org (Nikolaus Rath)
Date: Sat, 09 Oct 2010 23:37:57 +0000
Subject: [New-bugs-announce] [issue10058] Unclear PyString_AsStringAndSize
	return value
In-Reply-To: <1286667477.81.0.428824967814.issue10058@psf.upfronthosting.co.za>
Message-ID: <1286667477.81.0.428824967814.issue10058@psf.upfronthosting.co.za>


New submission from Nikolaus Rath <Nikolaus at rath.org>:

http://docs.python.org/c-api/string.html says about the return value of AsStringAndSize:

"If length is NULL, the resulting buffer may not contain NUL characters; if it does, the function returns -1 and a TypeError is raised."

"If string is not a string object at all, PyString_AsStringAndSize() returns -1 and raises TypeError."

This makes me wonder what the return code is if a) the function succeeds and b) it encounteres some other problem (i.e. out of memory when it tries to encode a unicode string into its default encoding).

I guess that the return value is 0 on success and -1 on all errors, but it would be nice if the documentation would be clear about this.

----------
assignee: docs at python
components: Documentation
messages: 118294
nosy: Nikratio, docs at python
priority: normal
severity: normal
status: open
title: Unclear PyString_AsStringAndSize return value
type: feature request
versions: Python 2.7

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

From report at bugs.python.org  Sun Oct 10 02:23:47 2010
From: report at bugs.python.org (Simon Liedtke)
Date: Sun, 10 Oct 2010 00:23:47 +0000
Subject: [New-bugs-announce] [issue10059] add the method `index` to
	collections.deque
In-Reply-To: <1286670227.45.0.57597987933.issue10059@psf.upfronthosting.co.za>
Message-ID: <1286670227.45.0.57597987933.issue10059@psf.upfronthosting.co.za>


New submission from Simon Liedtke <liedtke.simon at googlemail.com>:

I'd like to have the method `index` not only for list, but also for collections.deque.

Here is my attempt: http://bitbucket.org/derdon/hodgepodge/src/tip/extended_deque.py

I'm looking forward to see this method implemented in the stdlib!

----------
components: Library (Lib)
messages: 118296
nosy: Simon.Liedtke
priority: normal
severity: normal
status: open
title: add the method `index` to collections.deque
type: feature request

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

From report at bugs.python.org  Sun Oct 10 04:03:47 2010
From: report at bugs.python.org (Dev Player)
Date: Sun, 10 Oct 2010 02:03:47 +0000
Subject: [New-bugs-announce] [issue10060] python.exe crashes or hangs on
	help() modules when bad	modules found
In-Reply-To: <1286676227.2.0.62342583611.issue10060@psf.upfronthosting.co.za>
Message-ID: <1286676227.2.0.62342583611.issue10060@psf.upfronthosting.co.za>


New submission from Dev Player <devplayer at gmail.com>:

2010-10-10 python.exe crashes or hangs on help() modules 
when bad modules found

#######################################################################
SUMMARY

The python.exe command line interpreter crashes or hangs when
typing first >>>help() then >modules and a corrupt module is found.

Python 2.7 WinXP SP3 see version details in OUTPUT sections
#######################################################################
EXPLANATION

# -----------------------
I have a workaround as a user. However it appears to be a bug 
from previous Python versions, 2.5 and 2.6 from what I've seen 
through Google and other help() module tickets. 

The workaround is simply remove the corrupt package.

# -----------------------
I've noticed when there is a corrupt package on my PC in the 
Q:\Python27\Lib\site-packages folder that seems to cause 
a problem when issuing >>>help() then >modules in Python. 

Python command line interperter doesn't gracefully exit the 
assertion, it crashes or hangs.

When entering python.exe, idle.exe or pycrust.bat (runs pycrust.py),
typing help(), then typing modules, the help routine runs most of 
the "search-for-packages" routine fine (see OUTPUT SECTION below) 
and seems to find all the installed modules but when it's 
finished it does the following:

- python.exe either crashes, or puts up a help> prompt window and 
  then drops to the DOS command prompt as seen below.

  MS window error:
  python.exe has encountered a problem and needs to clos.
  We are sorry for the inconvienience
  AppName: python.exe
  AppVer: 0.0.0.0
  ModName: unknown
  ModVer: 0.0.0.0
  Offset: 00a20fdf

- IDLE.py doesn't crash but after the >>>help() >modules it shows
  the errors in .py files

- PyCrust.py runs the >>>help() > modules it then shows errors 
  in .py files, it then crashes


In my case you will note the problem occurs on my install of the 
pythonwin package. On my system pythonwin will work until I exit. 

I installed a new version pythonwin just after installing Python 2.7.
The pythonwin version always crashed on exit since it was installed. 
The old pythonwin was deinstalled before installation of the new.

However, having a corrupt installed package shouldn't crash python.

pythonwin version: pywin32 build214

# -----------------------
Something of note:
    All my development, including Python 2.7 installation and 
    packages and projects are on my Q: drive, which is 
    a mapped drive pointing to a sub-folder on a 
    networked-shared folder in WinXP.

    Actual Folder:
        D:\SUBST_DRIVES\DRIVE_Q_DEVELOPMENT
    Net-shared Folder:
       \\Mycomp\D$\Subst_drives
    Mapped Folder:
        Q: = \\Mycomp\D$\Subst_drives\DRIVE_Q_DEVELOPMENT

    Although not directly used by the user (me) I also have 
    subst'd drives attached to sub-folders of:
    D:\SUBST_DRIVES\DRIVE_Q_DEVELOPMENT
    such as:
    U: = D:\SUBST_DRIVES\DRIVE_Q_DEVELOPMENT\Projects\Python27\current

    I only mention this in case the >>>help() >modules routine, 
    while seeking modules, can traverse folder structure attached 
    to soft and hard link combos, symbolic links and junction points 
    or whether they have an effect on traversing the folder structure 
    while searching for packages.

However, I went directly to the folder holding python.exe
at D:\SUBST_DRIVES\DRIVE_Q_DEVELOPMENT\Python27\python.exe
When doing help() modules .\python.exe crashed at the end of 
executing "modules" as well.

# -----------------------
So far, I personally have not come across any other issues 
with my installation and python programs and demo code run 
with Python 2.7 except the previously noted exiting-of-pythonwin

# -----------------------
Further details and output from running help() modules below for each
of python.exe, pycrust and idle.


#######################################################################
OUTPUT 
(3 Sections for 3 programs packaged with Python distribution)
#######################################################################
#######################################################################
#######################################################################
SECTION 1 OF 3 
python.exe
#----------------------------------------------------------------------

Q:\Projects\Python27>python.exe
Python 2.7 (r27:82525, Jul  4 2010, 09:01:59) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> help()

Welcome to Python 2.7!  This is the online help utility.

If this is your first time using Python, you should definitely check out
the tutorial on the Internet at http://docs.python.org/tutorial/.

Enter the name of any module, keyword, or topic to get help on writing
Python programs and using Python modules.  To quit this help utility and
return to the interpreter, just type "quit".

To get a list of available modules, keywords, or topics, type "modules",
"keywords", or "topics".  Each module also comes with a one-line summary
of what it does; to list the modules whose summaries contain a given word
such as "spam", type "modules spam".

help> modules

Please wait a moment while I gather a list of all available modules...

AutoComplete        _threading_local    itertools           sspi
AutoCompleteWindow  _tkinter            json                sspicon
AutoExpand          _warnings           keybindingDialog    stat
BaseHTTPServer      _weakref            keyword             statvfs
Bastion             _weakrefset         lib                 string
Bindings            _win32sysloader     lib2to3             stringold
CGIHTTPServer       _winreg             linecache           stringprep
CallTipWindow       _winxptheme         locale              strop
CallTips            abc                 logging             struct
Canvas              aboutDialog         macosxSupport       subprocess
ClassBrowser        adodbapi            macpath             sunau
CodeContext         afxres              macurl2path         sunaudio
ColorDelegator      aifc                mailbox             symbol
ConfigParser        antigravity         mailcap             symtable
Cookie              anydbm              markupbase          sys
CreateBatchFiles    app                 marshal             sysconfig
CreateMacScripts    argparse            math                tabbedpages
Debugger            array               md5                 tabnanny
Delegator           ast                 media               tarfile
Dialog              asynchat            mhlib               telnetlib
DocXMLRPCServer     asyncore            mimetools           tempfile
EditorWindow        atexit              mimetypes           test
Enums               audiodev            mimify              testcode
FileDialog          audioop             mmap                tests
FileList            base64              mmapfile            text
FixTk               bdb                 mmsystem            textView
FormatParagraph     binascii            modulefinder        textwrap
GrepDialog          binhex              msilib              this
HTMLParser          bisect              msvcrt              thread
HyperParser         bsddb               multifile           threading
ID_NS               bz2                 multiprocessing     time
IOBinding           cPickle             mutex               timeit
IdleHistory         cProfile            netbios             timer
MOCK_WX             cStringIO           netrc               tkColorChooser
MimeWriter          calendar            new                 tkCommonDialog
MultiCall           cgi                 nntplib             tkFileDialog
MultiStatusBar      cgitb               nt                  tkFont
ObjectBrowser       chunk               ntpath              tkMessageBox
ObjectListView      clock               ntsecuritycon       tkSimpleDialog
OutputWindow        cmath               nturl2path          toaiff
ParenMatch          cmd                 numbers             token
PathBrowser         code                odbc                tokenize
Percolator          codecs              opcode              trace
PyParse             codeop              operator            traceback
PyShell             collections         optparse            ttk
PythonOgreConfig    colorsys            os                  tty
Queue               com                 os2emxpath          turtle
RemoteDebugger      commands            parser              types
RemoteObjectBrowser commctrl            pdb                 unicodedata
ReplaceDialog       compileall          perfmon             unittest
ReportVersion       compiler            pickle              urllib
RstripExtension     configDialog        pickletools         urllib2
SampleFramework     configHandler       pipes               urlparse
ScriptBinding       configHelpSourceEdit pkgutil             user
ScrolledList        configSectionNameDialog platform            utils
ScrolledText        contextlib          plistlib            uu
SearchDialog        convert_to_PANP     popen2              uuid
SearchDialogBase    cookielib           poplib              warnings
SearchEngine        copy                posixfile           wave
SimpleDialog        copy_reg            posixpath           weakref
SimpleHTTPServer    core                pprint              webbrowser
SimpleXMLRPCServer  csv                 profile             whichdb
SocketServer        ctypes              pstats              win2kras
StackViewer         curses              pty                 win32api
StringIO            datetime            pub                 win32clipboard
Tix                 dbhash              pubsub              win32com
Tkconstants         dbi                 pubsub1             win32con
Tkdnd               dde                 pubsubconf          win32console
Tkinter             decimal             py_compile          win32cred
ToolTip             difflib             pyclbr              win32crypt
TreeWidget          dircache            pycrust_c           win32cryptcon
UndoDelegator       dis                 pycrust_gdir        win32event
UserDict            distutils           pydoc               win32evtlog
UserList            doctest             pydoc_data          win32evtlogutil
UserString          dprint              pyexpat             win32file
WidgetRedirector    dumbdbm             pyglet              win32gui
WindowList          dummy_thread        pythoncom           win32gui_struct
ZoomHeight          dummy_threading     pythonstartup       win32help
_LWPCookieJar       dynOptionMenuWidget pywin               win32inet
_MozillaCookieJar   email               pywin32_postinstall win32inetcon
__builtin__         encodings           pywin32_testutil    win32job
__future__          errno               pywintypes          win32lz
_abcoll             event               quopri              win32net
_ast                exceptions          random              win32netcon
_autosetuppubsubv1  filecmp             rasutil             win32pdh
_bisect             fileinput           re                  win32pdhquery
_bsddb              fnmatch             regcheck            win32pdhutil
_codecs             font                regutil             win32pipe
_codecs_cn          formatter           repr                win32print
_codecs_hk          fpformat            resource            win32process
_codecs_iso2022     fractions           rexec               win32profile
_codecs_jp          ftplib              rfc822              win32ras
_codecs_kr          functools           rlcompleter         win32rcparser
_codecs_tw          future_builtins     robotparser         win32security
_collections        gc                  rpc                 win32service
_csv                genericpath         run                 win32serviceutil
_ctypes             getopt              runpy               win32timezone
_ctypes_test        getpass             sched               win32trace
_elementtree        gettext             select              win32traceutil
_functools          gl                  servicemanager      win32transaction
_hashlib            glob                sets                win32ts
_heapq              graphics            setup               win32ui
_hotshot            gzip                setuparg1           win32uiole
_io                 hashlib             setupkwargs         win32verstamp
_json               heapq               setupv1             win32wnet
_locale             hmac                setupv2             window
_lsprof             hotshot             sgmllib             winerror
_md5                htmlentitydefs      sha                 winioctlcon
_msi                htmllib             shelve              winnt
_multibytecodec     httplib             shlex               winperf
_multiprocessing    idle                shutil              winsound
_pyio               idlelib             signal              winxpgui
_random             idlever             singletonmixin      winxptheme
_sha                ihooks              site                wsgiref
_sha256             image               smtpd               wx
_sha512             imageop             smtplib             wxPython
_socket             imaplib             sndhdr              wxversion
_sqlite3            imghdr              socket              xdrlib
_sre                imp                 sprite              xml
_ssl                importlib           sqlite3             xmllib
_strptime           imputil             sre                 xmlrpclib
_struct             info                sre_compile         xxsubtype
_subprocess         inspect             sre_constants       zipfile
_symtable           io                  sre_parse           zipimport
_testcapi           isapi               ssl                 zlib

Enter any module name to get more help.  Or, type "modules spam" to search
for modules whose descriptions contain the word "spam".


Q:\Projects\Python27>

#----------------------------------------------------------------------
WHAT YOU SEE ABOVE a copy and past:
python.exe either crashes, or puts up a help> prompt window and then 
drops to the DOS command prompt as seen above without indicating
there was a corrupt package.

#######################################################################
#######################################################################
#######################################################################
SECTION 2 OF 3 
IDLE
#----------------------------------------------------------------------

Python 2.7 (r27:82525, Jul  4 2010, 09:01:59) [MSC v.1500 32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more information.

>>> help()

Welcome to Python 2.7!  This is the online help utility.

If this is your first time using Python, you should definitely check out
the tutorial on the Internet at http://docs.python.org/tutorial/.

Enter the name of any module, keyword, or topic to get help on writing
Python programs and using Python modules.  To quit this help utility and
return to the interpreter, just type "quit".

To get a list of available modules, keywords, or topics, type "modules",
"keywords", or "topics".  Each module also comes with a one-line summary
of what it does; to list the modules whose summaries contain a given word
such as "spam", type "modules spam".

help> modules

Please wait a moment while I gather a list of all available modules...

AutoComplete        _threading_local    itertools           sspi
AutoCompleteWindow  _tkinter            json                sspicon
AutoExpand          _warnings           keybindingDialog    stat
BaseHTTPServer      _weakref            keyword             statvfs
Bastion             _weakrefset         lib                 string
Bindings            _win32sysloader     lib2to3             stringold
CGIHTTPServer       _winreg             linecache           stringprep
CallTipWindow       _winxptheme         locale              strop
CallTips            abc                 logging             struct
Canvas              aboutDialog         macosxSupport       subprocess
ClassBrowser        adodbapi            macpath             sunau
CodeContext         afxres              macurl2path         sunaudio
ColorDelegator      aifc                mailbox             symbol
ConfigParser        antigravity         mailcap             symtable
Cookie              anydbm              markupbase          sys
CreateBatchFiles    app                 marshal             sysconfig
CreateMacScripts    argparse            math                tabbedpages
Debugger            array               md5                 tabnanny
Delegator           ast                 media               tarfile
Dialog              asynchat            mhlib               telnetlib
DocXMLRPCServer     asyncore            mimetools           tempfile
EditorWindow        atexit              mimetypes           test
Enums               audiodev            mimify              testcode
FileDialog          audioop             mmap                tests
FileList            base64              mmapfile            text
FixTk               bdb                 mmsystem            textView
FormatParagraph     binascii            modulefinder        textwrap
GrepDialog          binhex              msilib              this
HTMLParser          bisect              msvcrt              thread
HyperParser         bsddb               multifile           threading
ID_NS               bz2                 multiprocessing     time
IOBinding           cPickle             mutex               timeit
IdleHistory         cProfile            netbios             timer
MOCK_WX             cStringIO           netrc               tkColorChooser
MimeWriter          calendar            new                 tkCommonDialog
MultiCall           cgi                 nntplib             tkFileDialog
MultiStatusBar      cgitb               nt                  tkFont
ObjectBrowser       chunk               ntpath              tkMessageBox
ObjectListView      clock               ntsecuritycon       tkSimpleDialog
OutputWindow        cmath               nturl2path          toaiff
ParenMatch          cmd                 numbers             token
PathBrowser         code                odbc                tokenize
Percolator          codecs              opcode              trace
PyParse             codeop              operator            traceback
PyShell             collections         optparse            ttk
PythonOgreConfig    colorsys            os                  tty
Queue               com                 os2emxpath          turtle
RemoteDebugger      commands            parser              types
RemoteObjectBrowser commctrl            pdb                 unicodedata
ReplaceDialog       compileall          perfmon             unittest
ReportVersion       compiler            pickle              urllib
RstripExtension     configDialog        pickletools         urllib2
SampleFramework     configHandler       pipes               urlparse
ScriptBinding       configHelpSourceEdit pkgutil             user
ScrolledList        configSectionNameDialog platform            utils
ScrolledText        contextlib          plistlib            uu
SearchDialog        convert_to_PANP     popen2              uuid
SearchDialogBase    cookielib           poplib              warnings
SearchEngine        copy                posixfile           wave
SimpleDialog        copy_reg            posixpath           weakref
SimpleHTTPServer    core                pprint              webbrowser
SimpleXMLRPCServer  csv                 profile             whichdb
SocketServer        ctypes              pstats              win2kras
StackViewer         curses              pty                 win32api
StringIO            datetime            pub                 win32clipboard
Tix                 dbhash              pubsub              win32com
Tkconstants         dbi                 pubsub1             win32con
Tkdnd               dde                 pubsubconf          win32console
Tkinter             decimal             py_compile          win32cred
ToolTip             difflib             pyclbr              win32crypt
TreeWidget          dircache            pycrust_c           win32cryptcon
UndoDelegator       dis                 pycrust_gdir        win32event
UserDict            distutils           pydoc               win32evtlog
UserList            doctest             pydoc_data          win32evtlogutil
UserString          dprint              pyexpat             win32file
WidgetRedirector    dumbdbm             pyglet              win32gui
WindowList          dummy_thread        pythoncom           win32gui_struct
ZoomHeight          dummy_threading     pythonstartup       win32help
_LWPCookieJar       dynOptionMenuWidget pywin               win32inet
_MozillaCookieJar   email               pywin32_postinstall win32inetcon
__builtin__         encodings           pywin32_testutil    win32job
__future__          errno               pywintypes          win32lz
_abcoll             event               quopri              win32net
_ast                exceptions          random              win32netcon
_autosetuppubsubv1  filecmp             rasutil             win32pdh
_bisect             fileinput           re                  win32pdhquery
_bsddb              fnmatch             regcheck            win32pdhutil
_codecs             font                regutil             win32pipe
_codecs_cn          formatter           repr                win32print
_codecs_hk          fpformat            resource            win32process
_codecs_iso2022     fractions           rexec               win32profile
_codecs_jp          ftplib              rfc822              win32ras
_codecs_kr          functools           rlcompleter         win32rcparser
_codecs_tw          future_builtins     robotparser         win32security
_collections        gc                  rpc                 win32service
_csv                genericpath         run                 win32serviceutil
_ctypes             getopt              runpy               win32timezone
_ctypes_test        getpass             sched               win32trace
_elementtree        gettext             select              win32traceutil
_functools          gl                  servicemanager      win32transaction
_hashlib            glob                sets                win32ts
_heapq              graphics            setup               win32ui
_hotshot            gzip                setuparg1           win32uiole
_io                 hashlib             setupkwargs         win32verstamp
_json               heapq               setupv1             win32wnet
_locale             hmac                setupv2             window
_lsprof             hotshot             sgmllib             winerror
_md5                htmlentitydefs      sha                 winioctlcon
_msi                htmllib             shelve              winnt
_multibytecodec     httplib             shlex               winperf
_multiprocessing    idle                shutil              winsound
_pyio               idlelib             signal              winxpgui
_random             idlever             singletonmixin      winxptheme
_sha                ihooks              site                wsgiref
_sha256             image               smtpd               wx
_sha512             imageop             smtplib             wxPython
_socket             imaplib             sndhdr              wxversion
_sqlite3            imghdr              socket              xdrlib
_sre                imp                 sprite              xml
_ssl                importlib           sqlite3             xmllib
_strptime           imputil             sre                 xmlrpclib
_struct             info                sre_compile         xxsubtype
_subprocess         inspect             sre_constants       zipfile
_symtable           io                  sre_parse           zipimport
_testcapi           isapi               ssl                 zlib

Enter any module name to get more help.  Or, type "modules spam" to search
for modules whose descriptions contain the word "spam".


Traceback (most recent call last):
  File "<pyshell#0>", line 1, in <module>
    help()
  File "Q:\Python27\lib\site.py", line 453, in __call__
    return pydoc.help(*args, **kwds)
  File "Q:\Python27\lib\pydoc.py", line 1723, in __call__
    self.interact()
  File "Q:\Python27\lib\pydoc.py", line 1735, in interact
    request = self.getline('help> ')
  File "Q:\Python27\lib\pydoc.py", line 1746, in getline
    return raw_input(prompt)
  File "Q:\Python27\Lib\site-packages\pythonwin\pywin\framework\app.py", line 367, in Win32RawInput
    ret=dialog.GetSimpleInput(prompt)
  File "Q:\Python27\Lib\site-packages\pythonwin\pywin\mfc\dialog.py", line 223, in GetSimpleInput
    if title is None: title=win32ui.GetMainFrame().GetWindowText()
error: The frame does not exist
>>> 

#----------------------------------------------------------------------
IDLE doesn't crash

#######################################################################
#######################################################################
#######################################################################
SECTION 3 OF 3 
PyCrust
#----------------------------------------------------------------------

PyCrust 0.9.8 - The Flakiest Python Shell
Python 2.7 (r27:82525, Jul  4 2010, 09:01:59) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
Startup script executed: C:\Documents and Settings\User\Application Data\pycrust\startup
help()

Welcome to Python 2.7!  This is the online help utility.

If this is your first time using Python, you should definitely check out
the tutorial on the Internet at http://docs.python.org/tutorial/.

Enter the name of any module, keyword, or topic to get help on writing
Python programs and using Python modules.  To quit this help utility and
return to the interpreter, just type "quit".

To get a list of available modules, keywords, or topics, type "modules",
"keywords", or "topics".  Each module also comes with a one-line summary
of what it does; to list the modules whose summaries contain a given word
such as "spam", type "modules spam".

help> modules

Please wait a moment while I gather a list of all available modules...

AutoComplete        _threading_local    itertools           sspi
AutoCompleteWindow  _tkinter            json                sspicon
AutoExpand          _warnings           keybindingDialog    stat
BaseHTTPServer      _weakref            keyword             statvfs
Bastion             _weakrefset         lib                 string
Bindings            _win32sysloader     lib2to3             stringold
CGIHTTPServer       _winreg             linecache           stringprep
CallTipWindow       _winxptheme         locale              strop
CallTips            abc                 logging             struct
Canvas              aboutDialog         macosxSupport       subprocess
ClassBrowser        adodbapi            macpath             sunau
CodeContext         afxres              macurl2path         sunaudio
ColorDelegator      aifc                mailbox             symbol
ConfigParser        antigravity         mailcap             symtable
Cookie              anydbm              markupbase          sys
CreateBatchFiles    app                 marshal             sysconfig
CreateMacScripts    argparse            math                tabbedpages
Debugger            array               md5                 tabnanny
Delegator           ast                 media               tarfile
Dialog              asynchat            mhlib               telnetlib
DocXMLRPCServer     asyncore            mimetools           tempfile
EditorWindow        atexit              mimetypes           test
Enums               audiodev            mimify              testcode
FileDialog          audioop             mmap                tests
FileList            base64              mmapfile            text
FixTk               bdb                 mmsystem            textView
FormatParagraph     binascii            modulefinder        textwrap
GrepDialog          binhex              msilib              this
HTMLParser          bisect              msvcrt              thread
HyperParser         bsddb               multifile           threading
ID_NS               bz2                 multiprocessing     time
IOBinding           cPickle             mutex               timeit
IdleHistory         cProfile            netbios             timer
MOCK_WX             cStringIO           netrc               tkColorChooser
MimeWriter          calendar            new                 tkCommonDialog
MultiCall           cgi                 nntplib             tkFileDialog
MultiStatusBar      cgitb               nt                  tkFont
ObjectBrowser       chunk               ntpath              tkMessageBox
ObjectListView      clock               ntsecuritycon       tkSimpleDialog
OutputWindow        cmath               nturl2path          toaiff
ParenMatch          cmd                 numbers             token
PathBrowser         code                odbc                tokenize
Percolator          codecs              opcode              trace
PyParse             codeop              operator            traceback
PyShell             collections         optparse            ttk
PythonOgreConfig    colorsys            os                  tty
Queue               com                 os2emxpath          turtle
RemoteDebugger      commands            parser              types
RemoteObjectBrowser commctrl            pdb                 unicodedata
ReplaceDialog       compileall          perfmon             unittest
ReportVersion       compiler            pickle              urllib
RstripExtension     configDialog        pickletools         urllib2
SampleFramework     configHandler       pipes               urlparse
ScriptBinding       configHelpSourceEdit pkgutil             user
ScrolledList        configSectionNameDialog platform            utils
ScrolledText        contextlib          plistlib            uu
SearchDialog        convert_to_PANP     popen2              uuid
SearchDialogBase    cookielib           poplib              warnings
SearchEngine        copy                posixfile           wave
SimpleDialog        copy_reg            posixpath           weakref
SimpleHTTPServer    core                pprint              webbrowser
SimpleXMLRPCServer  csv                 profile             whichdb
SocketServer        ctypes              pstats              win2kras
StackViewer         curses              pty                 win32api
StringIO            datetime            pub                 win32clipboard
Tix                 dbhash              pubsub              win32com
Tkconstants         dbi                 pubsub1             win32con
Tkdnd               dde                 pubsubconf          win32console
Tkinter             decimal             py_compile          win32cred
ToolTip             difflib             pyclbr              win32crypt
TreeWidget          dircache            pycrust_c           win32cryptcon
UndoDelegator       dis                 pycrust_gdir        win32event
UserDict            distutils           pydoc               win32evtlog
UserList            doctest             pydoc_data          win32evtlogutil
UserString          dprint              pyexpat             win32file
WidgetRedirector    dumbdbm             pyglet              win32gui
WindowList          dummy_thread        pythoncom           win32gui_struct
ZoomHeight          dummy_threading     pythonstartup       win32help
_LWPCookieJar       dynOptionMenuWidget pywin               win32inet
_MozillaCookieJar   email               pywin32_postinstall win32inetcon
__builtin__         encodings           pywin32_testutil    win32job
__future__          errno               pywintypes          win32lz
_abcoll             event               quopri              win32net
_ast                exceptions          random              win32netcon
_autosetuppubsubv1  filecmp             rasutil             win32pdh
_bisect             fileinput           re                  win32pdhquery
_bsddb              fnmatch             regcheck            win32pdhutil
_codecs             font                regutil             win32pipe
_codecs_cn          formatter           repr                win32print
_codecs_hk          fpformat            resource            win32process
_codecs_iso2022     fractions           rexec               win32profile
_codecs_jp          ftplib              rfc822              win32ras
_codecs_kr          functools           rlcompleter         win32rcparser
_codecs_tw          future_builtins     robotparser         win32security
_collections        gc                  rpc                 win32service
_csv                genericpath         run                 win32serviceutil
_ctypes             getopt              runpy               win32timezone
_ctypes_test        getpass             sched               win32trace
_elementtree        gettext             select              win32traceutil
_functools          gl                  servicemanager      win32transaction
_hashlib            glob                sets                win32ts
_heapq              graphics            setup               win32ui
_hotshot            gzip                setuparg1           win32uiole
_io                 hashlib             setupkwargs         win32verstamp
_json               heapq               setupv1             win32wnet
_locale             hmac                setupv2             window
_lsprof             hotshot             sgmllib             winerror
_md5                htmlentitydefs      sha                 winioctlcon
_msi                htmllib             shelve              winnt
_multibytecodec     httplib             shlex               winperf
_multiprocessing    idle                shutil              winsound
_pyio               idlelib             signal              winxpgui
_random             idlever             singletonmixin      winxptheme
_sha                ihooks              site                wsgiref
_sha256             image               smtpd               wx
_sha512             imageop             smtplib             wxPython
_socket             imaplib             sndhdr              wxversion
_sqlite3            imghdr              socket              xdrlib
_sre                imp                 sprite              xml
_ssl                importlib           sqlite3             xmllib
_strptime           imputil             sre                 xmlrpclib
_struct             info                sre_compile         xxsubtype
_subprocess         inspect             sre_constants       zipfile
_symtable           io                  sre_parse           zipimport
_testcapi           isapi               ssl                 zlib

Enter any module name to get more help.  Or, type "modules spam" to search
for modules whose descriptions contain the word "spam".

Traceback (most recent call last):
  File "<input>", line 1, in <module>
  File "Q:\Python27\lib\site.py", line 453, in __call__
    return pydoc.help(*args, **kwds)
  File "Q:\Python27\lib\pydoc.py", line 1723, in __call__
    self.interact()
  File "Q:\Python27\lib\pydoc.py", line 1735, in interact
    request = self.getline('help> ')
  File "Q:\Python27\lib\pydoc.py", line 1746, in getline
    return raw_input(prompt)
  File "Q:\Python27\Lib\site-packages\pythonwin\pywin\framework\app.py", line 367, in Win32RawInput
    ret=dialog.GetSimpleInput(prompt)
  File "Q:\Python27\Lib\site-packages\pythonwin\pywin\mfc\dialog.py", line 223, in GetSimpleInput
    if title is None: title=win32ui.GetMainFrame().GetWindowText()
error: The frame does not exist

#----------------------------------------------------------------------
Then after doing anything in PyCrust it crashes

#######################################################################
#######################################################################
#######################################################################

----------
components: IDLE
messages: 118298
nosy: devplayer
priority: normal
severity: normal
status: open
title: python.exe crashes or hangs on help() modules when bad modules found
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Sun Oct 10 08:41:20 2010
From: report at bugs.python.org (eswar s)
Date: Sun, 10 Oct 2010 06:41:20 +0000
Subject: [New-bugs-announce] [issue10061] ** operator yielding wrong result
	for negative numbers
In-Reply-To: <1286692880.84.0.509145728664.issue10061@psf.upfronthosting.co.za>
Message-ID: <1286692880.84.0.509145728664.issue10061@psf.upfronthosting.co.za>


New submission from eswar s <eswar_js at yahoo.com>:

-5 ** 4 results as -625. It should be 625

----------
components: None
messages: 118311
nosy: eswar.s
priority: normal
severity: normal
status: open
title: ** operator yielding wrong result for negative numbers
type: compile error
versions: Python 2.6

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

From report at bugs.python.org  Sun Oct 10 09:51:19 2010
From: report at bugs.python.org (Akira Kitada)
Date: Sun, 10 Oct 2010 07:51:19 +0000
Subject: [New-bugs-announce] [issue10062] Python 3.2 does not build on
	systems which do not have	sem_timedwait
In-Reply-To: <1286697079.97.0.278086766223.issue10062@psf.upfronthosting.co.za>
Message-ID: <1286697079.97.0.278086766223.issue10062@psf.upfronthosting.co.za>


New submission from Akira Kitada <akitada at gmail.com>:

Build fails on FreeBSD 4 due to the lack of sem_timedwait.

"""
gcc -pthread   -Wl,--export-dynamic -o python Modules/python.o libpython3.2.a -lutil   -lm  
libpython3.2.a(thread.o): In function `PyThread_acquire_lock_timed':
/home/akitada/src/py3k/Python/thread_pthread.h:315: undefined reference to `sem_timedwait'
gmake: *** [python] Error 1
"""

----------
components: Build
messages: 118315
nosy: akitada
priority: normal
severity: normal
status: open
title: Python 3.2 does not build on systems which do not have sem_timedwait
type: compile error
versions: Python 3.2

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

From report at bugs.python.org  Sun Oct 10 11:40:24 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 10 Oct 2010 09:40:24 +0000
Subject: [New-bugs-announce] [issue10063] file:// scheme will stop accessing
	via ftp protocol
In-Reply-To: <1286703624.02.0.46805329948.issue10063@psf.upfronthosting.co.za>
Message-ID: <1286703624.02.0.46805329948.issue10063@psf.upfronthosting.co.za>


New submission from Senthil Kumaran <orsenthil at gmail.com>:

file:// scheme should not be allowed to access a file on remote machines.  RFC 1738, says that host, if present should be the FQDN of the machine, but relaxing on that I thinking that localhost and its variants should okay as long as it is the local machine.

What is going to break in 3.2 is file:// trying to access resources on remote machine via FTP, which it is currently trying to do.

Attached is patch to accomplish this.(NEWS and Docs will be added).

This would introduce a regression, so this may not be backported.

----------
assignee: orsenthil
components: Library (Lib)
files: file_scheme.diff
keywords: patch
messages: 118327
nosy: orsenthil
priority: normal
severity: normal
stage: patch review
status: open
title: file:// scheme will stop accessing via ftp protocol
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file19182/file_scheme.diff

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

From report at bugs.python.org  Sun Oct 10 16:55:59 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 10 Oct 2010 14:55:59 +0000
Subject: [New-bugs-announce] [issue10064] link to page with documentation
	bugs
In-Reply-To: <1286722559.84.0.874686130461.issue10064@psf.upfronthosting.co.za>
Message-ID: <1286722559.84.0.874686130461.issue10064@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

Link to bugtracker on http://docs.python.org/dev/bugs.html leads to main roundup page. It make more sense to redirect to a page that lists only documentation bugs.

Extra points:
- sort the landing page that Easy, then issues with Patches come first
- provide a link to Documentation HOWTO from an issue page

----------
assignee: docs at python
components: Documentation
messages: 118334
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: link to page with documentation bugs

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

From report at bugs.python.org  Sun Oct 10 21:31:48 2010
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Sun, 10 Oct 2010 19:31:48 +0000
Subject: [New-bugs-announce] [issue10065] future_builtins' docstring lacks
	some functions
In-Reply-To: <1286739108.25.0.226461556953.issue10065@psf.upfronthosting.co.za>
Message-ID: <1286739108.25.0.226461556953.issue10065@psf.upfronthosting.co.za>


New submission from Andreas St?hrk <andy-python at hammerhartes.de>:

Title says all, attached is a patch against release27-maint that adds them.

----------
assignee: docs at python
components: Documentation
files: future_builtins_docstring.patch
keywords: patch
messages: 118343
nosy: Trundle, docs at python
priority: normal
severity: normal
status: open
title: future_builtins' docstring lacks some functions
versions: Python 2.7
Added file: http://bugs.python.org/file19183/future_builtins_docstring.patch

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

From report at bugs.python.org  Mon Oct 11 18:16:41 2010
From: report at bugs.python.org (Peter Gyorko)
Date: Mon, 11 Oct 2010 16:16:41 +0000
Subject: [New-bugs-announce] [issue10066] xmlrpclib does not handle some
	non-printable characters	properly
In-Reply-To: <1286813801.19.0.762560466895.issue10066@psf.upfronthosting.co.za>
Message-ID: <1286813801.19.0.762560466895.issue10066@psf.upfronthosting.co.za>


New submission from Peter Gyorko <gyorkop at balabit.hu>:

If I add a string to the response, which contains non-printable characters, the output will not be parsed by the most of the XML parsers (I tried with XML-RPC for PHP).

Here is my quick and dirty fix:

--- a/Lib/xmlrpclib.py
+++ b/Lib/xmlrpclib.py
@@ -165,9 +165,18 @@ def _decode(data, encoding, is8bit=re.compile("[\x80-\xff]").search):
     return data
 
 def escape(s, replace=string.replace):
-    s = replace(s, "&", "&amp;")
-    s = replace(s, "<", "&lt;")
-    return replace(s, ">", "&gt;",)
+    res = ''
+    for char in s:
+        char_code = ord(char)
+        if (char_code < 32 and char_code not in (9, 10, 13)) or char_code > 126:
+            res += '\\x%02x' % ord(char)
+        else:
+            res += char
+
+    res = replace(res, "&", "&amp;")
+    res = replace(res, "<", "&lt;")
+    res = replace(res, ">", "&gt;")
+    return res
 
 if unicode:
     def _stringify(string):

----------
components: XML
messages: 118376
nosy: gyorkop
priority: normal
severity: normal
status: open
title: xmlrpclib does not handle some non-printable characters properly
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Tue Oct 12 11:20:14 2010
From: report at bugs.python.org (Daniel Abel)
Date: Tue, 12 Oct 2010 09:20:14 +0000
Subject: [New-bugs-announce] [issue10067] itertools' docs put izip_longest
	in the "terminating on	the shortest input sequence" section
In-Reply-To: <1286875214.59.0.114835470036.issue10067@psf.upfronthosting.co.za>
Message-ID: <1286875214.59.0.114835470036.issue10067@psf.upfronthosting.co.za>


New submission from Daniel Abel <abeld at hal.elte.hu>:

Both the 2.x and 3.x documentation for itertools has izip_longest (zip_longest for 3.x)  in the "Iterators terminating on the shortest input sequence" section. However, according to izip_longest's documentation, it terminates when the _longest_ iterator is exhausted.

Possible fixes might be:
- put izip_longest in a new "Iterators terminating on the longest input sequence" section
- rename section to "Iterators terminating on one of the input sequences"

----------
assignee: docs at python
components: Documentation
messages: 118407
nosy: abeld, docs at python
priority: normal
severity: normal
status: open
title: itertools' docs put izip_longest in the "terminating on the shortest input sequence" section
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Oct 12 12:09:28 2010
From: report at bugs.python.org (Valery Lesin)
Date: Tue, 12 Oct 2010 10:09:28 +0000
Subject: [New-bugs-announce] [issue10068] global objects created in some
	module are not destroyed	when last reference to that module
	is released
In-Reply-To: <1286878168.64.0.888099098753.issue10068@psf.upfronthosting.co.za>
Message-ID: <1286878168.64.0.888099098753.issue10068@psf.upfronthosting.co.za>


New submission from Valery Lesin <valery.lesin at gmail.com>:

Interpreter: Python 3.1.2

Sample:

===== first.py =====
import sys
import second 

if 'second' in sys.modules:
  print ('in sys modules')
  del sys.modules['second']

del second

===== second.py =====
class A:
 def __init__(self):
   print('created')

 def __del__(self):
   print('destroyed')

a = A()
---------------------------------------------

Result: 'destroyed' isn't printed
With Python 2.6.5 it worked fine

----------
components: Interpreter Core
messages: 118408
nosy: Valery.Lesin
priority: normal
severity: normal
status: open
title: global objects created in some module are not destroyed when last reference to that module is released
type: behavior
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Oct 12 13:16:48 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Tue, 12 Oct 2010 11:16:48 +0000
Subject: [New-bugs-announce] [issue10069] 2to3 crash in fix_urllib.py
In-Reply-To: <1286882208.41.0.35723041656.issue10069@psf.upfronthosting.co.za>
Message-ID: <1286882208.41.0.35723041656.issue10069@psf.upfronthosting.co.za>


New submission from Hallvard B Furuseth <h.b.furuseth at usit.uio.no>:

This line:

from urllib import quote as quote_url, urlencode

makes 2to3 on Python 3.2a2 crash.
At lib2to3/fixes/fix_urllib.py line 124, member = None.

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 118410
nosy: hfuru
priority: normal
severity: normal
status: open
title: 2to3 crash in fix_urllib.py
versions: Python 3.2

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

From report at bugs.python.org  Tue Oct 12 13:24:21 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Tue, 12 Oct 2010 11:24:21 +0000
Subject: [New-bugs-announce] [issue10070] 2to3 wishes for already-2to3'ed
	files
In-Reply-To: <1286882661.81.0.431457664283.issue10070@psf.upfronthosting.co.za>
Message-ID: <1286882661.81.0.431457664283.issue10070@psf.upfronthosting.co.za>


New submission from Hallvard B Furuseth <h.b.furuseth at usit.uio.no>:

It would be nice with some official way to tell 2to3, "Leave
this code chunk alone.  This is 2.* code, that is 3.* code":

try:                      # Python 2.6
    from urlparse         import urlparse, urlunparse
except ImportError:       # Python 3
    from urllib.parse     import urlparse, urlunparse

Could 2to3 without -p notice more cases of print(single argument),
to avoid slapping another () around them?  For example:

print(2*3)
print(", ".join(dir))

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 118411
nosy: hfuru
priority: normal
severity: normal
status: open
title: 2to3 wishes for already-2to3'ed files
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Tue Oct 12 13:43:24 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 12 Oct 2010 11:43:24 +0000
Subject: [New-bugs-announce] [issue10071] Should not release GIL while
	running RegEnumValue
In-Reply-To: <1286883804.1.0.981912449546.issue10071@psf.upfronthosting.co.za>
Message-ID: <1286883804.1.0.981912449546.issue10071@psf.upfronthosting.co.za>


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

Currently, PC/winreg.c releases GIL while calling registry
API, but I found this in Remarks section of RegEnumValue.

http://msdn.microsoft.com/en-us/library/ms724865%28VS.85%29.aspx

> While using RegEnumValue, an application should not call any registry
> functions that might change the key being queried.

Maybe we shouldn't release GIL in PC/winreg.c? Thank you.

# I sometimes experienced crash of test_changing_value(test_winreg)
# on release27-maint. It happens when 2 threads calls PyEnumValue and
# PySetValue simultaneously. And I could stop it by following patch.
# I'll attach the stack trace of crash.

Index: PC/_winreg.c
===================================================================
--- PC/_winreg.c	(revision 85344)
+++ PC/_winreg.c	(working copy)
@@ -1219,7 +1219,6 @@
     }
 
     while (1) {
-        Py_BEGIN_ALLOW_THREADS
         rc = RegEnumValue(hKey,
                   index,
                   retValueBuf,
@@ -1228,7 +1227,6 @@
                   &typ,
                   (BYTE *)retDataBuf,
                   &retDataSize);
-        Py_END_ALLOW_THREADS
 
         if (rc != ERROR_MORE_DATA)
             break;
@@ -1577,9 +1575,7 @@
         if (subKey == NULL)
             return NULL;
     }
-    Py_BEGIN_ALLOW_THREADS
     rc = RegSetValue(hKey, subKey, REG_SZ, str, len+1);
-    Py_END_ALLOW_THREADS
     if (rc != ERROR_SUCCESS)
         return PyErr_SetFromWindowsErrWithFunction(rc, "RegSetValue");
     Py_INCREF(Py_None);

----------
components: Extension Modules
files: py27_test_winreg_crash_stack_trace.txt
messages: 118413
nosy: ocean-city
priority: normal
severity: normal
status: open
title: Should not release GIL while running RegEnumValue
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file19198/py27_test_winreg_crash_stack_trace.txt

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

From report at bugs.python.org  Tue Oct 12 15:32:10 2010
From: report at bugs.python.org (Rafe H. Kettler)
Date: Tue, 12 Oct 2010 13:32:10 +0000
Subject: [New-bugs-announce] [issue10072] ftplib documentation is unclear
In-Reply-To: <1286890330.18.0.528330532597.issue10072@psf.upfronthosting.co.za>
Message-ID: <1286890330.18.0.528330532597.issue10072@psf.upfronthosting.co.za>


New submission from Rafe H. Kettler <rafe.kettler at gmail.com>:

I think that the documentation for ftplib is a bit too concise and assumes that the reader in an expert in the protocol when the point of the module is to abstract out such details.

For example, for the error documentation, the exceptions are only explained by the error code the server can return to trigger them. So, while the explanation of error_perm, for example, should say something about permissions, it just says "raised when an error code in the range 500?599 is received." This is particularly unclear for those with no knowledge of the internals of the protocol.

Also, in the documentation for RetrLines(), the documentation mentions the options LIST, NLST, and MLSD without explaining what they are. I know that when I first started using ftplib I had to experiment with each option to determine what they do, and I think it would be better if this was clear in the docs from the start.

This can become particularly unclear for less FTP-savvy users.

I can propose a patch to the documentation if needed.

----------
assignee: docs at python
components: Documentation
messages: 118423
nosy: Rafe.H..Kettler, docs at python, orsenthil
priority: normal
severity: normal
status: open
title: ftplib documentation is unclear
type: feature request
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Oct 12 15:47:56 2010
From: report at bugs.python.org (AM Helin)
Date: Tue, 12 Oct 2010 13:47:56 +0000
Subject: [New-bugs-announce] [issue10073] calendar.isleap() not checking
	parameter type
In-Reply-To: <1286891276.3.0.0479149618072.issue10073@psf.upfronthosting.co.za>
Message-ID: <1286891276.3.0.0479149618072.issue10073@psf.upfronthosting.co.za>


New submission from AM Helin <shadikka at gmail.com>:

calendar.isleap() doesn't enforce any types, leading to string formatting errors when a string is passed to it:

>>> calendar.isleap("2011")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/calendar.py", line 99, in isleap
    return year % 4 == 0 and (year % 100 != 0 or year % 400 == 0)
TypeError: not all arguments converted during string formatting

A quick peek at the SVN shows that the problem still exists.

----------
components: Library (Lib)
messages: 118424
nosy: shadikka
priority: normal
severity: normal
status: open
title: calendar.isleap() not checking parameter type
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Tue Oct 12 19:55:56 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 12 Oct 2010 17:55:56 +0000
Subject: [New-bugs-announce] [issue10074] dictobject.c: crash in Py_XDECREF
In-Reply-To: <1286906156.68.0.829457870543.issue10074@psf.upfronthosting.co.za>
Message-ID: <1286906156.68.0.829457870543.issue10074@psf.upfronthosting.co.za>


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

I noticed that Python 2.6.6 crashes on OSX 10.6 when using Komodo. The below traceback indicates a crash in line 911 - "Py_XDECREF(ep->me_value);" in tags/r266/Objects/dictobject.c

Thread 0:  Dispatch queue: com.apple.main-thread
0   org.activestate.ActivePython26	0x129a3716 dict_dealloc + 82 (dictobject.c:911)
1   org.activestate.ActivePython26	0x12976ed1 instance_dealloc + 437 (classobject.c:669)
2   org.activestate.ActivePython26	0x129a3752 dict_dealloc + 142 (dictobject.c:907)
3   org.activestate.ActivePython26	0x129bfcdd subtype_dealloc + 884 (typeobject.c:1004)
4   org.activestate.ActivePython26	0x12994f96 list_dealloc + 212 (listobject.c:306)
5   org.activestate.ActivePython26	0x129a2f81 insertdict + 122 (dictobject.c:459)
6   org.activestate.ActivePython26	0x129a33d9 PyDict_SetItem + 92 (dictobject.c:701)
7   org.activestate.ActivePython26	0x129a8f2e PyObject_GenericSetAttr + 262 (object.c:1504)
8   org.activestate.ActivePython26	0x129a7c2b PyObject_SetAttr + 135 (object.c:1252)
9   org.activestate.ActivePython26	0x12a08132 PyEval_EvalFrameEx + 8529 (ceval.c:1864)
10  org.activestate.ActivePython26	0x12a0bcaa PyEval_EvalFrameEx + 23753 (ceval.c:3836)
11  org.activestate.ActivePython26	0x12a0bcaa PyEval_EvalFrameEx + 23753 (ceval.c:3836)
12  org.activestate.ActivePython26	0x12a0cbca PyEval_EvalCodeEx + 1973 (ceval.c:3000)
13  org.activestate.ActivePython26	0x12990d81 function_call + 162 (funcobject.c:524)
14  org.activestate.ActivePython26	0x12963b46 PyObject_Call + 77 (abstract.c:2492)
15  org.activestate.ActivePython26	0x12a08f3b PyEval_EvalFrameEx + 12122 (ceval.c:4063)
16  org.activestate.ActivePython26	0x12a0cbca PyEval_EvalCodeEx + 1973 (ceval.c:3000)
17  org.activestate.ActivePython26	0x12990d81 function_call + 162 (funcobject.c:524)
18  org.activestate.ActivePython26	0x12963b46 PyObject_Call + 77 (abstract.c:2492)
19  org.activestate.ActivePython26	0x12974615 instancemethod_call + 401 (classobject.c:2579)
20  org.activestate.ActivePython26	0x12963b46 PyObject_Call + 77 (abstract.c:2492)
21  org.activestate.ActivePython26	0x12968e47 PyObject_CallMethod + 154 (abstract.c:2524)
22  libpyxpcom.dylib              	0x0078cdde PyXPCOM_XPTStub::CallMethod(unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*) + 242

Even though the traceback is for ActivePython (that Komodo includes), this seems to happen with the official Python binaries as well: http://www.gossamer-threads.com/lists/python/python/844086

----------
assignee: ronaldoussoren
components: Interpreter Core, Macintosh
messages: 118449
nosy: ronaldoussoren, srid
priority: normal
severity: normal
status: open
title: dictobject.c: crash in Py_XDECREF
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Tue Oct 12 20:47:04 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 Oct 2010 18:47:04 +0000
Subject: [New-bugs-announce] [issue10075] Get session cache stats from
	SSLContext
In-Reply-To: <1286909224.78.0.82870617442.issue10075@psf.upfronthosting.co.za>
Message-ID: <1286909224.78.0.82870617442.issue10075@psf.upfronthosting.co.za>


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

This patch adds a method to query the session cache statistics from an SSL context. See http://www.openssl.org/docs/ssl/SSL_CTX_set_session_cache_mode.html# for more info.

----------
components: Library (Lib)
files: sslstats.patch
keywords: patch
messages: 118455
nosy: giampaolo.rodola, janssen, jcea, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Get session cache stats from SSLContext
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file19199/sslstats.patch

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

From report at bugs.python.org  Tue Oct 12 22:45:24 2010
From: report at bugs.python.org (Michael Shields)
Date: Tue, 12 Oct 2010 20:45:24 +0000
Subject: [New-bugs-announce] [issue10076] Regex objects became uncopyable in
	2.5
In-Reply-To: <1286916324.24.0.772801528988.issue10076@psf.upfronthosting.co.za>
Message-ID: <1286916324.24.0.772801528988.issue10076@psf.upfronthosting.co.za>


New submission from Michael Shields <mshields at google.com>:

For many years now, the sre module has provided __copy__ and __deepcopy__ modules that raise an exception ("cannot copy this pattern object") by default, with an #ifdef to enable their implementations.  Until Python 2.5, these were simply unused.  Since then, deepcopying these objects fails, instead of falling back to the default implementation.

Python 2.4.6 (#1, Nov 23 2009, 03:28:22)
[GCC 4.2.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import re
>>> x = [re.compile('.*')]
>>> import copy
>>> copy.deepcopy(x)
[<_sre.SRE_Pattern object at 0x7f3e9411e168>]

Python 2.6.2 (r262:71600, Jul 24 2009, 17:29:21)
[GCC 4.2.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import re
>>> x = [re.compile('.*')]
>>> import copy
>>> copy.deepcopy(x)
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
 File "/usr/grte/v1/k8-linux/lib/python2.6/copy.py", line 162, in deepcopy
   y = copier(x, memo)
 File "/usr/grte/v1/k8-linux/lib/python2.6/copy.py", line 228, in _deepcopy_list
   y.append(deepcopy(a, memo))
 File "/usr/grte/v1/k8-linux/lib/python2.6/copy.py", line 173, in deepcopy
   y = copier(memo)
TypeError: cannot deepcopy this pattern object

I'll attach a patch against 2.7 to correct this.

----------
components: Library (Lib)
messages: 118469
nosy: Michael.Shields
priority: normal
severity: normal
status: open
title: Regex objects became uncopyable in 2.5
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7

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

From report at bugs.python.org  Wed Oct 13 00:47:59 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Oct 2010 22:47:59 +0000
Subject: [New-bugs-announce] [issue10077] Python 3.1: site error is not
	logged
In-Reply-To: <1286923679.0.0.360055889779.issue10077@psf.upfronthosting.co.za>
Message-ID: <1286923679.0.0.360055889779.issue10077@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

If the site module fails, the error is not logged because of a bug in initsite(). The problem is that PyFile_WriteString() does nothing if an error occurred.

 - Edit Lib/site.py to add "raise Exception('xxx')" at the beginning of main()
 - Run ./python
 - (no error is logged)

In verbose mode, only the exception is logged, without the first line:

  'import site' failed; traceback:

Attached patch fixes both issues.

--

This issue is specific to Python 3.1:
 - Python 2.7 and 3.2 consider site error as a fatal error 
 - Python 2.6 doesn't have the bug because PyFile_WriteString() write the message even if an error occurred

----------
components: Library (Lib)
files: site_error.patch
keywords: patch
messages: 118478
nosy: haypo
priority: normal
severity: normal
status: open
title: Python 3.1: site error is not logged
versions: Python 3.1
Added file: http://bugs.python.org/file19207/site_error.patch

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

From report at bugs.python.org  Wed Oct 13 01:05:35 2010
From: report at bugs.python.org (Retro)
Date: Tue, 12 Oct 2010 23:05:35 +0000
Subject: [New-bugs-announce] [issue10078] Documentation: 'Postive' should be
	'Positive'
In-Reply-To: <1286924735.29.0.0342537376676.issue10078@psf.upfronthosting.co.za>
Message-ID: <1286924735.29.0.0342537376676.issue10078@psf.upfronthosting.co.za>


New submission from Retro <vinetouu at gmail.com>:

There's a typo in the docs. Please follow http://docs.python.org/py3k/library/string.html#format-specification-mini-language and find the below text, and fix the word 'Postive' to 'Positive', indicated between >>> and <<<:

'g'	
General format. For a given precision p >= 1, this rounds the number to p significant digits and then formats the result in either fixed-point format or in scientific notation, depending on its magnitude.

The precise rules are as follows: suppose that the result formatted with presentation type 'e' and precision p-1 would have exponent exp. Then if -4 <= exp < p, the number is formatted with presentation type 'f' and precision p-1-exp. Otherwise, the number is formatted with presentation type 'e' and precision p-1. In both cases insignificant trailing zeros are removed from the significand, and the decimal point is also removed if there are no remaining digits following it.

>>>Postive<<< and negative infinity, positive and negative zero, and nans, are formatted as inf, -inf, 0, -0 and nan respectively, regardless of the precision.

A precision of 0 is treated as equivalent to a precision of 1.

----------
assignee: docs at python
components: Documentation
messages: 118482
nosy: Retro, docs at python
priority: normal
severity: normal
status: open
title: Documentation: 'Postive' should be 'Positive'
versions: 3rd party, Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Oct 13 05:19:56 2010
From: report at bugs.python.org (Bruce Sherwood)
Date: Wed, 13 Oct 2010 03:19:56 +0000
Subject: [New-bugs-announce] [issue10079] idlelib for Python 3 with
	Guilherme Polo GSoC	enhancements
In-Reply-To: <1286939996.87.0.346411752414.issue10079@psf.upfronthosting.co.za>
Message-ID: <1286939996.87.0.346411752414.issue10079@psf.upfronthosting.co.za>


New submission from Bruce Sherwood <bruce.sherwood at gmail.com>:

It is proposed to incorporate the work of Guilherme Polo in the 2009
Google Summer of Code into idlelib. Polo's enhancements have been
extensively tested for a year through being included with VPython.

Here is a description from NEWS.txt:

In December 2008 David Scherer created an alternative version
of IDLE to fix some long-standing problems. In the 2009 Google
Summer of Code Guilherme Polo continued this work, assisted by
Bruce Sherwood. Important new fixes and features include:

 * A configuration preference that permits writing and running
   test programs from the editor without having to save the file
   (you're warned upon quitting whether to save).

 * Bringing the shell window forward in case of an error (because
   novices often failed to realize why their program had stopped).
 * A revert plug-in (FileRevert.py).

 * Unreliable and slow termination of user program on Windows;
   now you can re-run without first closing the graphics window.

 * Missing preferences and other menus on Macintosh.

 * Use any port for RPC server, so multiple instances of VIDLE
   can run at the same time without interference.

Polo submitted patches at the end of the summer of 2009, found at
code.google.com/p/google-summer-of-code-2009-python/downloads/list
This was for the Python 2.X series.

Because the mechanism was not clear for getting these patches
into the version of IDLE distributed with Python, the patched
version has been distributed with VPython (vpython.org) with
the name VIDLE to attempt to avoid confusion with IDLE. It is
installed into site-packages.

In October 2010 Bruce Sherwood manually applied Polo's patches
to the idlelib found at 
   svn.python.org/projects/python/tags/r312/Lib/idlelib 

In addition to applying Polo's patches, the new code uses the new
dot addressing of modules (e.g. from . import PyShell). Except for
having to change one absolute address in the use of __import__ in
PyShell.py, this version can work either in Python31/Lib/idlelib or
in Python31/Lib/site-packages/vidle. This VIDLE will be included in
the installer for VPython for Python 3.

----------
components: IDLE
files: vidle20101012.diff
keywords: patch
messages: 118501
nosy: Bruce.Sherwood
priority: normal
severity: normal
status: open
title: idlelib for Python 3 with Guilherme Polo GSoC enhancements
type: feature request
versions: Python 3.1
Added file: http://bugs.python.org/file19211/vidle20101012.diff

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

From report at bugs.python.org  Wed Oct 13 06:11:15 2010
From: report at bugs.python.org (Mitchell Stokes)
Date: Wed, 13 Oct 2010 04:11:15 +0000
Subject: [New-bugs-announce] [issue10080] Py_Initialize crashes when stdout
	has been redirected	with freopen
In-Reply-To: <1286943075.1.0.984332542932.issue10080@psf.upfronthosting.co.za>
Message-ID: <1286943075.1.0.984332542932.issue10080@psf.upfronthosting.co.za>


New submission from Mitchell Stokes <mogurijin at gmail.com>:

I have Python embedded in a C/C++ program, and I'm trying to redirect stdout to a text file. Since I'm trying to get rid of the console, I want C and Python stdout going to the text file (so, not sys.stdout = open('log.txt', 'w')). To this end, I used freopen() like so:

freopen("log.txt", "w", stdout);

to redirect stdout in C. However, when using Python 3.1, I get the following error:

Fatal Python error: Py_Initialize: can't initialize sys standard streams
OSError: [Errno 9] Bad file descriptor

followed by a crash (Runtime Error). I think this is somewhat related to this bug: http://bugs.python.org/issue1415

I've attached a sample program that illustrates the problem. I compiled it with:

gcc -o py_main.exe py_main.c -IC:\Python31\include -LC:\Python31\libs -lpython31

I had someone test the sample program on Linux, and it worked fine there, so I think it's a Windows issue.

----------
components: Windows
files: py_main.c
messages: 118502
nosy: Mitchell.Stokes
priority: normal
severity: normal
status: open
title: Py_Initialize crashes when stdout has been redirected with freopen
type: crash
versions: Python 3.1
Added file: http://bugs.python.org/file19212/py_main.c

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

From report at bugs.python.org  Wed Oct 13 10:32:50 2010
From: report at bugs.python.org (Valery Lesin)
Date: Wed, 13 Oct 2010 08:32:50 +0000
Subject: [New-bugs-announce] [issue10081] 'import' operator doesn't work
	with unicode non 7-bit	ASCII module names (OS: windows)
In-Reply-To: <1286958770.12.0.126097151739.issue10081@psf.upfronthosting.co.za>
Message-ID: <1286958770.12.0.126097151739.issue10081@psf.upfronthosting.co.za>


New submission from Valery Lesin <valery.lesin at gmail.com>:

OS: windows

The attempt to import module with non 7-bit ASCII name results in 
'ImportError: No module named <module name>' exception.


Some thoughts: import.c uses functions like fopen, stat and FindFirstFile which wouldn't work correctly with non 7-bit ASCII filenames in Windows.

----------
components: Interpreter Core, Unicode
messages: 118505
nosy: Valery.Lesin
priority: normal
severity: normal
status: open
title: 'import' operator doesn't work with unicode non 7-bit ASCII module names (OS: windows)
type: behavior
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed Oct 13 10:50:03 2010
From: report at bugs.python.org (Valery Lesin)
Date: Wed, 13 Oct 2010 08:50:03 +0000
Subject: [New-bugs-announce] [issue10082] PyRun_SimpleFile crashes
	application
In-Reply-To: <1286959803.51.0.331487773868.issue10082@psf.upfronthosting.co.za>
Message-ID: <1286959803.51.0.331487773868.issue10082@psf.upfronthosting.co.za>


New submission from Valery Lesin <valery.lesin at gmail.com>:

All the functions in Python/C API for file execution (like PyRun_SimpleFile) crash the application.

Some thoughts about problem: these functions use FILE* as first parameter which is binary incompatible with different CRT (python.dll and application could use different ones). 

Some thoughts about solution: maybe it's possible to pass only filename and python will open (and close) file itself? Second idea is to use functions like PyFile_FromString (like in Python 2)

----------
components: Extension Modules, Windows
messages: 118506
nosy: Valery.Lesin
priority: normal
severity: normal
status: open
title: PyRun_SimpleFile crashes application
type: crash
versions: Python 3.1

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

From report at bugs.python.org  Wed Oct 13 12:36:27 2010
From: report at bugs.python.org (=?utf-8?q?Bram_Mari=C3=ABn?=)
Date: Wed, 13 Oct 2010 10:36:27 +0000
Subject: [New-bugs-announce] [issue10083] locale.currency() uses different
	formatting than system	locale for negative values
In-Reply-To: <1286966187.73.0.144936729531.issue10083@psf.upfronthosting.co.za>
Message-ID: <1286966187.73.0.144936729531.issue10083@psf.upfronthosting.co.za>


New submission from Bram Mari?n <bram.marien at gmail.com>:

On Windows Vista and Windows 7 (XP and Ubuntu seem ok):

If the system locale is used (using locale.setlocale(LC_ALL, '') and the system locale is set to dutch belgium: 
If the regional options are set to format negative monetary items as "<EURO sign> -<value>", than locale.currency(value) will format it as "<EURO sign)value-".

Other formatting options works ok: e.g. if the regional settings display negative monetary items as "(value)", than "locale.currency(value)" will also display "{value)".

Reproducable on Python 2.6.x, 2.7.x and 3.1.2 on Windows Vista (32 bit)

----------
components: Windows
files: locale_currency_negative.JPG
messages: 118509
nosy: bram.marien
priority: normal
severity: normal
status: open
title: locale.currency() uses different formatting than system locale for negative values
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1
Added file: http://bugs.python.org/file19213/locale_currency_negative.JPG

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

From report at bugs.python.org  Wed Oct 13 15:09:12 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Oct 2010 13:09:12 +0000
Subject: [New-bugs-announce] [issue10084] SSL support for asyncore
In-Reply-To: <1286975352.23.0.354014332486.issue10084@psf.upfronthosting.co.za>
Message-ID: <1286975352.23.0.354014332486.issue10084@psf.upfronthosting.co.za>


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

It might be useful to make public the SSL support for asyncore which is currently implemented in various tests.

----------
assignee: giampaolo.rodola
components: Library (Lib)
messages: 118519
nosy: giampaolo.rodola, pitrou
priority: normal
severity: normal
status: open
title: SSL support for asyncore
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Wed Oct 13 16:19:09 2010
From: report at bugs.python.org (=?utf-8?b?0JDQvdC00YDQtdC5INCU0LDQstGL0LTQvtCy?=)
Date: Wed, 13 Oct 2010 14:19:09 +0000
Subject: [New-bugs-announce] [issue10085] Memory allocation for primitive
	types
In-Reply-To: <1286979549.85.0.436821167858.issue10085@psf.upfronthosting.co.za>
Message-ID: <1286979549.85.0.436821167858.issue10085@psf.upfronthosting.co.za>


New submission from ?????? ??????? <andrey.a.davydov at gmail.com>:

Output for this script is

8.64453125
in test 163.80078125
in f 318.70703125
after f 280.49609375
in f 318.72265625
after f 280.50390625
0
164.4765625
126.26171875
10.01171875

If Python store all created objects of primitive types, why does it allocate (318 - 163) MB for call of function 'f'?
What memory does it free when call 'gc.collect()'

----------
components: None
files: memory.py
messages: 118523
nosy: ??????.???????
priority: normal
severity: normal
status: open
title: Memory allocation for primitive types
type: resource usage
versions: Python 2.6
Added file: http://bugs.python.org/file19215/memory.py

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

From report at bugs.python.org  Wed Oct 13 16:39:23 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Wed, 13 Oct 2010 14:39:23 +0000
Subject: [New-bugs-announce] [issue10086] test_sysconfig failure with
	site-packages
In-Reply-To: <1286980763.58.0.308351769071.issue10086@psf.upfronthosting.co.za>
Message-ID: <1286980763.58.0.308351769071.issue10086@psf.upfronthosting.co.za>


New submission from Hallvard B Furuseth <h.b.furuseth at usit.uio.no>:

test_sysconfig on Python 3.2a3 fails with AssertionError:
'/home/sjef/.local/lib/python3.2/site-packages' !=
'/home/sjef/.local/lib/python3.2/home/sjef/.local-packages'

Python-3.2a3$ ./python Lib/test/regrtest.py -v test_sysconfig
== CPython 3.2a3 (r32a3:85355, Oct 13 2010, 07:34:15) [GCC 4.4.3]
==   Linux-2.6.32-25-generic-x86_64-with-debian-squeeze-sid little-endian
==   /home/sjef/src/python/Python-3.2a3/build/test_python_17497
[1/1] test_sysconfig
test_get_config_h_filename (test.test_sysconfig.TestSysConfig) ... ok
test_get_config_vars (test.test_sysconfig.TestSysConfig) ... ok
test_get_makefile_filename (test.test_sysconfig.TestSysConfig) ... ok
test_get_path (test.test_sysconfig.TestSysConfig) ... ok
test_get_path_names (test.test_sysconfig.TestSysConfig) ... ok
test_get_paths (test.test_sysconfig.TestSysConfig) ... ok
test_get_platform (test.test_sysconfig.TestSysConfig) ... ok
test_get_scheme_names (test.test_sysconfig.TestSysConfig) ... ok
test_ldshared_value (test.test_sysconfig.TestSysConfig) ... ok
test_main (test.test_sysconfig.TestSysConfig) ... ok
test_symlink (test.test_sysconfig.TestSysConfig) ... ok
test_user_similar (test.test_sysconfig.TestSysConfig) ... FAIL

======================================================================
FAIL: test_user_similar (test.test_sysconfig.TestSysConfig)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/sjef/src/python/Python-3.2a3/Lib/test/test_sysconfig.py", line 278, in test_user_similar
    self.assertEquals(user_path, global_path.replace(base, user))
AssertionError: '/home/sjef/.local/lib/python3.2/site-packages' != '/home/sjef/.local/lib/python3.2/home/sjef/.local-packages'
- /home/sjef/.local/lib/python3.2/site-packages
?                                  ^^
+ /home/sjef/.local/lib/python3.2/home/sjef/.local-packages
?                                 +++++ ^ ++++++++


----------------------------------------------------------------------
Ran 12 tests in 0.145s

FAILED (failures=1)
test test_sysconfig failed -- Traceback (most recent call last):
  File "/home/sjef/src/python/Python-3.2a3/Lib/test/test_sysconfig.py", line 278, in test_user_similar
    self.assertEquals(user_path, global_path.replace(base, user))
AssertionError: '/home/sjef/.local/lib/python3.2/site-packages' != '/home/sjef/.local/lib/python3.2/home/sjef/.local-packages'
- /home/sjef/.local/lib/python3.2/site-packages
?                                  ^^
+ /home/sjef/.local/lib/python3.2/home/sjef/.local-packages
?                                 +++++ ^ ++++++++


1 test failed:
    test_sysconfig

----------
components: Tests
messages: 118525
nosy: hfuru
priority: normal
severity: normal
status: open
title: test_sysconfig failure with site-packages
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Wed Oct 13 17:43:28 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 13 Oct 2010 15:43:28 +0000
Subject: [New-bugs-announce] [issue10087] HTML calendar is broken
In-Reply-To: <1286984608.4.0.168516535909.issue10087@psf.upfronthosting.co.za>
Message-ID: <1286984608.4.0.168516535909.issue10087@psf.upfronthosting.co.za>


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

$ python3 -m calendar --type=html 2010

Produces HTML which renders into the attached PDF file.  It looks like bytes vs. strings issue.

----------
assignee: belopolsky
components: Library (Lib)
files: Calendar for 2010.pdf
messages: 118532
nosy: belopolsky
priority: normal
severity: normal
stage: unit test needed
status: open
title: HTML calendar is broken
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file19216/Calendar for 2010.pdf

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

From report at bugs.python.org  Wed Oct 13 18:01:24 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 13 Oct 2010 16:01:24 +0000
Subject: [New-bugs-announce] [issue10088] pdb can't re-set variables
In-Reply-To: <1286985684.86.0.916625287507.issue10088@psf.upfronthosting.co.za>
Message-ID: <1286985684.86.0.916625287507.issue10088@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

Not sure if this is on purpose but I've lost quite some time to debug this problem.

--- code ---

def foo():
    bar = 1
    import pdb; pdb.set_trace()   
foo()


--- pdb session ---

(Pdb) dir()
['__return__', 'bar', 'pdb']
(Pdb) bar
1
(Pdb) bar = 2
(Pdb) bar
1
(Pdb) 


If this is on purpose (pdb just CAN'T do it) then I would expect it to display an error of some kind when I enter "bar = 2", say: "*** NameError: 'foo' is a reserved name".

----------
messages: 118534
nosy: giampaolo.rodola
priority: normal
severity: normal
status: open
title: pdb can't re-set variables

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

From report at bugs.python.org  Wed Oct 13 21:01:40 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Oct 2010 19:01:40 +0000
Subject: [New-bugs-announce] [issue10089] Add support for arbitrary -X
	options
In-Reply-To: <1286996500.23.0.0250789164181.issue10089@psf.upfronthosting.co.za>
Message-ID: <1286996500.23.0.0250789164181.issue10089@psf.upfronthosting.co.za>


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

It can be useful to enable or disable global Python features based on command-line flags. The -X is supposed to allow implementation-specific options but it is currently disabled for CPython. This patch allows to use -X for arbitrary options in CPython. These options are not validated but minimally parsed and fed into a dictionary, sys.xoptions. An example is better than a thousand words:

$ ./python -c "import sys; print(sys.xoptions)"
{}
$ ./python -Xa,b=c,d -Xe,f=g=h -c "import sys; print(sys.xoptions)"
{'a': True, 'b': 'c', 'e': True, 'd': True, 'f': 'g=h'}


This could be useful for various debug enablers, such as Victor's SIGSEGV handler, warnings about unclosed files, etc.

----------
components: Interpreter Core
files: xopts.patch
keywords: patch
messages: 118563
nosy: haypo, loewis, ncoghlan, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Add support for arbitrary -X options
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file19221/xopts.patch

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

From report at bugs.python.org  Wed Oct 13 21:33:12 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 13 Oct 2010 19:33:12 +0000
Subject: [New-bugs-announce] [issue10090] python -m locale fails on OSX
In-Reply-To: <1286998392.83.0.0924618610068.issue10090@psf.upfronthosting.co.za>
Message-ID: <1286998392.83.0.0924618610068.issue10090@psf.upfronthosting.co.za>


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

$ python -m locale
Locale aliasing:

Locale defaults as determined by getdefaultlocale():
------------------------------------------------------------------------
Language:  en_US
Encoding:  UTF8
..

Locale settings after calling resetlocale():
------------------------------------------------------------------------
Traceback (most recent call last):
 ..

  File "Lib/locale.py", line 548, in resetlocale
    _setlocale(category, _build_localename(getdefaultlocale()))
locale.Error: unsupported locale setting


Apparently the problem is due to locale.getdefaultlocale() returning encoding as 'UTF8' while locale.setlocale() expects 'UTF-8'.

----------
components: Library (Lib)
messages: 118567
nosy: belopolsky
priority: normal
severity: normal
stage: unit test needed
status: open
title: python -m locale fails on OSX
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed Oct 13 21:36:42 2010
From: report at bugs.python.org (nestor)
Date: Wed, 13 Oct 2010 19:36:42 +0000
Subject: [New-bugs-announce] [issue10091] ast.literal_eval does not handled
	new set literals
In-Reply-To: <1286998602.58.0.486068120725.issue10091@psf.upfronthosting.co.za>
Message-ID: <1286998602.58.0.486068120725.issue10091@psf.upfronthosting.co.za>


New submission from nestor <nestornissen at gmail.com>:

>>> import ast
>>> eval('{1:11,2:22}')
{1: 11, 2: 22}
>>> ast.literal_eval('{1:11,2:22}')
{1: 11, 2: 22}

>>> eval('{1,2}')
{1, 2}
>>> ast.literal_eval('{1,2}')
Traceback (most recent call last):
  File "<pyshell#8>", line 1, in <module>
    ast.literal_eval('{1,2}')
  File "C:\Python31\lib\ast.py", line 80, in literal_eval
    return _convert(node_or_string)
  File "C:\Python31\lib\ast.py", line 79, in _convert
    raise ValueError('malformed string')
ValueError: malformed string

>>> 

I haven't tested for 2.7 or 3.2 but this bug probably applies also there.

----------
components: Library (Lib)
messages: 118568
nosy: aronacher, benjamin.peterson, georg.brandl, gpolo, mark.dickinson, nestor, rhettinger, terry.reedy
priority: normal
severity: normal
status: open
title: ast.literal_eval does not handled new set literals
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Wed Oct 13 21:53:36 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 13 Oct 2010 19:53:36 +0000
Subject: [New-bugs-announce] [issue10092] calendar does not restore locale
	properly
In-Reply-To: <1286999616.97.0.806385422046.issue10092@psf.upfronthosting.co.za>
Message-ID: <1286999616.97.0.806385422046.issue10092@psf.upfronthosting.co.za>


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

>>> import calendar
>>> calendar.TextCalendar().formatmonthname(2010,10,10)
'October 2010'
>>> calendar.LocaleTextCalendar(locale='fr_FR').formatmonthname(2010,10,10)
'octobre 2010'
>>> calendar.TextCalendar().formatmonthname(2010,10,10)
'octobre 2010'

----------
messages: 118570
nosy: belopolsky
priority: normal
severity: normal
stage: unit test needed
status: open
title: calendar does not restore locale properly

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

From report at bugs.python.org  Wed Oct 13 22:16:29 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Oct 2010 20:16:29 +0000
Subject: [New-bugs-announce] [issue10093] Warn when files are not explicitly
	closed
In-Reply-To: <1287000989.52.0.725529628819.issue10093@psf.upfronthosting.co.za>
Message-ID: <1287000989.52.0.725529628819.issue10093@psf.upfronthosting.co.za>


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

This patch outputs a warning on file deallocation when it hasn't been explicitly closed by the programmer.

Printing the warning by default is probably not desirable, but using the patch for "-X" options in issue10089 would allow to switch on when necessary.

----------
components: Extension Modules, Interpreter Core
files: deallocwarn.patch
keywords: patch
messages: 118577
nosy: pitrou
priority: normal
severity: normal
status: open
title: Warn when files are not explicitly closed
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file19224/deallocwarn.patch

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

From report at bugs.python.org  Thu Oct 14 00:46:22 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 13 Oct 2010 22:46:22 +0000
Subject: [New-bugs-announce] [issue10094] test_urllib.py fails in py3k
	r85440 with RuntimeError
In-Reply-To: <1287009982.88.0.0149254747743.issue10094@psf.upfronthosting.co.za>
Message-ID: <1287009982.88.0.0149254747743.issue10094@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

Running the test suite on py3k r85440, I get the following failure:


======================================================================
ERROR: test_getproxies_environment_keep_no_proxies (__main__.ProxyTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_urllib.py", line 121, in setUp
    for k in os.environ.keys():
  File "/home/barry/projects/python/py3k/Lib/_abcoll.py", line 410, in __iter__
    for key in self._mapping:
  File "/home/barry/projects/python/py3k/Lib/os.py", line 441, in __iter__
    for key in self._data:
RuntimeError: dictionary changed size during iteration

This is consistent (i.e. fails every time) on Ubuntu 10.10 amd64.

----------
components: Library (Lib)
messages: 118598
nosy: barry
priority: normal
severity: normal
status: open
title: test_urllib.py fails in py3k r85440 with RuntimeError
versions: Python 3.2

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

From report at bugs.python.org  Thu Oct 14 01:52:58 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Oct 2010 23:52:58 +0000
Subject: [New-bugs-announce] [issue10095] Support undecodable filenames in
	the parser API
In-Reply-To: <1287013978.13.0.815823866511.issue10095@psf.upfronthosting.co.za>
Message-ID: <1287013978.13.0.815823866511.issue10095@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

It looks like the parser API (eg. PyParser_ParseFileFlagsEx, PyParser_ASTFromFile) expects utf-8 filename: err_input() decodes the filename from utf-8. But 

Example in a non-ascii directory (/home/SHARE/SVN/py3k??) and an ascii locale:
----
$ LANG= ./python -c "import inspect"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/SHARE/SVN/py3k\xe9\u0141/Lib/inspect.py", line 1
SyntaxError: encoding problem: with BOM
----

The problem occurs in fp_setreadl(): this function reopens the file with the right encoding. But to open the file, the bytes filename is decoded from utf-8 (in strict mode), whereas the filename (in my example) contains surrogates and utf-8 in strict mode rejects surrogates.

To support undecodable filenames in the parser API, we have two solutions:

 * Use the filesystem encoding with surrogateescape (PyUnicode_EncodeFSDefault, PyUnicode_DecodeFSDefault)
 * Use utf-8 in another mode: surrogateescape or surrogatepass

The parser API has many public functions, and we have to consider the compatibility with Python 3.1.

See also #9713 and #8611.

----------
components: Interpreter Core, Unicode
messages: 118604
nosy: haypo
priority: normal
severity: normal
status: open
title: Support undecodable filenames in the parser API
versions: Python 3.2

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

From report at bugs.python.org  Thu Oct 14 07:29:35 2010
From: report at bugs.python.org (Pramod T Sridhar)
Date: Thu, 14 Oct 2010 05:29:35 +0000
Subject: [New-bugs-announce] [issue10096] Question regarding python migration
In-Reply-To: <1287034175.54.0.655150007041.issue10096@psf.upfronthosting.co.za>
Message-ID: <1287034175.54.0.655150007041.issue10096@psf.upfronthosting.co.za>


New submission from Pramod T Sridhar <pramod.sridhar at nxp.com>:

Hi All,

We have a Python based test framework which is being used in various projects.

Our current environment is 
Python (ver 2.5.1)
wxPython (wxPython2.8-win32-ansi-2.8.6.0-py25)
pywin32-210.win32-py2.5
vcredist_x86.exe
pyserial-2.2

Our Framework is being currently used in Windows XP.

The issue is:
Soon our environment will be migrated from Windows XP to Windows 7.
In this regard, I would be in need of suggestions/ideas/information
regarding migration of our existing framework into windows 7 environment.

Do i need to migrate our framework from Python 2.5 to either Python 2.6 or directly to Python 3.0 ? What happens to all supporting packages..etc

Which is the best way ?

We tried out of some option of using our framework under virtual xp context of windows 7.Thou it works for timebeing,i am not interested to having the same as kind of way of working for future.

Please help

Many thanks in advance

- Pramod

----------
messages: 118612
nosy: pramod.ts
priority: normal
severity: normal
status: open
title: Question regarding python migration
type: performance
versions: Python 2.5

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

From report at bugs.python.org  Thu Oct 14 08:10:13 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 14 Oct 2010 06:10:13 +0000
Subject: [New-bugs-announce] [issue10097] platform.uname gives UnicodeError
	for non-ASCII computer	names on Windows
In-Reply-To: <1287036613.43.0.313046805894.issue10097@psf.upfronthosting.co.za>
Message-ID: <1287036613.43.0.313046805894.issue10097@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

Reportedly, platform.uname gives UnicodeError for non-ASCII computer names on Windows, see http://www.pasteall.org/16215

I think it is incorrect that _node uses socket.gethostname on Windows. uname() should return the local hostname (i.e. the one that the system itself believes to have), independent of the network configuration or DNS.

Therefore, I think it should return the COMPUTERNAME environment variable, or the result of the GetComputerName() API.

----------
messages: 118615
nosy: loewis
priority: normal
severity: normal
status: open
title: platform.uname gives UnicodeError for non-ASCII computer names on Windows
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Oct 14 10:34:30 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Oct 2010 08:34:30 +0000
Subject: [New-bugs-announce] [issue10098] intermittent failure in test_os
In-Reply-To: <1287045270.71.0.765573711319.issue10098@psf.upfronthosting.co.za>
Message-ID: <1287045270.71.0.765573711319.issue10098@psf.upfronthosting.co.za>


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

The Windows 7 buildbot sometimes shows a failure in test_os:

test test_os failed -- Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_os.py", line 1080, in test_CTRL_BREAK_EVENT
    self._kill_with_event(signal.CTRL_BREAK_EVENT, "CTRL_BREAK_EVENT")
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_os.py", line 1058, in _kill_with_event
    self.fail("subprocess did not stop on {}".format(name))
AssertionError: subprocess did not stop on CTRL_BREAK_EVENT

http://www.python.org/dev/buildbot/3.x.stable/builders/x86%20Windows7%203.x/builds/1755/steps/test/logs/stdio

----------
components: Tests, Windows
messages: 118634
nosy: brian.curtin, db3l, pitrou, tim.golden
priority: normal
severity: normal
status: open
title: intermittent failure in test_os
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Thu Oct 14 10:42:45 2010
From: report at bugs.python.org (=?utf-8?q?K=C3=A1lm=C3=A1n_Gergely?=)
Date: Thu, 14 Oct 2010 08:42:45 +0000
Subject: [New-bugs-announce] [issue10099] socket.fromfd() documentation
	problem
In-Reply-To: <1287045765.45.0.437204596645.issue10099@psf.upfronthosting.co.za>
Message-ID: <1287045765.45.0.437204596645.issue10099@psf.upfronthosting.co.za>


New submission from K?lm?n Gergely <kalman.gergely at duodecad.hu>:

socket.fromfd()'s behaviour is somewhat counter-intutive and should contain a note to warn the user that it'll leave the original FD open. This is important if someone forgets to manually close the file descriptor as it might lead to FD leaks (and kernel memory leaks). This is especially the case when there is no python object associated with the FD, so no destruction will take place.

patch applies to this:
http://docs.python.org/py3k/archives/python-3.1.2-docs-html.tar.bz2

The only thing it does is that it adds a note section with the following message: "The original file descriptor will not be closed."

synapse

----------
assignee: docs at python
components: Documentation
files: fromfd_doc.patch
keywords: patch
messages: 118637
nosy: docs at python, synapse
priority: normal
severity: normal
status: open
title: socket.fromfd() documentation problem
type: feature request
versions: Python 3.1
Added file: http://bugs.python.org/file19230/fromfd_doc.patch

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

From report at bugs.python.org  Thu Oct 14 12:53:09 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 14 Oct 2010 10:53:09 +0000
Subject: [New-bugs-announce] [issue10100] fromfd is now available on all
	platforms
In-Reply-To: <1287053589.11.0.994213576919.issue10100@psf.upfronthosting.co.za>
Message-ID: <1287053589.11.0.994213576919.issue10100@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

fromfd is marked as Availability: Unix, but in Python 3 it is also available on Windows:

C:\>c:\python31\python.exe
Python 3.1 (r31:73574, Jun 26 2009, 20:21:35) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> socket.fromfd
<function fromfd at 0x00B9FBB8>

The following lines can also be removed from testFromFd:

        if not hasattr(socket, "fromfd"):
            return # On Windows, this doesn't exist

----------
assignee: docs at python
components: Documentation
messages: 118646
nosy: docs at python, stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: fromfd is now available on all platforms
type: behavior
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Oct 14 14:55:18 2010
From: report at bugs.python.org (Retro)
Date: Thu, 14 Oct 2010 12:55:18 +0000
Subject: [New-bugs-announce] [issue10101] a bug in built-in function round()
	?
In-Reply-To: <1287060918.13.0.131332755047.issue10101@psf.upfronthosting.co.za>
Message-ID: <1287060918.13.0.131332755047.issue10101@psf.upfronthosting.co.za>


New submission from Retro <vinetouu at gmail.com>:

>>> round(1.255, 2)
1.25

A bug in Python interpreter?


Shold have been:

>>> round(1.255, 2)
1.26

In mathematics, the .5 part is always rounded up, so in the example the .255 should be rounded to .26 so please fix this bug.

----------
components: Library (Lib)
messages: 118659
nosy: Retro
priority: normal
severity: normal
status: open
title: a bug in built-in function round() ?
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Oct 14 16:08:05 2010
From: report at bugs.python.org (Kevin Barnhart)
Date: Thu, 14 Oct 2010 14:08:05 +0000
Subject: [New-bugs-announce] [issue10102] mktime adding an hour in April
	(naive struct)?
In-Reply-To: <1287065285.33.0.306092502984.issue10102@psf.upfronthosting.co.za>
Message-ID: <1287065285.33.0.306092502984.issue10102@psf.upfronthosting.co.za>


New submission from Kevin Barnhart <barnburnr at gmail.com>:

Just starting to dabble in the world of time and datetime objects.  I was converting an array of datetime objects to an array of floats via mktime to do some data analysis.  I have ran into an issue where mktime seems to be adding an hour on April 6, 2003.  Attached is an example script which I used to create the below output:

Python version:  (2, 6, 5, 'final', 0)
Epoch:  time.struct_time(tm_year=1970, tm_mon=1, tm_mday=1, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=3, tm_yday=1, tm_isdst=0)
First datetime:  2003-04-06 02:58:17
Second datetime:  2003-04-06 03:13:17
Is first datetime prior to second?:  True
First datetime, time struct: time.struct_time(tm_year=2003, tm_mon=4, tm_mday=6, tm_hour=2, tm_min=58, tm_sec=17, tm_wday=6, tm_yday=96, tm_isdst=-1)
Second datetime, time struct: time.struct_time(tm_year=2003, tm_mon=4, tm_mday=6, tm_hour=3, tm_min=13, tm_sec=17, tm_wday=6, tm_yday=96, tm_isdst=-1)
Is first time struct prior to second?:  True
First timestamp generated by mktime:  1049623097.0
Second timestamp generated by mktime:  1049620397.0
Is first timestamp less than second timestamp?:  False
First recovered datetime:  2003-04-06 03:58:17
Second recovered datetime:  2003-04-06 03:13:17
Is first recovered prior to second recovered?:  False
Is first recovered datetime same as original?:  False
Is second recovered datetime same as original?:  True

----------
files: mktimeissue.py
messages: 118662
nosy: barnburnr
priority: normal
severity: normal
status: open
title: mktime adding an hour in April (naive struct)?
type: behavior
Added file: http://bugs.python.org/file19232/mktimeissue.py

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

From report at bugs.python.org  Thu Oct 14 17:16:40 2010
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 14 Oct 2010 15:16:40 +0000
Subject: [New-bugs-announce] [issue10103] use the SOABI for GNU/kfreeBSD and
	the GNU Hurd
In-Reply-To: <1287069400.41.0.250908287876.issue10103@psf.upfronthosting.co.za>
Message-ID: <1287069400.41.0.250908287876.issue10103@psf.upfronthosting.co.za>


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

use the SOABI for GNU/kfreeBSD and the GNU Hurd

afaik, the only distribution for GNU/kfreeBSD and the GNU Hurd currently is Debian, and Debian already has this turned on for Linux too.

----------
assignee: doko
components: Build
files: soabi.diff
keywords: needs review, patch
messages: 118665
nosy: doko
priority: normal
severity: normal
status: open
title: use the SOABI for GNU/kfreeBSD and the GNU Hurd
versions: Python 3.2
Added file: http://bugs.python.org/file19233/soabi.diff

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

From report at bugs.python.org  Thu Oct 14 18:09:33 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Oct 2010 16:09:33 +0000
Subject: [New-bugs-announce] [issue10104] test_socket failures on Debian
	unstable
In-Reply-To: <1287072573.8.0.312091305807.issue10104@psf.upfronthosting.co.za>
Message-ID: <1287072573.8.0.312091305807.issue10104@psf.upfronthosting.co.za>


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

This is following r85480 (issue #7523). It seems the Debian unstable system on one of the buildbots has SOCK_NONBLOCK and SOCK_CLOEXEC, but doesn't support creating sockets using these flags:

======================================================================
ERROR: testInitNonBlocking (test.test_socket.NonBlockingTCPTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/doko/buildarea/3.x.klose-debian-alpha/build/Lib/test/test_socket.py", line 914, in testInitNonBlocking
    socket.SOCK_NONBLOCK)
  File "/home/doko/buildarea/3.x.klose-debian-alpha/build/Lib/socket.py", line 94, in __init__
    _socket.socket.__init__(self, family, type, proto, fileno)
socket.error: [Errno 22] Invalid argument

======================================================================
ERROR: test_SOCK_CLOEXEC (test.test_socket.CloexecConstantTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/doko/buildarea/3.x.klose-debian-alpha/build/Lib/test/test_socket.py", line 1834, in test_SOCK_CLOEXEC
    socket.SOCK_STREAM | socket.SOCK_CLOEXEC)
  File "/home/doko/buildarea/3.x.klose-debian-alpha/build/Lib/socket.py", line 94, in __init__
    _socket.socket.__init__(self, family, type, proto, fileno)
socket.error: [Errno 22] Invalid argument

======================================================================
ERROR: test_SOCK_NONBLOCK (test.test_socket.NonblockConstantTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/doko/buildarea/3.x.klose-debian-alpha/build/Lib/test/test_socket.py", line 1854, in test_SOCK_NONBLOCK
    socket.SOCK_STREAM | socket.SOCK_NONBLOCK)
  File "/home/doko/buildarea/3.x.klose-debian-alpha/build/Lib/socket.py", line 94, in __init__
    _socket.socket.__init__(self, family, type, proto, fileno)
socket.error: [Errno 22] Invalid argument

(full log at http://www.python.org/dev/buildbot/3.x/builders/alpha%20Debian%203.x/builds/258/steps/test/logs/stdio)

----------
components: Tests
keywords: buildbot
messages: 118677
nosy: doko, lekma, nvetoshkin, pitrou
priority: normal
severity: normal
status: open
title: test_socket failures on Debian unstable
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Thu Oct 14 18:16:11 2010
From: report at bugs.python.org (RLS0812)
Date: Thu, 14 Oct 2010 16:16:11 +0000
Subject: [New-bugs-announce] [issue10105] Strings failing to print
In-Reply-To: <1287072971.15.0.392234959257.issue10105@psf.upfronthosting.co.za>
Message-ID: <1287072971.15.0.392234959257.issue10105@psf.upfronthosting.co.za>


New submission from RLS0812 <RLS0812 at YAHOO.COM>:

Attempting to print a string fails in 3.1.2, throwing up an "invalid syntax" 
 I included a screen shot with the same codes ran in 2.7 and 3.1.2 .

----------
components: None
files: 3_1_2_bug.jpg
messages: 118679
nosy: RLS0812
priority: normal
severity: normal
status: open
title: Strings failing to print
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file19234/3_1_2_bug.jpg

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

From report at bugs.python.org  Thu Oct 14 18:35:40 2010
From: report at bugs.python.org (S S)
Date: Thu, 14 Oct 2010 16:35:40 +0000
Subject: [New-bugs-announce] [issue10106] missing packages
In-Reply-To: <1287074140.25.0.416505470052.issue10106@psf.upfronthosting.co.za>
Message-ID: <1287074140.25.0.416505470052.issue10106@psf.upfronthosting.co.za>


New submission from S S <senya72 at gmail.com>:

when trying to install beutifulsoup package on windows xp x86 with python 2.6.6 getting the following error

C:\Python26>python C:\temp\BeautifulSoup-3.0.8.1\setup.py install
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "C:\temp\BeautifulSoup-3.0.8.1\setup.py", line 1, in <module>
    from distutils.core import setup
ImportError: No module named distutils.core


installing the same package with python 2.7 gives a different error about site module missing. 

these errors i am getting with any packages  installs actually.

----------
components: Installation
messages: 118685
nosy: S.S
priority: normal
severity: normal
status: open
title: missing packages
type: compile error
versions: Python 2.6

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

From report at bugs.python.org  Thu Oct 14 19:22:47 2010
From: report at bugs.python.org (Bruce Sherwood)
Date: Thu, 14 Oct 2010 17:22:47 +0000
Subject: [New-bugs-announce] [issue10107] Quitting IDLE on Mac doesn't save
	unsaved code
In-Reply-To: <1287076967.07.0.270311596559.issue10107@psf.upfronthosting.co.za>
Message-ID: <1287076967.07.0.270311596559.issue10107@psf.upfronthosting.co.za>


New submission from Bruce Sherwood <bruce.sherwood at gmail.com>:

It has just been discovered that at least since Python 2.6 on the Mac, quitting IDLE does not prompt to save unsaved code, which is then lost. The recently submitted diff for bringing Guilherme Polo's Google Summer of Code improvements into IDLE on Python 3 (ID 10079) does not fix the problem.

----------
components: IDLE
messages: 118697
nosy: Bruce.Sherwood
priority: normal
severity: normal
status: open
title: Quitting IDLE on Mac doesn't save unsaved code
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu Oct 14 23:54:30 2010
From: report at bugs.python.org (Leo Shklovskii)
Date: Thu, 14 Oct 2010 21:54:30 +0000
Subject: [New-bugs-announce] [issue10108] ExpatError not property wrapped
In-Reply-To: <1287093270.3.0.510777453712.issue10108@psf.upfronthosting.co.za>
Message-ID: <1287093270.3.0.510777453712.issue10108@psf.upfronthosting.co.za>


New submission from Leo Shklovskii <leos at thermopylae.net>:

>From my understanding of the documentation, the expected behavior is for xmlrpclib to raise an xmlrpclib.Fault wrapping the original error from whatever parser it chose to use if there's an error in parsing the response.

If, however, its using Expat under the hood and the response is completely blank, the ExpatError percolates up to the calling code unwrapped.

The following stack trace
/usr/lib/python2.6/xmlrpclib.pyc in __call__(self, *args)
   1197         return _Method(self.__send, "%s.%s" % (self.__name, name))
   1198     def __call__(self, *args):
-> 1199         return self.__send(self.__name, args)
   1200
   1201 ##


/usr/lib/python2.6/xmlrpclib.pyc in __request(self, methodname, params)
   1487             self.__handler,
   1488             request,
-> 1489             verbose=self.__verbose
   1490             )
   1491

/usr/lib/python2.6/xmlrpclib.pyc in request(self, host, handler, request_body, verbose)
   1251             sock = None
   1252
-> 1253         return self._parse_response(h.getfile(), sock)
   1254
   1255     ##


/usr/lib/python2.6/xmlrpclib.pyc in _parse_response(self, file, sock)
   1388
   1389         file.close()
-> 1390         p.close()
   1391
   1392         return u.close()

/usr/lib/python2.6/xmlrpclib.pyc in close(self)
    602
    603         def close(self):
--> 604             self._parser.Parse("", 1) # end of data
    605             del self._target, self._parser # get rid of circular references
    606

ExpatError: no element found: line 1, column 0

Please let me know if I'm misinterpreting the docs or if you need any other information to repro this bug.

----------
components: XML
messages: 118721
nosy: leos
priority: normal
severity: normal
status: open
title: ExpatError not property wrapped
type: behavior
versions: Python 2.6

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

From martin at v.loewis.de  Fri Oct 15 00:08:40 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 15 Oct 2010 00:08:40 +0200
Subject: [New-bugs-announce] [issue10108] ExpatError not property wrapped
In-Reply-To: <1287093270.3.0.510777453712.issue10108@psf.upfronthosting.co.za>
References: <1287093270.3.0.510777453712.issue10108@psf.upfronthosting.co.za>
Message-ID: <4CB77F68.6070802@v.loewis.de>

> From my understanding of the documentation, the expected behavior
> is for xmlrpclib to raise an xmlrpclib.Fault [...]

What specific wording in the documentation makes you thinks so?

If anything, I'd expect a ResponseError (which appears undocumented).

From report at bugs.python.org  Fri Oct 15 02:45:02 2010
From: report at bugs.python.org (Jeong-Min Lee)
Date: Fri, 15 Oct 2010 00:45:02 +0000
Subject: [New-bugs-announce] [issue10109] itertools.product with infinite
	iterator cause	MemoryError.
In-Reply-To: <1287103502.64.0.571191585998.issue10109@psf.upfronthosting.co.za>
Message-ID: <1287103502.64.0.571191585998.issue10109@psf.upfronthosting.co.za>


New submission from Jeong-Min Lee <falsetru at gmail.com>:

According to the documentation, itertools.product is equivalent to nested for-loops in a generator expression.
But, itertools.product(itertools.count(2010)) is not.

>>> import itertools
>>> (year for year in itertools.count(2010))
<generator object <genexpr> at 0x026367D8>
>>> itertools.product(itertools.count(2010))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
MemoryError

----------
components: Library (Lib)
messages: 118735
nosy: falsetru
priority: normal
severity: normal
status: open
title: itertools.product with infinite iterator cause MemoryError.
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Oct 15 03:25:05 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 15 Oct 2010 01:25:05 +0000
Subject: [New-bugs-announce] [issue10110] Queue doesn't recognize it is full
	after shrinking	maxsize
In-Reply-To: <1287105905.32.0.568830983004.issue10110@psf.upfronthosting.co.za>
Message-ID: <1287105905.32.0.568830983004.issue10110@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

The Queue object has a maxsize parameter and attribute, but due to the test for a full queue, shrinking the maxsize could result in the Queue not recognizing that it is full.

The attached patch (against the Python 3 trunk) demonstrates this limitation with a unit test and fixes the failing test case.

----------
files: shrinking_queue_not_full.patch
keywords: patch
messages: 118736
nosy: jaraco
priority: normal
severity: normal
status: open
title: Queue doesn't recognize it is full after shrinking maxsize
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file19240/shrinking_queue_not_full.patch

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

From report at bugs.python.org  Fri Oct 15 08:50:08 2010
From: report at bugs.python.org (Paul Bolle)
Date: Fri, 15 Oct 2010 06:50:08 +0000
Subject: [New-bugs-announce] [issue10111] Minor problems with PyFileObject
	documentation	(Doc/c-api/file.rst)
In-Reply-To: <1287125408.14.0.853619758536.issue10111@psf.upfronthosting.co.za>
Message-ID: <1287125408.14.0.853619758536.issue10111@psf.upfronthosting.co.za>


New submission from Paul Bolle <pebolle at tiscali.nl>:

0) I ran into some (small) problems with the documentation added by revision 62195 (see issue 815646 for background).

1) A small patch that addresses two problems with the Python 2.7 documentation should be attached:
- link three occurrences of "GIL" to the GIL entry in the glossary; and
- add some example code to clarify the usage of PyFile_IncUseCount() andPyFile_DecUseCount().

2) That patch also adds a link to the "Thread State and the Global Interpreter Lock" section to the GIL entry in the Documentation index. That is a separate problem. But fixing that minor problem could also be of help to people (like me) that need to better understand the GIL aspects of those two functions.

----------
assignee: docs at python
components: Documentation
files: python-2.7-Doc-gil.patch
keywords: patch
messages: 118742
nosy: docs at python, pebolle
priority: normal
severity: normal
status: open
title: Minor problems with PyFileObject documentation (Doc/c-api/file.rst)
versions: Python 2.7
Added file: http://bugs.python.org/file19241/python-2.7-Doc-gil.patch

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

From report at bugs.python.org  Fri Oct 15 12:16:25 2010
From: report at bugs.python.org (Jan Kratochvil)
Date: Fri, 15 Oct 2010 10:16:25 +0000
Subject: [New-bugs-announce] [issue10112] Use -Wl, --dynamic-list=x.list,
	not -Xlinker -export-dynamic
In-Reply-To: <1287137785.61.0.962664170792.issue10112@psf.upfronthosting.co.za>
Message-ID: <1287137785.61.0.962664170792.issue10112@psf.upfronthosting.co.za>


New submission from Jan Kratochvil <jan.kratochvil at redhat.com>:

FSF GDB (and future Fedora GDBs) became 250KB smaller than before.  Python recently disabled this GDB build optimization so GDB is 250KB larger again.

-rwxr-xr-x 1 4524488 gdb-7.1-19.fc13.x86_64/usr/bin/gdb
-rwxr-xr-x 1 4266728 gdb-7.1-19dynamiclist.fc13.x86_64/usr/bin/gdb
-rw-r--r-- 1 2364656 gdb-7.1-19.fc13.x86_64.rpm
-rw-r--r-- 1 2274300 gdb-7.1-19dynamiclist.fc13.x86_64.rpm

Some Python binaries/libraries could probably also benefit from smaller pageable code image.

GDB regressed due to /usr/lib*/python*/config/Makefile contains:
  LINKFORSHARED=-Xlinker -export-dynamic

and GDB thus has to use it even for its own link, effectively disabling its:
  -Wl,--dynamic-list=./proc-service.list

AFAIK Python already contains the required exports list but it is used only on MS-Windows.  It should be utilized even for GNU/Linux builds.

----------
components: Library (Lib)
messages: 118756
nosy: dmalcolm, jankratochvil
priority: normal
severity: normal
status: open
title: Use -Wl,--dynamic-list=x.list, not -Xlinker -export-dynamic
type: resource usage
versions: Python 3.2

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

From report at bugs.python.org  Fri Oct 15 12:57:52 2010
From: report at bugs.python.org (Vladimir Dmitriev)
Date: Fri, 15 Oct 2010 10:57:52 +0000
Subject: [New-bugs-announce] [issue10113] UnicodeDecodeError in
	mimetypes.guess_type on Windows
Message-ID: <1287140272.47.0.635588224312.issue10113@psf.upfronthosting.co.za>


Changes by Vladimir Dmitriev <vldmit at gmail.com>:


----------
components: Library (Lib), Windows
files: mime content types.reg
nosy: vldmit
priority: normal
severity: normal
status: open
title: UnicodeDecodeError in mimetypes.guess_type on Windows
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file19242/mime content types.reg

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

From report at bugs.python.org  Fri Oct 15 14:34:51 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Oct 2010 12:34:51 +0000
Subject: [New-bugs-announce] [issue10114] compile() doesn't support the PEP
	383 (surrogates)
In-Reply-To: <1287146091.4.0.492257332187.issue10114@psf.upfronthosting.co.za>
Message-ID: <1287146091.4.0.492257332187.issue10114@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Example:

$ ./python
Python 3.2a3+ (py3k, Oct 15 2010, 14:31:59) 
>>> compile('', 'abc\uDC80', 'exec')
...
UnicodeEncodeError: 'utf-8' codec can't encode character '\udc80' in position 3: surrogates not allowed

Attached patch encodes manually the filename to utf-8 with surrogateescape.

I found this problem while testing Python with an ASCII locale encoding (LANG=C ./python Lib/test/regrtest.py). Example:

  $ LANG=C ./python -m base64 -e setup.py 
  ...
  UnicodeEncodeError: 'utf-8' codec can't encode character '\udcc3' ...

----------
components: Interpreter Core, Unicode
files: compile_surrogates.patch
keywords: patch
messages: 118762
nosy: haypo
priority: normal
severity: normal
status: open
title: compile() doesn't support the PEP 383 (surrogates)
versions: Python 3.2
Added file: http://bugs.python.org/file19243/compile_surrogates.patch

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

From report at bugs.python.org  Fri Oct 15 15:23:24 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Oct 2010 13:23:24 +0000
Subject: [New-bugs-announce] [issue10115] accept4 can fail with errno 90
In-Reply-To: <1287149004.76.0.643231504051.issue10115@psf.upfronthosting.co.za>
Message-ID: <1287149004.76.0.643231504051.issue10115@psf.upfronthosting.co.za>


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

When a machine has a newer glibc and an old kernel, accept4 can fail and then Python accept() is unusable. For example:

Traceback (most recent call last):
  File "/home/pybot/buildarea-sid/3.x.klose-debian-sparc/build/Lib/threading.py", line 525, in _bootstrap_inner
    self.run()
  File "/home/pybot/buildarea-sid/3.x.klose-debian-sparc/build/Lib/test/test_asynchat.py", line 37, in run
    conn, client = self.sock.accept()
  File "/home/pybot/buildarea-sid/3.x.klose-debian-sparc/build/Lib/socket.py", line 132, in accept
    fd, addr = self._accept()
socket.error: [Errno 90] Function not implemented

(from http://www.python.org/dev/buildbot/builders/sparc%20Debian%203.x/builds/147/steps/test/logs/stdio )


Improving our configure check wouldn't do a lot of good, since people can reuse Python binaries with different kernels. Perhaps we have to use some kind of runtime fallback.

(Strangely, errno 90 is EMSGSIZE here, and ENOSYS is 38)

----------
components: Extension Modules
messages: 118767
nosy: doko, lekma, nvetoshkin, pitrou
priority: critical
severity: normal
stage: needs patch
status: open
title: accept4 can fail with errno 90
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Fri Oct 15 15:44:42 2010
From: report at bugs.python.org (Stephen Hansen)
Date: Fri, 15 Oct 2010 13:44:42 +0000
Subject: [New-bugs-announce] [issue10116] Sporadic failures in test_urllibnet
In-Reply-To: <1287150282.16.0.127032822399.issue10116@psf.upfronthosting.co.za>
Message-ID: <1287150282.16.0.127032822399.issue10116@psf.upfronthosting.co.za>


New submission from Stephen Hansen <me+python at ixokai.io>:

Ever since running the snow leopard buildslave, I've had sporadic failures in test_urllibnet. At first I thought it was just a net glitch on my machine or something, as immediately re-running the tests made it go away: but this most recent one:

http://www.python.org/dev//buildbot/builders/x86%20Snow%20Leopard%203.1/builds/20/steps/test/logs/stdio

happened while I was very much monitoring and using the network on the machine for other purposes, and everything was fine in general.

So, I went and looked into test_urllibnet to try to figure out why, and I notice that some of the tests use code to retry on IOErrors, and some don't-- and this test that failed in particular is one that doesn't. 

So: anyone have a better idea of what's going wrong, or is it just that hey, the active network tests are a bit flaky and all should use _open_with_retry instead of just some as is the case now?

[If the latter, I can do a patch]

FWIW, I've only seen this on the 3.1 and 3.x buildslaves, but have seen it on both of those more then once. But I don't know that its a 3.x specific issue: those builds get run more often then the 2.7 one, so have more chances to run into a sporadic issue.

----------
components: Tests
messages: 118772
nosy: ixokai
priority: normal
severity: normal
status: open
title: Sporadic failures in test_urllibnet
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Oct 15 18:54:42 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 15 Oct 2010 16:54:42 +0000
Subject: [New-bugs-announce] [issue10117] Tools/scripts/reindent.py fails on
	non-UTF-8 encodings
In-Reply-To: <1287161682.26.0.892900314694.issue10117@psf.upfronthosting.co.za>
Message-ID: <1287161682.26.0.892900314694.issue10117@psf.upfronthosting.co.za>


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

Tools/scripts/reindent.py -d Lib/test/encoded_modules/module_koi8_r.py
Traceback (most recent call last):
  File "Tools/scripts/reindent.py", line 310, in <module>
    main()
  File "Tools/scripts/reindent.py", line 93, in main
    check(arg)
  File "Tools/scripts/reindent.py", line 114, in check
    r = Reindenter(f)
  File "Tools/scripts/reindent.py", line 162, in __init__
    self.raw = f.readlines()
  File "Lib/codecs.py", line 300, in decode
    (result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xf0 in position 59: invalid continuation byte

Attached patch fixes this issue.

----------
components: Demos and Tools
files: reindent.diff
keywords: needs review, patch
messages: 118804
nosy: belopolsky
priority: normal
severity: normal
status: open
title: Tools/scripts/reindent.py fails on non-UTF-8 encodings
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file19245/reindent.diff

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

From report at bugs.python.org  Sat Oct 16 03:30:30 2010
From: report at bugs.python.org (mark saaltink)
Date: Sat, 16 Oct 2010 01:30:30 +0000
Subject: [New-bugs-announce] [issue10118] Tkinter does not find font
In-Reply-To: <1287192630.89.0.924571330725.issue10118@psf.upfronthosting.co.za>
Message-ID: <1287192630.89.0.924571330725.issue10118@psf.upfronthosting.co.za>


New submission from mark saaltink <platonic.liquid at gmail.com>:

Tkinter, since tk 8.5 apparently, does not find all the fonts that tk knows about.

I'm using Python 2.6.5 on Linux but have seen this on previous versions.  I have added the font with "xset fp+ <some font directory>"".  The font is Richard Jones' zed font, available from http://www.cs.kent.ac.uk/people/staff/rej/Zedfont/latest/

xlsfonts shows the font.

tk sees the font; in wish if I type "font families" there it is:

% font families
{fangsong ti} fixed {clearlyu alternate glyphs} charter lucidatypewriter zedfont {latin modern roman}  ...

In Tkinter I do not see the font:
>>> from Tkinter import *
>>> r = Tk()
>>> import tkFont
>>> tkFont.families(r)
... no sign of the zedfont here.

Is this expected behaviour?  Is there another way to install the font that avoids this problem?

----------
components: Tkinter
messages: 118850
nosy: mark.saaltink
priority: normal
severity: normal
status: open
title: Tkinter does not find font
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sat Oct 16 04:04:39 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 16 Oct 2010 02:04:39 +0000
Subject: [New-bugs-announce] [issue10119] test_urllibnet failure when
	using	support.transient_internet
In-Reply-To: <1287194679.07.0.887400455499.issue10119@psf.upfronthosting.co.za>
Message-ID: <1287194679.07.0.887400455499.issue10119@psf.upfronthosting.co.za>


New submission from Senthil Kumaran <orsenthil at gmail.com>:

I am attaching the script which exhibits the problem.

wrapping the urllib.request.urlopen, with the support.transient_internet contextmanager exhibits an Unexpected Behavior. Without the context manager, reading the file using the filedescriptor succeeds, but when wrapping it with the context manager, it fails with a TypeError.

----------
files: simple_test.py
messages: 118852
nosy: orsenthil
priority: normal
severity: normal
stage: needs patch
status: open
title: test_urllibnet failure when using support.transient_internet
type: behavior
Added file: http://bugs.python.org/file19248/simple_test.py

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

From report at bugs.python.org  Sat Oct 16 09:04:51 2010
From: report at bugs.python.org (Neil Muller)
Date: Sat, 16 Oct 2010 07:04:51 +0000
Subject: [New-bugs-announce] [issue10120] concurrent.futures module is not
	installed properly
In-Reply-To: <1287212691.14.0.409015662426.issue10120@psf.upfronthosting.co.za>
Message-ID: <1287212691.14.0.409015662426.issue10120@psf.upfronthosting.co.za>


New submission from Neil Muller <drnlmuller+bugs at gmail.com>:

with make install (r85564), lib/python3.2/concurrent is created, but the futures module is not installed there. The attached trivial patch fixes this here.

----------
files: futures-Makefile.diff
keywords: patch
messages: 118858
nosy: Neil Muller
priority: normal
severity: normal
status: open
title: concurrent.futures module is not installed properly
Added file: http://bugs.python.org/file19249/futures-Makefile.diff

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

From report at bugs.python.org  Sat Oct 16 14:39:33 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 16 Oct 2010 12:39:33 +0000
Subject: [New-bugs-announce] [issue10121] test_multiprocessing stuck in
	test_make_pool if run in a	loop
In-Reply-To: <1287232773.28.0.893033557088.issue10121@psf.upfronthosting.co.za>
Message-ID: <1287232773.28.0.893033557088.issue10121@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Hello,
when trying to see if issue6661 was still valid, I run test_multiprocessing in a tight loop and I got it reproducibly stuck on test_make_pool:

...

test_imap_unordered (test.test_multiprocessing.WithManagerTestPool) ... ok
test_make_pool (test.test_multiprocessing.WithManagerTestPool) ... 

when I enter Ctrl+C here's the traceback (on 2.7 HEAD):

test_make_pool (test.test_multiprocessing.WithManagerTestPool) ... ^CProcess PoolWorker-5:3:
Traceback (most recent call last):
  File "/home/morph/python-dev/release2.7-maint/Lib/multiprocessing/process.py", line 232, in _bootstrap
Process PoolWorker-5:2:
Traceback (most recent call last):
Process PoolWorker-5:4:
  File "/home/morph/python-dev/release2.7-maint/Lib/multiprocessing/process.py", line 232, in _bootstrap
Traceback (most recent call last):
  File "/home/morph/python-dev/release2.7-maint/Lib/multiprocessing/process.py", line 232, in _bootstrap
Process PoolWorker-5:1:
Traceback (most recent call last):
  File "/home/morph/python-dev/release2.7-maint/Lib/multiprocessing/process.py", line 232, in _bootstrap
Process PoolWorker-79:
Process PoolWorker-80:
Traceback (most recent call last):
Traceback (most recent call last):
  File "/home/morph/python-dev/release2.7-maint/Lib/multiprocessing/process.py", line 232, in _bootstrap
  File "/home/morph/python-dev/release2.7-maint/Lib/multiprocessing/process.py", line 232, in _bootstrap
    self.run()
    self.run()
  File "/home/morph/python-dev/release2.7-maint/Lib/multiprocessing/process.py", line 88, in run
  File "/home/morph/python-dev/release2.7-maint/Lib/multiprocessing/process.py", line 88, in run
    self._target(*self._args, **self._kwargs)
    self._target(*self._args, **self._kwargs)
  File "/home/morph/python-dev/release2.7-maint/Lib/multiprocessing/pool.py", line 59, in worker
  File "/home/morph/python-dev/release2.7-maint/Lib/multiprocessing/pool.py", line 59, in worker
    task = get()
    task = get()
  File "/home/morph/python-dev/release2.7-maint/Lib/multiprocessing/queues.py", line 352, in get
  File "/home/morph/python-dev/release2.7-maint/Lib/multiprocessing/queues.py", line 350, in get

Test suite interrupted by signal SIGINT.
1 test omitted:
    test_multiprocessing

and on py3k:

test_make_pool (test.test_multiprocessing.WithProcessesTestPool) ... ^CProcess PoolWorker-5:1:
Process PoolWorker-3:
Process PoolWorker-5:3:
Process PoolWorker-5:4:
Process PoolWorker-5:2:
Process PoolWorker-4:
Process PoolWorker-2:
Process PoolWorker-1:
Traceback (most recent call last):
Traceback (most recent call last):
Traceback (most recent call last):
Traceback (most recent call last):
Traceback (most recent call last):
Traceback (most recent call last):
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/process.py", line 233, in _bootstrap
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/process.py", line 233, in _bootstrap
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/process.py", line 233, in _bootstrap
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/process.py", line 233, in _bootstrap
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/process.py", line 233, in _bootstrap
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/process.py", line 233, in _bootstrap
Traceback (most recent call last):
Traceback (most recent call last):
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/process.py", line 233, in _bootstrap
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/process.py", line 233, in _bootstrap
Process PoolWorker-29:
Traceback (most recent call last):
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/process.py", line 233, in _bootstrap

Test suite interrupted by signal SIGINT.
1 test omitted:
    self.run()
    self.run()
    self.run()
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/process.py", line 88, in run
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/process.py", line 88, in run
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/process.py", line 88, in run
    self._target(*self._args, **self._kwargs)
    self._target(*self._args, **self._kwargs)
    self._target(*self._args, **self._kwargs)
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/pool.py", line 59, in worker
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/pool.py", line 59, in worker
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/pool.py", line 59, in worker
    self.run()
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/process.py", line 88, in run
    self._target(*self._args, **self._kwargs)
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/pool.py", line 59, in worker
    self.run()
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/process.py", line 88, in run
    self.run()
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/process.py", line 88, in run
    self._target(*self._args, **self._kwargs)
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/pool.py", line 59, in worker
    self._target(*self._args, **self._kwargs)
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/pool.py", line 59, in worker
    self.run()
    self.run()
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/process.py", line 88, in run
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/process.py", line 88, in run
    self._target(*self._args, **self._kwargs)
    self._target(*self._args, **self._kwargs)
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/pool.py", line 59, in worker
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/pool.py", line 59, in worker
    task = get()
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/queues.py", line 350, in get
    task = get()
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/queues.py", line 350, in get
    racquire()
KeyboardInterrupt
    racquire()
KeyboardInterrupt
    task = get()
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/queues.py", line 352, in get
    task = get()
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/queues.py", line 350, in get
    return recv()
    racquire()
KeyboardInterrupt
KeyboardInterrupt
    task = get()
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/queues.py", line 350, in get
    racquire()
    task = get()
    task = get()
KeyboardInterrupt
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/queues.py", line 350, in get
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/queues.py", line 350, in get
    racquire()
KeyboardInterrupt
    racquire()
KeyboardInterrupt
    task = get()
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/queues.py", line 352, in get
    return recv()
KeyboardInterrupt
    test_multiprocessing

It's reproducible here so I can make any tests you want to verify the problem (I don't know what to look at, sorry); just to give some more info, here's a Debian sid on AMD64.

Cheers,
Sandro

PS: it's my first bug report to python, so please be gentle and forgive any mistakes I could have made :)

----------
components: Tests
messages: 118867
nosy: jnoller, sandro.tosi
priority: normal
severity: normal
status: open
title: test_multiprocessing stuck in test_make_pool if run in a loop
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sat Oct 16 16:09:04 2010
From: report at bugs.python.org (Retro)
Date: Sat, 16 Oct 2010 14:09:04 +0000
Subject: [New-bugs-announce] [issue10122] Documentation typo fix and a side
	question
In-Reply-To: <1287238144.34.0.432770346734.issue10122@psf.upfronthosting.co.za>
Message-ID: <1287238144.34.0.432770346734.issue10122@psf.upfronthosting.co.za>


New submission from Retro <vinetouu at gmail.com>:

Please read the first sentence of the docs for the built-in function getattr() here: http://docs.python.org/library/functions.html?highlight=getattr#getattr

Fix the word 'attributed' to 'attribute', because the former is a typo.



A side question. When you document an object's API in the docstring, you write it like this:
getattr(object, name[, default]) -> value

Don't you find it nicer if that would look like this:
getattr(object, name, [default]) -> value

Note the cosmetic fix between the arguments 'name' and 'default'. Do you find my fix acceptable? If yes, please fix docstrings in Python that document the object's API from the '...name[, default]...' format to '...name, [default]...' format.

----------
assignee: docs at python
components: Documentation
messages: 118869
nosy: Retro, docs at python
priority: normal
severity: normal
status: open
title: Documentation typo fix and a side question
versions: 3rd party, Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Oct 16 16:15:54 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 16 Oct 2010 14:15:54 +0000
Subject: [New-bugs-announce] [issue10123] test_doctest failure with ASCII
	filesystem encoding
In-Reply-To: <1287238554.77.0.835644404703.issue10123@psf.upfronthosting.co.za>
Message-ID: <1287238554.77.0.835644404703.issue10123@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

In #10114, I changed parser filename encoding from utf-8/strict to the filesystem encoding/surrogateescape. With C locale, the filesystem encoding is ASCII and test_doctest fails because it uses an unencoable filename (foo-b?r at baz.py).

A solution is to write a test specific to non-ascii filenames and skip it if the filename is not encodable (try if os.fsencode() raises an UnicodeEncodeError or not), and use only ascii filenames in the other tests.

----------
components: Tests, Unicode
messages: 118870
nosy: haypo
priority: normal
severity: normal
status: open
title: test_doctest failure with ASCII filesystem encoding
versions: Python 3.2

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

From report at bugs.python.org  Sat Oct 16 17:48:48 2010
From: report at bugs.python.org (Paul Bolle)
Date: Sat, 16 Oct 2010 15:48:48 +0000
Subject: [New-bugs-announce] [issue10124] obvious typo in cporting HOWTO
In-Reply-To: <1287244128.31.0.267492647227.issue10124@psf.upfronthosting.co.za>
Message-ID: <1287244128.31.0.267492647227.issue10124@psf.upfronthosting.co.za>


New submission from Paul Bolle <pebolle at tiscali.nl>:

0) There's an obvious typo in the cporting HOWTO:

[...] It?s also important to remember that PyBytes and PyUnicode in 3.0 are not interchangeable like PyString and PyString are in 2.x. [...]

That PyString and PyString are interchangeable is obviously not what the author wanted to tell.

1) I'll attach a patch to change this into what I suppose the author had in mind. (If I knew for sure I wouldn't have read that HOWTO in the first place.)

----------
assignee: docs at python
components: Documentation
files: python-2.7-Doc-pystring.patch
keywords: patch
messages: 118875
nosy: docs at python, pebolle
priority: normal
severity: normal
status: open
title: obvious typo in cporting HOWTO
Added file: http://bugs.python.org/file19251/python-2.7-Doc-pystring.patch

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

From report at bugs.python.org  Sat Oct 16 19:00:21 2010
From: report at bugs.python.org (intuited)
Date: Sat, 16 Oct 2010 17:00:21 +0000
Subject: [New-bugs-announce] [issue10125] Closing a file within its
	writelines method causes	segfault
In-Reply-To: <1287248421.18.0.88895338197.issue10125@psf.upfronthosting.co.za>
Message-ID: <1287248421.18.0.88895338197.issue10125@psf.upfronthosting.co.za>


New submission from intuited <cecinemapasderange at gmail.com>:

Discovered when using the current Ubuntu 10.04 package of Python: 2.6.5-0ubuntu1

Reproducible with ::

    outfile = open("tmpout", "w")
    outfile.writelines(f() or "line" for f in (outfile.close,))

This problem is probably most likely to be encountered when using the ``fileinput`` module, because of the way it abstracts away the closing of files.  E.G.::

    from fileinput import input
    lines = input("tmpout", inplace=1)
    first = lines.next()
    from sys import stdout
    stdout.writelines(lines)

Both of the above pieces of code cause Segmentation Faults.

It looks like in line 1779 of ``Objects/fileobject.c``, ``f->fp`` is being passed to ``fwrite`` as 0.  I guess this happens because no check is done after the call to ``PyIter_Next`` on line 1730 to see if the file is still open.

I don't see this as a big issue, though it is annoying that it seemingly prevents generators from being used with the `fileinput` module.  Doing so would be a bit awkward and hacky anyway though.

----------
components: IO
messages: 118877
nosy: intuited
priority: normal
severity: normal
status: open
title: Closing a file within its writelines method causes segfault
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Sat Oct 16 22:25:51 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 Oct 2010 20:25:51 +0000
Subject: [New-bugs-announce] [issue10126] test_distutils failure with
	--enable-shared
In-Reply-To: <1287260751.98.0.49456572991.issue10126@psf.upfronthosting.co.za>
Message-ID: <1287260751.98.0.49456572991.issue10126@psf.upfronthosting.co.za>


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

This happens on Python 3.1:

/usr/bin/ld: cannot find -lpython3.1
collect2: ld returned 1 exit status
test test_distutils failed -- Traceback (most recent call last):
  File "/srv/buildbot/buildarea/3.1.bolen-ubuntu/build/Lib/distutils/unixccompiler.py", line 254, in link
    self.spawn(linker + ld_args)
  File "/srv/buildbot/buildarea/3.1.bolen-ubuntu/build/Lib/distutils/ccompiler.py", line 909, in spawn
    spawn(cmd, dry_run=self.dry_run)
  File "/srv/buildbot/buildarea/3.1.bolen-ubuntu/build/Lib/distutils/spawn.py", line 34, in spawn
    _spawn_posix(cmd, search_path, dry_run=dry_run)
  File "/srv/buildbot/buildarea/3.1.bolen-ubuntu/build/Lib/distutils/spawn.py", line 138, in _spawn_posix
    % (cmd[0], exit_status))
distutils.errors.DistutilsExecError: command 'gcc' failed with exit status 1

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/srv/buildbot/buildarea/3.1.bolen-ubuntu/build/Lib/distutils/tests/test_build_ext.py", line 321, in test_get_outputs
    cmd.run()
  File "/srv/buildbot/buildarea/3.1.bolen-ubuntu/build/Lib/distutils/command/build_ext.py", line 347, in run
    self.build_extensions()
  File "/srv/buildbot/buildarea/3.1.bolen-ubuntu/build/Lib/distutils/command/build_ext.py", line 456, in build_extensions
    self.build_extension(ext)
  File "/srv/buildbot/buildarea/3.1.bolen-ubuntu/build/Lib/distutils/command/build_ext.py", line 543, in build_extension
    target_lang=language)
  File "/srv/buildbot/buildarea/3.1.bolen-ubuntu/build/Lib/distutils/ccompiler.py", line 719, in link_shared_object
    extra_preargs, extra_postargs, build_temp, target_lang)
  File "/srv/buildbot/buildarea/3.1.bolen-ubuntu/build/Lib/distutils/unixccompiler.py", line 256, in link
    raise LinkError(msg)
distutils.errors.LinkError: command 'gcc' failed with exit status 1

(from http://www.python.org/dev/buildbot/builders/x86%20Ubuntu%20Shared%203.1/builds/1132/steps/test/logs/stdio )

Since it is on one of the stable buildbots, it might be considered release-blocking.

----------
components: Tests
messages: 118890
nosy: barry, eric.araujo, pitrou, tarek
priority: high
severity: normal
stage: needs patch
status: open
title: test_distutils failure with --enable-shared
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Sat Oct 16 23:14:34 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 16 Oct 2010 21:14:34 +0000
Subject: [New-bugs-announce] [issue10127] ssl.SSLSocket().close() does not
	close the connection
In-Reply-To: <1287263674.2.0.992398068639.issue10127@psf.upfronthosting.co.za>
Message-ID: <1287263674.2.0.992398068639.issue10127@psf.upfronthosting.co.za>


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

Quoting PoltoS from issue 8293:

If I do sock.close() (sock is instance of ssl.SSLSocket), the connection is not closed: I see it as Established in netstat and nothing is sent over network: tcpdump show nothing going thru the network.

----------
components: Library (Lib)
messages: 118896
nosy: PoltoS, TTT, amaury.forgeotdarc, dandrzejewski, eric.smith, giampaolo.rodola, orsenthil, pitrou, r.david.murray
priority: normal
severity: normal
status: open
title: ssl.SSLSocket().close() does not close the connection
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sun Oct 17 00:41:53 2010
From: report at bugs.python.org (Michael Olson)
Date: Sat, 16 Oct 2010 22:41:53 +0000
Subject: [New-bugs-announce] [issue10128] multiprocessing.Pool throws
	exception with __main__.py
In-Reply-To: <1287268913.13.0.756366299299.issue10128@psf.upfronthosting.co.za>
Message-ID: <1287268913.13.0.756366299299.issue10128@psf.upfronthosting.co.za>


New submission from Michael Olson <olson at irinim.net>:

In an application with an entry point of __main__.py, multiprocessing.Pool throws the following:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "D:\Dev\Python27\lib\multiprocessing\forking.py", line 346, in main
    prepare(preparation_data)
  File "D:\Dev\Python27\lib\multiprocessing\forking.py", line 454, in prepare
    assert main_name not in sys.modules, main_name
AssertionError: __main__

These messages repeat as long as the application is running.

Demonstration Code, must be in file named __main__.py:
--------------------
import multiprocessing
import time

if __name__ == '__main__':
    pool = multiprocessing.Pool()
    time.sleep(2)
--------------------

----------
components: Library (Lib)
messages: 118905
nosy: Michael.Olson
priority: normal
severity: normal
status: open
title: multiprocessing.Pool throws exception with __main__.py
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Oct 17 05:42:27 2010
From: report at bugs.python.org (Andreas Kloeckner)
Date: Sun, 17 Oct 2010 03:42:27 +0000
Subject: [New-bugs-announce] [issue10129] Curious 'name not defined error'
	with 'python -m'
In-Reply-To: <1287286947.38.0.536856909733.issue10129@psf.upfronthosting.co.za>
Message-ID: <1287286947.38.0.536856909733.issue10129@psf.upfronthosting.co.za>


New submission from Andreas Kloeckner <inform at tiker.net>:

$ python3.1 -m a b.py

results in

Traceback (most recent call last):
  File "/usr/lib/python3.1/runpy.py", line 128, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/usr/lib/python3.1/runpy.py", line 34, in _run_code
    exec(code, run_globals)
  File "/home/andreas/tmp/python-mbug/a.py", line 6, in <module>
    main()
  File "/home/andreas/tmp/python-mbug/a.py", line 3, in main
    exec(compile(open(sys.argv[1]).read(), sys.argv[1], 'exec'))
  File "b.py", line 8, in <module>
    sys.exit(main())
  File "b.py", line 5, in main
    argv = sys.argv[1:]
NameError: global name 'sys' is not defined

a.py --------------------------------------------------
def main():
    import sys
    exec(compile(open(sys.argv[1]).read(), sys.argv[1], 'exec'))

if __name__=='__main__':
    main()
-------------------------------------------------------

b.py --------------------------------------------------
import sys

def main():
  sys.argv[1:]

if __name__ == "__main__":
  main()
-------------------------------------------------------

----------
components: Interpreter Core
messages: 118913
nosy: inducer
priority: normal
severity: normal
status: open
title: Curious 'name not defined error' with 'python -m'
type: behavior
versions: Python 2.6, Python 3.1

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

From report at bugs.python.org  Sun Oct 17 13:32:48 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 17 Oct 2010 11:32:48 +0000
Subject: [New-bugs-announce] [issue10130] Create epub format docs and offer
	them on the download	page
Message-ID: <1287315169.0.0.39413411509.issue10130@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee: georg.brandl
nosy: georg.brandl
priority: deferred blocker
severity: normal
status: open
title: Create epub format docs and offer them on the download page
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Sun Oct 17 15:42:20 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 17 Oct 2010 13:42:20 +0000
Subject: [New-bugs-announce] [issue10131] deepcopying an
	xml.dom.minidom.Document generates an	invalid XML document
In-Reply-To: <1287322940.78.0.0838139062813.issue10131@psf.upfronthosting.co.za>
Message-ID: <1287322940.78.0.0838139062813.issue10131@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

>>> import copy
>>> from xml.dom import minidom

>>> doc = minidom.parseString('<root/>')
>>> doc2 = copy.deepcopy(doc)

>>> doc.toxml()
u'<?xml version="1.0" ?><root/>'
>>> doc2.toxml()
u'<?xml version="1.0" ?><root/><root/>'
>>> minidom.parseString(doc2.toxml())
Traceback (most recent call last):
...
ExpatError: junk after document element: line 1, column 2


The workaround is to use doc.cloneNode(True).

----------
components: XML
messages: 118942
nosy: flox
priority: normal
severity: normal
stage: needs patch
status: open
title: deepcopying an xml.dom.minidom.Document generates an invalid XML document
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun Oct 17 21:17:36 2010
From: report at bugs.python.org (Atsushi Odagiri)
Date: Sun, 17 Oct 2010 19:17:36 +0000
Subject: [New-bugs-announce] [issue10132] mkpkg.py is lacked.
In-Reply-To: <1287343056.23.0.00370138188039.issue10132@psf.upfronthosting.co.za>
Message-ID: <1287343056.23.0.00370138188039.issue10132@psf.upfronthosting.co.za>


New submission from Atsushi Odagiri <aodagx at gmail.com>:

I try to install distutils2-1.0a3 to python 2.5.
But I got error such a below.

$ python -V
Python 2.5.2
$ python setup.py build
running build
running build_py
running build_scripts
error: file 'distutils2/mkpkg.py' does not exist
$ ls distutils2/mkpkg.pyls: cannot access distutils2/mkpkg.py: No such file or directory

----------
assignee: tarek
components: Distutils2
messages: 118966
nosy: Atsushi.Odagiri, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: mkpkg.py is lacked.
versions: Python 2.5

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

From report at bugs.python.org  Sun Oct 17 22:14:55 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Sun, 17 Oct 2010 20:14:55 +0000
Subject: [New-bugs-announce] [issue10133] conn_recv_string() broken error
	handling
In-Reply-To: <1287346495.15.0.809946654619.issue10133@psf.upfronthosting.co.za>
Message-ID: <1287346495.15.0.809946654619.issue10133@psf.upfronthosting.co.za>


New submission from Hallvard B Furuseth <h.b.furuseth at usit.uio.no>:

Neither conn_recv_string() nor its callers free *newbuffer on error.

The promotion rules break negative 'res' for 64-bit Py_ssize_t
in the (ulength <= buflength) branch:
res = -1 ==> (UINT32)-1 ==> Py_ssize_t 0xffffffff instead of -1.

While I'm writing: The _conn_recvall() calls can be factored out
of the if().

This patch applies to both 3.2a3 and 2.7.  However, the patched failure
cases are untested: I do not know how to test them. It passes make test.

----------
components: IO
files: conn_recv_string_failures.diff
keywords: patch
messages: 118978
nosy: hfuru
priority: normal
severity: normal
status: open
title: conn_recv_string() broken error handling
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file19256/conn_recv_string_failures.diff

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

From report at bugs.python.org  Mon Oct 18 05:49:04 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Oct 2010 03:49:04 +0000
Subject: [New-bugs-announce] [issue10134] test_email failures on Windows:
	end of line issue?
In-Reply-To: <1287373744.55.0.18095949035.issue10134@psf.upfronthosting.co.za>
Message-ID: <1287373744.55.0.18095949035.issue10134@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

See attached file for the full output. One example:

== CPython 3.2a3+ (py3k:85660, Oct 17 2010, 21:57:48) [MSC v.1500 32 bit (Intel)]
==   Windows-XP-5.1.2600-SP3 little-endian
======================================================================
FAIL: test_MIME_digest (email.test.test_email.TestBytesGeneratorIdempotent)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\victor\py3k\lib\email\test\test_email.py", line 2016, in test_MIME_digest
    self._idempotent(msg, text)
  File "C:\victor\py3k\lib\email\test\test_email.py", line 2947, in _idempotent
    self.assertEqual(data, b.getvalue())
  File "C:\victor\py3k\lib\email\test\test_email.py", line 2952, in assertEqual
    self.assertListEqual(str1.split(b'\n'), str2.split(b'\n'))
AssertionError: Lists differ: [b'MIME-version: 1.0\r', b'Fro... != [b'MIME-version: 1.0', b'From:...

First differing element 0:
b'MIME-version: 1.0\r'
b'MIME-version: 1.0'

- [b'MIME-version: 1.0\r',
?                     --

+ [b'MIME-version: 1.0',
-  b'From: ppp-request at zzz.org\r',
?                             --

+  b'From: ppp-request at zzz.org',
-  b'Sender: ppp-admin at zzz.org\r',
?                             --

+  b'Sender: ppp-admin at zzz.org',
-  b'To: ppp at zzz.org\r',
?                   --

+  b'To: ppp at zzz.org',
-  b'Subject: Ppp digest, Vol 1 #2 - 5 msgs\r',
?                                          --

+  b'Subject: Ppp digest, Vol 1 #2 - 5 msgs',
-  b'Date: Fri, 20 Apr 2001 20:18:00 -0400 (EDT)\r',
?                                               --

+  b'Date: Fri, 20 Apr 2001 20:18:00 -0400 (EDT)',
-  b'X-Mailer: Mailman v2.0.4\r',
?                            --

+  b'X-Mailer: Mailman v2.0.4',
-  b'X-Mailman-Version: 2.0.4\r',
?                            --

+  b'X-Mailman-Version: 2.0.4',
-  b'Content-Type: multipart/mixed; boundary="192.168.1.2.889.32614.987812255.500.21814"\r',
?                                                                                       --

+  b'Content-Type: multipart/mixed; boundary="192.168.1.2.889.32614.987812255.500.21814"',
-  b'\r',
?    --

+  b'',
-  b'--192.168.1.2.889.32614.987812255.500.21814\r',
?                                               --

+  b'--192.168.1.2.889.32614.987812255.500.21814',
-  b'Content-type: text/plain; charset=us-ascii\r',
?                                              --

+  b'Content-type: text/plain; charset=us-ascii',
-  b'Content-description: Masthead (Ppp digest, Vol 1 #2)\r',
?                                                        --

+  b'Content-description: Masthead (Ppp digest, Vol 1 #2)',
-  b'\r',
?    --

+  b'',
   b'Send Ppp mailing list submissions to\r',
   b'\tppp at zzz.org\r',
   b'\r',
   b'To subscribe or unsubscribe via the World Wide Web, visit\r',
   b'\thttp://www.zzz.org/mailman/listinfo/ppp\r',
   b"or, via email, send a message with subject or body 'help' to\r",
   b'\tppp-request at zzz.org\r',
   b'\r',
   b'You can reach the person managing the list at\r',
   b'\tppp-admin at zzz.org\r',
   b'\r',
   b'When replying, please edit your Subject line so it is more specific\r',
   b'than "Re: Contents of Ppp digest..."\r',
   b'\r',
-  b'\r',
?    --

+  b'',
-  b'--192.168.1.2.889.32614.987812255.500.21814\r',
?                                               --

+  b'--192.168.1.2.889.32614.987812255.500.21814',
-  b'Content-type: text/plain; charset=us-ascii\r',
?                                              --

+  b'Content-type: text/plain; charset=us-ascii',
-  b"Content-description: Today's Topics (5 msgs)\r",
?                                                --

+  b"Content-description: Today's Topics (5 msgs)",
-  b'\r',
?    --

+  b'',
   b"Today's Topics:\r",
   b'\r',
   b'   1. testing #1 (Barry A. Warsaw)\r',
   b'   2. testing #2 (Barry A. Warsaw)\r',
   b'   3. testing #3 (Barry A. Warsaw)\r',
   b'   4. testing #4 (Barry A. Warsaw)\r',
   b'   5. testing #5 (Barry A. Warsaw)\r',
-  b'\r',
?    --

+  b'',
-  b'--192.168.1.2.889.32614.987812255.500.21814\r',
?                                               --

+  b'--192.168.1.2.889.32614.987812255.500.21814',
-  b'Content-Type: multipart/digest; boundary="__--__--"\r',
?                                                       --

+  b'Content-Type: multipart/digest; boundary="__--__--"',
-  b'\r',
?    --

+  b'',
-  b'--__--__--\r',
?              --

+  b'--__--__--',
-  b'\r',
?    --

+  b'',
-  b'Message: 1\r',
?              --

+  b'Message: 1',
-  b'Content-Type: text/plain; charset=us-ascii\r',
?                                              --

+  b'Content-Type: text/plain; charset=us-ascii',
-  b'Content-Transfer-Encoding: 7bit\r',
?                                   --

+  b'Content-Transfer-Encoding: 7bit',
-  b'Date: Fri, 20 Apr 2001 20:16:13 -0400\r',
?                                         --

+  b'Date: Fri, 20 Apr 2001 20:16:13 -0400',
-  b'To: ppp at zzz.org\r',
?                   --

+  b'To: ppp at zzz.org',
-  b'From: barry at digicool.com (Barry A. Warsaw)\r',
?                                              --

+  b'From: barry at digicool.com (Barry A. Warsaw)',
-  b'Subject: [Ppp] testing #1\r',
?                             --

+  b'Subject: [Ppp] testing #1',
-  b'Precedence: bulk\r',
?                    --

+  b'Precedence: bulk',
-  b'\r',
?    --

+  b'',
   b'\r',
   b'hello\r',
   b'\r',
-  b'\r',
?    --

+  b'',
-  b'--__--__--\r',
?              --

+  b'--__--__--',
-  b'\r',
?    --

+  b'',
-  b'Message: 2\r',
?              --

+  b'Message: 2',
-  b'Date: Fri, 20 Apr 2001 20:16:21 -0400\r',
?                                         --

+  b'Date: Fri, 20 Apr 2001 20:16:21 -0400',
-  b'Content-Type: text/plain; charset=us-ascii\r',
?                                              --

+  b'Content-Type: text/plain; charset=us-ascii',
-  b'Content-Transfer-Encoding: 7bit\r',
?                                   --

+  b'Content-Transfer-Encoding: 7bit',
-  b'To: ppp at zzz.org\r',
?                   --

+  b'To: ppp at zzz.org',
-  b'From: barry at digicool.com (Barry A. Warsaw)\r',
?                                              --

+  b'From: barry at digicool.com (Barry A. Warsaw)',
-  b'Precedence: bulk\r',
?                    --

+  b'Precedence: bulk',
-  b'\r',
?    --

+  b'',
   b'\r',
   b'hello\r',
   b'\r',
-  b'\r',
?    --

+  b'',
-  b'--__--__--\r',
?              --

+  b'--__--__--',
-  b'\r',
?    --

+  b'',
-  b'Message: 3\r',
?              --

+  b'Message: 3',
-  b'Date: Fri, 20 Apr 2001 20:16:25 -0400\r',
?                                         --

+  b'Date: Fri, 20 Apr 2001 20:16:25 -0400',
-  b'Content-Type: text/plain; charset=us-ascii\r',
?                                              --

+  b'Content-Type: text/plain; charset=us-ascii',
-  b'Content-Transfer-Encoding: 7bit\r',
?                                   --

+  b'Content-Transfer-Encoding: 7bit',
-  b'To: ppp at zzz.org\r',
?                   --

+  b'To: ppp at zzz.org',
-  b'From: barry at digicool.com (Barry A. Warsaw)\r',
?                                              --

+  b'From: barry at digicool.com (Barry A. Warsaw)',
-  b'Subject: [Ppp] testing #3\r',
?                             --

+  b'Subject: [Ppp] testing #3',
-  b'Precedence: bulk\r',
?                    --

+  b'Precedence: bulk',
-  b'\r',
?    --

+  b'',
   b'\r',
   b'hello\r',
   b'\r',
-  b'\r',
?    --

+  b'',
-  b'--__--__--\r',
?              --

+  b'--__--__--',
-  b'\r',
?    --

+  b'',
-  b'Message: 4\r',
?              --

+  b'Message: 4',
-  b'Date: Fri, 20 Apr 2001 20:16:28 -0400\r',
?                                         --

+  b'Date: Fri, 20 Apr 2001 20:16:28 -0400',
-  b'Content-Type: text/plain; charset=us-ascii\r',
?                                              --

+  b'Content-Type: text/plain; charset=us-ascii',
-  b'Content-Transfer-Encoding: 7bit\r',
?                                   --

+  b'Content-Transfer-Encoding: 7bit',
-  b'To: ppp at zzz.org\r',
?                   --

+  b'To: ppp at zzz.org',
-  b'From: barry at digicool.com (Barry A. Warsaw)\r',
?                                              --

+  b'From: barry at digicool.com (Barry A. Warsaw)',
-  b'Subject: [Ppp] testing #4\r',
?                             --

+  b'Subject: [Ppp] testing #4',
-  b'Precedence: bulk\r',
?                    --

+  b'Precedence: bulk',
-  b'\r',
?    --

+  b'',
   b'\r',
   b'hello\r',
   b'\r',
-  b'\r',
?    --

+  b'',
-  b'--__--__--\r',
?              --

+  b'--__--__--',
-  b'\r',
?    --

+  b'',
-  b'Message: 5\r',
?              --

+  b'Message: 5',
-  b'Date: Fri, 20 Apr 2001 20:16:32 -0400\r',
?                                         --

+  b'Date: Fri, 20 Apr 2001 20:16:32 -0400',
-  b'Content-Type: text/plain; charset=us-ascii\r',
?                                              --

+  b'Content-Type: text/plain; charset=us-ascii',
-  b'Content-Transfer-Encoding: 7bit\r',
?                                   --

+  b'Content-Transfer-Encoding: 7bit',
-  b'To: ppp at zzz.org\r',
?                   --

+  b'To: ppp at zzz.org',
-  b'From: barry at digicool.com (Barry A. Warsaw)\r',
?                                              --

+  b'From: barry at digicool.com (Barry A. Warsaw)',
-  b'Subject: [Ppp] testing #5\r',
?                             --

+  b'Subject: [Ppp] testing #5',
-  b'Precedence: bulk\r',
?                    --

+  b'Precedence: bulk',
-  b'\r',
?    --

+  b'',
   b'\r',
   b'hello\r',
   b'\r',
   b'\r',
   b'\r',
-  b'\r',
?    --

+  b'',
-  b'--__--__----\r',
?                --

+  b'--__--__----',
-  b'--192.168.1.2.889.32614.987812255.500.21814\r',
?                                               --

+  b'--192.168.1.2.889.32614.987812255.500.21814',
-  b'Content-type: text/plain; charset=us-ascii\r',
?                                              --

+  b'Content-type: text/plain; charset=us-ascii',
-  b'Content-description: Digest Footer\r',
?                                      --

+  b'Content-description: Digest Footer',
-  b'\r',
?    --

+  b'',
   b'_______________________________________________\r',
   b'Ppp mailing list\r',
   b'Ppp at zzz.org\r',
   b'http://www.zzz.org/mailman/listinfo/ppp\r',
   b'\r',
-  b'\r',
?    --

+  b'',
-  b'--192.168.1.2.889.32614.987812255.500.21814--\r',
?                                                 --

+  b'--192.168.1.2.889.32614.987812255.500.21814--',
   b'\r',
   b'End of Ppp Digest\r',
   b'\r',
   b'']

----------
components: Library (Lib)
files: out.txt
messages: 118996
nosy: haypo, r.david.murray
priority: normal
severity: normal
status: open
title: test_email failures on Windows: end of line issue?
versions: Python 3.2
Added file: http://bugs.python.org/file19261/out.txt

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

From report at bugs.python.org  Mon Oct 18 12:26:03 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Mon, 18 Oct 2010 10:26:03 +0000
Subject: [New-bugs-announce] [issue10135] Format specifier 'n' not working
In-Reply-To: <1287397563.59.0.0941833598936.issue10135@psf.upfronthosting.co.za>
Message-ID: <1287397563.59.0.0941833598936.issue10135@psf.upfronthosting.co.za>


New submission from Bo?tjan Mejak <bostjan.mejak at gmail.com>:

Have your default locale set to 'Slovenian' which uses a comma for the decimal symbol, like 2.76 is written as 2,76. Observe that the format specifier 'n' does not work for the default 'Slovenian' locale setting.

Then try running this in the Python interpreter:
'{number:.3n}'.format(number=2.76)

You get this:
>>> '{number:.3n}'.format(number=2.76)
'2.76'

Excepted the is the return value '2,76'. Please fix this bug.

----------
components: Interpreter Core
messages: 119003
nosy: Retro
priority: normal
severity: normal
status: open
title: Format specifier 'n' not working
type: behavior
versions: 3rd party, Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Oct 18 13:29:55 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 18 Oct 2010 11:29:55 +0000
Subject: [New-bugs-announce] [issue10136] kill_python doesn't work with
	short path
In-Reply-To: <1287401395.69.0.888132012732.issue10136@psf.upfronthosting.co.za>
Message-ID: <1287401395.69.0.888132012732.issue10136@psf.upfronthosting.co.za>


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

When kill_python[,d].exe was called via short path,
no python processes won't be killed. This happens
because, directory path is compared via simple
wcsnicmp. If one is short path and another is long path,
wcsnicmp determines they are not same path. This patch
solves this issue with GetFileInformationByHandle's
File ID information.

Probably this won't happen so much, so priority is low.

----------
components: Build
files: py3k_fix_kill_python_for_short_path.patch
keywords: patch
messages: 119007
nosy: ocean-city
priority: normal
severity: normal
status: open
title: kill_python doesn't work with short path
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file19262/py3k_fix_kill_python_for_short_path.patch

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

From report at bugs.python.org  Mon Oct 18 17:54:05 2010
From: report at bugs.python.org (Bruce Sherwood)
Date: Mon, 18 Oct 2010 15:54:05 +0000
Subject: [New-bugs-announce] [issue10137] Patch to IDLE for Python 2.7,
	at Guido's request
In-Reply-To: <1287417245.71.0.949450394447.issue10137@psf.upfronthosting.co.za>
Message-ID: <1287417245.71.0.949450394447.issue10137@psf.upfronthosting.co.za>


New submission from Bruce Sherwood <bruce.sherwood at gmail.com>:

At Guido's request, I've carried out the same update to the IDLE
distributed with Python 2.7 that I submitted for Python 3, to incorporate the work of Guilherme Polo in the Google Summer of Code 2009. Guido was concerned that with significant problems reported for IDLE 2.7, there should be an update despite Python 2.7 itself being essentially frozen. The basic structure for IDLE 3.2 was carried over. The main changes that had to be made were the change in module names between Python 2.7 and Python 3.2 (e.g. Tkinter in 2.7 is tkinter in 3.2).

----------
components: IDLE
files: idlelib2.7.patch
keywords: patch
messages: 119033
nosy: Bruce.Sherwood
priority: normal
severity: normal
status: open
title: Patch to IDLE for Python 2.7, at Guido's request
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file19263/idlelib2.7.patch

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

From report at bugs.python.org  Mon Oct 18 19:23:40 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 18 Oct 2010 17:23:40 +0000
Subject: [New-bugs-announce] [issue10138] calendar module does not support
	years outside [1, 9999] range
In-Reply-To: <1287422620.12.0.790695371078.issue10138@psf.upfronthosting.co.za>
Message-ID: <1287422620.12.0.790695371078.issue10138@psf.upfronthosting.co.za>


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

Documentation for the calendar module says:

"""
Most of these functions and classes rely on the datetime module which uses an idealized calendar, the current Gregorian calendar indefinitely extended in both directions.
"""

However, neither the datetime nor as a consequence the calendar module support years  outside [1, 9999] range.

----------
assignee: belopolsky
components: Documentation
messages: 119041
nosy: belopolsky
priority: normal
severity: normal
status: open
title: calendar module does not support years outside [1, 9999] range
versions: Python 3.2

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

From report at bugs.python.org  Tue Oct 19 00:26:02 2010
From: report at bugs.python.org (=?utf-8?b?zqfPgc6uz4PPhM6/z4IgzpPOtc+Jz4HOs86vzr/PhSAoQ2hyaXN0b3MgR2Vvcmdp?= =?utf-8?b?b3Up?=)
Date: Mon, 18 Oct 2010 22:26:02 +0000
Subject: [New-bugs-announce] [issue10139] regex A|B : both A and B match,
	but B is wrongly preferred
In-Reply-To: <1287440762.5.0.953129438054.issue10139@psf.upfronthosting.co.za>
Message-ID: <1287440762.5.0.953129438054.issue10139@psf.upfronthosting.co.za>


New submission from ??????? ???????? (Christos Georgiou) <tzot at users.sourceforge.net>:

This is based on that StackOverflow answer: http://stackoverflow.com/questions/3957164/3963443#3963443. It also applies to Python 2.6 .

Searching for a regular expression that satisfies the mentioned SO question (a regular expression that matches strings with an initial A and/or final Z and returns everything except said initial A and final Z), I discovered something that I consider a bug. I've tried to thoroughly verify that this is not a PEBCAK before reporting the issue here.

Given:

>>> import re
>>> text= 'A***Z'

then:

>>> re.compile('(?<=^A).*(?=Z$)').search(text).group(0) # regex_1
'***'
>>> re.compile('(?<=^A).*').search(text).group(0) # regex_2
'***Z'
>>> re.compile('.*(?=Z$)').search(text).group(0) # regex_3
'A***'
>>> re.compile('(?<=^A).*(?=Z$)|(?<=^A).*').search(text).group(0) # regex_1|regex_2
'***'
>>> re.compile('(?<=^A).*(?=Z$)|.*(?=Z$)').search(text).group(0) # regex_1|regex_3
'A***'
>>> re.compile('(?<=^A).*|.*(?=Z$)').search(text).group(0) # regex_2|regex_3
'A***'
>>> re.compile('(?<=^A).*(?=Z$)|(?<=^A).*|.*(?=Z$)').search(text).group(0) # regex_1|regex_2|regex_3
'A***'

regex_1 returns '***'. Based on the documentation (http://docs.python.org/py3k/library/re.html#regular-expression-syntax), I assert that, likewise, '***' should be returned by:

regex_1|regex_2
regex_1|regex_3
regex_1|regex_2|regex_3

And yet, regex_3 ( ".*(?=Z$)" ) seems to take precedence over both regex_1 and regex_2, even though it's the last alternative.

This works even if I substitute "(?:regex_n)" for every "regex_n", so it's not a matter of precedence.

I really hope that this is a PEBCAK; if that is true, I apologize for any time lost on the issue by anyone; but really don't think it is.

----------
components: Regular Expressions
messages: 119088
nosy: tzot
priority: normal
severity: normal
status: open
title: regex A|B : both A and B match, but B is wrongly preferred
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Tue Oct 19 01:17:00 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 18 Oct 2010 23:17:00 +0000
Subject: [New-bugs-announce] [issue10140] Tools/scripts/pathfix.py: add
	option to preserve	timestamps
In-Reply-To: <1287443820.79.0.521760966173.issue10140@psf.upfronthosting.co.za>
Message-ID: <1287443820.79.0.521760966173.issue10140@psf.upfronthosting.co.za>


New submission from Dave Malcolm <dmalcolm at redhat.com>:

I'm attempting to fix up the build in my Fedora/RHEL packages of Python to preserve timestamps of .py files as far as possible during the build, so that .pyc/.pyo files end up with predictable embedded mtime values and thus predictable hashes.

Am attaching a patch to the py3k branch which adds a "-p" option to the Tools/script/pathfix.py script, which makes it preserve the mtime of the input files.

----------
components: Build
files: pathfix-preserve-timestamps.patch
keywords: needs review, patch
messages: 119092
nosy: dmalcolm
priority: normal
severity: normal
stage: patch review
status: open
title: Tools/scripts/pathfix.py: add option to preserve timestamps
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file19276/pathfix-preserve-timestamps.patch

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

From report at bugs.python.org  Tue Oct 19 02:49:27 2010
From: report at bugs.python.org (instigatorirc)
Date: Tue, 19 Oct 2010 00:49:27 +0000
Subject: [New-bugs-announce] [issue10141] SocketCan support
In-Reply-To: <1287449366.98.0.655876257649.issue10141@psf.upfronthosting.co.za>
Message-ID: <1287449366.98.0.655876257649.issue10141@psf.upfronthosting.co.za>


New submission from instigatorirc <instigatorirc at gmail.com>:

Python lacks support for the AF_CAN family of sockets ( http://en.wikipedia.org/wiki/Controller_area_network http://lwn.net/Articles/253425/)

https://lists.berlios.de/pipermail/socketcan-users/2010-July/001456.html

----------
components: IO
files: socketcan.dpatch
messages: 119096
nosy: instigatorirc
priority: normal
severity: normal
status: open
title: SocketCan support
type: feature request
versions: Python 2.6, Python 3.3
Added file: http://bugs.python.org/file19277/socketcan.dpatch

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

From report at bugs.python.org  Tue Oct 19 05:15:19 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 19 Oct 2010 03:15:19 +0000
Subject: [New-bugs-announce] [issue10142] Support for SEEK_HOLE/SEEK_DATA
In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za>
Message-ID: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za>


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

ZFS supports SEEK_HOLE/SEEK_DATA in "lseek()" syscall.

Oracle Solaris man page por "lseek":

"""
[...]
       o  If whence is SEEK_HOLE, the offset of the start of  the
          next  hole greater than or equal to the supplied offset
          is returned. The definition of a hole is provided  near
          the end of the DESCRIPTION.

       o  If whence is SEEK_DATA, the file pointer is set to  the
          start  of the next non-hole file region greater than or
          equal to the supplied offset.


     The  symbolic  constants   SEEK_SET,   SEEK_CUR,   SEEK_END,
     SEEK_HOLE,   and   SEEK_DATA   are  defined  in  the  header
     <unistd.h>.
[...]
     A "hole" is defined as a contiguous  range  of  bytes  in  a
     file,  all  having the value of zero, but not all zeros in a
     file are guaranteed to be represented as holes returned with
     SEEK_HOLE. Filesystems are allowed to expose ranges of zeros
     with SEEK_HOLE, but not required to.  Applications  can  use
     SEEK_HOLE  to  optimise  their behavior for ranges of zeros,
     but must not depend on it to find all such ranges in a file.
     The  existence  of  a  hole  at the end of every data region
     allows for easy programming and implies that a virtual  hole
     exists  at  the  end  of  the  file. Applications should use
     fpathconf(_PC_MIN_HOLE_SIZE) or  pathconf(_PC_MIN_HOLE_SIZE)
     to  determine if a filesystem supports SEEK_HOLE. See fpath-
     conf(2).

     For filesystems that do not supply information about  holes,
     the file will be represented as one entire data region.
"""

Implementation would be trivial. Simply conditionally compile the constant export in the C module. Or adopt the approach in the last phrase.

Any novice?.

----------
keywords: easy
messages: 119112
nosy: jcea
priority: normal
severity: normal
status: open
title: Support for SEEK_HOLE/SEEK_DATA
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Tue Oct 19 05:30:31 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 19 Oct 2010 03:30:31 +0000
Subject: [New-bugs-announce] [issue10143] Update "os.pathconf" values
In-Reply-To: <1287459031.95.0.424598520823.issue10143@psf.upfronthosting.co.za>
Message-ID: <1287459031.95.0.424598520823.issue10143@psf.upfronthosting.co.za>


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

os.pathconf and related functions are a bit outdated and some platforms, like Solaris are pretty badly represented.

We need to support more values.

Trivial to implement.

----------
components: Library (Lib)
keywords: easy
messages: 119113
nosy: jcea
priority: normal
severity: normal
status: open
title: Update "os.pathconf" values
versions: Python 3.2

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

From report at bugs.python.org  Tue Oct 19 06:05:48 2010
From: report at bugs.python.org (Wes McKinney)
Date: Tue, 19 Oct 2010 04:05:48 +0000
Subject: [New-bugs-announce] [issue10144] Buffering bug after calling curses
	function
In-Reply-To: <1287461148.01.0.951326412516.issue10144@psf.upfronthosting.co.za>
Message-ID: <1287461148.01.0.951326412516.issue10144@psf.upfronthosting.co.za>


New submission from Wes McKinney <wesmckinn at gmail.com>:

We tracked a bug originating in IPython to the Python interpreter itself, seems to be present in 2.6.x and 2.7.x but not 3.1.x. This is on Ubuntu Linux 10.04, does not seem to occur in OS X 10.6.

Reference: http://article.gmane.org/gmane.comp.python.ipython.user/5336

> cat bufferbug.py
"""Strange bug in buffering of sys.stdout after calling curses functions.
"""
import time
import curses

def bug():
   curses.initscr()
   curses.endwin()

def f(n=2):
   s = 0.75
   for i in range(n):
       print i
       time.sleep(s)
   print i+1

if __name__ == '__main__':
   f()
   print 'Calling bug() now!'
   bug()
   f()

####

----------
components: Interpreter Core
messages: 119115
nosy: Wes.McKinney
priority: normal
severity: normal
status: open
title: Buffering bug after calling curses function
type: behavior
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Tue Oct 19 13:40:40 2010
From: report at bugs.python.org (Ralph Corderoy)
Date: Tue, 19 Oct 2010 11:40:40 +0000
Subject: [New-bugs-announce] [issue10145] (4.2).is_integer() is undocumented.
In-Reply-To: <1287488440.57.0.0400472595143.issue10145@psf.upfronthosting.co.za>
Message-ID: <1287488440.57.0.0400472595143.issue10145@psf.upfronthosting.co.za>


New submission from Ralph Corderoy <ralph-pythonbugs at inputplus.co.uk>:

floats now have an is_integer() method.  I think it was added in 2.6 around the same time as as_integer_ratio().  It has a docstring but it isn't mentioned in the documentation.  I only idled across it when reading the C source.  I'd expect to find it, for example, at

    http://docs.python.org/library/stdtypes.html?highlight=as_integer_ratio#additional-methods-on-float
    http://docs.python.org/py3k/library/stdtypes.html?highlight=as_integer_ratio#additional-methods-on-float

Can it please be added, and for Py2, mention what version it appeared in.

----------
assignee: docs at python
components: Documentation
messages: 119133
nosy: docs at python, ralph.corderoy
priority: normal
severity: normal
status: open
title: (4.2).is_integer() is undocumented.
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Oct 19 21:10:45 2010
From: report at bugs.python.org (Noah Kantrowitz)
Date: Tue, 19 Oct 2010 19:10:45 +0000
Subject: [New-bugs-announce] [issue10146] Incorrect regex generation in
	translate_pattern
In-Reply-To: <1287515445.03.0.219266745901.issue10146@psf.upfronthosting.co.za>
Message-ID: <1287515445.03.0.219266745901.issue10146@psf.upfronthosting.co.za>


New submission from Noah Kantrowitz <noah+bugs.python.org at coderanger.net>:

If a prefix is passed to translate_pattern it will generate a pattern using the unescaped output of os.path.join(). This is fine on *nix, but on Windows it results in a pattern like r'build\.*', which matches any string starting with "build" (in my case, "buildout.cfg"). Escaping the separator fixes this (patch attached).

----------
assignee: tarek
components: Distutils
files: filelist.diff
keywords: patch
messages: 119159
nosy: coderanger, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: Incorrect regex generation in translate_pattern
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1
Added file: http://bugs.python.org/file19287/filelist.diff

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

From report at bugs.python.org  Tue Oct 19 21:19:52 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Tue, 19 Oct 2010 19:19:52 +0000
Subject: [New-bugs-announce] [issue10147] Python Documentation bugs
In-Reply-To: <1287515992.96.0.884562024831.issue10147@psf.upfronthosting.co.za>
Message-ID: <1287515992.96.0.884562024831.issue10147@psf.upfronthosting.co.za>


New submission from Bo?tjan Mejak <bostjan.mejak at gmail.com>:

Please read the docs here: http://docs.python.org/py3k/reference/expressions#boolean-operations

This is the last sentence in the '5.10. Boolean operations' text):
([...] Because not has to >>>invent<<< a value anyway, it does not bother to return a value of the same type as its argument, so e.g., not 'foo' yields False, not ''.)

Fix to:
([...] Because not has to >>>invert<<< a value anyway, it does not bother to return a value of the same type as its argument, so e.g., not 'foo' yields False, not ''.)

----------
assignee: docs at python
components: Documentation
messages: 119160
nosy: Retro, docs at python
priority: normal
severity: normal
status: open
title: Python Documentation bugs
versions: 3rd party, Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Oct 20 01:14:31 2010
From: report at bugs.python.org (Luke McCarthy)
Date: Tue, 19 Oct 2010 23:14:31 +0000
Subject: [New-bugs-announce] [issue10148] st_mtime differs after shutil.copy2
In-Reply-To: <1287530071.19.0.608159353416.issue10148@psf.upfronthosting.co.za>
Message-ID: <1287530071.19.0.608159353416.issue10148@psf.upfronthosting.co.za>


New submission from Luke McCarthy <luke at iogopro.co.uk>:

When copying a file with shutil.copy2() between two ext4 filesystems on 64-bit Linux, the mtime of the destination file is different after the copy. It appears as if the resolution is slightly different, so the mtime is truncated slightly. For example:

source file mtime:      1287367331.8433506
destination file mtime: 1287367331.84335

----------
components: Library (Lib)
messages: 119176
nosy: shaurz
priority: normal
severity: normal
status: open
title: st_mtime differs after shutil.copy2
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Wed Oct 20 03:43:21 2010
From: report at bugs.python.org (Maciek J)
Date: Wed, 20 Oct 2010 01:43:21 +0000
Subject: [New-bugs-announce] [issue10149] Data truncation in expat parser
In-Reply-To: <1287539001.05.0.466094845115.issue10149@psf.upfronthosting.co.za>
Message-ID: <1287539001.05.0.466094845115.issue10149@psf.upfronthosting.co.za>


New submission from Maciek J <egil at wp.pl>:

Not sure if this is a Python problem or an expat problem, but I get truncated data while parsing XML documents.

This particular project is for parsing an XML file of Wikipedia dump.

The attached files are:
* xml-parse-revisions.py - parser script
* revision-test.xml - input XML
* revision-test.xml.sql - output XML
* revision_create.sql - not really needed for this test case, but attached for completeness

You can notice that the output file sometimes contains too short values for the "timestamp". Also note that if you add whitespace to the input XML, then different timestamps will be truncated.

My Python is 2.6.6.

----------
components: XML
files: pyxml_error.zip
messages: 119184
nosy: Maciek.J
priority: normal
severity: normal
status: open
title: Data truncation in expat parser
versions: Python 2.6
Added file: http://bugs.python.org/file19292/pyxml_error.zip

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

From report at bugs.python.org  Wed Oct 20 06:01:47 2010
From: report at bugs.python.org (James Bowman)
Date: Wed, 20 Oct 2010 04:01:47 +0000
Subject: [New-bugs-announce] [issue10150] Local references not released
	after exception
In-Reply-To: <1287547307.96.0.164615718741.issue10150@psf.upfronthosting.co.za>
Message-ID: <1287547307.96.0.164615718741.issue10150@psf.upfronthosting.co.za>


New submission from James Bowman <bowmanator at gmail.com>:

import sys

def foo():
    x = [o] * 100
    raise ArithmeticError

o = "something"
print sys.getrefcount(o)
try:
    foo()
except ArithmeticError:
    pass
print sys.getrefcount(o)

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

Gives:

4
104


Looking at the CPython source, FrameObject's deallocator does actually decrement refcounts of its locals and arguments.  Guessing that the FrameObject is not being deallocated.

----------
components: Interpreter Core
messages: 119187
nosy: James.Bowman
priority: normal
severity: normal
status: open
title: Local references not released after exception
type: resource usage
versions: Python 2.6

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

From report at bugs.python.org  Wed Oct 20 09:19:47 2010
From: report at bugs.python.org (Thomas Guettler)
Date: Wed, 20 Oct 2010 07:19:47 +0000
Subject: [New-bugs-announce] [issue10151] Docs: can globals() be updated?
In-Reply-To: <1287559187.64.0.23978641371.issue10151@psf.upfronthosting.co.za>
Message-ID: <1287559187.64.0.23978641371.issue10151@psf.upfronthosting.co.za>


New submission from Thomas Guettler <guettli at thomas-guettler.de>:

Hi,

the documentation of "globals()" is missing a note if you can update
the dictionary:

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

For "locals()" it is documented:
http://docs.python.org/library/functions.html?highlight=locals#locals

----------
assignee: docs at python
components: Documentation
messages: 119192
nosy: docs at python, guettli
priority: normal
severity: normal
status: open
title: Docs: can globals() be updated?
versions: Python 2.7

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

From report at bugs.python.org  Wed Oct 20 12:47:53 2010
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 20 Oct 2010 10:47:53 +0000
Subject: [New-bugs-announce] [issue10152] symtable.c: ste_tmpname
	uninitialized
In-Reply-To: <1287571673.13.0.775838367643.issue10152@psf.upfronthosting.co.za>
Message-ID: <1287571673.13.0.775838367643.issue10152@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

Found by Valgrind:

==3947== Use of uninitialised value of size 8
==3947==    at 0x5716D13: _itoa_word (in /lib/libc-2.8.90.so)
==3947==    by 0x5719F53: vfprintf (in /lib/libc-2.8.90.so)
==3947==    by 0x5743239: vsnprintf (in /lib/libc-2.8.90.so)
==3947==    by 0x4956AF: PyOS_vsnprintf (mysnprintf.c:74)
==3947==    by 0x495661: PyOS_snprintf (mysnprintf.c:47)
==3947==    by 0x49FC1E: symtable_new_tmpname (symtable.c:1092)
==3947==    by 0x4A2CE6: symtable_handle_comprehension (symtable.c:1648)
==3947==    by 0x4A2F7C: symtable_visit_listcomp (symtable.c:1673)
==3947==    by 0x4A1C63: symtable_visit_expr (symtable.c:1363)
==3947==    by 0x4A07C5: symtable_visit_stmt (symtable.c:1178)
==3947==    by 0x4A0BBE: symtable_visit_stmt (symtable.c:1200)
==3947==    by 0x4A08D4: symtable_visit_stmt (symtable.c:1187)



The patch fixes the issue (unless the intent was to use somewhat randomized tmpnames).

----------
files: ste_tmpname.patch
keywords: patch
messages: 119198
nosy: skrah
priority: normal
severity: normal
status: open
title: symtable.c: ste_tmpname uninitialized
Added file: http://bugs.python.org/file19293/ste_tmpname.patch

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

From report at bugs.python.org  Wed Oct 20 13:09:36 2010
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 20 Oct 2010 11:09:36 +0000
Subject: [New-bugs-announce] [issue10153] Memory leak in pythonrun.c
In-Reply-To: <1287572976.12.0.192446732245.issue10153@psf.upfronthosting.co.za>
Message-ID: <1287572976.12.0.192446732245.issue10153@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

Found by Valgrind, patch attached:

==4921== 24 bytes in 1 blocks are definitely lost in loss record 419 of 2,694
==4921==    at 0x4C2412C: malloc (vg_replace_malloc.c:195)
==4921==    by 0x417F06: _PyObject_New (object.c:244)
==4921==    by 0x520C4E: PyFile_NewStdPrinter (fileobject.c:364)
==4921==    by 0x499438: Py_InitializeEx (pythonrun.c:281)
==4921==    by 0x49951E: Py_Initialize (pythonrun.c:322)
==4921==    by 0x4B2579: Py_Main (main.c:587)
==4921==    by 0x417D6B: main (python.c:51)

----------
components: Interpreter Core
files: pythonrun.patch
keywords: patch
messages: 119201
nosy: skrah
priority: normal
severity: normal
stage: patch review
status: open
title: Memory leak in pythonrun.c
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file19294/pythonrun.patch

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

From report at bugs.python.org  Wed Oct 20 17:31:25 2010
From: report at bugs.python.org (Stephen Hansen)
Date: Wed, 20 Oct 2010 15:31:25 +0000
Subject: [New-bugs-announce] [issue10154] locale.normalize strips "-" from
	UTF-8, which fails on Mac
In-Reply-To: <1287588685.92.0.0691926945263.issue10154@psf.upfronthosting.co.za>
Message-ID: <1287588685.92.0.0691926945263.issue10154@psf.upfronthosting.co.za>


New submission from Stephen Hansen <me+python at ixokai.io>:

In the course of investigating issue10092, Georg discovered that the behavior of locale.normalize() on Mac is bad.

Basically, "en_US.UTF-8" is how the "correct" locale string should be spelled on the Mac. If you drop the dash, it fails: which locale.normalize does, so you can't pass the return value of the function to setlocale, even though that's what its documented to be for.

If that isn't clear, this should demonstrate (from /branches/py3k):


Top-2:build pythonbuildbot$ ./python.exe
Python 3.2a3+ (py3k:85631, Oct 17 2010, 06:45:22) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
[51767 refs]
>>> locale.normalize("en_US.UTF-8")
'en_US.UTF8'
[51770 refs]
>>> locale.setlocale(locale.LC_TIME, 'en_US.UTF8')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/pythonbuildbot/test/build/Lib/locale.py", line 538, in setlocale
    return _setlocale(category, locale)
locale.Error: unsupported locale setting
[51816 refs]
>>> locale.setlocale(locale.LC_TIME, 'en_US.UTF-8')
'en_US.UTF-8'
[51816 refs]

The precise same behavior exists on my stock/system Python 2.6, too, fwiw. (Not that it can be fixed on 2.6, but maybe 2.7?)

----------
assignee: ronaldoussoren
components: Library (Lib), Macintosh
messages: 119213
nosy: ixokai, ronaldoussoren
priority: normal
severity: normal
status: open
title: locale.normalize strips "-" from UTF-8, which fails on Mac
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed Oct 20 18:23:42 2010
From: report at bugs.python.org (And Clover)
Date: Wed, 20 Oct 2010 16:23:42 +0000
Subject: [New-bugs-announce] [issue10155] Add fixups for encoding problems
	to wsgiref
In-Reply-To: <1287591822.31.0.50492787235.issue10155@psf.upfronthosting.co.za>
Message-ID: <1287591822.31.0.50492787235.issue10155@psf.upfronthosting.co.za>


New submission from And Clover <and at doxdesk.com>:

Currently wsgiref's CGIHandler makes a WSGI environ from the CGI environ without changes.

Unfortunately the CGI environ is wrong in a number of common circumstances:

- on Windows, the native environ is Unicode, and different servers choose different decodings for HTTP bytes to store in the environ (most notably for PATH_INFO);

- on Windows with Python 2.x, os.environ is read from the Unicode native environ using the ANSI encoding, which will lose/mangle non-ASCII characters;

- on Posix with Python 3.x, os.environ is read from a native bytes environ using the filesystemencoding which is probably not ISO-8859-1.

- on IIS, PATH_INFO inappropriately includes SCRIPT_NAME unless a hidden, rarely-used, and problematic config option is applied.

Previously, it was not clear in PEP 333 what was supposed to happen with headers and encodings, especially under Python 3. PEP 3333 clears this up. These patches add fixups to wsgiref to try to generate the nearest to a 'correct' environ as per PEP 3333 as possible for the current platform and server software.

They also fix simple_server to use the correct encoding for PATH_INFO, and include the fix for issue 9022, correspondingly updating the simple_server demo app and tests to conform to PEP 3333's expectation that headers will be ISO-8859-1-decoded Unicode strings. The test_bytes_validation test is removed: as I understand it, it's no long allowed to use byte string headers/status.

----------
components: Library (Lib)
files: wsgiref-patches-3.2a3.patch
keywords: patch
messages: 119220
nosy: aclover
priority: normal
severity: normal
status: open
title: Add fixups for encoding problems to wsgiref
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file19303/wsgiref-patches-3.2a3.patch

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

From report at bugs.python.org  Wed Oct 20 19:27:07 2010
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 20 Oct 2010 17:27:07 +0000
Subject: [New-bugs-announce] [issue10156] Memory leak (r70459)
In-Reply-To: <1287595627.82.0.548953621137.issue10156@psf.upfronthosting.co.za>
Message-ID: <1287595627.82.0.548953621137.issue10156@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

This is one of two remaining "definitely lost" leaks in py3k. It started
to appear in r70459. How to reproduce:

make distclean && ./configure OPT="-O0 -g" --without-pymalloc && make

valgrind --leak-check=full --suppressions=Misc/valgrind-python.supp ./python > VGOUT 2>&1

Then search for 'definitely'. This leak is not present in release-2.7.


==2058== 56 bytes in 1 blocks are definitely lost in loss record 918 of 2,136
==2058==    at 0x4C2412C: malloc (vg_replace_malloc.c:195)
==2058==    by 0x4167DE: _PyObject_New (object.c:243)
==2058==    by 0x42C278: _PyUnicode_New (unicodeobject.c:341)
==2058==    by 0x4306BD: PyUnicodeUCS2_DecodeUTF8Stateful (unicodeobject.c:2100)
==2058==    by 0x430671: PyUnicodeUCS2_DecodeUTF8 (unicodeobject.c:2065)
==2058==    by 0x42C8F7: PyUnicodeUCS2_FromStringAndSize (unicodeobject.c:541)
==2058==    by 0x42C973: PyUnicodeUCS2_FromString (unicodeobject.c:559)
==2058==    by 0x50B432: PyDict_SetItemString (dictobject.c:2088)
==2058==    by 0x4258DF: PyType_Ready (typeobject.c:3844)
==2058==    by 0x517B64: PyStructSequence_InitType (structseq.c:522)
==2058==    by 0x4F3B4F: _PyFloat_Init (floatobject.c:1905)
==2058==    by 0x4813CE: Py_InitializeEx (pythonrun.c:217)

----------
components: Interpreter Core
messages: 119226
nosy: mark.dickinson, skrah
priority: normal
severity: normal
status: open
title: Memory leak (r70459)
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Wed Oct 20 19:33:21 2010
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 20 Oct 2010 17:33:21 +0000
Subject: [New-bugs-announce] [issue10157] Memory leak (r70152)
In-Reply-To: <1287596001.72.0.908968504513.issue10157@psf.upfronthosting.co.za>
Message-ID: <1287596001.72.0.908968504513.issue10157@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

This is one of two remaining "definitely lost" leaks in py3k. It first
appeared in r70152. How to reproduce:

make distclean && ./configure OPT="-O0 -g" --without-pymalloc && make

valgrind --leak-check=full --suppressions=Misc/valgrind-python.supp ./python > VGOUT 2>&1

Then search for 'definitely'. This leak is not present in release-2.7.


==25233== 106 (56 direct, 50 indirect) bytes in 1 blocks are definitely lost in loss record 1,432 of 2,121
==25233==    at 0x4C2412C: malloc (vg_replace_malloc.c:195)
==25233==    by 0x4167AE: _PyObject_New (object.c:243)
==25233==    by 0x42C1C4: _PyUnicode_New (unicodeobject.c:341)
==25233==    by 0x430562: PyUnicodeUCS2_DecodeUTF8Stateful (unicodeobject.c:2036)
==25233==    by 0x430516: PyUnicodeUCS2_DecodeUTF8 (unicodeobject.c:2001)
==25233==    by 0x479F81: r_object (marshal.c:726)
==25233==    by 0x47A03E: r_object (marshal.c:745)
==25233==    by 0x47A720: r_object (marshal.c:873)
==25233==    by 0x47AF4B: PyMarshal_ReadObjectFromString (marshal.c:1053)
==25233==    by 0x47AE2A: PyMarshal_ReadLastObjectFromFile (marshal.c:1012)
==25233==    by 0x471C5B: read_compiled_module (import.c:823)
==25233==    by 0x47230C: load_source_module (import.c:1043)

----------
assignee: amaury.forgeotdarc
components: Interpreter Core
messages: 119227
nosy: amaury.forgeotdarc, benjamin.peterson, pitrou, skrah
priority: normal
severity: normal
status: open
title: Memory leak (r70152)
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Wed Oct 20 22:54:22 2010
From: report at bugs.python.org (Bob Halley)
Date: Wed, 20 Oct 2010 20:54:22 +0000
Subject: [New-bugs-announce] [issue10158] BadInternalCall running
	test_multiprocessing
In-Reply-To: <1287608062.36.0.615501498317.issue10158@psf.upfronthosting.co.za>
Message-ID: <1287608062.36.0.615501498317.issue10158@psf.upfronthosting.co.za>


New submission from Bob Halley <halley at dnspython.org>:

For reasons not germane to this bug report, I was running a modified Python 2.7 where PyTrash_UNWIND_LEVEL in Include/object.h had been defined to 10 instead of 50.

With such a python, running test_multiprocessing causes a BadInternalCall to be triggered at line 903 of weakrefobject.c.

test_finalize (__main__.WithProcessesTestFinalize) ... Process Process-18:
Traceback (most recent call last):
  File "/Users/halley/src/release27-maint/Lib/multiprocessing/process.py", line 229, in _bootstrap
    util._run_after_forkers()
  File "/Users/halley/src/release27-maint/Lib/multiprocessing/util.py", line 125, in _run_after_forkers
    items = list(_afterfork_registry.items())
  File "/Users/halley/src/release27-maint/Lib/weakref.py", line 116, in items
    for key, wr in self.data.items():
SystemError: Objects/weakrefobject.c:903: bad argument to internal function

I'm running the head of the release27-maint branch, but the problem occurs with the released 2.7 too.

The trigger for the error is that object->ob_refcount is 1.

I stuck an abort() into the code just before the BadInternalCall, and looked at the core.  The ob_type is a Semaphore, and the last bit of the call chain is:

(gdb) bt
#0  0x00007fff8791c3d6 in __kill ()
#1  0x00007fff879bc972 in abort ()
#2  0x000000010007eb05 in PyObject_ClearWeakRefs (object=<value temporarily unavailable, due to optimizations>) at Objects/weakrefobject.c:903
#3  0x000000010006c949 in subtype_dealloc (self=0x10070a150) at Objects/typeobject.c:952
#4  0x000000010005341b in _PyTrash_destroy_chain () at Objects/object.c:2435
#5  0x000000010003bfaf in listiter_next (it=0x1006db8d0) at Objects/listobject.c:2917
#6  0x00000001000b9f16 in PyEval_EvalFrameEx (f=0x1013b91a0, throwflag=<value temporarily unavailable, due to optimizations>) at Python/ceval.c:2496
#7  0x00000001000c0966 in PyEval_EvalFrameEx (f=0x1013bcc40, throwflag=<value temporarily unavailable, due to optimizations>) at Python/ceval.c:4098
#8  0x00000001000c0966 in PyEval_EvalFrameEx (f=0x10137a500, throwflag=<value temporarily unavailable, due to optimizations>) at Python/ceval.c:4098
#9  0x00000001000c0966 in PyEval_EvalFrameEx (f=0x101374aa0, throwflag=<value temporarily unavailable, due to optimizations>) at Python/ceval.c:4098
#10 0x00000001000c1826 in PyEval_EvalCodeEx (co=0x10065d1b0, globals=<value temporarily unavailable, due to optimizations>, locals=<value temporarily unavailable, due to optimizations>, args=0x100708458, argcount=2, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3252
#11 0x0000000100037580 in function_call (func=0x100678488, arg=0x100708440, kw=0x0) at Objects/funcobject.c:526
#12 0x00000001000063e2 in PyObject_Call (func=0x100678488, arg=0x100708440, kw=0x0) at Objects/abstract.c:2529
#13 0x00000001000177bd in instancemethod_call (func=0x100678488, arg=0x100708440, kw=0x0) at Objects/classobject.c:2578
#14 0x00000001000063e2 in PyObject_Call (func=0x100704780, arg=0x1006f17d0, kw=0x0) at Objects/abstract.c:2529
#15 0x0000000100071a38 in slot_tp_init (self=<value temporarily unavailable, due to optimizations>, args=0x1006f17d0, kwds=0x0) at Objects/typeobject.c:5651
#16 0x000000010006ee75 in type_call (type=0x10130bd10, args=0x1006f17d0, kwds=0x0) at Objects/typeobject.c:726
#17 0x00000001000063e2 in PyObject_Call (func=0x10130bd10, arg=0x1006f17d0, kw=0x0) at Objects/abstract.c:2529

Note that the trashcan function _PyTrash_destroy_chain() is involved.

I don't understand this code well enough to have figured out what's going wrong yet.  I worry that there's some subtle interaction with weakrefs, subtyped objects, and the trashcan, but maybe it's something simpler!

Regards,

/Bob

----------
components: Interpreter Core
messages: 119233
nosy: rthalley
priority: normal
severity: normal
status: open
title: BadInternalCall running test_multiprocessing
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Thu Oct 21 00:40:14 2010
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Wed, 20 Oct 2010 22:40:14 +0000
Subject: [New-bugs-announce] [issue10159] rlcompleter's tests depend on dict
	order
In-Reply-To: <1287614414.29.0.153122456911.issue10159@psf.upfronthosting.co.za>
Message-ID: <1287614414.29.0.153122456911.issue10159@psf.upfronthosting.co.za>


New submission from Andreas St?hrk <andy-python at hammerhartes.de>:

Some tests in test_rlcompleter make assumptions about the order of the list of names that the completion methods of a Completer object return. That order is not guaranteed and will break when running the tests under e.g. PyPy.

The attached patch against py3k branch tries to fix that.

----------
components: Tests
files: test_rlcompleter_order.patch
keywords: patch
messages: 119240
nosy: Trundle
priority: normal
severity: normal
status: open
title: rlcompleter's tests depend on dict order
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file19308/test_rlcompleter_order.patch

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

From report at bugs.python.org  Thu Oct 21 02:10:21 2010
From: report at bugs.python.org (=?utf-8?b?zqfPgc6uz4PPhM6/z4IgzpPOtc+Jz4HOs86vzr/PhSAoQ2hyaXN0b3MgR2Vvcmdp?= =?utf-8?b?b3Up?=)
Date: Thu, 21 Oct 2010 00:10:21 +0000
Subject: [New-bugs-announce] [issue10160] operator.attrgetter slower than
	lambda after adding	dotted names ability
In-Reply-To: <1287619821.22.0.706433716481.issue10160@psf.upfronthosting.co.za>
Message-ID: <1287619821.22.0.706433716481.issue10160@psf.upfronthosting.co.za>


New submission from ??????? ???????? (Christos Georgiou) <tzot at users.sourceforge.net>:

(Discovered in that StackOverflow answer: http://stackoverflow.com/questions/3940518/3942509#3942509 ; check the comments too)

operator.attrgetter in its simplest form (i.e. with a single non-dotted name) needs more time to execute than an equivalent lambda expression.

Attached file so3940518.py runs a simple benchmark comparing: a list comprehension of plain attribute access; attrgetter; and lambda. I will append sample benchmark times at the end of the comment.

Browsing Modules/operator.c, I noticed that the dotted_getattr function was using PyUnicode_Check and (possibly) splitting on dots on *every* call of the attrgetter, which I thought to be most inefficient.

I changed the py3k-daily-snapshot source to make the PyUnicode_Check calls in the attrgetter_new function; also, I modified the algorithm to pre-parse the operator.attrgetter functions for possible dots in the names, in order for the dotted_getattr function to become speedier.

The only ?drawback? is that now operator.attrgetter raises a TypeError on creation, not on subsequent calls of the attrgetter object; this shouldn't be a compatibility problem. However, I obviously had to update both Doc/library/operator.rst and Lib/test/test_operator.py .

I am not sure whether I should attach a zip/tar file with both the attachments (the sample benchmark and the diff); so I'll attach the diff in a further comment.

On the Ubuntu server 9.10 where I made the changes, I ran the so3940518.py sample benchmark before and after the changes.

Run before the changes (third column is seconds, less is better):

list comp 0.40999999999999925 1000000
map attrgetter 1.3899999999999997 1000000
map lambda 1.0099999999999998 1000000

Run after the changes:

list comp 0.40000000000000036 1000000
map attrgetter 0.5199999999999996 1000000
map lambda 0.96 1000000

----------
assignee: docs at python
components: Documentation, Library (Lib), Tests
files: so3940518.py
messages: 119247
nosy: docs at python, tzot
priority: normal
severity: normal
status: open
title: operator.attrgetter slower than lambda after adding dotted names ability
versions: Python 3.2
Added file: http://bugs.python.org/file19310/so3940518.py

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

From report at bugs.python.org  Thu Oct 21 02:14:05 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Oct 2010 00:14:05 +0000
Subject: [New-bugs-announce] [issue10161] unittest: use ascii() instead of
	repr() to display	values on error
In-Reply-To: <1287620045.08.0.616475344874.issue10161@psf.upfronthosting.co.za>
Message-ID: <1287620045.08.0.616475344874.issue10161@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

On a failure, unittest does its best to display values. But sometimes, the output doesn't help me. Example:

FAIL: test_listdir (test.test_pep277.UnicodeFileTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_pep277.py", line 157, in test_listdir
    self.assertEqual(sf0, sf2)
AssertionError: Items in the first set but not the second:
'@test_18608_tmp/ ????????????'
'@test_18608_tmp/??????????????????????????????????????????'
Items in the second set but not the first:
'@test_18608_tmp/ ????????????'
'@test_18608_tmp/??????????????????????????????????????????'
'@test_18608_tmp/????????????'

This is a test on unicode filenames. I would prefer to see non-ASCII characters as \xHH or \uXXXX than strange characters or boxes.

Do you think that it is a good idea to replace calls to repr() by ascii() in the unittest library?

In Python2, repr(unicode) escapes all non-ASCII characters. But in Python3, only control characters and surrogates are escaped. So the output depends on the terminal encoding.

Write non-ASCII characters in a backtrace may also raise a new error if the terminal is unable to a character. Raise an error while printing an error is just horrible :-)

--

Attached patch is a try to replace repr() by ascii() in the unittest module. But I don't know this library, so don't trust the patch :-)

----------
components: Library (Lib), Unicode
files: unittest_ascii.patch
keywords: patch
messages: 119248
nosy: haypo
priority: normal
severity: normal
status: open
title: unittest: use ascii() instead of repr() to display values on error
versions: Python 3.2
Added file: http://bugs.python.org/file19311/unittest_ascii.patch

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

From report at bugs.python.org  Thu Oct 21 02:44:37 2010
From: report at bugs.python.org (And Clover)
Date: Thu, 21 Oct 2010 00:44:37 +0000
Subject: [New-bugs-announce] [issue10162] mimetypes read_windows_registry
	should tolerate	permissions errors
In-Reply-To: <1287621877.59.0.625449070173.issue10162@psf.upfronthosting.co.za>
Message-ID: <1287621877.59.0.625449070173.issue10162@psf.upfronthosting.co.za>


New submission from And Clover <and at doxdesk.com>:

It is relatively common to have keys in the HKEY_CLASSES_ROOT MIME database that are not readable to all users, typically written by third-party applications. (My WinXP test box has a dozen, for apps like Flash, Silverlight and Java.)

Currently, initialising mimetypes causes Python to try to read them all, and if the user running Python doesn't have permission to read a key (in particular, if the user is a low-privilege daemon user such as IUSR_...), the script that caused mimetypes to be called will error out.

This patch moves the try-block around the call to OpenKey as well as QueryValueEx, allowing the key to be skipped if unreadable.

----------
components: Library (Lib)
files: mimetypes-patch-3.2a3.patch
keywords: patch
messages: 119252
nosy: aclover
priority: normal
severity: normal
status: open
title: mimetypes read_windows_registry should tolerate permissions errors
type: feature request
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file19314/mimetypes-patch-3.2a3.patch

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

From report at bugs.python.org  Thu Oct 21 13:21:50 2010
From: report at bugs.python.org (Henry Eshbaugh)
Date: Thu, 21 Oct 2010 11:21:50 +0000
Subject: [New-bugs-announce] [issue10163] 7/200 and 7%200 show weird results
In-Reply-To: <1287660110.32.0.294845890342.issue10163@psf.upfronthosting.co.za>
Message-ID: <1287660110.32.0.294845890342.issue10163@psf.upfronthosting.co.za>


New submission from Henry Eshbaugh <newts500 at gmail.com>:

This may be happening with other numbers, but I got weird results with the modulus and division operators, after I imported the math module. I tried to do 7/200 and got 0, and 200%7 yielded 7, an impossibility with modulus.

----------
messages: 119274
nosy: Henry.Eshbaugh
priority: normal
severity: normal
status: open
title: 7/200 and 7%200 show weird results

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

From report at bugs.python.org  Thu Oct 21 14:48:17 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 21 Oct 2010 12:48:17 +0000
Subject: [New-bugs-announce] [issue10164] Add an assertBytesMultiLineEqual
	to unittest and use it	for bytes assertEqual
In-Reply-To: <1287665297.21.0.48545376383.issue10164@psf.upfronthosting.co.za>
Message-ID: <1287665297.21.0.48545376383.issue10164@psf.upfronthosting.co.za>


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

Just as with regular strings, when comparing failed output involving bytes strings it is really helpful to have a diff showing which bytes have changed.  The attached patch adds an assertMultiLineEqual method to unittest and uses it for comparing bytes in assertEqual.

The diff output is created by first breaking the byte strings into lines using 'splitlines(True)' just as in assertMultiLineEqual, but then each line is converted to a string using 'repr' before the lines sets are passed to ndiff.  This results in output containing escaped bytes, making it easier to compare the differences in the byte strings.

(NB: this patch is the end result of several attempts to make the unittest output more useful in the email package when testing bytes handling).

----------
files: bytes_multi_line_equal.diff
keywords: patch
messages: 119280
nosy: michael.foord, r.david.murray
priority: normal
severity: normal
stage: patch review
status: open
title: Add an assertBytesMultiLineEqual to unittest and use it for bytes assertEqual
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file19320/bytes_multi_line_equal.diff

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

From report at bugs.python.org  Thu Oct 21 15:31:08 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 21 Oct 2010 13:31:08 +0000
Subject: [New-bugs-announce] [issue10165] char overwrite mode is by default
	on in Python console	under Vista
In-Reply-To: <1287667868.12.0.532990029308.issue10165@psf.upfronthosting.co.za>
Message-ID: <1287667868.12.0.532990029308.issue10165@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

I never used Python console much, but now I see it has a very annoying behavior under Windows Vista. By default entered char overwrites the char under cursor. If you press Insert key once - it allows to insert key, but after you press enter - overwrite mode is back.

----------
messages: 119289
nosy: techtonik
priority: normal
severity: normal
status: open
title: char overwrite mode is by default on in Python console under Vista
versions: Python 2.7

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

From report at bugs.python.org  Thu Oct 21 17:50:14 2010
From: report at bugs.python.org (=?utf-8?q?Adam_Biela=C5=84ski?=)
Date: Thu, 21 Oct 2010 15:50:14 +0000
Subject: [New-bugs-announce] [issue10166] maximum recursion depth exceeded
	in lib\pstats.py
In-Reply-To: <1287676214.72.0.937902766344.issue10166@psf.upfronthosting.co.za>
Message-ID: <1287676214.72.0.937902766344.issue10166@psf.upfronthosting.co.za>


New submission from Adam Biela?ski <abgans at gmail.com>:

There's a bug in module lib\pstats.py, line 150. 

Let me paste a little piece of surrounding code:

    class Stats:
      (....)
        def add(self, *arg_list):
            if not arg_list: return self
            if len(arg_list) > 1: self.add(*arg_list[1:])  #Line 150, the problem is right here!
            other = arg_list[0]
            (... do some processing with first item from arg_list ...)

This is the code for adding profiling stats from multiple files (names are on arg_list) so that they can be displayed in cumulated and readable form.

As you can see it chops off the first item from the list and then uses recursion to process the rest of it. It's no wonder then that when you profiled a little too many function calls, you're bound to see RuntimeError with 'maximum recursion depth exceeded' message when you try using this. IMO this should be done with iteration instead, like:

        def add(self, *arg_list):
            if not arg_list: return self
            for other in arg_list: #Preserved variable name only for sake of comparison with previous snippet
                (... do some processing with each item from arg_list, merging results in some rightful manner ...)


You can find a patch for this issue in the attachment.

----------
components: Library (Lib)
files: pstats.patch
keywords: patch
messages: 119311
nosy: Adam.Biela?ski
priority: normal
severity: normal
status: open
title: maximum recursion depth exceeded in lib\pstats.py
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file19322/pstats.patch

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

From report at bugs.python.org  Thu Oct 21 18:05:05 2010
From: report at bugs.python.org (Alexander Collins)
Date: Thu, 21 Oct 2010 16:05:05 +0000
Subject: [New-bugs-announce] [issue10167] ESET Torgan Alert
	[python-3.1.2.amd64 ON Win7-64]
In-Reply-To: <1287677105.85.0.830529518835.issue10167@psf.upfronthosting.co.za>
Message-ID: <1287677105.85.0.830529518835.issue10167@psf.upfronthosting.co.za>


New submission from Alexander Collins <abdullah.lemon at gmail.com>:

While trying to install 3.1.2 on my windows 7. I was faced with a Trojan alert from my ESET "NOD32" anti-virus.

The link to the file: http://www.python.org/ftp/python/3.1.2/python-3.1.2.amd64.msi

A snapshot is attached.


Windows 7 x64
ESET Smart Security 4.2.64.12

----------
components: Installation
files: pythonSecurityWarningESET.png
messages: 119313
nosy: Mr.Collins
priority: normal
severity: normal
status: open
title: ESET Torgan Alert [python-3.1.2.amd64 ON Win7-64]
type: security
versions: Python 3.1
Added file: http://bugs.python.org/file19323/pythonSecurityWarningESET.png

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

From report at bugs.python.org  Thu Oct 21 18:44:29 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 21 Oct 2010 16:44:29 +0000
Subject: [New-bugs-announce] [issue10168] tkinter.Canvas.coords should
	return a list, not a map
In-Reply-To: <1287679469.77.0.585032581167.issue10168@psf.upfronthosting.co.za>
Message-ID: <1287679469.77.0.585032581167.issue10168@psf.upfronthosting.co.za>


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

Apparently a 2.x to 3.x migration artifact.  Canvas.coords() is documented as returning a list:

    def coords(self, *args):
        """Return a list of coordinates for the item given in ARGS."""

but in 3.x it returns a map object.

Attached patch fixes that.

----------
components: Tkinter
files: canvas-coords.diff
keywords: patch
messages: 119316
nosy: belopolsky
priority: normal
severity: normal
stage: unit test needed
status: open
title: tkinter.Canvas.coords should return a list, not a map
type: behavior
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file19324/canvas-coords.diff

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

From report at bugs.python.org  Thu Oct 21 19:22:08 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 21 Oct 2010 17:22:08 +0000
Subject: [New-bugs-announce] [issue10169] socket.sendto raises incorrect
	exception when passed	incorrect types
In-Reply-To: <1287681728.0.0.651147678785.issue10169@psf.upfronthosting.co.za>
Message-ID: <1287681728.0.0.651147678785.issue10169@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <invalid at example.invalid>:

>>> s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
>>> s.bind(('', 0))
>>> s.sendto(u'hell?', s.getsockname())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: sendto() takes exactly 3 arguments (2 given)
>>> s.sendto(3, s.getsockname())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: sendto() takes exactly 3 arguments (2 given)
>>> s.sendto('hello', s.getsockname())
5

The TypeError gives the wrong explanation for what's wrong.

----------
components: Library (Lib)
messages: 119320
nosy: exarkun
priority: normal
severity: normal
status: open
title: socket.sendto raises incorrect exception when passed incorrect types
type: behavior
versions: Python 2.6, Python 2.7, Python 3.2

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

From report at bugs.python.org  Thu Oct 21 22:20:11 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 21 Oct 2010 20:20:11 +0000
Subject: [New-bugs-announce] [issue10170] Relationship between turtle speed
	setting and actual	speed is not documented
In-Reply-To: <1287692411.21.0.472855700629.issue10170@psf.upfronthosting.co.za>
Message-ID: <1287692411.21.0.472855700629.issue10170@psf.upfronthosting.co.za>


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

As Terry J. Reedy mentioned in his comment on issue 7061, turtle documentation is lacking information on how speed "codes" 0-10 translate into actual turtle speed.

Attached script measures the speed of the two primitive operations that form the basis of turtle functionality at various speed settings.  The results below show highly irregular pattern.  The columns are: the speed code, time to draw a 200 unit line, time to complete a 360 degrees turn and the ratio of the two times.


         0: 0.01 0.01 0.83
         1: 1.04 2.05 0.51
         2: 0.49 1.06 0.46
         3: 0.30 0.72 0.42
         4: 0.23 0.54 0.44
         5: 0.17 0.44 0.38
         6: 0.13 0.39 0.35
         7: 0.08 0.32 0.26
         8: 0.08 0.28 0.30
         9: 0.10 0.27 0.37
        10: 0.08 0.23 0.36


>From the source code, it appears that the on-screen speed is controlled by the number of animation steps while each step takes approximately time controlled by the "delay" setting that defaults to 10 milliseconds.

The number of steps is determined by somewhat peculiar computations.  For a rotation by angle of a degrees at speed setting s, the number of steps is

       n = 2 + int(a / (3 * s))

and for drawing a line of length d,

       n = 1 +  int(d / (3 * 1.1**s * s))

I am not sure what was the reason for these choices, but I think it would be better if numeric speed code had a more direct relationship to the apparent speed.

----------
assignee: docs at python
components: Demos and Tools, Documentation
messages: 119334
nosy: belopolsky, docs at python, eric.araujo, georg.brandl, gregorlingl, terry.reedy
priority: normal
severity: normal
status: open
title: Relationship between turtle speed setting and actual speed is not documented
versions: Python 3.2

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

From report at bugs.python.org  Fri Oct 22 04:34:26 2010
From: report at bugs.python.org (Rafe Kettler)
Date: Fri, 22 Oct 2010 02:34:26 +0000
Subject: [New-bugs-announce] [issue10171] Ugly buttons in some Tkinter
	objects in Windows
In-Reply-To: <1287714866.92.0.753573590678.issue10171@psf.upfronthosting.co.za>
Message-ID: <1287714866.92.0.753573590678.issue10171@psf.upfronthosting.co.za>


New submission from Rafe Kettler <rafe.kettler at gmail.com>:

Some of the dialogs in Tkinter don't correctly show buttons in newer versions of Windows (XP, Vista, 7). Instead, they use square Win2000-and-before-type buttons. Here's some Python 2.7 code that illustrates this:

import tkMessageBox
tkMessageBox.showinfo()

import tkColorChooser
tkColorChooser.askcolor()

I attached a screenshot as well, illustrating what is meant by "ugly buttons."

I'm not sure if this is on the Tk or Tkinter side, but since the rest of Tkinter uses new-style buttons, these few objects should too (as far as I'm aware, these are the only objects that exhibit this behavior.

----------
components: Tkinter
files: uglybuttons.png
messages: 119359
nosy: rafe.kettler
priority: normal
severity: normal
status: open
title: Ugly buttons in some Tkinter objects in Windows
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file19330/uglybuttons.png

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

From report at bugs.python.org  Fri Oct 22 15:38:05 2010
From: report at bugs.python.org (Winston C. Yang)
Date: Fri, 22 Oct 2010 13:38:05 +0000
Subject: [New-bugs-announce] [issue10172] code block has no syntax coloring
In-Reply-To: <1287754685.88.0.964365557653.issue10172@psf.upfronthosting.co.za>
Message-ID: <1287754685.88.0.964365557653.issue10172@psf.upfronthosting.co.za>


New submission from Winston C. Yang <winston at cs.wisc.edu>:

The following code block in http://docs.python.org/tutorial/errors.html has no syntax coloring:

import sys

try:
    f = open('myfile.txt')
    s = f.readline()
    i = int(s.strip())
except IOError as (errno, strerror):
    print "I/O error({0}): {1}".format(errno, strerror)
except ValueError:
    print "Could not convert data to an integer."
except:
    print "Unexpected error:", sys.exc_info()[0]
    raise

----------
assignee: docs at python
components: Documentation
messages: 119382
nosy: docs at python, wcyang
priority: normal
severity: normal
status: open
title: code block has no syntax coloring
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat Oct 23 00:36:33 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Oct 2010 22:36:33 +0000
Subject: [New-bugs-announce] [issue10173] Don't pickle TestCase instances in
	test_multiprocessing
In-Reply-To: <1287786993.14.0.756780399794.issue10173@psf.upfronthosting.co.za>
Message-ID: <1287786993.14.0.756780399794.issue10173@psf.upfronthosting.co.za>


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

unittest.TestCase instances aren't supposed to be picklable, but test_multiprocessing does it anyway (under Windows). Here is a patch.

----------
components: Tests
files: tmp.patch
keywords: patch
messages: 119407
nosy: asksol, jnoller, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Don't pickle TestCase instances in test_multiprocessing
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file19337/tmp.patch

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

From report at bugs.python.org  Sat Oct 23 01:22:19 2010
From: report at bugs.python.org (Simon de Vlieger)
Date: Fri, 22 Oct 2010 23:22:19 +0000
Subject: [New-bugs-announce] [issue10174] multiprocessing expects sys.stdout
	to have a	fileno/close method.
In-Reply-To: <1287789739.18.0.21420008091.issue10174@psf.upfronthosting.co.za>
Message-ID: <1287789739.18.0.21420008091.issue10174@psf.upfronthosting.co.za>


New submission from Simon de Vlieger <simon at ikanobori.jp>:

When I have replaced sys.stdin with my own file-like object and I try to do a multiprocessing.Pool(processes=x) I get errors about sys.stdin not having a fileno or close method.

For at least fileno it is described in the docs (http://docs.python.org/library/stdtypes.html#file-objects) that if your object is not a real file you should not implement it.

This happens to me on Mac OS X, I will add the traceback a bit later as I am currently not on my Mac.

----------
components: None
messages: 119408
nosy: ikanobori
priority: normal
severity: normal
status: open
title: multiprocessing expects sys.stdout to have a fileno/close method.
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Sat Oct 23 03:02:24 2010
From: report at bugs.python.org (Tom Fogal)
Date: Sat, 23 Oct 2010 01:02:24 +0000
Subject: [New-bugs-announce] [issue10175] vs version for win32 compilation
	of extension modules is	undocumented.
In-Reply-To: <1287795744.75.0.288699311556.issue10175@psf.upfronthosting.co.za>
Message-ID: <1287795744.75.0.288699311556.issue10175@psf.upfronthosting.co.za>


New submission from Tom Fogal <tfogal at alumni.unh.edu>:

I have recently attempted to install a couple third party packages (zope.interface and dulwech, FWIW) and encountered great difficulties.  In particular, the setup complained that it could not find "vcvarsall.bat".  Even running these setup scripts from a VC++ 2010 Express command shell gave the error.

Through browsing this bug database, specifically bugs 5235, 7511, and 2513, I have determined that the 'official' python.org binary is built with either VS 2008 or VS 2008 Express, I'm not sure which yet, but it does not really matter.

Setting DISTUTILS_USE_SDK and MSSdk to 1 and manually running the script, as suggested in one of the bug reports, does get by the issue of finding "vcvarsall.bat".  As one might guess, this only results in a confusing error message during compilation (c1010070, "Failed to load and parse the manifest"), presumably because vs2008 binaries are not compatible with vs2010 output files.

This bug isn't so much about the incompatibility as to the difficulty in diagnosing the issue.  It seems that trying to figure out which VS was used to compile a particular version of python is stored within a puzzle of bug reports.  Could this be listed on the download page, e.g.:

   http://www.python.org/download/releases/2.6.6/

?  Of course, it would be ideal if multiple binaries existed, so that someone in my position could say, "Oh, I don't even have 2008 installed; I should go with the 2010-compiled version", or vice-versa.  In the absence of that, simply knowing which version I'll need for extension modules is nice.

----------
components: Extension Modules
messages: 119410
nosy: tfogal
priority: normal
severity: normal
status: open
title: vs version for win32 compilation of extension modules is undocumented.
type: compile error
versions: Python 2.6

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

From report at bugs.python.org  Sat Oct 23 12:31:26 2010
From: report at bugs.python.org (ptz)
Date: Sat, 23 Oct 2010 10:31:26 +0000
Subject: [New-bugs-announce] [issue10176] telnetlib.Telnet.read_very_eager()
	performance
In-Reply-To: <1287829886.22.0.155091946841.issue10176@psf.upfronthosting.co.za>
Message-ID: <1287829886.22.0.155091946841.issue10176@psf.upfronthosting.co.za>


New submission from ptz <pptzpp at gmail.com>:

In Python 2.4, Assuming we've imported telnetlib, the following works:

    >>> f = telnetlib.Telnet("some_text_based_server")
    >>> f.read_very_eager()

The last call outputs the text that the server outputs upon connection (e.g. "login: ").

However, if we put this inside a function it does not work:

    >>> def g():
    ...   f = telnetlib.Telnet("server")
    ...   data = f.read_very_eager()
    ...   print data
    ...
    >>> g()

This returns the empty string. I believe this indicates that the data from the server isn't cooked. 

Note that if we use read_until() instead of read_very_eager(), everything works as expected, further supporting the hypothesis that data doesn't cook properly when the functions are called as above.

So why the difference?

----------
components: Library (Lib)
messages: 119423
nosy: ptz
priority: normal
severity: normal
status: open
title: telnetlib.Telnet.read_very_eager() performance
type: behavior
versions: 3rd party

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

From report at bugs.python.org  Sat Oct 23 14:21:38 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 23 Oct 2010 12:21:38 +0000
Subject: [New-bugs-announce] [issue10177] PyUnicode_AsWideCharString and
	PyMem_Free
In-Reply-To: <1287836498.58.0.900203329868.issue10177@psf.upfronthosting.co.za>
Message-ID: <1287836498.58.0.900203329868.issue10177@psf.upfronthosting.co.za>


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

Hello. I found several codes using PyMem_Free to free
allocated memory via PyUnicode_AsWideCharString.
In PyUnicode_AsWideCharString, memory is allocated
with PyMem_MALLOC. Is it OK to use PyMem_Free
not PyMem_FREE? Thank you.

----------
keywords: easy
messages: 119424
nosy: ocean-city
priority: normal
severity: normal
status: open
title: PyUnicode_AsWideCharString and PyMem_Free
type: resource usage
versions: Python 3.2

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

From report at bugs.python.org  Sat Oct 23 16:05:25 2010
From: report at bugs.python.org (samwyse)
Date: Sat, 23 Oct 2010 14:05:25 +0000
Subject: [New-bugs-announce] [issue10178] PEP 378 uses replace where
	translate may work better
In-Reply-To: <1287842725.3.0.632950856337.issue10178@psf.upfronthosting.co.za>
Message-ID: <1287842725.3.0.632950856337.issue10178@psf.upfronthosting.co.za>


New submission from samwyse <samwyse at gmail.com>:

PEP 378 states;

  format(n, "6,f").replace(",", "X").replace(".", ",").replace("X", ".")

This is complex and relatively slow.  A better technique, which IMHO the proposal should high-lighted, would be:

  swap_commas_and_periods = bytes.maketrans(b',.', b'.,')
  format(n, "6,f").translate(swap_commas_and_periods)

While performing the maketrans each time a string is formatted is slower than the triple replace, calling it once and caching the result is faster.  I have tested with with the 3.1 interpreter; example timings follow.

>>> Timer("""
  '1,234,567.89'.replace(',', 'X').replace('.', ',').replace('X', '.')
""").timeit()
3.0645400462908015

>>> Timer("""
  '1,234,567.89'.translate(swap_commas_and_periods)
""", """
  swap_commas_and_periods = bytes.maketrans(b',.', b'.,')
""").timeit()
2.276630409730846


>>> Timer("""
  '1,234,567.89'.translate(bytes.maketrans(b',.', b'.,'))
""").timeit()
3.760715677551161

----------
assignee: docs at python
components: Documentation
messages: 119427
nosy: docs at python, samwyse
priority: normal
severity: normal
status: open
title: PEP 378 uses replace where translate may work better
type: behavior
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Sat Oct 23 16:52:04 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Oct 2010 14:52:04 +0000
Subject: [New-bugs-announce] [issue10179] os.stat fails on mapped network
	drive
In-Reply-To: <1287845524.9.0.573963701431.issue10179@psf.upfronthosting.co.za>
Message-ID: <1287845524.9.0.573963701431.issue10179@psf.upfronthosting.co.za>


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

This network drive is actually mapped through the VirtualBox guest additions. Under Python 2.7 (official 64-bit MSI installer), this works fine:

>>> s = 'Z:\\__svn__\\Lib\\test\\keycert.pem'
>>> os.stat(s)
nt.stat_result(st_mode=33206, st_ino=0L, st_dev=0, st_nlink=0, st_uid=0, st_gid=0, st_size=1783L, st_atime=1287771307L, st_mtime=1286578916L, st_ctime=1286578916L)

Under a freshly compiled 32-bit py3k, though, it fails with a rather strange error message:

>>> s = 'Z:\\__svn__\\Lib\\test\\keycert.pem'
>>> os.stat(s)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
WindowsError: [Error 1] Incorrect function: 'Z:\\__svn__\\Lib\\test\\keycert.pem'
>>> errno.errorcode[1]
'EPERM'

While a local directory works fine:

>>> os.stat('c:\\Windows')
nt.stat_result(st_mode=16895, st_ino=0, st_dev=0, st_nlink=0, st_uid=0, st_gid=0, st_size=16384, st_atime=1287843075, st_mtime=1287843075, st_ctime=1247541608)

----------
components: Extension Modules
messages: 119430
nosy: brian.curtin, ocean-city, pitrou, tim.golden
priority: critical
severity: normal
status: open
title: os.stat fails on mapped network drive
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sat Oct 23 19:19:27 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Oct 2010 17:19:27 +0000
Subject: [New-bugs-announce] [issue10180] File objects should not pickleable
In-Reply-To: <1287854367.84.0.526587779087.issue10180@psf.upfronthosting.co.za>
Message-ID: <1287854367.84.0.526587779087.issue10180@psf.upfronthosting.co.za>


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

In Python 3, pickle accepts to serialize a file object, but the result is nonsensical when unpickled. I think we should explicitly forbid pickling of FileIO, Buffered{Reader,Writer} and TextIOWrapper objects.

----------
components: IO, Library (Lib)
messages: 119450
nosy: alexandre.vassalotti, amaury.forgeotdarc, benjamin.peterson, pitrou
priority: normal
severity: normal
status: open
title: File objects should not pickleable
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sat Oct 23 20:22:38 2010
From: report at bugs.python.org (Roger Upole)
Date: Sat, 23 Oct 2010 18:22:38 +0000
Subject: [New-bugs-announce] [issue10181] get_shape0 in memoryobject.c not
	checked for error return
In-Reply-To: <1287858158.95.0.0752296181045.issue10181@psf.upfronthosting.co.za>
Message-ID: <1287858158.95.0.0752296181045.issue10181@psf.upfronthosting.co.za>


New submission from Roger Upole <rupole at hotmail.com>:

There are a number of places in memoryobject.c where get_shape0 is used without the return value being checked.  If it fails, this leads to hanging exceptions and crashes.

----------
components: Interpreter Core
messages: 119460
nosy: rupole
priority: normal
severity: normal
status: open
title: get_shape0 in memoryobject.c not checked for error return
type: crash
versions: Python 3.2

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

From report at bugs.python.org  Sat Oct 23 20:37:51 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 23 Oct 2010 18:37:51 +0000
Subject: [New-bugs-announce] [issue10182] match_start truncates large values
In-Reply-To: <1287859071.54.0.617398147143.issue10182@psf.upfronthosting.co.za>
Message-ID: <1287859071.54.0.617398147143.issue10182@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

_sre.c:match_start currently uses Py_BuildValue("i") to return the start index, which itself is of type Py_ssize_t. This will get truncated on x64 Windows if the start is > 2**31. PyInt_FromSsize_t should be used instead. Other usages of Py_BuildValue should be reviewed as well.

----------
messages: 119462
nosy: loewis
priority: normal
severity: normal
status: open
title: match_start truncates large values
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat Oct 23 20:54:11 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Oct 2010 18:54:11 +0000
Subject: [New-bugs-announce] [issue10183] test_concurrent_futures failure on
	Windows
In-Reply-To: <1287860051.06.0.49357269827.issue10183@psf.upfronthosting.co.za>
Message-ID: <1287860051.06.0.49357269827.issue10183@psf.upfronthosting.co.za>


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

I get this failure quite reliably on a Windows 7 VM, in both 32-bit and 64-bit builds:

======================================================================
FAIL: test_map_timeout (test.test_concurrent_futures.ProcessPoolExecutorTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Y:\py3k\__svn__\lib\test\test_concurrent_futures.py", line 572, in test_map_timeout
    self.assertEquals([42, 42], results)
AssertionError: Lists differ: [42, 42] != []

First list contains 2 additional elements.
First extra element 0:
42

- [42, 42]
+ []

----------
assignee: bquinlan
components: Library (Lib)
messages: 119466
nosy: bquinlan, pitrou
priority: normal
severity: normal
status: open
title: test_concurrent_futures failure on Windows
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sat Oct 23 21:06:40 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 23 Oct 2010 19:06:40 +0000
Subject: [New-bugs-announce] [issue10184] tarfile touches directories twice
In-Reply-To: <1287860800.8.0.977653393639.issue10184@psf.upfronthosting.co.za>
Message-ID: <1287860800.8.0.977653393639.issue10184@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

When extracting, the time stamps of directories are modified twice: once when creating the directories, and then once in reverse order when done.
The first utimes call is redundant; it also causes issues with a buggy NFS server, see

http://www.python.org/dev/buildbot/3.1/builders/AMD64%20debian%20parallel%203.1/builds/147/steps/test/logs/stdio

(specifically, touching a file twice with the same second-resolution time stamp will increase the microsecond counter).

The attached patch works around the issue; regardless of the NFS bug, I think that the redundant call should be eliminated.

----------
assignee: ghaering
files: tarfile.diff
keywords: patch
messages: 119467
nosy: ghaering, loewis
priority: normal
severity: normal
status: open
title: tarfile touches directories twice
Added file: http://bugs.python.org/file19345/tarfile.diff

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

From report at bugs.python.org  Sat Oct 23 21:32:15 2010
From: report at bugs.python.org (Case Van Horsen)
Date: Sat, 23 Oct 2010 19:32:15 +0000
Subject: [New-bugs-announce] [issue10185] Py_hash_t declaration needed in
	_testcapimodule
In-Reply-To: <1287862335.94.0.457424318631.issue10185@psf.upfronthosting.co.za>
Message-ID: <1287862335.94.0.457424318631.issue10185@psf.upfronthosting.co.za>


New submission from Case Van Horsen <casevh at gmail.com>:

While researching errors in issue 9778, I found a variable in _testcapimodule.c that should be declared Py_hash_t instead of long.

Patch is attached.

----------
components: Interpreter Core
files: py_hash_t_testcapimodule.diff
keywords: patch
messages: 119469
nosy: casevh
priority: normal
severity: normal
status: open
title: Py_hash_t declaration needed in _testcapimodule
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file19346/py_hash_t_testcapimodule.diff

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

From report at bugs.python.org  Sun Oct 24 01:42:05 2010
From: report at bugs.python.org (Alex)
Date: Sat, 23 Oct 2010 23:42:05 +0000
Subject: [New-bugs-announce] [issue10186] Invalid SyntaxError pointer offset
In-Reply-To: <1287877325.31.0.208364473897.issue10186@psf.upfronthosting.co.za>
Message-ID: <1287877325.31.0.208364473897.issue10186@psf.upfronthosting.co.za>


New submission from Alex <malicious.wizard at gmail.com>:

Builtin SyntaxError formatter does never point to char before last in wrong source line. traceback.format_exception() is not affected.

*** Example:
>>> raise SyntaxError('', ('', 0, 3, 'hello'))
...
    hello
      ^
SyntaxError: test
>>> raise SyntaxError('', ('', 0, 4, 'hello'))
...
    hello
       ^
SyntaxError: test
>>> raise SyntaxError('', ('', 0, 5, 'hello'))
...
    hello   # <-- note that it's not "o"
       ^
SyntaxError: test
>>> raise SyntaxError('', ('', 0, 6, 'hello'))
...
    hello
         ^
SyntaxError: test

----------
components: Interpreter Core
messages: 119479
nosy: mwizard
priority: normal
severity: normal
status: open
title: Invalid SyntaxError pointer offset
versions: Python 2.7

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

From report at bugs.python.org  Sun Oct 24 05:04:46 2010
From: report at bugs.python.org (wjm251)
Date: Sun, 24 Oct 2010 03:04:46 +0000
Subject: [New-bugs-announce] [issue10187] exec encode unicode to utf-8 str
	automatically in GBK	environment
In-Reply-To: <1287889486.79.0.122222504002.issue10187@psf.upfronthosting.co.za>
Message-ID: <1287889486.79.0.122222504002.issue10187@psf.upfronthosting.co.za>


New submission from wjm251 <wjm251 at gmail.com>:

windows Xp chinese version

see the attached file, the header was set to GBK,and the file is GBK encoded, but why the output was '\xe5\xa4\xa7'(it is utf-8 encoded of Chinese character "?")

----------
components: Library (Lib)
files: test.py
messages: 119482
nosy: wjm251
priority: normal
severity: normal
status: open
title: exec encode unicode to utf-8 str automatically in GBK environment
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file19349/test.py

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

From report at bugs.python.org  Sun Oct 24 12:53:00 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 24 Oct 2010 10:53:00 +0000
Subject: [New-bugs-announce] [issue10188] tempfile.TemporaryDirectory may
	throw errors at shutdown
In-Reply-To: <1287917580.57.0.982180579105.issue10188@psf.upfronthosting.co.za>
Message-ID: <1287917580.57.0.982180579105.issue10188@psf.upfronthosting.co.za>


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

During interpreter shutdown, modules can become unusable as module globals are set to None. This is a problem for tempfile.TemporaryDirectory, as it needs working os, os.path and stat modules in order to clean up the filesystem.

The class makes a valiant attempt at reducing the frequency of these errors, but it is ultimately useless, since the three modules internally rely on their various globals remaining valid.

Issue #812369 may be a possible solution to this problem, or perhaps even an explicit list of essential modules that are nulled out only after all other modules have been destroyed.

----------
messages: 119505
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: tempfile.TemporaryDirectory may throw errors at shutdown

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

From report at bugs.python.org  Sun Oct 24 21:22:07 2010
From: report at bugs.python.org (Alex)
Date: Sun, 24 Oct 2010 19:22:07 +0000
Subject: [New-bugs-announce] [issue10189] SyntaxError: no binding for
	nonlocal doesn't contain a	useful traceback
In-Reply-To: <1287948127.54.0.779100996642.issue10189@psf.upfronthosting.co.za>
Message-ID: <1287948127.54.0.779100996642.issue10189@psf.upfronthosting.co.za>


New submission from Alex <alex.gaynor at gmail.com>:

Given the code:

def f():
    def g():
        nonlocal a
        a = 3

Running it produces:

alex at alex-laptop:/tmp$ python3.1 test.py 
SyntaxError: no binding for nonlocal 'a' found

Compared to a different SyntaxError:

alex at alex-laptop:/tmp$ python3.1 test.py 
  File "test.py", line 1
    print a
          ^
SyntaxError: invalid syntax

----------
components: Interpreter Core
messages: 119527
nosy: alex
priority: normal
severity: normal
status: open
title: SyntaxError: no binding for nonlocal doesn't contain a useful traceback
versions: Python 3.1

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

From report at bugs.python.org  Mon Oct 25 06:44:47 2010
From: report at bugs.python.org (Dariusz Suchojad)
Date: Mon, 25 Oct 2010 04:44:47 +0000
Subject: [New-bugs-announce] [issue10190] Can
	argparse._AttributeHolder._get_kwargs become a	public API?
In-Reply-To: <1287981887.42.0.335099838745.issue10190@psf.upfronthosting.co.za>
Message-ID: <1287981887.42.0.335099838745.issue10190@psf.upfronthosting.co.za>


New submission from Dariusz Suchojad <dsuch at gefira.pl>:

Hello,

I was wondering if it were possible for the argparse._AttributeHolder._get_kwargs to become a part of the public API.

Using this method is a very convenient way to get a hold of the arguments provided by the user and it would be shame to keep it private, I for one use it in several places even though I clearly know the name starts with an underscore, it's just that reimplementing it in my code seems counter-productive, would be very nice if '_get_kwargs' became 'get_kwargs' in some future release.

Thanks for considering it!

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 119539
nosy: bethard, docs at python, dsuch
priority: normal
severity: normal
status: open
title: Can argparse._AttributeHolder._get_kwargs become a public API?
type: feature request

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

From report at bugs.python.org  Mon Oct 25 15:55:47 2010
From: report at bugs.python.org (Atsushi Odagiri)
Date: Mon, 25 Oct 2010 13:55:47 +0000
Subject: [New-bugs-announce] [issue10191] scripts files are not RECORDed.
In-Reply-To: <1288014947.33.0.874343051999.issue10191@psf.upfronthosting.co.za>
Message-ID: <1288014947.33.0.874343051999.issue10191@psf.upfronthosting.co.za>


New submission from Atsushi Odagiri <aodagx at gmail.com>:

I wrote setup.py includes scripts with distutils2, and ran `setup.py install`.
scripts were installed in scripts directory, but not recorded in .dist-info/RECORD.


I think that `distutils2._backport.shutil:copytree` should return copied filenames.

----------
assignee: tarek
components: Distutils2
files: hello.zip
messages: 119550
nosy: Atsushi.Odagiri, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: scripts files are not RECORDed.
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file19357/hello.zip

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

From report at bugs.python.org  Mon Oct 25 18:26:19 2010
From: report at bugs.python.org (hhas)
Date: Mon, 25 Oct 2010 16:26:19 +0000
Subject: [New-bugs-announce] [issue10192] 'from urllib.parse import *' does
	not import urlencode	function
In-Reply-To: <1288023979.78.0.403326103088.issue10192@psf.upfronthosting.co.za>
Message-ID: <1288023979.78.0.403326103088.issue10192@psf.upfronthosting.co.za>


New submission from hhas <hhas at users.sourceforge.net>:

Problem:

The following statement fails to import the public urlencode function into the current namespace:

    from urllib.parse import *

Solution:

Add 'urlencode' to urllib.parse.__all__.

----------
components: Library (Lib)
messages: 119558
nosy: hhas
priority: normal
severity: normal
status: open
title: 'from urllib.parse import *' does not import urlencode function
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Mon Oct 25 20:48:46 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 25 Oct 2010 18:48:46 +0000
Subject: [New-bugs-announce] [issue10193] Simplify instrospection used by
	turtle module
In-Reply-To: <1288032526.99.0.352179918003.issue10193@psf.upfronthosting.co.za>
Message-ID: <1288032526.99.0.352179918003.issue10193@psf.upfronthosting.co.za>


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

The turtle module uses introspection in order to generate module level functions.  Attached patch streamlines the introspection code by using inspect module function instead of direct access to cod object attributes.

----------
components: Library (Lib)
files: turtle-inspect.diff
keywords: patch
messages: 119569
nosy: belopolsky
priority: normal
severity: normal
status: open
title: Simplify instrospection used by turtle module
versions: Python 3.2
Added file: http://bugs.python.org/file19359/turtle-inspect.diff

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

From report at bugs.python.org  Mon Oct 25 23:48:13 2010
From: report at bugs.python.org (Peter Ingebretson)
Date: Mon, 25 Oct 2010 21:48:13 +0000
Subject: [New-bugs-announce] [issue10194] Add gc.remap() function to the gc
	module.
In-Reply-To: <1288043293.98.0.0362084529098.issue10194@psf.upfronthosting.co.za>
Message-ID: <1288043293.98.0.0362084529098.issue10194@psf.upfronthosting.co.za>


New submission from Peter Ingebretson <pingebre at yahoo.com>:

This patch implements the gc.remap() function as described in the following document:

http://doublestar.org/in-place-python-reloading/

The intended use is an enhanced module reloading mechanism, a prototype of which is described here:

http://doublestar.org/python-hot-loading-prototype/

The patch includes unit tests for gc.remap as well as documentation.  The NEWS has a TODO where the issue number would be, which needs to be updated.  The unit test suite has been run on Ubuntu 10.10 and Windows XP.

----------
components: Extension Modules
files: python_remap.diff
keywords: patch
messages: 119582
nosy: pingebretson
priority: normal
severity: normal
status: open
title: Add gc.remap() function to the gc module.
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file19361/python_remap.diff

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

From report at bugs.python.org  Tue Oct 26 02:23:49 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Tue, 26 Oct 2010 00:23:49 +0000
Subject: [New-bugs-announce] [issue10195] Memory allocation fault-injection?
In-Reply-To: <1288052629.43.0.603183515135.issue10195@psf.upfronthosting.co.za>
Message-ID: <1288052629.43.0.603183515135.issue10195@psf.upfronthosting.co.za>


New submission from Dave Malcolm <dmalcolm at redhat.com>:

We were chatting on #python-dev on possible ways of testing the correct handling of "MemoryError".

Attached is one idea: adding a sys._inject_malloc_failure() hook, letting you inject a memory-allocation (or reallocation) failure some number of allocations in the future:

>>> import sys
[52733 refs]
>>> 2 + 2
4
[52733 refs]
>>> sys._inject_malloc_failure(50)
[52733 refs]
>>> 2 + 2
MemoryError
[52747 refs]
>>> 2 + 2
4
[52747 refs]

I'm not sure how to make this useful; perhaps it could instead compare with the "serialno" in Objects/obmalloc.c so that you could set up a specific numbered allocation and have it fail (or perhaps a range of serial numbers, and expose "serialno" within the "sys" module?)

Another idea might be to randomly have some proportion of allocations fail.  Perhaps the test suite could have an option where it runs each set of tests in a separate subprocess, and sets a command-line switch to inject "random" malloc failures? (storing the seed, so that they're reproducible, on one machine at least).

----------
components: Tests
files: py3k-inject-malloc-failure.txt
messages: 119586
nosy: dmalcolm, pitrou
priority: normal
severity: normal
status: open
title: Memory allocation fault-injection?
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file19365/py3k-inject-malloc-failure.txt

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

From report at bugs.python.org  Tue Oct 26 07:33:18 2010
From: report at bugs.python.org (Bruce Sherwood)
Date: Tue, 26 Oct 2010 05:33:18 +0000
Subject: [New-bugs-announce] [issue10196] distutils.get_python_lib()
	returns	/usr/local/python3/dist-packages on Ubuntu 10.10
In-Reply-To: <1288071198.84.0.0625228182395.issue10196@psf.upfronthosting.co.za>
Message-ID: <1288071198.84.0.0625228182395.issue10196@psf.upfronthosting.co.za>


New submission from Bruce Sherwood <bruce.sherwood at gmail.com>:

Using Python 3.1 installed on Ubuntu 10.10 from the package manager, distutils.get_python_lib() returns the nonexistent location /usr/local/python3/dist-packages instead of the correct location /usr/local/python3.1/dist-packages. This subversion bug is not present in distutils.get_python_inc(), which correctly returns /usr/include/python3.1.

----------
assignee: tarek
components: Distutils
messages: 119590
nosy: Bruce.Sherwood, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: distutils.get_python_lib() returns /usr/local/python3/dist-packages on Ubuntu 10.10
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Tue Oct 26 14:19:01 2010
From: report at bugs.python.org (jldm)
Date: Tue, 26 Oct 2010 12:19:01 +0000
Subject: [New-bugs-announce] [issue10197] subprocess.getoutput fails on win32
In-Reply-To: <1288095541.88.0.426506052882.issue10197@psf.upfronthosting.co.za>
Message-ID: <1288095541.88.0.426506052882.issue10197@psf.upfronthosting.co.za>


New submission from jldm <j_l_domenech at yahoo.com>:

Hi, first of all sorry for my English.

On windows XP SP3, the following code:

import subprocess
subprocess.getoutput("dir")

returns
    '"{" is not recognized as an internal or external command,\noperable program or batch file.'

I made a workaround by changing in the file Lib/subprocess.py the line 574 (I thin in 3.2a3 is 584) (in the getstatusoutput(cmd) function definition) from:
pipe = os.popen('{ ' + cmd + '; } 2>&1', 'r')

to:
pipe = os.popen('( ' + cmd + '; ) 2>&1', 'r')

I have tested it with:

ActivePython 3.1.2.3 (ActiveState Software Inc.) based on
Python 3.1.2 (r312:79147, Mar 22 2010, 12:20:29) [MSC v.1500 32 bit (Intel)] on win32

and

Python 3.2a3 (r32a3:85355, Oct 10 2010, 17:11:45) [MSC v.1500 32 bit (Intel)] on win32


Regards from Spain.
Jos? Luis Domenech

----------
messages: 119605
nosy: jldm
priority: normal
severity: normal
status: open
title: subprocess.getoutput fails on win32
type: behavior
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Oct 26 17:35:37 2010
From: report at bugs.python.org (David Barnett)
Date: Tue, 26 Oct 2010 15:35:37 +0000
Subject: [New-bugs-announce] [issue10198] wave module writes corrupt wav
	file for zero-length	writeframes
In-Reply-To: <1288107337.09.0.986719080657.issue10198@psf.upfronthosting.co.za>
Message-ID: <1288107337.09.0.986719080657.issue10198@psf.upfronthosting.co.za>


New submission from David Barnett <davidbarnett2 at gmail.com>:

If the first call to writeframes happens to take an empty string as the data to write, then the next call to writeframes writes a 2nd header into the file, and forever after fails to patch the data length correctly.

----------
components: Library (Lib)
messages: 119609
nosy: mu_mind
priority: normal
severity: normal
status: open
title: wave module writes corrupt wav file for zero-length writeframes
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Tue Oct 26 17:48:56 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 26 Oct 2010 15:48:56 +0000
Subject: [New-bugs-announce] [issue10199] Move Demo/turtle under Lib/
In-Reply-To: <1288108136.2.0.449929547782.issue10199@psf.upfronthosting.co.za>
Message-ID: <1288108136.2.0.449929547782.issue10199@psf.upfronthosting.co.za>


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

On Tue, Oct 26, 2010 at 11:18 AM, Guido van Rossum <guido at python.org> wrote:
> On Tue, Oct 26, 2010 at 8:13 AM, Alexander Belopolsky
> <alexander.belopolsky at gmail.com> wrote:
>> The one demo that I want to find a better place for is Demo/turtle.
>
> Sure, go for it. It is a special case because the turtle module is
> also in the stdlib and these are intended for a particular novice
> audience. Anything we can do to make things easier for those people to
> get start with is probably worth it. Ideally they could just double
> click some file and the demo would fire up, with a command-line
> alternative (for the geeks among them) e.g. "python -m turtledemo" .
>
> --
> --Guido van Rossum (python.org/~guido)
>
-- "Move Demo scripts under Lib"
http://mail.python.org/pipermail/python-ideas/2010-October/008397.html

Before I prepare a patch, I would like to get an agreement on the location of the demo package.  In the order of my preference:

1. turtle.demo Pro: obvious relationship to turtle.  Cons: require converting turtle.py to a package.

2. turtledemo  Pro: BDFL's suggestion; "Flat is better than nested".  Cons: relationship to turtle module is less obvious than in #1; stdlib namespace pollution. (Turtle invasion! :-)

3. demo.turtle - probably not a good idea if not as a part of a general Demo reorganization.

Note that while I listed conversion of turtle.py to a package as a cons, it may not be a bad idea on its own.  For example, toolkit abstraction naturally belongs to submodules and procedural interface belongs to package level while OOP classes may be separated into submodules.  While I am not proposing any such changes as a part of this ticket, it may not be a bad idea to take the first step and rename turtle.py to turtle/__init__.py.

----------
assignee: belopolsky
components: Demos and Tools
messages: 119612
nosy: belopolsky
priority: normal
severity: normal
status: open
title: Move Demo/turtle under Lib/
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Tue Oct 26 18:21:31 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Tue, 26 Oct 2010 16:21:31 +0000
Subject: [New-bugs-announce] [issue10200] Documentation: "link use"?
In-Reply-To: <AANLkTim9cza8NQYbMkwELXgTvaikj_dZWX4zk-s5EgkW@mail.gmail.com>
Message-ID: <AANLkTim9cza8NQYbMkwELXgTvaikj_dZWX4zk-s5EgkW@mail.gmail.com>


New submission from Bo??tjan Mejak <bostjan.mejak at gmail.com>:

There's a bug in the docs at
http://docs.python.org/library/locale.html#access-to-message-catalogs in a
statement before the last. "A known exception to this rule are applications
that >>link use<< additional C libraries which internally invoke gettext()
 or dcgettext(). "

Either use the word "link" or "use" in that statement.

----------
files: unnamed
messages: 119614
nosy: Retro
priority: normal
severity: normal
status: open
title: Documentation: "link use"?
Added file: http://bugs.python.org/file19370/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10200>
_______________________________________
-------------- next part --------------
There&#39;s a bug in the docs at??<a href="http://docs.python.org/library/locale.html#access-to-message-catalogs">http://docs.python.org/library/locale.html#access-to-message-catalogs</a>??in a statement before the last. &quot;<span class="Apple-style-span" style="font-family: sans-serif; font-size: 16px; line-height: 20px; ">A known exception to this rule are applications that &gt;&gt;link use&lt;&lt; additional C libraries which internally invoke??<tt class="xref docutils literal" style="background-color: transparent; padding-top: 0px; padding-right: 1px; padding-bottom: 0px; padding-left: 1px; font-size: 0.95em; font-weight: bold; "><span class="pre">gettext()</span></tt>??or??<tt class="xref docutils literal" style="background-color: transparent; padding-top: 0px; padding-right: 1px; padding-bottom: 0px; padding-left: 1px; font-size: 0.95em; font-weight: bold; "><span class="pre">dcgettext()</span></tt>.??</span>&quot;<div>
<br></div><div>Either use the word &quot;link&quot; or &quot;use&quot; in that statement.</div>

From report at bugs.python.org  Tue Oct 26 18:22:49 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 26 Oct 2010 16:22:49 +0000
Subject: [New-bugs-announce] [issue10201] Fix building of socket module
	under Solaris
In-Reply-To: <1288110169.62.0.573070204064.issue10201@psf.upfronthosting.co.za>
Message-ID: <1288110169.62.0.573070204064.issue10201@psf.upfronthosting.co.za>


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

Sun/Oracle uses the following patch to fix building of the socket module, since on Solaris "netpacket/packet.h" is incompatible with its Linux counterpart. Otherwise, it fails with the following messages:

/home/antoine/py3k/gcc/Modules/socketmodule.c: In function ?makesockaddr?:
/home/antoine/py3k/gcc/Modules/socketmodule.c:1150: error: ?struct ifreq? has no member named ?ifr_ifindex?
/home/antoine/py3k/gcc/Modules/socketmodule.c:1151: error: ?SIOCGIFNAME? undeclared (first use in this function)
/home/antoine/py3k/gcc/Modules/socketmodule.c:1151: error: (Each undeclared identifier is reported only once
/home/antoine/py3k/gcc/Modules/socketmodule.c:1151: error: for each function it appears in.)
/home/antoine/py3k/gcc/Modules/socketmodule.c: In function ?getsockaddrarg?:
/home/antoine/py3k/gcc/Modules/socketmodule.c:1484: error: ?SIOCGIFINDEX? undeclared (first use in this function)
/home/antoine/py3k/gcc/Modules/socketmodule.c:1502: error: ?struct ifreq? has no member named ?ifr_ifindex?
/home/antoine/py3k/gcc/Modules/socketmodule.c: In function ?PyInit__socket?:
/home/antoine/py3k/gcc/Modules/socketmodule.c:4580: error: ?PACKET_LOOPBACK? undeclared (first use in this function)
/home/antoine/py3k/gcc/Modules/socketmodule.c:4581: error: ?PACKET_FASTROUTE? undeclared (first use in this function)



$ cat ~/spec-files/patches/Python26-17-netpacket-packet-h.diff 
--- Python-2.6.2/Modules/socketmodule.c.packet	2009-04-01 07:20:48.000000000 +1300
+++ Python-2.6.2/Modules/socketmodule.c	2009-12-01 21:25:04.133257645 +1300
@@ -81,6 +81,14 @@
 
 */
 
+#ifdef HAVE_NETPACKET_PACKET_H
+#ifdef sun
+#define USE_NETPACKET_PACKET_H 0
+#else
+#define USE_NETPACKET_PACKET_H 1
+#endif
+#endif
+
 #ifdef __APPLE__
   /*
    * inet_aton is not available on OSX 10.3, yet we want to use a binary
@@ -1092,7 +1100,7 @@
 		}
 #endif
 
-#ifdef HAVE_NETPACKET_PACKET_H
+#if USE_NETPACKET_PACKET_H
 	case AF_PACKET:
 	{
 		struct sockaddr_ll *a = (struct sockaddr_ll *)addr;
@@ -1382,7 +1390,7 @@
 	}
 #endif
 
-#ifdef HAVE_NETPACKET_PACKET_H
+#if USE_NETPACKET_PACKET_H
 	case AF_PACKET:
 	{
 		struct sockaddr_ll* addr;
@@ -1559,7 +1567,7 @@
 	}
 #endif
 
-#ifdef HAVE_NETPACKET_PACKET_H
+#if USE_NETPACKET_PACKET_H
 	case AF_PACKET:
 	{
 		*len_ret = sizeof (struct sockaddr_ll);
@@ -4575,7 +4583,7 @@
 	PyModule_AddStringConstant(m, "BDADDR_LOCAL", "00:00:00:FF:FF:FF");
 #endif
 
-#ifdef HAVE_NETPACKET_PACKET_H
+#if USE_NETPACKET_PACKET_H
 	PyModule_AddIntConstant(m, "AF_PACKET", AF_PACKET);
 	PyModule_AddIntConstant(m, "PF_PACKET", PF_PACKET);
 	PyModule_AddIntConstant(m, "PACKET_HOST", PACKET_HOST);

----------
components: Build
messages: 119615
nosy: jcea, loewis, movement, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Fix building of socket module under Solaris
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Oct 26 21:04:50 2010
From: report at bugs.python.org (John Nagle)
Date: Tue, 26 Oct 2010 19:04:50 +0000
Subject: [New-bugs-announce] [issue10202] ftplib doesn't check close status
	after sending file
In-Reply-To: <1288119890.05.0.476969255522.issue10202@psf.upfronthosting.co.za>
Message-ID: <1288119890.05.0.476969255522.issue10202@psf.upfronthosting.co.za>


New submission from John Nagle <nagle at users.sourceforge.net>:

"ftplib" doesn't check the status on socket close after writing.  This can lead to silently truncated files when sending files with "ftplib".

A report of truncated files on comp.lang.python led me to check the source code. 

The "ftplib" module does sending by calling sock_sendall in "socketmodule.c". That does an OS-level "send", and once everything has been sent, returns.

But an OS-level socket send returns when the data is queued for sending, not when it is delivered.  Only when the socket is closed, and the close status checked, do you know if the data was delivered. There's a final TCP close handshake that occurs when close has been called at both ends, and only when it completes successfully do you know that the data has been delivered.

At the socket level, this is performed by "shutdown" (which closes the connection and returns the proper network status information), or by "close".

Look at sock_close in "socketmodule.c".  Note that it ignores the return status on close, always returns None, and never raises an exception.  As the Linux manual page for "close" says:
"Not checking the return value of close() is a common but nevertheless serious programming error. It is quite possible that errors on a previous write(2) operation are first reported at the final close(). Not checking the return value when closing the file may lead to silent loss of data."

"ftplib", in "storlines" and "storbinary", calls "close" without checking the status or calling "shutdown" first.  So if the other end disconnects after all data has been queued locally but not sent, received and acknowledged, the sender will never know.

----------
components: Library (Lib)
messages: 119638
nosy: nagle
priority: normal
severity: normal
status: open
title: ftplib doesn't check close status after sending file
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Oct 26 21:11:33 2010
From: report at bugs.python.org (Paul Sokolovsky)
Date: Tue, 26 Oct 2010 19:11:33 +0000
Subject: [New-bugs-announce] [issue10203] sqlite3.Row doesn't support
	sequence protocol
In-Reply-To: <1288120293.93.0.799619941752.issue10203@psf.upfronthosting.co.za>
Message-ID: <1288120293.93.0.799619941752.issue10203@psf.upfronthosting.co.za>


New submission from Paul Sokolovsky <pfalcon at users.sourceforge.net>:

sqlite.Row class doesn't implement sequence protocol, which is rather unfortunate, because it is described and expected to work like a tuple, with extra mapping-like functionality.

Specific issue I hit:

Adding rows to PyGTK ListStore,

        model = gtk.ListStore(*db.getSchema())
        for r in listGen():
            model.append(r)

I get:

TypeError: expecting a sequence

Looking at PyGTK sources, append() method uses PySequence Check() on the argument. Looking at Python 2.6.5 abstract.c:

int
PySequence_Check(PyObject *s)
{
        if (s && PyInstance_Check(s))
                return PyObject_HasAttrString(s, "__getitem__");
        if (PyObject_IsInstance(s, (PyObject *)&PyDict_Type))
                return 0;
        return s != NULL && s->ob_type->tp_as_sequence &&
                s->ob_type->tp_as_sequence->sq_item != NULL;
}

And sqlite3.Row doesn't set ob_type->tp_as_sequence as of Py 2.6.5 or 2.7.

----------
components: Library (Lib)
messages: 119639
nosy: pfalcon
priority: normal
severity: normal
status: open
title: sqlite3.Row doesn't support sequence protocol
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Tue Oct 26 21:21:18 2010
From: report at bugs.python.org (Eric Promislow)
Date: Tue, 26 Oct 2010 19:21:18 +0000
Subject: [New-bugs-announce] [issue10204] exec string fails with trailing
	whitespace
In-Reply-To: <1288120878.97.0.786929493479.issue10204@psf.upfronthosting.co.za>
Message-ID: <1288120878.97.0.786929493479.issue10204@psf.upfronthosting.co.za>


New submission from Eric Promislow <ericp at activestate.com>:

The following code throws an exception in Python 3.1 (and 3.2 alpha),
but runs with 2.x:

>>> exec('if True:\n    print("Hello")\n    \n    ')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 4

SyntaxError: invalid syntax
>>>

This is with Python 3.1.1.2, but I can repro it with a 3.2 alpha
as well.

Ref Komodo bug http://bugs.activestate.com/show_bug.cgi?id=88566

----------
components: Interpreter Core
messages: 119640
nosy: ericp
priority: normal
severity: normal
status: open
title: exec string fails with trailing whitespace
versions: Python 3.1

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

From report at bugs.python.org  Tue Oct 26 21:40:49 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89tienne_BERSAC?=)
Date: Tue, 26 Oct 2010 19:40:49 +0000
Subject: [New-bugs-announce] [issue10205] Can't have two tags with the same
	QName
In-Reply-To: <1288122049.66.0.916624044666.issue10205@psf.upfronthosting.co.za>
Message-ID: <1288122049.66.0.916624044666.issue10205@psf.upfronthosting.co.za>


New submission from ?tienne BERSAC <bersace03 at gmail.com>:

Hi,

Here is the code to reproduce and the unexcpected behaviour?:

21:37:41 bersace at st-francois-de-sales:~/Bureau/$ cat bug.py 
from xml.etree.ElementTree import QName, ElementTree, Element, SubElement
import sys

head = Element(QName('http://www.w3.org/1999/xhtml', 'html'))
SubElement(head, QName('http://www.w3.org/1999/xhtml', 'meta'))
SubElement(head, QName('http://www.w3.org/1999/xhtml', 'meta'))

tree = ElementTree(head)
tree.write(sys.stdout, encoding="utf-8", xml_declaration=True,
           default_namespace='http://www.w3.org/1999/xhtml')
21:38:00 bersace at st-francois-de-sales:~/Bureau/$ python2.7 bug.py 
<?xml version='1.0' encoding='utf-8'?>
Traceback (most recent call last):
  File "bug.py", line 10, in <module>
    default_namespace='http://www.w3.org/1999/xhtml')
  File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 812, in write
    self._root, encoding, default_namespace
  File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 880, in _namespaces
    _raise_serialization_error(tag)
  File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 1046, in _raise_serialization_error
    "cannot serialize %r (type %s)" % (text, type(text).__name__)
TypeError: cannot serialize <xml.etree.ElementTree.QName object at 0xb76aa60c> (type QName)
21:38:01 bersace at st-francois-de-sales:~/Bureau/$ 

Patch is attached.

Regards,
?tienne

----------
components: XML
files: python2.7-fix-qname-already-registered.patch
keywords: patch
messages: 119643
nosy: bersace
priority: normal
severity: normal
status: open
title: Can't have two tags with the same QName
versions: Python 2.7
Added file: http://bugs.python.org/file19374/python2.7-fix-qname-already-registered.patch

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

From report at bugs.python.org  Tue Oct 26 22:01:28 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 26 Oct 2010 20:01:28 +0000
Subject: [New-bugs-announce] [issue10206] python program starting with
	unmatched quote spews	spaces to stdout
In-Reply-To: <1288123288.86.0.422520379457.issue10206@psf.upfronthosting.co.za>
Message-ID: <1288123288.86.0.422520379457.issue10206@psf.upfronthosting.co.za>


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

To reproduce:

  python -c "'"

(Hint: don't do this on a slow terminal)

----------
messages: 119646
nosy: r.david.murray
priority: critical
severity: normal
stage: needs patch
status: open
title: python program starting with unmatched quote spews spaces to stdout
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Wed Oct 27 00:20:25 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 26 Oct 2010 22:20:25 +0000
Subject: [New-bugs-announce] [issue10207] test_file2k crashes under Windows
In-Reply-To: <1288131625.06.0.246375636536.issue10207@psf.upfronthosting.co.za>
Message-ID: <1288131625.06.0.246375636536.issue10207@psf.upfronthosting.co.za>


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

This recurrent crash appeared recently under the XP-4 buildbot, between r85816 and r85819. But none of these revisions looks related to potential file issues.

Each time the test just finishes with:

[...]
test_file2k
program finished with exit code -1073741819

(which according to Google means access violation)

See http://www.python.org/dev/buildbot/builders/x86%20XP-4%202.7/ for test logs.

----------
components: Tests, Windows
keywords: buildbot
messages: 119655
nosy: brian.curtin, db3l, loewis, ocean-city, pitrou
priority: normal
severity: normal
status: open
title: test_file2k crashes under Windows
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Wed Oct 27 02:05:46 2010
From: report at bugs.python.org (Piotr Matuszewski)
Date: Wed, 27 Oct 2010 00:05:46 +0000
Subject: [New-bugs-announce] [issue10208] add mazovia.py to encodings/
In-Reply-To: <1288137946.29.0.185771065626.issue10208@psf.upfronthosting.co.za>
Message-ID: <1288137946.29.0.185771065626.issue10208@psf.upfronthosting.co.za>


New submission from Piotr Matuszewski <pythlea4 at farmatex.com.pl>:

mazovia is an old encoding for Polish language, it's modified cp437 (more info at http://en.wikipedia.org/wiki/Mazovia_encoding and (in Polish, but tables are useful anyway) http://pl.wikipedia.org/wiki/Mazovia_(kod) )

----------
components: Library (Lib), Unicode
files: mazovia.py
messages: 119660
nosy: matusz
priority: normal
severity: normal
status: open
title: add mazovia.py to encodings/
type: feature request
Added file: http://bugs.python.org/file19376/mazovia.py

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

From report at bugs.python.org  Wed Oct 27 02:36:36 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Oct 2010 00:36:36 +0000
Subject: [New-bugs-announce] [issue10209] Mac OS X: Decompose filenames on
	encode, and precompose filenames on decode
In-Reply-To: <1288139796.38.0.381630346424.issue10209@psf.upfronthosting.co.za>
Message-ID: <1288139796.38.0.381630346424.issue10209@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

PyUnicode_EncodeFSDefault() and os.fsencode() should decompose the filename (NFD) before encoding it to utf-8.

PyUnicode_DecodeFSDefault(AndSize)() and os.fsdecode() should precompose the filename (NFC) after decoding it from utf-8.

Qt library does this on Mac: see locale_encode()/locale_decode() (filename encoder/decoder) functions in src/corelib/io/qfile.cpp.

It should fix some issues of test_pep277 on Mac OS X (see #8423).

I'm not completly sure that we should do that :-)

(I used the nosy list from issues #4388 and #8423).

--

Technical Q&A QA1173, Text Encodings in VFS:
http://developer.apple.com/mac/library/qa/qa2001/qa1173.html

Q: I'm writing a file system (VFS) plug-in for Mac OS X. How do I handle text encodings correctly?
A: In Mac OS X's VFS API file names are, by definition, canonically decomposed Unicode, encoded using UTF-8. This raises a number of interesting issues. (...)

----------
assignee: ronaldoussoren
components: Interpreter Core, Macintosh, Unicode
messages: 119662
nosy: MrJean1, amaury.forgeotdarc, db3l, flox, haypo, ixokai, loewis, mark.dickinson, michael.foord, ned.deily, piro, pitrou, ronaldoussoren, rpetrov, skip.montanaro, slmnhq
priority: normal
severity: normal
status: open
title: Mac OS X: Decompose filenames on encode, and precompose filenames on decode
versions: Python 3.2

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

From report at bugs.python.org  Wed Oct 27 02:58:06 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Oct 2010 00:58:06 +0000
Subject: [New-bugs-announce] [issue10210] os.get_exec_path() should not
	produce any warning
In-Reply-To: <1288141086.46.0.441985990964.issue10210@psf.upfronthosting.co.za>
Message-ID: <1288141086.46.0.441985990964.issue10210@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Using -b command line option, os.get_exec_path() always produce a warning. Example:

$ ./python -b
>>> import os: os.get_exec_path({'PATH': ''})
.../Lib/os.py:395: BytesWarning: Comparison between bytes and string
  path_listb = env[b'PATH']
['']

You can see such warning on some buildbots. This function should make this warning quiet because it is expected: it is not possible to check that a dict contains 'PATH' and b'PATH' keys without emiting a BytesWarning (see issue #9636).

Attached patch fixes this bug. It imports the warnings module in get_exec_path() function because os is a core module and it should not import too much modules. But... I'm not sure that it's the right way to fix this issue.

----------
components: Library (Lib), Unicode
files: get_exec_path_byteswarning.patch
keywords: patch
messages: 119666
nosy: haypo
priority: normal
severity: normal
status: open
title: os.get_exec_path() should not produce any warning
versions: Python 3.2
Added file: http://bugs.python.org/file19378/get_exec_path_byteswarning.patch

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

From report at bugs.python.org  Wed Oct 27 10:49:12 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 27 Oct 2010 08:49:12 +0000
Subject: [New-bugs-announce] [issue10211] BufferObject doesn't support new
	buffer interface
In-Reply-To: <1288169352.49.0.219368546772.issue10211@psf.upfronthosting.co.za>
Message-ID: <1288169352.49.0.219368546772.issue10211@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

The BufferObject in 2.7 doesn't support the new buffer interface.
This makes it useless for use with the new memoryview object.
This simple patch adds that support.

----------
components: Interpreter Core
files: buffer_newbuf.patch
keywords: easy, patch
messages: 119683
nosy: krisvale
priority: normal
severity: normal
status: open
title: BufferObject doesn't support new buffer interface
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file19381/buffer_newbuf.patch

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

From report at bugs.python.org  Wed Oct 27 12:36:53 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 27 Oct 2010 10:36:53 +0000
Subject: [New-bugs-announce] [issue10212] struct.unpack and
	cStringIO.StringIO don't support new	buffer
In-Reply-To: <1288175813.33.0.0310491559114.issue10212@psf.upfronthosting.co.za>
Message-ID: <1288175813.33.0.0310491559114.issue10212@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

When doing socket IO, it is beneficial to use a bytearra() and then using sock.recv_into() to avoid moving data about.
However, many useful functions still don't accept new style buffers, such as the bytearray and memoryview.  In particular, the struct module cannot unpack from them, and the StringIO doesn't accept them as input.

The attached patch adds new-buffer support to the struct module and cStringIO.

----------
components: Interpreter Core
files: newbuffer.patch
keywords: needs review, patch
messages: 119687
nosy: krisvale
priority: normal
severity: normal
status: open
title: struct.unpack and cStringIO.StringIO don't support new buffer
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file19382/newbuffer.patch

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

From report at bugs.python.org  Wed Oct 27 13:51:26 2010
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Wed, 27 Oct 2010 11:51:26 +0000
Subject: [New-bugs-announce] [issue10213] tests shouldn't fail with unset
	timezone
In-Reply-To: <1288180286.09.0.61662115749.issue10213@psf.upfronthosting.co.za>
Message-ID: <1288180286.09.0.61662115749.issue10213@psf.upfronthosting.co.za>


New submission from Dirkjan Ochtman <dirkjan at ochtman.nl>:

test_strptime in test_time fails when the timezone is not set:

======================================================================
FAIL: test_strptime (test.test_time.TimeTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/var/tmp/portage/dev-lang/python-2.6.4/work/Python-2.6.4/Lib/test/test_time.py",
line 117, in test_strptime
    (format, strf_output))
AssertionError: conversion specifier '%Z' failed with 'Local time zone must be set--see zic manual page' input.

----------------------------------------------------------------------
Ran 14 tests in 1.206s
Maybe something like this is good enough?

Index: test_time.py
===================================================================
--- test_time.py        (revision 85856)
+++ test_time.py        (working copy)
@@ -111,6 +111,8 @@
             try:
                 time.strptime(strf_output, format)
             except ValueError:
+                if 'Local time zone must be set' in strf_output:
+                    continue
                 self.fail("conversion specifier %r failed with '%s' input." %
                           (format, strf_output))

----------
components: Tests
messages: 119696
nosy: belopolsky, djc
priority: normal
severity: normal
status: open
title: tests shouldn't fail with unset timezone
versions: Python 2.6

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

From report at bugs.python.org  Wed Oct 27 15:13:08 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 27 Oct 2010 13:13:08 +0000
Subject: [New-bugs-announce] [issue10214] Misc/python-mode.el is out of date.
In-Reply-To: <1288185188.37.0.749151956354.issue10214@psf.upfronthosting.co.za>
Message-ID: <1288185188.37.0.749151956354.issue10214@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

Misc/python-mode.el is pretty far out of date.  http://launchpad.net/python-mode has the latest versions.  Of course, there's also python.el that comes with GNU Emacs.

I will replace Misc/python-mode.el with Misc/README.Emacs

----------
assignee: barry
messages: 119709
nosy: barry
priority: normal
severity: normal
status: open
title: Misc/python-mode.el is out of date.
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed Oct 27 22:38:14 2010
From: report at bugs.python.org (Bruce Sherwood)
Date: Wed, 27 Oct 2010 20:38:14 +0000
Subject: [New-bugs-announce] [issue10215] Mac Python 3.1 installer does less
	than earlier	installers
In-Reply-To: <1288211894.49.0.439153814714.issue10215@psf.upfronthosting.co.za>
Message-ID: <1288211894.49.0.439153814714.issue10215@psf.upfronthosting.co.za>


New submission from Bruce Sherwood <bruce.sherwood at gmail.com>:

For Python 2.x on Macs, the installer added PATH code to .profile and switched /Library/Framework/Python.framework/Versions/Current to point to the newly installed version of Python. Neither of these actions is carried out by the 3.1.2 installer, and I wonder whether this is intentional or an oversight. Also, it's not clear to me what command one could issue in a terminal to execute the new Python (you can of course start the new Python from the Applications folder).

----------
components: Installation
messages: 119731
nosy: Bruce.Sherwood
priority: normal
severity: normal
status: open
title: Mac Python 3.1 installer does less than earlier installers
type: feature request
versions: Python 3.1

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

From report at bugs.python.org  Wed Oct 27 22:41:17 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 27 Oct 2010 20:41:17 +0000
Subject: [New-bugs-announce] [issue10216] json.loads() on str erroneously
	returns str
In-Reply-To: <1288212077.55.0.987280574244.issue10216@psf.upfronthosting.co.za>
Message-ID: <1288212077.55.0.987280574244.issue10216@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

json is defined as mapping the JSON string type into unicodes.  This works as advertised in Python 2.6 and 3, but in Python 2.7 it returns a str.

% python2.6 -c "import json; print json.loads('{\"foo\":\"bar\"}')"
{u'foo': u'bar'}
% python2.7 -c "import json; print json.loads('{\"foo\":\"bar\"}')"
{'foo': 'bar'}

Platform tested so far: Ubuntu 10.10 amd64.

----------
messages: 119732
nosy: barry
priority: critical
severity: normal
status: open
title: json.loads() on str erroneously returns str
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Oct 28 04:58:26 2010
From: report at bugs.python.org (Manfred Bartz)
Date: Thu, 28 Oct 2010 02:58:26 +0000
Subject: [New-bugs-announce] [issue10217] python-2.7.amd64.msi install fails
In-Reply-To: <1288234706.92.0.436900381953.issue10217@psf.upfronthosting.co.za>
Message-ID: <1288234706.92.0.436900381953.issue10217@psf.upfronthosting.co.za>


New submission from Manfred Bartz <manfred.bartz at gmail.com>:

python-2.7.amd64.msi as well as python-2.6.6.amd64.msi fail to install on a Windows7-64 system.  In both cases with: "An error occurred during the installation of assembly 'Microsoft.VC90.CRT,version=9.0.21022.8 ...'"

See attached screen-cap.

The installer succeeds with its automatic roll-back.

python-2.7.msi (32bit installer) succeeds without any problems.

----------
components: Installation, Windows
files: Python-64bit_on_Win7-64_install_fails.png
messages: 119753
nosy: Manfred.Bartz
priority: normal
severity: normal
status: open
title: python-2.7.amd64.msi install fails
type: crash
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file19391/Python-64bit_on_Win7-64_install_fails.png

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

From report at bugs.python.org  Thu Oct 28 09:34:22 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 28 Oct 2010 07:34:22 +0000
Subject: [New-bugs-announce] [issue10218] Add a return value to
	threading.Condition.wait()
In-Reply-To: <1288251262.79.0.658149458375.issue10218@psf.upfronthosting.co.za>
Message-ID: <1288251262.79.0.658149458375.issue10218@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

Add a return value to Condition.wait() that can be used to tell if Condition.wait() returns due to a timeout effect.  This mirrors other wait apis in threading.py

----------
components: Library (Lib)
files: condwait.patch
keywords: patch
messages: 119763
nosy: georg.brandl, krisvale
priority: normal
severity: normal
status: open
title: Add a return value to threading.Condition.wait()
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file19393/condwait.patch

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

From report at bugs.python.org  Thu Oct 28 13:43:18 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 28 Oct 2010 11:43:18 +0000
Subject: [New-bugs-announce] [issue10219] BufferedReader.read1 does not
	check for closed file
In-Reply-To: <1288266198.95.0.214499177882.issue10219@psf.upfronthosting.co.za>
Message-ID: <1288266198.95.0.214499177882.issue10219@psf.upfronthosting.co.za>


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

The following snippet should raise ValueError (twice :-)

f = open('foo', 'rb')
print(f.read1(1)) # OK
f.close()
print(f.read1(5)) # expected ValueError("I/O operation on closed file")
print(f.peek())   # expected ValueError("I/O operation on closed file")

The _pyio implementation of BufferedReader.read() has the same issue.

----------
messages: 119771
nosy: amaury.forgeotdarc, pitrou
priority: normal
severity: normal
status: open
title: BufferedReader.read1 does not check for closed file

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

From report at bugs.python.org  Thu Oct 28 14:42:53 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 28 Oct 2010 12:42:53 +0000
Subject: [New-bugs-announce] [issue10220] Make generator state easier to
	introspect
In-Reply-To: <1288269773.83.0.431465195808.issue10220@psf.upfronthosting.co.za>
Message-ID: <1288269773.83.0.431465195808.issue10220@psf.upfronthosting.co.za>


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

Generators can be in four different states that may be relevant to framework code making use of them (especially as coroutines). This state is all currently available from Python code, but is rather obscure and could be made readable.

The four states are:

Created:
  "g.gi_frame is not None and g.gi_frame.f_lasti == -1"
  (Frame exists, but no instructions have been executed yet)

Currently executing:
  "g.gi_running"
  (This being true implies other things about the state as well, but this is all you need to check)

Suspended at a yield point:
  "g.gi_frame is not None and g.gi_frame.f_lasti != -1 and not g.gi_running"

Exhausted/closed:
  "g.gi_frame is None"

My API proposal is to add the following to the inspect module:

GEN_CREATED, GEN_RUNNING, GEN_SUSPENDED, GEN_CLOSED = range(4)

def getgeneratorstate(g):
  if g.gi_running:
    return GEN_RUNNING
  if g.gi_frame is None:
    return GEN_CLOSED
  if g.gi_frame.f_lasti == -1:
    return GEN_CREATED
  return GEN_SUSPENDED

(the lack of underscores in the function name follows the general style of the inspect module)

----------
components: Library (Lib)
keywords: easy
messages: 119774
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Make generator state easier to introspect
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Thu Oct 28 15:26:42 2010
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Thu, 28 Oct 2010 13:26:42 +0000
Subject: [New-bugs-announce] [issue10221] {}.pop('a') raises non-standard
	KeyError exception
In-Reply-To: <1288272402.21.0.117850725041.issue10221@psf.upfronthosting.co.za>
Message-ID: <1288272402.21.0.117850725041.issue10221@psf.upfronthosting.co.za>


New submission from Dirkjan Ochtman <dirkjan at ochtman.nl>:

djc at miles ~ $ python2.7
Python 2.7 (r27:82500, Oct  4 2010, 10:01:41)
[GCC 4.3.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> {}.pop('a')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: 'pop(): dictionary is empty'
>>> {'a': 'b'}.pop('c')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: 'c'

IMO the former exception should be in line with normal KeyErrors.

----------
messages: 119778
nosy: djc
priority: normal
severity: normal
status: open
title: {}.pop('a') raises non-standard KeyError exception

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

From report at bugs.python.org  Thu Oct 28 21:44:14 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 28 Oct 2010 19:44:14 +0000
Subject: [New-bugs-announce] [issue10222] 3.2 on AIX -  Unexpected text ',
	' encountered.
In-Reply-To: <1288295054.95.0.251729908149.issue10222@psf.upfronthosting.co.za>
Message-ID: <1288295054.95.0.251729908149.issue10222@psf.upfronthosting.co.za>


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

"Parser/tokenizer.h", line 18.17: 1506-275 (S) Unexpected text ',' encountered.

http://svn.python.org/view/python/branches/py3k/Parser/tokenizer.h?annotate=76232#l16

Extra comma in the following line:

  STATE_NORMAL, /* have a codec associated with input */

Introduced by neil.schem in r58226

----------
components: Build
messages: 119809
nosy: nascheme, srid
priority: normal
severity: normal
status: open
title: 3.2 on AIX -  Unexpected text ',' encountered.
type: compile error
versions: Python 3.2

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

From report at bugs.python.org  Fri Oct 29 00:13:09 2010
From: report at bugs.python.org (EcmaXp)
Date: Thu, 28 Oct 2010 22:13:09 +0000
Subject: [New-bugs-announce] [issue10223] socket.gethostname() fail
In-Reply-To: <1288303989.88.0.633861339057.issue10223@psf.upfronthosting.co.za>
Message-ID: <1288303989.88.0.633861339057.issue10223@psf.upfronthosting.co.za>


New submission from EcmaXp <admin at ecmaxp.pe.kr>:

C:\Users\PC-\Desktop>c:\python31\python
Python 3.1.2 (r312:79149, Mar 21 2010, 00:41:52) [MSC v.1500 32 bit (Intel)] on
win32
Type ?help?, ?copyright?, ?credits? or ?license? for more information.
>>> import socket
>>> socket.gethostname()
Traceback (most recent call last):
  File ?<stdin>?, line 1, in <module>
UnicodeDecodeError: ?utf8? codec can?t decode bytes in position 0-1: invalid data
>>>

socket.gethostname() fail when system name is korean on Window Vista

[...

----------
components: Library (Lib)
messages: 119818
nosy: EcmaXp
priority: normal
severity: normal
status: open
title: socket.gethostname() fail
type: crash
versions: Python 3.1

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

From report at bugs.python.org  Fri Oct 29 00:16:39 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 28 Oct 2010 22:16:39 +0000
Subject: [New-bugs-announce] [issue10224] Build 3.x documentation using
	python3.x
In-Reply-To: <1288304199.49.0.7053863257.issue10224@psf.upfronthosting.co.za>
Message-ID: <1288304199.49.0.7053863257.issue10224@psf.upfronthosting.co.za>


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

Opening a ticket to track the progress of getting python 3.x build its own documentation.

So far I have installed Sphinx from http://bitbucket.org/birkenfeld/sphinx, but I get the following error:

$ sphinx-build -b html -d Doc/build3/doctrees -D latex_paper_size=  Doc  Doc/build3/html


There is a syntax error in your configuration file: invalid syntax (patchlevel.py, line 71)
Did you change the syntax from 2.x to 3.x?

----------
messages: 119819
nosy: belopolsky
priority: normal
severity: normal
status: open
title: Build 3.x documentation using python3.x

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

From report at bugs.python.org  Fri Oct 29 04:18:55 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 29 Oct 2010 02:18:55 +0000
Subject: [New-bugs-announce] [issue10225] Fix doctest runable examples in
	python manual
In-Reply-To: <1288318735.45.0.959857258913.issue10225@psf.upfronthosting.co.za>
Message-ID: <1288318735.45.0.959857258913.issue10225@psf.upfronthosting.co.za>


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

As noted in issue 10224, python 3.x documentation is not being built with python 3.x yet, so a simple cd Doc; make doctest does not work.  However, hg trunk version os sphinx works with python 3.x and can be used to validate examples in ReST documentation.

----------
assignee: belopolsky
components: Documentation
messages: 119840
nosy: belopolsky
priority: normal
severity: normal
stage: needs patch
status: open
title: Fix doctest runable examples in python manual
versions: Python 3.2

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

From report at bugs.python.org  Fri Oct 29 07:26:06 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 29 Oct 2010 05:26:06 +0000
Subject: [New-bugs-announce] [issue10226] urlparse example is wrong
In-Reply-To: <1288329966.05.0.0344146922962.issue10226@psf.upfronthosting.co.za>
Message-ID: <1288329966.05.0.0344146922962.issue10226@psf.upfronthosting.co.za>


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

The following example in Doc/library/urlparse.rst is wrong

>>> urlparse('www.cwi.nl:80/%7Eguido/Python.html')
ParseResult(scheme='', netloc='', path='www.cwi.nl:80/%7Eguido/Python.html',
           params='', query='', fragment='')

In the actual output, scheme='www.cwi.nl'.

In addition, the preceding text is confusing and probably not grammatical:

"""
Otherwise, it is not possible to distinguish between netloc and path components, and would the indistinguishable component would be classified as the path as in a relative URL.
"""

Discovered while working on issue 10225.

----------
assignee: docs at python
components: Documentation
messages: 119855
nosy: belopolsky, docs at python
priority: normal
severity: normal
status: open
title: urlparse example is wrong
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Oct 29 10:50:28 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 29 Oct 2010 08:50:28 +0000
Subject: [New-bugs-announce] [issue10227] Improve performance of MemoryView
	slicing
In-Reply-To: <1288342228.97.0.170566139041.issue10227@psf.upfronthosting.co.za>
Message-ID: <1288342228.97.0.170566139041.issue10227@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

In a recent email exchange on python-dev, Antoine Pitrou mentioned that slicing memoryview objects (lazy slices) wasn't necessarily very efficient when dealing with short slices.  The data he posted was:


$ ./python -m timeit -s "x = b'x'*10000" "x[:100]"
10000000 loops, best of 3: 0.134 usec per loop
$ ./python -m timeit -s "x = memoryview(b'x'*10000)" "x[:100]"
10000000 loops, best of 3: 0.151 usec per loop

Actually, this is not a fair comparison.  A more realistic alternative to the memoryview is the bytearray, a mutable buffer.  My local tests gave these numbers:

python.exe -m timeit -n 10000000 -s "x = ((b'x'*10000))" "x[:100]"
10000000 loops, best of 3: 0.14 usec per loop

python.exe -m timeit -n 10000000 -s "x = (bytearray(b'x'*10000))" "x[:100]"
10000000 loops, best of 3: 0.215 usec per loop

python.exe -m timeit -n 10000000 -s "x = memoryview(bytearray(b'x'*10000))" "x[:100]"
10000000 loops, best of 3: 0.163 usec per loop

In this case, lazy slicing is indeed faster than greedy slicing.  However, I was intrigued by how much these cases differ.  Why was slicing bytes objects so much faster?  Each should just result in the generation of a single object.

It turns out that the slicing operation for strings (and sequences is very streamlined in the core.  To address this to some extent I provide a patch with three main components:

1) There is now a single object cache of slice objects.  These are generated by the core when slicing and immediately released.  Reusing them if possible is very beneficial.
2) The PySlice_GetIndicesEx couldn't be optimized because of aliasing.  Fixing that function sped it up considerably.
3) Creating a new api to create a memory view from a base memory view and a slice is much faster.  The old way would do two copies of a Py_buffer with adverse effects on cache performance.

Applying this patch provides the following figures:
python.exe -m timeit -n 10000000 -s "x = ((b'x'*10000))" "x[:100]"
10000000 loops, best of 3: 0.125 usec per loop

python.exe -m timeit -n 10000000 -s "x = (bytearray(b'x'*10000))" "x[:100]"
10000000 loops, best of 3: 0.202 usec per loop

python.exe -m timeit -n 10000000 -s "x = memoryview(bytearray(b'x'*10000))" "x[:100]"
10000000 loops, best of 3: 0.138 usec per loop

in memoryobject.c there was a comment stating that there should be an API for this.  Now there is, only internal.

----------
components: Interpreter Core
keywords: needs review, patch
messages: 119872
nosy: krisvale, pitrou
priority: normal
severity: normal
status: open
title: Improve performance of MemoryView slicing
type: performance
versions: Python 3.2

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

From report at bugs.python.org  Fri Oct 29 12:11:52 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Oct 2010 10:11:52 +0000
Subject: [New-bugs-announce] [issue10228] Refleak run of test_dbm fails when
	several dbm modules	are available
In-Reply-To: <1288347112.92.0.717435942769.issue10228@psf.upfronthosting.co.za>
Message-ID: <1288347112.92.0.717435942769.issue10228@psf.upfronthosting.co.za>


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

This is only when several dbm modules are compiled in (e.g. "gnu" and "dumb"):

$ ./python -m test.regrtest -R 3:2 test_dbm
[1/1] test_dbm
beginning 5 repetitions
12345
test test_dbm failed -- Traceback (most recent call last):
  File "/home/antoine/py3k/deallocwarn/Lib/test/test_dbm.py", line 129, in test_whichdb
    self.assertEqual(name, dbm.whichdb(_fname))
AssertionError: 'dbm.gnu' != 'dbm.dumb'
- dbm.gnu
+ dbm.dumb

----------
components: Tests
messages: 119877
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Refleak run of test_dbm fails when several dbm modules are available
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Fri Oct 29 12:31:34 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Oct 2010 10:31:34 +0000
Subject: [New-bugs-announce] [issue10229] Refleak run of test_gettext fails
In-Reply-To: <1288348294.62.0.0907397506052.issue10229@psf.upfronthosting.co.za>
Message-ID: <1288348294.62.0.0907397506052.issue10229@psf.upfronthosting.co.za>


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

This is probably caused by r85223.

$ ./python -m test.regrtest -R 3:2 test_gettext
[1/1] test_gettext
beginning 5 repetitions
12345
test test_gettext failed -- Traceback (most recent call last):
  File "/home/antoine/py3k/deallocwarn/Lib/test/test_gettext.py", line 348, in test_cache
    self.assertEqual(len(gettext._translations), 0)
AssertionError: 2 != 0

1 test failed:
    test_gettext

----------
assignee: eric.araujo
components: Tests
messages: 119882
nosy: eric.araujo, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Refleak run of test_gettext fails
type: resource usage
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Oct 29 14:08:21 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 29 Oct 2010 12:08:21 +0000
Subject: [New-bugs-announce] [issue10230] test_tarfile failure
	(test_extractall) on AMD64 debian	parallel 3.x:
	os.utime(float) issue
In-Reply-To: <1288354101.14.0.267054038013.issue10230@psf.upfronthosting.co.za>
Message-ID: <1288354101.14.0.267054038013.issue10230@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

test_tarfile in only failing on one 3.x buildbot: AMD64 debian parallel 3.x. The problem is related to the mtime field and os.utime():

http://www.python.org/dev/buildbot/builders/AMD64 debian parallel 3.x/builds/508/steps/test/logs/stdio
======================================================================
FAIL: test_extractall (test.test_tarfile.MiscReadTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/Lib/test/test_tarfile.py", line 358, in test_extractall
    self.assertEqual(tarinfo.mtime, file_mtime, errmsg)
AssertionError: tar mtime 1041808783 (int) != file time 1041808783.000001 (0x1.f0c5ec7800008p+29) of path '/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/build/test_python_23882/@test_23882_tmp-tardir/ustar/dirtype'

======================================================================
FAIL: test_extractall (test.test_tarfile.GzipMiscReadTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/Lib/test/test_tarfile.py", line 358, in test_extractall
    self.assertEqual(tarinfo.mtime, file_mtime, errmsg)
AssertionError: tar mtime 1041808783 (int) != file time 1041808783.000003 (0x1.f0c5ec7800019p+29) of path '/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/build/test_python_23882/@test_23882_tmp-tardir/ustar/dirtype'

======================================================================
FAIL: test_extractall (test.test_tarfile.Bz2MiscReadTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/Lib/test/test_tarfile.py", line 358, in test_extractall
    self.assertEqual(tarinfo.mtime, file_mtime, errmsg)
AssertionError: tar mtime 1041808783 (int) != file time 1041808783.000005 (0x1.f0c5ec780002ap+29) of path '/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/build/test_python_23882/@test_23882_tmp-tardir/ustar/dirtype'

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

(I patched test_extractall to dump mtime values as hexadecimal for floats)

Binary dump os this "ustar/dirtype" entry:

15360) file[2]: Tar File (ustar/dirtype/: Directory, 0 bytes) (512 bytes)
      0) name= "ustar/dirtype/": Name (100 bytes)
      100) mode= "0000755": Mode (8 bytes)
      108) uid= "0001750": User ID (8 bytes)
      116) gid= "0000144": Group ID (8 bytes)
      124) size= "00000000000": Size (12 bytes)
      136) mtime= "07606136617": Modification time (12 bytes)
      148) check_sum= "015042": Check sum (8 bytes)
      156) type= Directory: Type (1 byte)
      157) lname= (empty): Link name (100 bytes)
      257) magic= "ustar\x0000": Magic (8 bytes)
      265) uname= "tarfile": User name (32 bytes)
      297) gname= "tarfile": Group name (32 bytes)
      329) devmajor= "0000000": Dev major (8 bytes)
      337) devminor= "0000000": Dev minor (8 bytes)
      345) padding= <null>: Padding (zero) (167 bytes)             

So this directory has no PAX extra headers, only classical headers, and mtime is 0o7606136617 (1041808783).

os.utime() gets an integer with exact value 1041808783, but then os.stat() gives st_mtime:
 - 1041808783.000001 (0x1.f0c5ec7800008p+29)
 - 1041808783.000003 (0x1.f0c5ec7800019p+29)
 - 1041808783.000005 (0x1.f0c5ec780002ap+29)

To set file time, os.utime() has 4 implementations:
 - SetFileTime() for Windows
 - utimes() using struct timeval
 - utime() using time_t
 - utime() using struct utimbuf

I don't know which one is used (except that it is not supposed to be a Windows host :-)).

----------
components: Library (Lib), Tests
keywords: buildbot
messages: 119890
nosy: haypo, loewis
priority: normal
severity: normal
status: open
title: test_tarfile failure (test_extractall) on AMD64 debian parallel 3.x: os.utime(float) issue
versions: Python 3.2

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

From report at bugs.python.org  Fri Oct 29 15:10:35 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Fri, 29 Oct 2010 13:10:35 +0000
Subject: [New-bugs-announce] [issue10231] SimpleHTTPRequestHandler directory
	bugs
In-Reply-To: <1288357835.63.0.535261040588.issue10231@psf.upfronthosting.co.za>
Message-ID: <1288357835.63.0.535261040588.issue10231@psf.upfronthosting.co.za>


New submission from Hallvard B Furuseth <h.b.furuseth at usit.uio.no>:

SimpleHTTPRequestHandler directory bugs

Running 3.2a3 http/server.py or 2.7 SimpleHTTPServer.py as a script:

* Redirection appends "/" to the unparsed URL instead of to the
  pathname component of the parsed URL: "foo/dir?baz" => "foo/dir?baz/".

* The unparsed URL is also used to check if the URL ends with "/".
  Thus "foo/dir?baz/" gives a directory listing instead of redirecting,
  which makes the files relative to "foo/" instead of to "foo/dir/".

* translate_path("directory/") produces filenames without a final "/".
  Not sure if that is correct for CGI env['PATH_TRANSLATED'].  Anyway:
  This means a non-directory file with a final slash is accepted, but
  again relative URLs in that file will refer to the wrong absolute URL.
  ".../foo.html/" + relative URL "bar.html" -> ".../foo.html/bar.html".

  However if translate_path("...foo/") is changed and you use stat() on
  the result, I do not know if all relevant directory operations work
  with the final directory separator on all OSes.  I seem to remember
  getting errors in some OS for stat("dirname/", &st) in C.

* translate_path() does not handle initial "."/".." on non-Posix systems.
  If that's wrong, it can (ignoring other issues listed here) do this:
      drop = frozenset((os.curdir, os.pardir, '', '.', '..'))
      for ...:
          if word not in drop: os.path.join(path, word)
  Though it looks a bit quicker to do
      words, drop = [], frozenset((os.curdir, os.pardir, '', '.', '..'))
      for word in filter(None, path.split('/')):
          word = os.path.split(os.path.splitdrive(word)[1])[1]
          if word not in drop: words.append(word)
      return os.path.join(os.getcwd(), *words)
  unless that can somehow produce a different result.

----------
components: Library (Lib)
messages: 119899
nosy: hfuru
priority: normal
severity: normal
status: open
title: SimpleHTTPRequestHandler directory bugs
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Fri Oct 29 17:39:48 2010
From: report at bugs.python.org (Robert Lerche)
Date: Fri, 29 Oct 2010 15:39:48 +0000
Subject: [New-bugs-announce] [issue10232] Tkinter issues with Scrollbar and
	custom widget list
In-Reply-To: <1288366788.46.0.695886030233.issue10232@psf.upfronthosting.co.za>
Message-ID: <1288366788.46.0.695886030233.issue10232@psf.upfronthosting.co.za>


New submission from Robert Lerche <ral at msbit.com>:

I have run across several issues (one serious one, showing up only on Windows) when implementing a scroll bar with a list of custom widgets.

I suspect these may really be Tk issues but I thought I'd try posting here first.  I sent this to the tkinter-discuss list and saw no replies.

Please have a look and advise me on the right way to proceed.  Thanks.

----------
components: Tkinter
files: testcase.py
messages: 119907
nosy: Robert.Lerche
priority: normal
severity: normal
status: open
title: Tkinter issues with Scrollbar and custom widget list
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file19412/testcase.py

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

From report at bugs.python.org  Fri Oct 29 17:44:41 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Oct 2010 15:44:41 +0000
Subject: [New-bugs-announce] [issue10233] fix test_tarfile ResourceWarnings
In-Reply-To: <1288367081.73.0.870098966091.issue10233@psf.upfronthosting.co.za>
Message-ID: <1288367081.73.0.870098966091.issue10233@psf.upfronthosting.co.za>


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

This fixes all the warnings because of files not closed explicitly in test_tarfile.

----------
components: Library (Lib)
files: tarfileclose.patch
keywords: patch
messages: 119909
nosy: lars.gustaebel, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: fix test_tarfile ResourceWarnings
type: resource usage
versions: Python 3.2
Added file: http://bugs.python.org/file19414/tarfileclose.patch

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

From report at bugs.python.org  Fri Oct 29 18:27:31 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Oct 2010 16:27:31 +0000
Subject: [New-bugs-announce] [issue10234] ResourceWarnings in test_subprocess
In-Reply-To: <1288369651.8.0.988581354556.issue10234@psf.upfronthosting.co.za>
Message-ID: <1288369651.8.0.988581354556.issue10234@psf.upfronthosting.co.za>


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

Since r85920, test_subprocess has been showing a bunch of ResourceWarnings.
It seems that the pipe objects don't get explicitly closed in wait() or __del__, while they do in communicate().

----------
components: Library (Lib), Tests
messages: 119916
nosy: gregory.p.smith, pitrou
priority: normal
severity: normal
status: open
title: ResourceWarnings in test_subprocess
type: resource usage
versions: Python 3.2

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

From report at bugs.python.org  Fri Oct 29 21:43:35 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Oct 2010 19:43:35 +0000
Subject: [New-bugs-announce] [issue10235] test_argparse depends on the
	COLUMNS environment variable
In-Reply-To: <1288381415.18.0.712134871651.issue10235@psf.upfronthosting.co.za>
Message-ID: <1288381415.18.0.712134871651.issue10235@psf.upfronthosting.co.za>


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

Changing it can produce failures, e.g.:

$ COLUMNS=178 ./python -m test.regrtest -v test_argparse

This can be seen on one of the buildbots:
http://www.python.org/dev/buildbot/all/builders/PPC%20Leopard%203.x/builds/685/steps/test/logs/stdio

----------
assignee: bethard
components: Tests
messages: 119931
nosy: bethard, janssen, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_argparse depends on the COLUMNS environment variable
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Oct 29 21:46:55 2010
From: report at bugs.python.org (Stephen Hansen)
Date: Fri, 29 Oct 2010 19:46:55 +0000
Subject: [New-bugs-announce] [issue10236] Sporadic failures of test_ssl
In-Reply-To: <1288381615.12.0.769531001166.issue10236@psf.upfronthosting.co.za>
Message-ID: <1288381615.12.0.769531001166.issue10236@psf.upfronthosting.co.za>


New submission from Stephen Hansen <me+python at ixokai.io>:

Another sporadic failure I've noticed since setting up my buildbot; test_ssl keeps going down. This one I have a hard time analyzing with the tests output, but the latest is: 
http://www.python.org/dev/buildbot/all/builders/x86%20Snow%20Leopard%203.x/builds/250

There's this part in the log:

test_get_server_certificate (test.test_ssl.NetworkedTests) ... [Errno 1] _ssl.c:390: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

Verified certificate for svn.python.org:443 is
[...pem...]
ok

There's an errno printed there, but then more debugging for that same test-- and an 'ok'-- so I don't see the FAIL message I'm expecting. So to my naive reading, it seems that it is running once and failing, then re-running in verbose and /not/ failing (and that the error-like message there may not be an error). So, the original problem is a mystery.

Or I'm totally reading it wrong. Either way, I've seen this several times and am not sure how to further debug it. Any suggestions or pointers are welcome. Or fixes :)

----------
messages: 119932
nosy: ixokai
priority: normal
severity: normal
status: open
title: Sporadic failures of test_ssl
versions: Python 3.2

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

From report at bugs.python.org  Sat Oct 30 00:25:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Oct 2010 22:25:42 +0000
Subject: [New-bugs-announce] [issue10237] failure in Barrier tests
In-Reply-To: <1288391142.98.0.44997335021.issue10237@psf.upfronthosting.co.za>
Message-ID: <1288391142.98.0.44997335021.issue10237@psf.upfronthosting.co.za>


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

A buildbot has shows occasional failures in the Barrier tests:

[299/349] test_threading
[39130 refs]
[39501 refs]
[39501 refs]
[39491 refs]
[39499 refs]
Unhandled exception in thread started by <function task at 0x45e4df54>
Traceback (most recent call last):
  File "/home/buildslave/python-trunk/3.x.norwitz-x86/build/Lib/test/lock_tests.py", line 37, in task
    f()
  File "/home/buildslave/python-trunk/3.x.norwitz-x86/build/Lib/test/lock_tests.py", line 704, in f
    i = self.barrier.wait()
  File "/home/buildslave/python-trunk/3.x.norwitz-x86/build/Lib/threading.py", line 441, in wait
    self._enter() # Block while the barrier drains.
  File "/home/buildslave/python-trunk/3.x.norwitz-x86/build/Lib/threading.py", line 465, in _enter
    raise BrokenBarrierError
threading.BrokenBarrierError
Unhandled exception in thread started by <function task at 0x45e4df54>
Traceback (most recent call last):
  File "/home/buildslave/python-trunk/3.x.norwitz-x86/build/Lib/test/lock_tests.py", line 37, in task
    f()
  File "/home/buildslave/python-trunk/3.x.norwitz-x86/build/Lib/test/lock_tests.py", line 704, in f
    i = self.barrier.wait()
  File "/home/buildslave/python-trunk/3.x.norwitz-x86/build/Lib/threading.py", line 441, in wait
    self._enter() # Block while the barrier drains.
  File "/home/buildslave/python-trunk/3.x.norwitz-x86/build/Lib/threading.py", line 465, in _enter
    raise BrokenBarrierError
threading.BrokenBarrierError
Unhandled exception in thread started by <function task at 0x45e4df54>
Traceback (most recent call last):
  File "/home/buildslave/python-trunk/3.x.norwitz-x86/build/Lib/test/lock_tests.py", line 37, in task
    f()
  File "/home/buildslave/python-trunk/3.x.norwitz-x86/build/Lib/test/lock_tests.py", line 704, in f
    i = self.barrier.wait()
  File "/home/buildslave/python-trunk/3.x.norwitz-x86/build/Lib/threading.py", line 441, in wait
    self._enter() # Block while the barrier drains.
  File "/home/buildslave/python-trunk/3.x.norwitz-x86/build/Lib/threading.py", line 465, in _enter
    raise BrokenBarrierError
threading.BrokenBarrierError
Unhandled exception in thread started by <function task at 0x45e4df54>
Traceback (most recent call last):
  File "/home/buildslave/python-trunk/3.x.norwitz-x86/build/Lib/test/lock_tests.py", line 37, in task
    f()
  File "/home/buildslave/python-trunk/3.x.norwitz-x86/build/Lib/test/lock_tests.py", line 704, in f
    i = self.barrier.wait()
  File "/home/buildslave/python-trunk/3.x.norwitz-x86/build/Lib/threading.py", line 441, in wait
    self._enter() # Block while the barrier drains.
  File "/home/buildslave/python-trunk/3.x.norwitz-x86/build/Lib/threading.py", line 465, in _enter
    raise BrokenBarrierError
threading.BrokenBarrierError
test test_threading failed -- Traceback (most recent call last):
  File "/home/buildslave/python-trunk/3.x.norwitz-x86/build/Lib/test/lock_tests.py", line 720, in test_reset
    self.run_threads(f)
  File "/home/buildslave/python-trunk/3.x.norwitz-x86/build/Lib/test/lock_tests.py", line 615, in run_threads
    f()
  File "/home/buildslave/python-trunk/3.x.norwitz-x86/build/Lib/test/lock_tests.py", line 704, in f
    i = self.barrier.wait()
  File "/home/buildslave/python-trunk/3.x.norwitz-x86/build/Lib/threading.py", line 450, in wait
    self._wait(timeout)
  File "/home/buildslave/python-trunk/3.x.norwitz-x86/build/Lib/threading.py", line 489, in _wait
    raise BrokenBarrierError
threading.BrokenBarrierError

----------
assignee: krisvale
components: Library (Lib), Tests
messages: 119942
nosy: krisvale, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: failure in Barrier tests
versions: Python 3.2

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

From report at bugs.python.org  Sat Oct 30 00:27:55 2010
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 29 Oct 2010 22:27:55 +0000
Subject: [New-bugs-announce] [issue10238] ctypes not building under OS X
	10.6 with LLVM/Clang 2.8
In-Reply-To: <1288391275.39.0.918201255477.issue10238@psf.upfronthosting.co.za>
Message-ID: <1288391275.39.0.918201255477.issue10238@psf.upfronthosting.co.za>


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

I get the following output related to the build failure:


/var/folders/MN/MN-E3HgoFXSKDXb9le7FQ++++TI/-Tmp-/cc-MxvLE7.s:153:2: error: unrecognized instruction
 cmovnz %rax, %rdx
 ^
/var/folders/MN/MN-E3HgoFXSKDXb9le7FQ++++TI/-Tmp-/cc-MxvLE7.s:154:2: error: unrecognized instruction
 cmovnz %r10, %rax
 ^
/var/folders/MN/MN-E3HgoFXSKDXb9le7FQ++++TI/-Tmp-/cc-MxvLE7.s:156:2: error: unrecognized instruction
 cmovnz %r10, %rdx
 ^
/var/folders/MN/MN-E3HgoFXSKDXb9le7FQ++++TI/-Tmp-/cc-MxvLE7.s:158:2: error: unrecognized instruction
 cmovnz %r10, %rax
 ^
/var/folders/MN/MN-E3HgoFXSKDXb9le7FQ++++TI/-Tmp-/cc-MxvLE7.s:159:2: error: unrecognized instruction
 cmovnz %r11, %rdx
 ^
/var/folders/MN/MN-E3HgoFXSKDXb9le7FQ++++TI/-Tmp-/cc-MxvLE7.s:166:2: error: unrecognized instruction
 rep movsb
 ^
/var/folders/MN/MN-E3HgoFXSKDXb9le7FQ++++TI/-Tmp-/cc-MxvLE7.s:281:2: error: unrecognized instruction
 cmovnz %rdx, %rcx
 ^
/var/folders/MN/MN-E3HgoFXSKDXb9le7FQ++++TI/-Tmp-/cc-MxvLE7.s:285:2: error: unrecognized instruction
 cmovnz %rdx, %rax
 ^

----------
components: Build
messages: 119945
nosy: brett.cannon
priority: deferred blocker
severity: normal
status: open
title: ctypes not building under OS X 10.6 with LLVM/Clang 2.8
type: compile error
versions: Python 3.2

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

From report at bugs.python.org  Sat Oct 30 01:16:55 2010
From: report at bugs.python.org (Neal Becker)
Date: Fri, 29 Oct 2010 23:16:55 +0000
Subject: [New-bugs-announce] [issue10239] multiprocessing signal defect
In-Reply-To: <1288394215.77.0.548546453829.issue10239@psf.upfronthosting.co.za>
Message-ID: <1288394215.77.0.548546453829.issue10239@psf.upfronthosting.co.za>


New submission from Neal Becker <ndbecker2 at gmail.com>:

multiprocessing signal defect
From:
Neal Becker <ndbecker2 at gmail.com>
  Date:
Friday 29 October 2010 8:12:19 am
  To:
python-list at python.org
  Groups:
gmane.comp.python.general

Tested on:
python-2.6.4-27.fc13.x86_64
linux fedora 13 x86_64

Seems multiprocessing doesn't behave well with signals:

-----------
from multiprocessing import Pool
import time

def sleep (dummy):
????time.sleep (10)
????
if __name__ == '__main__':
????pool = Pool (processes=2)
????result = pool.map (sleep, range (4))
????
-------------

start it up
$ python test_multip.py?

----------------------
ps auxf | grep python
nbecker???6605??1.6??0.1 338192??6952 pts/1????Sl+??08:03???0:00??|???????\_?
python test_multip.py
nbecker???6606??0.0??0.1 186368??4760 pts/1????S+???08:03???0:00??|???????????
\_ python test_multip.py
nbecker???6607??0.0??0.1 186372??4740 pts/1????S+???08:03???0:00??|???????????
\_ python test_multip.py

kill 6607
?ps auxf | grep python
nbecker???6605??0.5??0.1 338192??6952 pts/1????Sl+??08:03???0:00??|???????\_?
python test_multip.py
nbecker???6606??0.0??0.1 186368??4760 pts/1????S+???08:03???0:00??|???????????
\_ python test_multip.py
nbecker???6607??0.0??0.0??????0?????0 pts/1????Z+???08:03???0:00??|???????????
\_ [python] <defunct>

?kill 6606
ps auxf | grep python
nbecker???6605??0.3??0.1 338192??6952 pts/1????Sl+??08:03???0:00??|???????\_?
python test_multip.py
nbecker???6606??0.0??0.0??????0?????0 pts/1????Z+???08:03???0:00??|???????????
\_ [python] <defunct>
nbecker???6607??0.0??0.0??????0?????0 pts/1????Z+???08:03???0:00??|???????????
\_ [python] <defunct>

Now we have 2 dead children and the parent is hung forever.

Isn't this a serious defect?

----------
components: Library (Lib)
messages: 119948
nosy: Neal.Becker
priority: normal
severity: normal
status: open
title: multiprocessing signal defect
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sat Oct 30 04:34:08 2010
From: report at bugs.python.org (ivank)
Date: Sat, 30 Oct 2010 02:34:08 +0000
Subject: [New-bugs-announce] [issue10240] dict.update.__doc__ is misleading
In-Reply-To: <1288406048.13.0.615215732385.issue10240@psf.upfronthosting.co.za>
Message-ID: <1288406048.13.0.615215732385.issue10240@psf.upfronthosting.co.za>


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

It would be nice if dict.update.__doc__ conveyed some of the subtleties of the update algorithm.  See the patch.  I changed __doc__ to mention the fast path for dicts, and changed one instance of E: -> E.keys():

----------
components: Interpreter Core
files: dict.update.__doc__.patch
keywords: patch
messages: 119954
nosy: ivank
priority: normal
severity: normal
status: open
title: dict.update.__doc__ is misleading
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file19420/dict.update.__doc__.patch

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

From report at bugs.python.org  Sat Oct 30 05:48:50 2010
From: report at bugs.python.org (Neil Schemenauer)
Date: Sat, 30 Oct 2010 03:48:50 +0000
Subject: [New-bugs-announce] [issue10241] gc fixes for module m_copy
	attribute
In-Reply-To: <1288410530.83.0.095379048444.issue10241@psf.upfronthosting.co.za>
Message-ID: <1288410530.83.0.095379048444.issue10241@psf.upfronthosting.co.za>


New submission from Neil Schemenauer <nas-python at arctrix.com>:

I'm trying implement some saner module shutdown procedure (similar to issue 812369).  One of the many problems I've run into is that the GC doesn't know about the m_copy attribute of modules. 

I think the attached patch is correct.  tp_tranverse exposes m_copy if it is non-NULL.  tp_clear calls Py_CLEAR on it.

----------
assignee: loewis
components: Interpreter Core
files: module_m_copy.txt
messages: 119957
nosy: benjamin.peterson, loewis, nascheme
priority: normal
severity: normal
status: open
title: gc fixes for module m_copy attribute
type: behavior
Added file: http://bugs.python.org/file19423/module_m_copy.txt

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

From report at bugs.python.org  Sat Oct 30 07:26:12 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 30 Oct 2010 05:26:12 +0000
Subject: [New-bugs-announce] [issue10242] unittest's assertItemsEqual()
	method makes too many	assumptions about its input
In-Reply-To: <1288416372.65.0.387803067469.issue10242@psf.upfronthosting.co.za>
Message-ID: <1288416372.65.0.387803067469.issue10242@psf.upfronthosting.co.za>


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

class T(unittest.TestCase):
    def test_items_equal(self):
        # this test fails, but should succeed
        a = [{2,4}, {1,2}]
        b = a[::-1]
        self.assertItemsEqual(a, b)

This method has a fast-path using sorted() and a slow-path that doesn't care about cross-type comparisons.  The fast-path is incorrect though and gets the wrong answer in the above test case.

----------
assignee: michael.foord
messages: 119960
nosy: michael.foord, rhettinger
priority: high
severity: normal
status: open
title: unittest's assertItemsEqual() method makes too many assumptions about its input
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sat Oct 30 08:46:30 2010
From: report at bugs.python.org (Max Skaller)
Date: Sat, 30 Oct 2010 06:46:30 +0000
Subject: [New-bugs-announce] [issue10243] Packaged Pythons
In-Reply-To: <1288421190.78.0.406160800778.issue10243@psf.upfronthosting.co.za>
Message-ID: <1288421190.78.0.406160800778.issue10243@psf.upfronthosting.co.za>


New submission from Max Skaller <max.skaller at gmail.com>:

Not sure if this is a bug or not. I am unable to find libpython.so for Python3 on either my Mac or Ubuntu. Perhaps this is a packaging fault, however some documentation in the Wiki suggests otherwise. It appears the builders have reverted to an archaic linkage pattern which I helped to get rid of (lets see, perhaps a decade ago?). Python 2.6, for example, does ship a shared library.

Python must be shipped with code linked as follows, I will explain below why, but first the list:

1) The mainline (C main() function) must be a stub which calls the real mainline, which is located in libpython.

2) The mainline MUST be compiled with C++ not C.

3) All extension libraries and add-ons to Python provided as shared libraries must be explicitly linked against libpython.

In particular it is NOT acceptable for any extension or shared library component to expect to find its symbols in the host application executable as the Wiki documentation seems to suggest (in a section which explains a bit of a workaround for OSX frameworks).

Now the reason it MUST be this way. First, any C++ code which is to be linked into an application, either statically, dynamically at load time, or under program control at run time, may require certain stuff to be in place (RTTI, streams, exception handling stuff, or whatever) which can only be put in place in the initialisation of the main application. Although the details are platform specific, it is simply not safe to permit C++ extension modules unless this step is taken.

Legacy or embedded systems may have to make do with a C mainline, and systems which don't support dynamic loading can also do without C++ compilation provided the pre-loaded extensions are all C.

On most major platforms, however, a C++ driver stub is required.

The second issue is also quite simple. It is quite incorrect in a modern computing environment to assume an *application* will be hosting the python interpreter directly. It is not only possible, it is in fact the case for my project, that were the Python interpreter to be called, it would from a shared library loaded under program control at run time.

Such an interpreter cannot be loaded at all if it isn't present in a library: it either has to be statically linked into the shared library making the call, with some ugly linker switches to make sure no symbols are dropped, or it has to be loaded dynamically. The latter case is the only viable option if the run time linker is unable to share symbols to a loaded application, and even if that is possible and can be arranged it is not likely to work so well if multiple shared libraries try to do it.

Similarly, even if you managed to load it somehow, any dynamically loaded extensions may or may not be able to find the symbols.

The ONLY reliable way to ensure extensions can find libpython symbols is to link them against libpython.

In fact, the mainline application should not only contain NO libpython symbols specifically to disable this wrong practice and break any bad extensions that rely on it, it should also, as explained, contain exactly one reference to libpython, which calls Python with argv, argc[] as if it were the mainline.

Just as motivation here: my product is an ultra-high performance programming language with a special construction to allow Python C-extension modules to be built. Its target is usually a shared library and that library is produced by first generating C++ and then compiling it with your native C++ compiler.

For a generated program to call Python interpreter, it HAS to be available in a shared library, and for any extension modules that interpreter loads, they HAVE to get their symbols from that shared library, and, if the generated program is itself a Python module, then if that module is to be loaded from any C extension, including itself or some other extension, it HAS to be linked against libpython which HAS to be loaded dynamically by the loaded.

The unfortunate downside of this is that it is NOT POSSIBLE to have a huge statically linked Python executable which just loads C extensions and nothing else happens. If you're loading any C extensions dynamically libpython must be loaded dynamically too.

Just to be clear: I can easily build it the way I want it but this will not solve my problem, which is to support clients who wish to use my product to generate high performance Python callable modules which will just work "out of the box" with existing Python code. In particular, replacing some slow modules with optimised ones would be more or less entirely transparent .. except that at the moment it could only work with Python 2.x since Python 3.x shipments don't seem to have any shared libpython included (and I just changed my compiler to support Python 3 modules instead of Python 2).

----------
components: Installation
messages: 119963
nosy: Max.Skaller
priority: normal
severity: normal
status: open
title: Packaged Pythons
type: resource usage
versions: Python 3.2

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

From report at bugs.python.org  Sat Oct 30 12:20:02 2010
From: report at bugs.python.org (Maciej Fijalkowski)
Date: Sat, 30 Oct 2010 10:20:02 +0000
Subject: [New-bugs-announce] [issue10244] PEP100 has broken links
In-Reply-To: <1288434002.3.0.460558889846.issue10244@psf.upfronthosting.co.za>
Message-ID: <1288434002.3.0.460558889846.issue10244@psf.upfronthosting.co.za>


New submission from Maciej Fijalkowski <fijall at gmail.com>:

PEP100 (http://www.python.org/dev/peps/pep-0100/) links to python starship. Should it just link to python.org for the newest version of this doc?

----------
assignee: docs at python
components: Documentation
messages: 119967
nosy: docs at python, fijall
priority: normal
severity: normal
status: open
title: PEP100 has broken links

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

From report at bugs.python.org  Sat Oct 30 14:17:57 2010
From: report at bugs.python.org (Brian Brazil)
Date: Sat, 30 Oct 2010 12:17:57 +0000
Subject: [New-bugs-announce] [issue10245] Fix resource warnings in
	test_telnetlib
In-Reply-To: <1288441077.58.0.74967624488.issue10245@psf.upfronthosting.co.za>
Message-ID: <1288441077.58.0.74967624488.issue10245@psf.upfronthosting.co.za>


New submission from Brian Brazil <brian.brazil at gmail.com>:

Please see attached patch and "closing files and sockets in a timely manner in the stdlib" on python-dev.

----------
components: Tests
files: test_telnetlib_fd_leak.patch
keywords: patch
messages: 119974
nosy: bbrazil, brett.cannon
priority: normal
severity: normal
status: open
title: Fix resource warnings in test_telnetlib
versions: Python 3.3
Added file: http://bugs.python.org/file19424/test_telnetlib_fd_leak.patch

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

From report at bugs.python.org  Sat Oct 30 14:43:59 2010
From: report at bugs.python.org (Brian Brazil)
Date: Sat, 30 Oct 2010 12:43:59 +0000
Subject: [New-bugs-announce] [issue10246] uu.encode fd leak if arguments are
	filenames
In-Reply-To: <1288442639.64.0.225506910081.issue10246@psf.upfronthosting.co.za>
Message-ID: <1288442639.64.0.225506910081.issue10246@psf.upfronthosting.co.za>


New submission from Brian Brazil <brian.brazil at gmail.com>:

Please see attached patch, I'm not sure if this is the cleanest way to fix this. This also fixes the resource warnings in the test.

----------
components: Library (Lib)
files: uu_fd_leak.patch
keywords: patch
messages: 119975
nosy: bbrazil, brett.cannon
priority: normal
severity: normal
status: open
title: uu.encode fd leak if arguments are filenames
versions: Python 3.3
Added file: http://bugs.python.org/file19425/uu_fd_leak.patch

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

From report at bugs.python.org  Sat Oct 30 15:04:00 2010
From: report at bugs.python.org (Lorenz Quack)
Date: Sat, 30 Oct 2010 13:04:00 +0000
Subject: [New-bugs-announce] [issue10247] mold builder
In-Reply-To: <20101030130356.13C177820C@psf.upfronthosting.co.za>
Message-ID: <20101030130356.13C177820C@psf.upfronthosting.co.za>


New submission from Lorenz Quack <don at amberfisharts.com>:

RV Plastics is your end to end partner for all your moulds and Injection Moulding requirements. 

Founded in 2003, RV Plastics dedicates itself to the plastic industry, exporting 
Plastic injection moulds and molded Components to customers spread over 20 countries. 
We offer mould design & development services for plastic house ware, electrical, automobile and industrial products. 
We produce high quality moulds at attractive prices.

Tel: 86-769-8997 5802
Fax: 86-769-8458 5238
Web: www(dot)rvmold(dot)com
E-mail: rvmold(at)hotmail(dot)com / sales(at)rvmold(dot)com

----------
messages: 119981
nosy: donlorenzo
priority: normal
severity: normal
status: open
title: mold builder

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

From report at bugs.python.org  Sat Oct 30 15:17:28 2010
From: report at bugs.python.org (Brian Brazil)
Date: Sat, 30 Oct 2010 13:17:28 +0000
Subject: [New-bugs-announce] [issue10248] Fix resource warnings in
	test_xmlrpclib
In-Reply-To: <1288444648.27.0.0542551809175.issue10248@psf.upfronthosting.co.za>
Message-ID: <1288444648.27.0.0542551809175.issue10248@psf.upfronthosting.co.za>


New submission from Brian Brazil <brian.brazil at gmail.com>:

I'm not 100% comfortable with this patch as my knowledge of the xmlrpc interface is very limited, a simple p.close() would seem cleaner - but that doesn't work.

----------
files: test_xmlrpclib_fd_leak.patch
keywords: patch
messages: 119983
nosy: bbrazil
priority: normal
severity: normal
status: open
title: Fix resource warnings in test_xmlrpclib
Added file: http://bugs.python.org/file19427/test_xmlrpclib_fd_leak.patch

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

From report at bugs.python.org  Sat Oct 30 15:18:05 2010
From: report at bugs.python.org (Brian Brazil)
Date: Sat, 30 Oct 2010 13:18:05 +0000
Subject: [New-bugs-announce] [issue10249] Fix resource warnings in
	test_unicodedata
In-Reply-To: <1288444685.04.0.0407449427319.issue10249@psf.upfronthosting.co.za>
Message-ID: <1288444685.04.0.0407449427319.issue10249@psf.upfronthosting.co.za>


New submission from Brian Brazil <brian.brazil at gmail.com>:

Please see attached.

----------
components: Library (Lib)
files: test_unicodedata_fd_leak.patch
keywords: patch
messages: 119984
nosy: bbrazil
priority: normal
severity: normal
status: open
title: Fix resource warnings in test_unicodedata
versions: Python 3.3
Added file: http://bugs.python.org/file19428/test_unicodedata_fd_leak.patch

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

From report at bugs.python.org  Sat Oct 30 15:18:47 2010
From: report at bugs.python.org (Brian Brazil)
Date: Sat, 30 Oct 2010 13:18:47 +0000
Subject: [New-bugs-announce] [issue10250] Fix resource warnings in
	test_urllib2_localnet
In-Reply-To: <1288444727.09.0.95705539029.issue10250@psf.upfronthosting.co.za>
Message-ID: <1288444727.09.0.95705539029.issue10250@psf.upfronthosting.co.za>


New submission from Brian Brazil <brian.brazil at gmail.com>:

Please see attached, not sure this is quite right.

----------
components: Tests
files: test_urllib2_localnet_fd_leak.patch
keywords: patch
messages: 119985
nosy: bbrazil
priority: normal
severity: normal
status: open
title: Fix resource warnings in test_urllib2_localnet
versions: Python 3.3
Added file: http://bugs.python.org/file19429/test_urllib2_localnet_fd_leak.patch

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

From report at bugs.python.org  Sat Oct 30 16:08:06 2010
From: report at bugs.python.org (Brian Brazil)
Date: Sat, 30 Oct 2010 14:08:06 +0000
Subject: [New-bugs-announce] [issue10251] Fix resource warnings in test_file
In-Reply-To: <1288447686.86.0.275228284078.issue10251@psf.upfronthosting.co.za>
Message-ID: <1288447686.86.0.275228284078.issue10251@psf.upfronthosting.co.za>


New submission from Brian Brazil <brian.brazil at gmail.com>:

Please see attached.

----------
components: Tests
files: test_file_fd_leak.patch
keywords: patch
messages: 119987
nosy: bbrazil
priority: normal
severity: normal
status: open
title: Fix resource warnings in test_file
versions: Python 3.3
Added file: http://bugs.python.org/file19430/test_file_fd_leak.patch

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

From report at bugs.python.org  Sat Oct 30 16:22:54 2010
From: report at bugs.python.org (Brian Brazil)
Date: Sat, 30 Oct 2010 14:22:54 +0000
Subject: [New-bugs-announce] [issue10252] Fix resource warnings in distutil
	tests
In-Reply-To: <1288448574.25.0.83148173886.issue10252@psf.upfronthosting.co.za>
Message-ID: <1288448574.25.0.83148173886.issue10252@psf.upfronthosting.co.za>


New submission from Brian Brazil <brian.brazil at gmail.com>:

Please see attached.

----------
assignee: tarek
components: Distutils
files: distutils_fd_leak.patch
keywords: patch
messages: 119988
nosy: bbrazil, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: Fix resource warnings in distutil tests
versions: Python 3.3
Added file: http://bugs.python.org/file19431/distutils_fd_leak.patch

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

From report at bugs.python.org  Sat Oct 30 16:59:08 2010
From: report at bugs.python.org (Brian Brazil)
Date: Sat, 30 Oct 2010 14:59:08 +0000
Subject: [New-bugs-announce] [issue10253] Fix fd leak in fileio.c and test
	resource warnings
In-Reply-To: <1288450748.11.0.919591582507.issue10253@psf.upfronthosting.co.za>
Message-ID: <1288450748.11.0.919591582507.issue10253@psf.upfronthosting.co.za>


New submission from Brian Brazil <brian.brazil at gmail.com>:

fileio_init will leak a fd if you open a file for append that isn't seekable. We should close this fd before returning the failure.

The attached patch fixes this and a resource warning in the tests, but I'm unsure if it'd be better to use internal_close. I'd want the error from the seek rather than any potential error from the close, so I think this is okay.

Regrtest is happy.

----------
components: IO
files: fileio_fd_leak.patch
keywords: patch
messages: 119992
nosy: bbrazil
priority: normal
severity: normal
status: open
title: Fix fd leak in fileio.c and test resource warnings
versions: Python 3.3
Added file: http://bugs.python.org/file19432/fileio_fd_leak.patch

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

From report at bugs.python.org  Sat Oct 30 17:42:14 2010
From: report at bugs.python.org (Merlijn van Deen)
Date: Sat, 30 Oct 2010 15:42:14 +0000
Subject: [New-bugs-announce] [issue10254] unicodedata.normalize('NFC',
	s) regression
In-Reply-To: <1288453334.74.0.770473212932.issue10254@psf.upfronthosting.co.za>
Message-ID: <1288453334.74.0.770473212932.issue10254@psf.upfronthosting.co.za>


New submission from Merlijn van Deen <valhallasw at gmail.com>:

Summary: Somewhere between 2.6.5 r79063 and 3.1 r79147 a regression in the unicode NFC normalization has been introduces. This regression leads to bot edit wars on wikipedia [1]. It is reproducable with a simple script [2]. Mediawiki/PHP [3] and C# [4] test scripts both show the old behaviour, which leads me to believe this is a python bug.
A search for older bugs shows bug #1054943 [5] which has commits in the suspected region.

The regression causes certain NFC-normalized strings to become mangled. Because of the wide range of unicode strings on wikipedia, this causes several problems. Details of those can be found at [1].

Example strings include: (these strings have been NFC-normalized by mediawiki)
 * u'Li\u030dt-s\u1e73\u0301'
 * u'\u092e\u093e\u0930\u094d\u0915 \u091c\u093c\u0941\u0915\u0947\u0930\u092c\u0930\u094d\u0917'
 * u'\u0915\u093f\u0930\u094d\u0917\u093f\u091c\u093c\u0938\u094d\u0924\u093e\u0928'

The bug can be shown simply with
unicodedata.normalize('NFC', s) == s
where s is one of the strings above. This will return True on older python versions, False on newer versions. There is a script available that does this [2].

The bug has been tested on the following machines and python versions. OK indicates the bug is not present, FAIL indicates the bug is present.

Host: SunOS willow 5.10 Generic_142910-17 i86pc i386 i86pc Solaris
'2.3.3 (#1, Dec 16 2004, 14:38:56) [C]' OK
'2.6.5 (r265:79063, Jul 10 2010, 17:50:38) [C]' OK
'2.7 (r27:82500, Aug  5 2010, 04:28:45) [C]' FAIL
'3.1.2 (r312:79147, Sep 24 2010, 05:34:04) [C]' FAIL

Host: Linux nightshade 2.6.26-2-amd64 #1 SMP Thu Sep 16 15:56:38 UTC 2010 x86_64 GNU/Linux
'2.4.6 (#2, Jan 24 2010, 12:20:41) \n[GCC 4.3.2]' OK
'2.5.2 (r252:60911, Jan 24 2010, 17:44:40) \n[GCC 4.3.2]' OK
'2.6.4+ (r264:75706, Feb 16 2010, 05:11:28) \n[GCC 4.4.3]' OK

Host: Linux dorthonion 2.6.22.18-co-0.7.4 #1 PREEMPT Wed Apr 15 18:57:39 UTC 2009 i686 GNU/Linux
'2.5.4 (r254:67916, Jan 20 2010, 21:44:03) \n[GCC 4.3.3]' OK
'2.6.2 (release26-maint, Apr 19 2009, 01:56:41) \n[GCC 4.3.3]' OK
'3.0.1+ (r301:69556, Apr 15 2009, 15:59:22) \n[GCC 4.3.3]' OK

[1] https://sourceforge.net/tracker/index.php?func=detail&aid=3081100&group_id=93107&atid=603138# ; http://fr.wikipedia.org/w/index.php?title=Mark_Zuckerberg&action=historysubmit&diff=57753004&oldid=57751674
[2] http://pastebin.ca/1977285 (py2.x), http://pastebin.ca/1977287 (py3.x)
[3] http://pastebin.ca/1977292 (PHP, placed in http://svn.wikimedia.org/svnroot/mediawiki/trunk/phase3/normal/), 
[4] http://pastebin.ca/1977261 (C#)
[5] http://bugs.python.org/issue1054943#

----------
components: Unicode
messages: 119995
nosy: valhallasw
priority: normal
severity: normal
status: open
title: unicodedata.normalize('NFC', s) regression
type: behavior
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Sat Oct 30 21:44:33 2010
From: report at bugs.python.org (Neil Schemenauer)
Date: Sat, 30 Oct 2010 19:44:33 +0000
Subject: [New-bugs-announce] [issue10255] refleak in initstdio
In-Reply-To: <1288467873.78.0.806058844227.issue10255@psf.upfronthosting.co.za>
Message-ID: <1288467873.78.0.806058844227.issue10255@psf.upfronthosting.co.za>


New submission from Neil Schemenauer <nas-python at arctrix.com>:

It looks to me like initstdio leaks a reference to "open".  AFAIK, PyObject_SetAttrString() does not steal a reference.

----------
assignee: pitrou
components: Interpreter Core
files: initstdio_refleak.txt
messages: 120008
nosy: nascheme, pitrou
priority: normal
severity: normal
status: open
title: refleak in initstdio
type: resource usage
Added file: http://bugs.python.org/file19434/initstdio_refleak.txt

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

From report at bugs.python.org  Sat Oct 30 22:26:23 2010
From: report at bugs.python.org (Brian Brazil)
Date: Sat, 30 Oct 2010 20:26:23 +0000
Subject: [New-bugs-announce] [issue10256] Fix resource warnings in
	test_pkgimport
In-Reply-To: <1288470383.48.0.0497448669979.issue10256@psf.upfronthosting.co.za>
Message-ID: <1288470383.48.0.0497448669979.issue10256@psf.upfronthosting.co.za>


New submission from Brian Brazil <brian.brazil at gmail.com>:

Please see attached patch.

----------
components: Tests
files: test_pkgimport_fd_leak.patch
keywords: patch
messages: 120014
nosy: bbrazil
priority: normal
severity: normal
status: open
title: Fix resource warnings in test_pkgimport
versions: Python 3.3
Added file: http://bugs.python.org/file19436/test_pkgimport_fd_leak.patch

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

From report at bugs.python.org  Sat Oct 30 22:31:24 2010
From: report at bugs.python.org (Brian Brazil)
Date: Sat, 30 Oct 2010 20:31:24 +0000
Subject: [New-bugs-announce] [issue10257] Fix resource warnings in test_os
In-Reply-To: <1288470684.7.0.213634483079.issue10257@psf.upfronthosting.co.za>
Message-ID: <1288470684.7.0.213634483079.issue10257@psf.upfronthosting.co.za>


New submission from Brian Brazil <brian.brazil at gmail.com>:

Please see attached.

----------
components: Tests
files: test_os_fd_leak.patch
keywords: patch
messages: 120015
nosy: bbrazil
priority: normal
severity: normal
status: open
title: Fix resource warnings in test_os
versions: Python 3.3
Added file: http://bugs.python.org/file19437/test_os_fd_leak.patch

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

From report at bugs.python.org  Sat Oct 30 23:01:56 2010
From: report at bugs.python.org (Brian Brazil)
Date: Sat, 30 Oct 2010 21:01:56 +0000
Subject: [New-bugs-announce] [issue10258] Fix resource warnings in distutil
	test_tokenize
In-Reply-To: <1288472516.9.0.895455205535.issue10258@psf.upfronthosting.co.za>
Message-ID: <1288472516.9.0.895455205535.issue10258@psf.upfronthosting.co.za>


New submission from Brian Brazil <brian.brazil at gmail.com>:

Please see attached patch.

----------
components: Tests
files: test_tokenize_fd_leak.patch
keywords: patch
messages: 120019
nosy: bbrazil
priority: normal
severity: normal
status: open
title: Fix resource warnings in distutil test_tokenize
versions: Python 3.3
Added file: http://bugs.python.org/file19439/test_tokenize_fd_leak.patch

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

From report at bugs.python.org  Sun Oct 31 03:10:57 2010
From: report at bugs.python.org (Ivan Razumov)
Date: Sun, 31 Oct 2010 02:10:57 +0000
Subject: [New-bugs-announce] [issue10259] Entry text not set if both 'Font'
	and 'fg' are set
In-Reply-To: <1288491057.47.0.0560000338786.issue10259@psf.upfronthosting.co.za>
Message-ID: <1288491057.47.0.0560000338786.issue10259@psf.upfronthosting.co.za>


New submission from Ivan Razumov <iarspider at gmail.com>:

OS: Windows 7 x86
Python: 2.6.4

An Entry with both Font and Foreground properties changed (i.e. not OS-default) does not display text set with textvariable.set method. 

Attached an example of such behavior.

----------
components: Tkinter
files: Project5.py
messages: 120030
nosy: iarspider
priority: normal
severity: normal
status: open
title: Entry text not set if both 'Font' and 'fg' are set
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file19441/Project5.py

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

From report at bugs.python.org  Sun Oct 31 05:46:49 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sun, 31 Oct 2010 04:46:49 +0000
Subject: [New-bugs-announce] [issue10260] Add a
	thrading.Condition.wait_for() method
In-Reply-To: <1288500409.32.0.639501337625.issue10260@psf.upfronthosting.co.za>
Message-ID: <1288500409.32.0.639501337625.issue10260@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

The attached patch adds a wait_for method to condition objects.
It can simplify code that uses condition variables since it relieves the user from writing a condition loop.  In addition it simplifies timeout logic which otherwise has to correctly deal with non-successful wakeups.

We also modify the barrier to use it, giving more robust timeout behaviour.

(btw, the use of time.time() in threading is unfortunate, since it has low resolution and is affected by a user adjusting the clock. On Windows one would want time.clock(), but that function measures CPU time on unix.  Do we need a proper time.wallclock() function available on all platforms?)

----------
components: Library (Lib)
files: wait_for.patch
keywords: patch
messages: 120036
nosy: georg.brandl, krisvale
priority: normal
severity: normal
status: open
title: Add a thrading.Condition.wait_for() method
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file19442/wait_for.patch

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

From report at bugs.python.org  Sun Oct 31 12:19:58 2010
From: report at bugs.python.org (Karsten Wolf)
Date: Sun, 31 Oct 2010 11:19:58 +0000
Subject: [New-bugs-announce] [issue10261] tarfile iterator without members
	caching
In-Reply-To: <1288523998.25.0.554801648749.issue10261@psf.upfronthosting.co.za>
Message-ID: <1288523998.25.0.554801648749.issue10261@psf.upfronthosting.co.za>


New submission from Karsten Wolf <karstenwo at web.de>:

It would be helpful to have a tarfile iterator that does not cache every archive member encountered.

This makes it nearly impossible to iterate over an archive with millions of files.

----------
components: Library (Lib)
messages: 120041
nosy: karstenw
priority: normal
severity: normal
status: open
title: tarfile iterator without members caching
type: feature request

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

From report at bugs.python.org  Sun Oct 31 13:07:23 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 31 Oct 2010 12:07:23 +0000
Subject: [New-bugs-announce] [issue10262] Add --disable-abi-flags option to
	`configure`
In-Reply-To: <1288526843.14.0.55690735161.issue10262@psf.upfronthosting.co.za>
Message-ID: <1288526843.14.0.55690735161.issue10262@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

Some packagers might want to disable ABI flags. The attached patch adds --disable-abi-flags option to `configure`.

----------
components: Build
files: python-abi-flags.patch
keywords: patch
messages: 120044
nosy: Arfrever, barry
priority: normal
severity: normal
status: open
title: Add --disable-abi-flags option to `configure`
versions: Python 3.2
Added file: http://bugs.python.org/file19443/python-abi-flags.patch

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

From report at bugs.python.org  Sun Oct 31 14:18:43 2010
From: report at bugs.python.org (Doug Hellmann)
Date: Sun, 31 Oct 2010 13:18:43 +0000
Subject: [New-bugs-announce] [issue10263] "python -m site" does not print
	path details
In-Reply-To: <1288531123.45.0.881083161674.issue10263@psf.upfronthosting.co.za>
Message-ID: <1288531123.45.0.881083161674.issue10263@psf.upfronthosting.co.za>


New submission from Doug Hellmann <doug.hellmann at gmail.com>:

Running "python -m site" is supposed to print a report about the current import path and its components (like USER_BASE and USER_SITE).

This works under 2.6 and 3.1, but not 2.7.  No output is produced under 2.7 at all.  

When I add a print statement to the end of the module, I see that __name__ is set to "site" instead of "__main__", so the _script() function isn't being invoked at all.

----------
components: Library (Lib)
messages: 120045
nosy: doughellmann
priority: normal
severity: normal
status: open
title: "python -m site" does not print path details
versions: Python 2.7

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

From report at bugs.python.org  Sun Oct 31 15:09:54 2010
From: report at bugs.python.org (Brian Brazil)
Date: Sun, 31 Oct 2010 14:09:54 +0000
Subject: [New-bugs-announce] [issue10264] Fix resource warnings in
	test_smtplib
In-Reply-To: <1288534194.29.0.658250394155.issue10264@psf.upfronthosting.co.za>
Message-ID: <1288534194.29.0.658250394155.issue10264@psf.upfronthosting.co.za>


New submission from Brian Brazil <brian.brazil at gmail.com>:

Please see attached.

----------
components: Tests
files: test_smtplib_fd_leak.patch
keywords: patch
messages: 120047
nosy: bbrazil
priority: normal
severity: normal
status: open
title: Fix resource warnings in test_smtplib
versions: Python 3.3
Added file: http://bugs.python.org/file19444/test_smtplib_fd_leak.patch

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

From report at bugs.python.org  Sun Oct 31 16:03:33 2010
From: report at bugs.python.org (Brian Brazil)
Date: Sun, 31 Oct 2010 15:03:33 +0000
Subject: [New-bugs-announce] [issue10265] Fix fd leak in sunau
In-Reply-To: <1288537413.19.0.268070514121.issue10265@psf.upfronthosting.co.za>
Message-ID: <1288537413.19.0.268070514121.issue10265@psf.upfronthosting.co.za>


New submission from Brian Brazil <brian.brazil at gmail.com>:

Please see attached.

It's possible that this change will lead to fds leaking if someone is passing in a fd, however a) this is consistent with how other modules (e.g. uu) do it and b) of the 2 (!) uses of this module I found on Google Codesearch, both pass in filenames.

----------
components: Library (Lib)
messages: 120049
nosy: bbrazil
priority: normal
severity: normal
status: open
title: Fix fd leak in sunau
versions: Python 3.3

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

From report at bugs.python.org  Sun Oct 31 16:16:08 2010
From: report at bugs.python.org (Brian Brazil)
Date: Sun, 31 Oct 2010 15:16:08 +0000
Subject: [New-bugs-announce] [issue10266] uu.decode fd leak if in_file is a
	filename
In-Reply-To: <1288538168.63.0.84193162166.issue10266@psf.upfronthosting.co.za>
Message-ID: <1288538168.63.0.84193162166.issue10266@psf.upfronthosting.co.za>


New submission from Brian Brazil <brian.brazil at gmail.com>:

I missed this when fixing issue 10246. The attached patch fixes this and adds a test that produces a resource warning with the old code.

----------
components: Library (Lib)
files: uu_decode_fd_leak.patch
keywords: patch
messages: 120054
nosy: bbrazil
priority: normal
severity: normal
status: open
title: uu.decode fd leak if in_file is a filename
versions: Python 3.3
Added file: http://bugs.python.org/file19445/uu_decode_fd_leak.patch

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

From report at bugs.python.org  Sun Oct 31 17:25:06 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 31 Oct 2010 16:25:06 +0000
Subject: [New-bugs-announce] [issue10267] test_ttk_guionly leaks many
	references
In-Reply-To: <1288542306.75.0.249495592657.issue10267@psf.upfronthosting.co.za>
Message-ID: <1288542306.75.0.249495592657.issue10267@psf.upfronthosting.co.za>


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

This can be seen on all 3 branches:

$ ./python -m test.regrtest -uall -R 3:2 test_ttk_guionly
[306/349] test_ttk_guionly
beginning 5 repetitions
12345
.....
test_ttk_guionly leaked [590, 590] references, sum=1180

----------
components: Tkinter
messages: 120067
nosy: gpolo, pitrou
priority: high
severity: normal
status: open
title: test_ttk_guionly leaks many references
type: resource usage
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun Oct 31 18:07:11 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 31 Oct 2010 17:07:11 +0000
Subject: [New-bugs-announce] [issue10268] Add
	--enable-loadable-sqlite-extensions option to	`configure`
In-Reply-To: <1288544831.28.0.692302384707.issue10268@psf.upfronthosting.co.za>
Message-ID: <1288544831.28.0.692302384707.issue10268@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

I would like to suggest introduction of --enable-loadable-sqlite-extensions option, so that packagers (and maybe other users) don't need to comment out 1 line in setup.py. I'm attaching the patch.

----------
components: Build
files: python-loadable-sqlite-extensions.patch
keywords: patch
messages: 120069
nosy: Arfrever, ghaering
priority: normal
severity: normal
status: open
title: Add --enable-loadable-sqlite-extensions option to `configure`
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file19448/python-loadable-sqlite-extensions.patch

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

From report at bugs.python.org  Sun Oct 31 19:21:01 2010
From: report at bugs.python.org (Brian Brazil)
Date: Sun, 31 Oct 2010 18:21:01 +0000
Subject: [New-bugs-announce] [issue10269] Fix some resource warnings in
	test_sax
In-Reply-To: <1288549261.81.0.692632435193.issue10269@psf.upfronthosting.co.za>
Message-ID: <1288549261.81.0.692632435193.issue10269@psf.upfronthosting.co.za>


New submission from Brian Brazil <brian.brazil at gmail.com>:

Please see attached.

----------
components: Tests
files: test_sax_fd_leak.patch
keywords: patch
messages: 120077
nosy: bbrazil
priority: normal
severity: normal
status: open
title: Fix some resource warnings in test_sax
versions: Python 3.3
Added file: http://bugs.python.org/file19449/test_sax_fd_leak.patch

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

From report at bugs.python.org  Sun Oct 31 19:30:42 2010
From: report at bugs.python.org (Brian Brazil)
Date: Sun, 31 Oct 2010 18:30:42 +0000
Subject: [New-bugs-announce] [issue10270] Fix resource warnings in
	test_threading
In-Reply-To: <1288549842.1.0.819549161722.issue10270@psf.upfronthosting.co.za>
Message-ID: <1288549842.1.0.819549161722.issue10270@psf.upfronthosting.co.za>


New submission from Brian Brazil <brian.brazil at gmail.com>:

Please see attached.

----------
components: Tests
files: test_threading_fd_leak.patch
keywords: patch
messages: 120079
nosy: bbrazil
priority: normal
severity: normal
status: open
title: Fix resource warnings in test_threading
Added file: http://bugs.python.org/file19450/test_threading_fd_leak.patch

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

From report at bugs.python.org  Sun Oct 31 19:53:35 2010
From: report at bugs.python.org (lekma)
Date: Sun, 31 Oct 2010 18:53:35 +0000
Subject: [New-bugs-announce] [issue10271] warnings.showwarning should allow
	any callable object
In-Reply-To: <1288551215.82.0.402250167562.issue10271@psf.upfronthosting.co.za>
Message-ID: <1288551215.82.0.402250167562.issue10271@psf.upfronthosting.co.za>


New submission from lekma <lekmalek at gmail.com>:

Overriding warnings.showwarning() with a c/python module function (from a c/python module) doesn't work because warn_explicit() only allow PyFunction or PyMethod objects to be called (unfortunately c/python module functions are of type PyCFunction).

Suggested changes in _warnings.c (from py3k) - not tested at all:

from:
412            if (!PyMethod_Check(show_fxn) && !PyFunction_Check(show_fxn)) {
413                PyErr_SetString(PyExc_TypeError,
414                                "warnings.showwarning() must be set to a "
415                                "function or method");

to:
412            if (!PyCallable_Check(show_fxn)) {
413                PyErr_SetString(PyExc_TypeError,
414                                "warnings.showwarning() must be set to a "
415                                "callable");

----------
components: Library (Lib)
messages: 120080
nosy: lekma
priority: normal
severity: normal
status: open
title: warnings.showwarning should allow any callable object
type: feature request
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun Oct 31 22:43:53 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 31 Oct 2010 21:43:53 +0000
Subject: [New-bugs-announce] [issue10272] SSL handshake timeouts not caught
	by transient_internet
In-Reply-To: <1288561433.38.0.641849376879.issue10272@psf.upfronthosting.co.za>
Message-ID: <1288561433.38.0.641849376879.issue10272@psf.upfronthosting.co.za>


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

The issue here is that ssl is using its own exception class rather than the socket module's "timeout" class:

test test_httplib failed -- Traceback (most recent call last):
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/test/test_httplib.py", line 408, in test_networked
    h.request('GET', '/')
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/http/client.py", line 943, in request
    self._send_request(method, url, body, headers)
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/http/client.py", line 981, in _send_request
    self.endheaders(body)
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/http/client.py", line 939, in endheaders
    self._send_output(message_body)
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/http/client.py", line 791, in _send_output
    self.send(msg)
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/http/client.py", line 737, in send
    self.connect()
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/http/client.py", line 1086, in connect
    server_hostname=server_hostname)
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/ssl.py", line 168, in wrap_socket
    _context=self)
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/ssl.py", line 254, in __init__
    raise x
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/ssl.py", line 250, in __init__
    self.do_handshake()
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/ssl.py", line 429, in do_handshake
    self._sslobj.do_handshake()
ssl.SSLError: _ssl.c:374: The handshake operation timed out

----------
components: Tests
messages: 120090
nosy: pitrou
priority: low
severity: normal
status: open
title: SSL handshake timeouts not caught by transient_internet
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

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